Payment System

Abstract

To provide a mechanism that realizes as low fraud risk in off-line settlement as in on-line settlement.SOLUTION: In on-line settlement processing, a settlement server calculates off-line remittance constraint information. In off-line settlement processing, it is determined whether remittance between settlement terminals is possible on the basis of off-line remittance constraint information calculated by the settlement server.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a payment system and a payment method. [Background technology]

[0002] Patent Document 1 is a background technology in this technical field. Patent Document 1 states that "In a payment system, a payment management device (payment server) comprises: means for acquiring a payment request indicating the transaction amount and transaction status; means for determining whether to request approval of the payment from the payer according to the transaction amount and transaction status indicated in the acquired payment request; means for requesting approval from the payer's terminal via a network if it is determined that approval is required; and means for processing the payment if the payment is approved at the payer's terminal" (see abstract). [Prior art documents] [Patent documents]

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

[0004] The above-mentioned Patent Document 1 describes a payment method that reduces the risk of fraud. However, the technology described in the above-mentioned Patent Document 1 is a mechanism that assumes online payments (payments realized through communication between an end-user terminal and a payment server), and has the problem that it cannot adequately handle offline payments (payments realized through direct communication between end-user terminals, assuming a situation where the internet line is down due to a disaster or other reason and connection to the payment server cannot be made).

[0005] Specifically, the technology stores payment history information, which is input information for fraud risk confirmation and analysis, on a server, but in the case of offline payments, the server cannot be accessed and the input information cannot be used.

[0006] One solution would be to have a copy of the payment history information stored on the end user's device, but when considering more complex fraud risk analysis (for example, analysis using artificial intelligence that makes combined use of the payment history information of the end user and other end users), it is not realistic to implement this on the device from the perspective of data volume and computing resources.

[0007] The present invention aims to provide a mechanism for reducing fraud risks in offline payments to a degree equivalent to that of online payments. [Means for solving the problem]

[0008] One aspect of the present invention provides a payment system having a payment server that manages the balances of users' funds, and a plurality of payment terminals that transmit and receive remittance instructions and remittance results to and from the payment server, wherein the payment terminals have a remittance result confirmation unit that requests and obtains information on the balance and remittance history of the user of the payment terminal from the payment server, a remittance instruction creation unit that creates and sends a remittance instruction message to the payment server, an offline remittance instruction creation unit that creates and sends an inter-terminal remittance message to another payment terminal without going through the payment server, an offline remittance instruction verification unit that verifies the validity of the inter-terminal remittance message sent via the offline remittance instruction creation unit based on specified conditions, an offline remittance instruction reflection unit that records the inter-terminal remittance message that the offline remittance instruction verification unit determines to be valid, and an offline remittance result notification unit that transmits the inter-terminal remittance message recorded by the offline remittance instruction reflection unit to the payment server.

[0009] A payment method according to one aspect of the present invention is a payment method in a payment system having a payment server that manages the balance of users' funds and a plurality of payment terminals that send and receive remittance instructions and remittance results to and from the payment server, and comprises: an online payment process that realizes remittance by rewriting the balance managed by the payment server; and an offline payment process that realizes remittance between the plurality of payment terminals through direct communication between the payment terminals, wherein the online payment process comprises an offline remittance constraint calculation step in which the payment server calculates predetermined offline remittance constraint information, and the offline payment process comprises an offline remittance constraint reflection step in which the payment server determines whether the remittance between the payment terminals is possible based on the offline remittance constraint information calculated by the payment server. [Effects of the Invention]

[0010] According to one aspect of the present invention, it is possible to reduce the risk of fraud in offline payments to a degree equivalent to that of online payments. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a diagram illustrating an example of a configuration of a payment system. [Figure 2] 1 is a diagram illustrating an example of a hardware configuration of a payment server. [Figure 3] 1 is a diagram illustrating an example of a hardware configuration of a payment terminal. [Figure 4] 1 is a diagram illustrating an example of a software configuration of a payment server. [Figure 5] 1 is a diagram illustrating an example of a software configuration of a payment terminal. [Figure 6] 1 is an example of a flowchart illustrating online payment in a payment system. [Figure 7] 10 is an example of an image diagram illustrating a personal balance. [Figure 8] 10 is an example of an image diagram illustrating a process for creating a remittance instruction. [Figure 9] 10A and 10B are diagrams illustrating examples of user information according to the present embodiment. [Figure 10] 10 is an example of an image diagram illustrating a user balance in this embodiment. FIG. [Figure 11] 10 is an example of an image diagram illustrating a user remittance history in this embodiment. [Figure 12] 10A and 10B are examples of image diagrams illustrating the process of verifying the eligibility of a remittance instruction in this embodiment. [Figure 13] 10A and 10B are examples of conceptual diagrams illustrating a process for reflecting the contents of a remittance instruction in this embodiment. [Figure 14] 10 is an example of an image diagram illustrating a confirmation-waiting remittance instruction according to this embodiment. [Figure 15] 10A and 10B are examples of conceptual diagrams illustrating a process for reflecting the contents of a remittance instruction in this embodiment. [Figure 16] 10A and 10B are diagrams illustrating examples of user offline remittance restrictions according to the present embodiment. [Figure 17] 10A and 10B are diagrams illustrating an example of an image illustrating a process for updating a user offline remittance restriction in the present embodiment. [Figure 18] 10 is an example of a flowchart illustrating a process for creating a new record of a user offline remittance restriction according to an embodiment of the present invention. [Figure 19] 10 is an example of an image diagram illustrating a process in which the offline remittance constraint calculation function of the present embodiment categorizes a group of records. [Figure 20] 10 is an example of an image diagram illustrating a process in which the offline remittance constraint calculation function of the present embodiment calculates the remaining available amount. [Figure 21] 10 is an example of an image diagram illustrating a process in which the offline remittance constraint calculation function of the present embodiment records the remaining available amount. [Figure 22] 10 is an example of an image diagram illustrating the process of adjusting the remaining available amount when the balance is sufficient for the remaining available amount, in the process in which the offline remittance constraint calculation function of this embodiment adjusts the remaining available amount. FIG. [Figure 23] 10 is an example of an image diagram illustrating the process of adjusting the remaining available amount when the balance is sufficient for the remaining available amount, in the process in which the offline remittance constraint calculation function of this embodiment adjusts the remaining available amount. FIG. [Figure 24]10 is an example of an image diagram illustrating a process in which the offline remittance restriction calculation function of this embodiment updates information on the remittance range in the offline remittance restriction information. [Figure 25] 10A and 10B are diagrams illustrating examples of information to be transmitted to the payment terminal. [Figure 26] 10 is an example of an image diagram illustrating the process in which the remittance result confirmation function reflects the online processing result. [Figure 27] 10 is an example of an image diagram illustrating a self offline remittance balance. [Figure 28] 10 is an example of an image diagram illustrating a process in which the offline remittance restriction reflection function reflects the online processing results. [Figure 29] 10 is an example of a flowchart illustrating offline payment in the payment system of the present embodiment. [Figure 30] 10A and 10B are diagrams illustrating an example of an image illustrating a process for creating an offline remittance instruction according to the present embodiment. [Figure 31] 10A and 10B are examples of image diagrams illustrating a process for verifying the eligibility of an offline remittance instruction in this embodiment. [Figure 32] 10 is an example of an image diagram illustrating a self offline payment history 523 according to the present embodiment. [Figure 33] 10 is an example of an image diagram illustrating the process of the offline remittance instruction reflection function of the remittance source settlement terminal of this embodiment reflecting the contents of the offline remittance instruction. FIG. [Figure 34] 10 is an example of an image diagram illustrating the process of reflecting the contents of an offline remittance instruction by the offline remittance instruction reflection function of the remittee's settlement terminal in this embodiment. FIG. [Figure 35] 10 is an example of an image diagram illustrating the process of reflecting the contents of an offline remittance instruction by the offline remittance instruction reflection function of the remittee's settlement terminal in this embodiment. FIG. [Figure 36] 10 is an example of a flowchart illustrating synchronization of offline payment results with a payment server in the payment system of the present embodiment. [Figure 37] 10A and 10B are examples of image diagrams illustrating a process for verifying the eligibility of a received offline remittance history in this embodiment. [Figure 38] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. [Figure 39] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. [Figure 40] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. [Figure 41] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. [Figure 42] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. [Figure 43] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. [Figure 44] 10A and 10B are diagrams illustrating an example of a process for reflecting received offline remittance history in the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, an embodiment will be described with reference to the drawings. [Example]

[0013] In this embodiment, an example of a payment system will be described.

[0014] FIG. 1 is a diagram showing an example of the configuration of a payment system according to this embodiment. Payment system 100 includes a payment server and multiple payment terminals. In this embodiment, payment system 100 is composed of payment server 110 and payment terminals 120, 130, and 140. Payment system 110 is connected to payment terminals 120, 130, and 140 via a communication path such as the Internet so that data can be exchanged between them. Payment terminals 120, 130, and 140 are owned and operated by different users, Users A, B, and X, respectively. If two of payment terminals 120, 130, and 140 are geographically close to each other, short-range wireless communication is performed between the payment terminals to exchange data as necessary.

[0015] It should be noted that, for the payment terminals 120, 130, and 140, a configuration utilizing a secure element or a trusted execution environment may be considered to ensure the security of data and processing on the terminal, but for simplicity, this embodiment will be described using a configuration that does not use these.

[0016] FIG. 2 is a diagram showing an example of the hardware configuration of the payment server 110 of this embodiment. The payment server 110 has a CPU 201, a memory 202, an input interface 203, a communication interface 204, an auxiliary storage device 205, and an output interface 206. In the payment server 110, input devices such as a mouse and a keyboard connected via the input interface 203, and output devices such as a display connected via the output interface 206 are operated by an administrator of the payment system. The payment server 110 is connected to a communication channel such as the Internet via the communication interface 204.

[0017] FIG. 3 is a diagram showing an example of the hardware configuration of the payment terminal 120 of this embodiment. Payment terminal 120 has a CPU 301, memory 302, input interface 303, communication interface 304, auxiliary storage device 305, and output interface 306. Devices such as a touch panel connected to payment terminal 120 via input interface 304 and output interface 306 are operated by user A, the owner of payment terminal 120. Payment terminal 120 connects to a communication channel such as the Internet and performs short-range wireless communication via communication interface 304. Note that in this embodiment, the hardware configuration of payment terminals 130 and 140 is the same as the configuration of payment terminal 120.

[0018] FIG. 4 is an example of a software configuration diagram of the payment server 110 of this embodiment. The settlement server 110 has, as the calculation unit 410, a remittance instruction verification function 411, a remittance instruction reflection function 412, an offline remittance result verification function 413, an offline remittance result reflection function 414, and an offline remittance constraint calculation function 415.

[0019] Furthermore, the payment server 110 has, as a storage unit 420, usage information 421, user balance 422, user remittance history 423, remittance instructions waiting for confirmation 424, and user offline remittance constraints 425. The calculation unit 410 is read into the memory 202 at the time of execution and executed by the CPU 201.

[0020] FIG. 5 is an example of a software configuration diagram of the payment terminal 120 of this embodiment. The payment terminal 120 has, as its calculation unit 510, a remittance result confirmation function 511, a remittance instruction creation function 512, an offline remittance instruction creation function 513, an offline remittance instruction verification function 514, an offline remittance instruction reflection function 515, an offline remittance restriction reflection function 516, and an offline remittance result notification function 517.

[0021] Furthermore, payment terminal 120 has, as memory unit 520, own balance 521, own offline balance 522, and own offline payment history 523. Calculation unit 510 is read into memory 302 at runtime and executed by CPU 301. In this embodiment, the software configuration of payment terminals 130 and 140 is the same as that of payment terminal 120.

[0022] FIG. 6 is an example of a flowchart illustrating online payment in the payment system of this embodiment. Hereinafter, the operation of online payment in payment system 100 will be described with reference to the flowchart in Fig. 6. In this embodiment, a scenario in which user A transfers money to user B will be used as an example.

[0023] Step 600 is a step carried out between the payment server 110 and the payment terminal 120. Information on the result of offline processing in the payment terminal 120 is synchronized with the payment server 110. The operation of step 600 will be described later.

[0024] Step 601 is a step performed by the payment terminal 120 under the operation of user A. In step 601, the remittance instruction creation function 512 of the payment terminal 120 creates a remittance instruction by referencing the information in the user's balance 521 under the instruction of user A, and transmits the remittance instruction to the payment server 110. The transmission is performed via the communication interface 304 of the payment terminal 120 via the Internet or the like.

[0025] FIG. 7 is an example of an image diagram illustrating the personal balance 521 in this embodiment. Own balance 521 has data attributes, ie, an identifier 711 and a balance 712, and has values ​​corresponding to these data attributes. In the example of Fig. 7, the value of identifier 711 is "A" and the value of balance 712 is "500".

[0026] FIG. 8 is an example of an image diagram illustrating the process of creating a remittance instruction in this embodiment. The remittance instruction 800 has data attributes, namely, a remittance source ID 811, a remittance destination ID 812, and an amount 813, and has values ​​corresponding to these data attributes. In the example of Figure 8, the value of the remittance source ID 811 is "A", the value of the remittance destination ID 812 is "B", and the amount 813 is "100".

[0027] When creating the remittance instruction 800, the remittance instruction creation function 512 writes the values ​​entered or selected by user A via the input interface 303 as the values ​​of the remittance destination ID 812 and amount 813. The remittance instruction creation function 512 also writes the value of the identifier 711 of the own balance 521 as the value of the remitter ID 811. Furthermore, the remittance instruction creation function 512 verifies that the value of the amount 813 of the created remittance instruction 800 is lower than the value of the balance 712 of the own balance 521.

[0028] Note that authentication information is required so that the settlement server can confirm that user A himself has created and sent the remittance instruction for user A's balance, but in this embodiment, for simplicity, the processing and description of information related to authentication information are omitted. Note that if user A does not create a remittance instruction in step 601, this is notified to the settlement server 110, and the process proceeds to step 605.

[0029] Steps 602 to 606 are steps performed by the payment server 110. In step 602, the remittance instruction verification function 411 of the payment server 110 verifies the eligibility of the remittance instruction received from the payment terminal 120 by referring to the information in the user information 421, user balance 422, and user remittance history 423.

[0030] FIG. 9 is an example of an image diagram illustrating the user information 421 of this embodiment. The user information 421 has a user ID 911, a name 912, and a caution flag 913 as data attributes. The system administrator operates the payment server 110 to record the values ​​of the above-mentioned data attributes in the user information 421 for all users who access the payment server 110. In the example of Fig. 9, information about user A, user B, and user C is written in the rows where the ID 911 values ​​are "A", "B", and "C", respectively.

[0031] It should be noted that a valid value should be entered for the caution flag 913 in cases where the user is suspected of being involved in a crime and it is necessary to temporarily suspend remittance instructions from the user.

[0032] FIG. 10 is an example of an image diagram illustrating the user balance 422 in this embodiment. The user balance 422 has data attributes such as a user ID 1011, a balance 1012, and an amount in process 1013. The user balance 422 is intended to record the values ​​of the above-mentioned data attributes for all users who access the payment server 110. In the example of Figure 10, information about users A, B, and C is written in the rows where the values ​​of ID 1011 are "A," "B," and "C," respectively.

[0033] FIG. 11 is an example of an image diagram illustrating the user remittance history 423 in this embodiment. The user remittance history 423 has, as data attributes, a remittance source ID 1111, a remittance destination ID 1112, a remittance amount 1113, and a remittance date and time 1114. Note that the values ​​of the remittance source ID 1111 and the remittance destination ID 1112 are assumed to be any of the values ​​of the user ID 911 held by the user information 421.

[0034] FIG. 12 is an example of an image diagram illustrating the process of verifying the eligibility of a remittance instruction in this embodiment. The remittance instruction verification function 411 references the value of the remittance source ID 811 in the remittance instruction 800 received from the payment terminal 120, and extracts record groups 1201, 1202, and 1203 that have the same values ​​of user ID 911, user ID 1011, and remittance source ID 1111 from the information in user information 421, user balance 422, and user payment history 423. Note that the record group 1203 may be narrowed down to those with relatively recent remittance dates and times 1114 (for example, from the past year) from the information in user payment history 423.

[0035] The remittance instruction verification function 411 also references the value of the remittance destination ID 812 in the remittance instruction 800 received from the payment terminal 120, and extracts from the user information 421 a record 1204 having the same user ID 911 value.

[0036] If no records 1201, 1202, 1204 that meet the above conditions are found, the information of the remittance instruction 800 is discarded and the process proceeds to step 605. The remittance instruction verification function 411 also verifies that the value of the balance 1012 of the extracted record 1202 is equal to or greater than the value of the amount 813 of the remittance instruction 800. If the value of the balance 1012 is less than the value of the amount 813, the information of the remittance instruction 800 is discarded and the process proceeds to step 605.

[0037] The remittance instruction verification function 411 also checks that the extracted record 1201 does not have a valid value in the caution flag 913. If a valid value is entered, it determines that the remittance cannot be made immediately and proceeds to step 604.

[0038] The remittance instruction verification function 411 also compares the information in the remittance instruction 800 with the information in the extracted record set 1203 to confirm that it is not an abnormal value. For example, if the value of the amount 813 in the remittance instruction 800 is extremely large compared to the remittance amount 1113 in the record set 1203, it determines that the remittance cannot be made immediately and proceeds to step 604.

[0039] In addition to the above, the remittance instruction verification function 411 may make a judgment based on more advanced analysis (for example, analysis using artificial intelligence using a large amount of data including data of other users).

[0040] If there is no problem in the confirmation process of the remittance instruction 800 based on the information of the extracted record groups 1201, 1202, and 1203, the process proceeds to step 603.

[0041] In step 603 , if there is no problem in the confirmation process in step 602 , the remittance instruction reflection function 412 of the settlement server 110 reflects the contents of the remittance instruction 800 in the user balance 422 and the user remittance history 423 .

[0042] FIG. 13 is an example of an image diagram illustrating the process of reflecting the contents of a remittance instruction in this embodiment. The remittance instruction reflection function 412 extracts from the user balance 422 a record 1301 having the value of the remittance source ID 811 of the remittance instruction 800 as the user ID 1011, and updates the value of the balance 1012 by subtracting the numerical value of the amount 813 of the remittance instruction 800. The remittance instruction reflection function 412 also extracts from the user balance 422 a record 1302 having the value of the remittance destination ID 812 of the remittance instruction 800 as the user ID 1011, and updates the value of the balance 1012 by adding the numerical value of the amount 813 of the remittance instruction 800. The remittance instruction reflection function 412 also adds and records the record 1303 in the user settlement history 423. The remittance source ID 1111, remittance destination ID 1112, remittance amount 1113, and remittance date and time 1114 of record 1303 respectively record the value of the remittance source ID 811 of the remittance instruction 800, the value of the remittance destination ID 812 of the remittance instruction 800, the value of the amount 813 of the remittance instruction 800, and the current date and time.

[0043] In step 604, if the confirmation process in step 602 determines that the remittance cannot be made immediately, the remittance instruction reflection function 412 of the settlement server 110 reflects the contents of the remittance instruction 800 in the user balance 422 and the remittance instruction waiting for confirmation 424.

[0044] FIG. 14 is an example of an image diagram illustrating the confirmation waiting remittance instruction 424 of this embodiment. The confirmation-awaiting remittance instruction 424 has, as data attributes, a remittance source ID 1411, a remittance destination ID 1412, a remittance amount 1413, and a remittance request date and time 1414. The records recorded in the confirmation-awaiting remittance instruction 424 are confirmed by the system administrator, and are then reflected in the user balance 422 and user remittance history 423 in an appropriate manner, and then deleted.

[0045] FIG. 15 is an example of an image diagram illustrating the process of reflecting the contents of a remittance instruction in this embodiment. The remittance instruction reflection function 412 extracts from the user balance 422 a record 1501 having the value of the remittance source ID 811 of the remittance instruction 800 as the user ID 1011, and updates the value of the balance 1012 by subtracting the numerical value of the amount 813 of the remittance instruction 800. The remittance instruction reflection function 412 also updates the value of the processing amount 1013 of the extracted record 1501 by adding the numerical value of the amount 813 of the remittance instruction 800.

[0046] Furthermore, the remittance instruction reflection function 412 adds and records a record 1502 to the remittance instruction waiting for confirmation 424. The remittance source ID 1411, remittance destination ID 1412, remittance amount 1413, and remittance request date and time 1414 of the record 1502 record the value of the remittance source ID 811 of the remittance instruction 800, the value of the remittance destination ID 812 of the remittance instruction 800, the value of the amount 813 of the remittance instruction 800, and the current date and time, respectively.

[0047] In step 605 , the offline remittance constraint calculation function 415 of the settlement server 110 updates the information of the user offline remittance constraint 425 based on the information of the user remittance history 423 .

[0048] FIG. 16 is an example of an image diagram illustrating the user offline remittance constraints 425 of this embodiment. The offline constraint 425 has, as data attributes, a user ID 1611, a fund ID 1612, an amount 1613, a remittance range 1614, an amount in process 1615, and a processed amount 1616. Note that the remittance range 1614 is shown in a simplified diagram for simplicity, but in practice it can be in a format capable of expressing a tree structure (for example, JSON format).

[0049] The remittance range 1614 has, as a value, information on restrictions on the remittance destination of funds. For example, the value 1621 means that remittance can be made from A to F, and from F to the next user, but not beyond that, and also means that if remittance is made from A to a user other than F, remittance beyond that user is not possible.

[0050] FIG. 17 is an example of an image diagram illustrating the process of updating the user offline remittance constraint 425 in this embodiment. The user offline remittance constraint calculation function 415 creates and adds a new record group 1702 to the user offline remittance constraints 425. The values ​​of the processing amount 1615 and processing amount 1616 of the added record group 1702 are all entered as zero. The total value of the amount 1613 of the added record group 1702 is equal to the value of the balance 1012 of the record in the user balance 422 that has the same user ID 1011 value.

[0051] FIG. 18 is an example of a flowchart illustrating the process of creating a new record of user offline remittance restrictions in this embodiment. Hereinafter, the operation of the offline remittance constraint creation process in the offline remittance constraint calculation function 415 will be described based on the flowchart in Fig. 18. In this embodiment, a scenario for creating an offline remittance constraint for user A will be used as an example.

[0052] In step 1801, a starting point for calculating remittance constraints is determined. In this embodiment, since an offline remittance constraint relating to user A is created, user A is selected as the initial starting point.

[0053] In step 1802, the remittance history for the user selected in step 1801 is extracted. The offline remittance constraint calculation function 415 extracts a group of records from the user remittance history 423, where the value of the remittance source ID 1111 is the ID of the user selected in step 1801, and the remittance date and time 1114 is within a specific period. In this embodiment, assuming that the current date and time is "April 2021", a group of records where the value of the remittance source ID 1111 is "A" and the remittance date and time 1114 is between "January 2021" and "April 2021" is extracted.

[0054] In addition, with regard to the remittance history extracted in step 1802, the values ​​of the remittance source ID 1411, remittance destination ID 1412, remittance amount 1413, and remittance request date and time 1414 of the remittance instruction waiting for confirmation 424 may be considered to be the remittance source ID 1111, remittance destination ID 1112, remittance amount 1113, and remittance date and time 1114 of the user remittance history 423, respectively, and may be included in the extraction targets.

[0055] In step 1803, the records of the user payment history 423 extracted in step 1802 are categorized.

[0056] FIG. 19 is an example of an image diagram illustrating the process of categorizing a group of records by the offline remittance constraint calculation function 415 of this embodiment. The offline remittance constraint calculation function 415 sorts the record group 1901, in which the value of the remittance source ID 1111 is "A" and the remittance date and time 1114 is between "January 2021" and "April 2021", into different categories according to the value of the remittance amount 1113. In this embodiment, the records are classified into two categories: category 1902, in which the value of the remittance amount 1113 is "10,000 yen or more", and category 1903, in which the value of the remittance amount 1113 is "less than 10,000 yen".

[0057] For the record set 2001, the values ​​of the remittance source ID 1111, the remittance destination ID 1112, and the remittance amount 1113 may be regarded as the values ​​of the remittance source ID 811, the remittance destination ID 812, and the amount 813 of the remittance instruction 800, respectively, and the eligibility may be verified by the remittance instruction verification function 411. In this case, records whose eligibility cannot be immediately determined as a result of the verification (records for which it is determined that remittance cannot be immediately made) are excluded from the record set 2001.

[0058] In step 1804, the remaining available amount is calculated and recorded based on the information of each category extracted in step 1803.

[0059] FIG. 20 is an example of an image diagram illustrating the process of calculating the remaining available amount by the offline remittance constraint calculation function 415 of this embodiment. The offline remittance constraint calculation function 415 selects category 1902 from the categories extracted in step 1803. Furthermore, the offline remittance constraint calculation function 415 classifies the information in category 1902 into two categories depending on the remittance date and time.

[0060] In this embodiment, assuming that the current date and time is "April 2021," the records are divided into a record group 2001 whose remittance date and time 1114 is between "January 2021" and "March 2021," and a record group 2002 whose remittance date and time 1114 is "April 2021." The offline remittance constraint calculation function then calculates the monthly average of the value of the remittance amount 1113 in the record group 2001, and subtracts the total value of the remittance amount 1113 in the record group 2002 to calculate the remaining available amount.

[0061] In this embodiment, the monthly average amount calculated from the record group 2001 is "350" and the total amount calculated from the record group 2002 is "150", so the remaining usage amount 2003 is calculated as "200".

[0062] FIG. 21 is an example of an image diagram illustrating the process in which the offline remittance constraint calculation function 415 of this embodiment records the remaining available amount. The offline remittance constraint calculation function 415 creates and adds one new record to the offline remittance constraint 2101 being created. In this record, the value of the remittance source ID 1111 from the record group 2001 is entered as the value of the user ID 1611. The offline remittance constraint calculation function 415 calculates and enters a unique value as the value of the funds ID 1612. The value of the remaining available amount 2003 is entered as the value of the amount 1613. For the value of the remittance possible range 1614, the value of the remittance source ID 1111 from the record group 2001 is entered as the remittance source 2011, and the value of the remittance destination ID 1112 from the record group 2002 is entered as the primary remittance destination 2012 with duplicates eliminated. Note that the processing of step 1804 is performed for all categories extracted in step 1803. Note that if the value of the remaining available amount 2003 is zero or a negative value, the processing to record the remaining available amount is not performed.

[0063] In step 1805, the remaining available amount recorded in step 1804 is adjusted based on consistency with the balance information.

[0064] FIG. 22 is an example of an image diagram illustrating the process of adjusting the remaining available amount by the offline remittance constraint calculation function 415 of this embodiment when the balance is sufficient for the remaining available amount.

[0065] In the example of Figure 22, the sum of the values ​​of the amount 1613 in the record group 2101, "20200", is less than the value of the balance 1012 in the user balance, "20800". In this case, a new record 2201 is created and added to the record group 2101. The value of the user ID 1611 in record 2201 is the same as the user ID 1611 in the other records in the record group 2101. The value of the fund ID 1612 is calculated and entered by the offline remittance constraint calculation function 415 as a unique value. The value of the amount 1613 is calculated and entered as the difference between the value of the balance 1012 in the user balance and the sum of the values ​​of the amount 1613 in the record group 2101. For the remittance range, a value that is the same as the user ID 1611 is created and entered as the remitter.

[0066] FIG. 23 is an example of an image diagram illustrating the process of adjusting the remaining available amount by the offline remittance constraint calculation function 415 of this embodiment when the balance is sufficient for the remaining available amount.

[0067] In the example of FIG. 22, the sum of the values ​​of the amount 1613 in the record group 2101, "20200," exceeds the value of the balance 1012 in the user balance, "10100." In this case, the value of the amount 1613 in the record group 2101 is adjusted so that the sum of the values ​​of the amount 1613 in the record group 2101 becomes the same as the value of the balance 1012 in the user balance. In this embodiment, the amount 1613 in the records 2301 and 2302 is updated by allocating the amount "10100" in the balance 1012 according to the ratio of the values ​​of the amount 1613 in the records 2301 and 2302.

[0068] As described above, remittance restriction information for first-order remittance destinations has been calculated through the processing of steps 1801 to 1805. However, if necessary, the process proceeds to step 1806 and subsequent steps to supplement information on second-order and subsequent remittance destinations.

[0069] In step 1806, the remitter (primary remitter) to be targeted for calculation of secondary and subsequent remitter destinations is selected. In this example, the options are "B," "D," and "F" listed as primary remitter destinations in the record set 2101 created in Figure 22, but the following steps will be explained assuming that "B" is selected.

[0070] In step 1807, the remittance history of the user selected in step 1806 is extracted. The processing in this step is the same as that in step 1802.

[0071] In step 1808, the remittance range information of the offline remittance restriction information being created is updated based on the remittance history extracted in step 1807.

[0072] FIG. 24 is an example of an image diagram illustrating the process in which the offline remittance restriction calculation function 415 of this embodiment updates the information on the remittance range in the offline remittance restriction information. The offline remittance constraint calculation function 415 extracts the remittance destination ID 1112 value with duplicates eliminated from the record group 2401 of the user remittance history 423 where the remitter ID 1111 value is "B" extracted in step 1807. Furthermore, the offline remittance constraint calculation function 415 adds the remittance destination ID extracted with duplicates eliminated as described above to the secondary remittance destination for the value of the offline remittance constraint 2101 being created where the primary remittance destination in the remittance possible range 1614 is "B".

[0073] By carrying out the above steps 1806 to 1808 for the first remittance destination and for the second and subsequent remittance destinations as necessary, the offline remittance constraint creation process is completed.

[0074] Returning to the flowchart of FIG. 6, the remaining operations of online payment in payment system 100 will be described. In step 606, the payment server 110 creates information about the processing results of step 602, step 603 or 604, and step 605, and transmits it to the payment terminal 120. The transmission is performed via the communication interface 204 of the payment server 110, via the Internet, etc.

[0075] FIG. 25 is an example of an image diagram illustrating information to be transmitted to the payment terminal 120. In FIG. In step 606, record 2501 is transmitted in which the value of user ID 1011 in user balance 422 matches the value of user ID 811 in remittance instruction 800. Also in step 606, information is transmitted for record 1303 in user payment history 423 added in step 603, or record 1502 in remittance instruction waiting for confirmation 424 added in step 604. Furthermore, in step 606, a group of records 1702 added in step 605 from user offline remittance constraints 425 is transmitted.

[0076] Step 607 is a step performed by the payment terminal 120. In step 607, the remittance result confirmation function 511 and the offline remittance restriction reflection function 516 update the information of the own balance 521 and the own offline balance 522 based on the information transmitted from the payment server in step 607.

[0077] FIG. 26 is an example of an image diagram illustrating the process in which the remittance result confirmation function 511 reflects the online processing result. The remittance result confirmation function 511 overwrites the information of the balance 712 of the own balance 521 with the value of the balance 1012 of the record 2501 sent from the settlement server in step 606 .

[0078] FIG. 27 is an example of an image diagram illustrating the self-offline remittance balance. The self offline remittance balance 522 has, as data attributes, a user ID 2711, a fund ID 2712, an amount 2713, a remittable range, and a remittance record 2714. The values ​​of the user ID 2711, fund ID 2712, and amount 2713 are the same as the values ​​of the user ID 1611, fund ID 1612, and amount 1613 of the user offline remittance constraints.

[0079] The values ​​of remittance range and remittance record 2714 include information equivalent to the value of remittance range 1614 in the user offline remittance constraints, as well as information on remittance record. In the example of Figure 27, elements with solid and diagonal lines indicate remittances that have been completed, and elements with dotted and white lines indicate remittances that have not yet been completed, and for all records, remittances have been completed up to "A."

[0080] FIG. 28 is an example of an image diagram illustrating the process in which the offline remittance restriction reflection function 516 reflects the online processing result. The offline remittance constraint reflection function 516 creates a record group for the user's offline balance 522 that has the values ​​of the user ID 1611, fund ID 1612, amount 1613, and remittance range 1614 of the user's offline remittance constraint record group 2502 as the user ID 2711, fund ID 2712, amount 2713, remittance range, and remittance record 2714, respectively, and overwrites the information in the user's offline balance 522.

[0081] Next, we will explain the operation of offline payments in the payment system of this embodiment. In offline payments in the payment system of this embodiment, by utilizing the information on the own offline balance created in the steps described above, strictness equivalent to that of the remittance instruction verification function 411 of the payment server 110 can be ensured even in offline payments between terminals.

[0082] Figure 29 is an example of a flowchart illustrating offline payment in the payment system of this embodiment. Hereinafter, the operation of offline payment in payment system 100 will be explained based on the flowchart in Figure 29. In this embodiment, a scenario in which user A transfers money to user B is used as an example.

[0083] Step 2901 is a step performed by the payment terminal 120 under the operation of user A. In step 2901, the offline remittance instruction creation function 513 of the payment terminal 120 creates an offline remittance instruction by referencing the information in the own offline balance 522 under the instruction of user A, and transmits the offline remittance instruction to the payment terminal 130. The transmission is performed via the communication interface 304 of the payment terminal 120 by short-range wireless communication or the like.

[0084] FIG. 30 is an example of an image diagram illustrating the process of creating an offline remittance instruction in this embodiment. The offline remittance instruction 3000 has, as data attributes, a user ID 3011, a fund ID 3012, an amount 3013, a remittable range and remittance record 3014, a remittance source 3015, and a remittance destination 3016.

[0085] When creating the offline remittance instruction 3000, the offline remittance instruction creation function 513 writes the values ​​entered or selected by user A via the input interface 303 as the values ​​for user ID 3011, fund ID 3012, amount 3013, and remittance destination ID 3016.

[0086] The offline remittance instruction creation function 513 also writes the value of the identifier 711 of the own balance 521 as the value of the remittance source ID 3015. Furthermore, the offline remittance instruction creation function 513 extracts, from the information of the own offline balance 522, a record in which the values ​​of the user ID 2711 and the funds ID 2712 match the values ​​of the user ID 3011 and the funds ID 3012, respectively, and confirms that the value of the amount 2713 of said record is equal to or greater than the value of the amount 3013 of the offline remittance instruction 3000, and transcribes the values ​​of the remittance range and remittance record 2714 of said record as the values ​​of the remittance range and remittance record 3014 of the offline remittance instruction 3000.

[0087] In addition, information is required to enable the recipient's payment terminal 130 and payment server 110 to confirm that User A himself created and sent the remittance instruction for User A's balance, but in this embodiment, for simplicity's sake, the description of the processing and information related to this will be omitted.

[0088] Steps 2902 and 2903 are steps that are performed by the payment terminal 130 under the operation of user B.

[0089] In step 2902, the offline remittance instruction verification function 514 of the payment terminal 130 verifies the validity of the offline remittance instruction received from the payment terminal 130.

[0090] FIG. 31 is an example of an image diagram illustrating the process of verifying the eligibility of an offline remittance instruction in this embodiment. The offline remittance instruction verification function 514 references the value of the remittance destination ID 3016 in the offline remittance instruction 3000 received from the settlement terminal 120 and verifies that it is the same as the value of the identifier 711 of the own balance 521 .

[0091] In step 2903, the offline remittance instruction verification function 514 of the payment terminal 130, under the instruction of user B, determines whether to accept the offline remittance instruction received from the payment terminal 130. If acceptance is approved, the offline remittance instruction verification function 514 transmits information to the payment terminal 120 indicating acceptance, and proceeds to step 2904.

[0092] As a result of accepting the offline remittance instruction 3000, the degree of freedom of the balance that will ultimately be added to the settlement terminal 130's own offline balance 522 varies depending on the remittance range of the offline remittance instruction 3000 and the value of the remittance record 3014. Step 2903 is provided because User B needs to be able to confirm the degree of freedom before accepting the instruction.

[0093] Step 2904 is a step performed by the payment terminals 120 and 130. In step 2094, the offline remittance instruction reflection function 515 of the payment terminals 120 and 130 reflects the contents of the offline remittance instruction 3000 in the own balance 521, own offline balance 522, and own offline payment history 523.

[0094] FIG. 32 is an example of an image diagram illustrating the own offline payment history 523 in this embodiment. The own offline payment history 523 has a remittance source ID 3211, a remittance destination ID 3212, a remittance amount 3213, a user ID 3214, a fund ID 3215, and a remittance date and time 3216 as data attributes.

[0095] FIG. 33 is an example of an image diagram illustrating the process in which the offline remittance instruction reflecting function 515 of the remittance source settlement terminal 120 of this embodiment reflects the contents of the offline remittance instruction 3000. The offline remittance instruction reflection function 515 subtracts the value of the balance 712 of the own balance 521 by the value of the amount 3013 of the offline remittance instruction 3000 .

[0096] Furthermore, the offline remittance instruction reflection function 515 creates and adds a record of its own offline payment history. In the added record, the values ​​of remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, user ID 3214, and fund ID 3215 are respectively input with the values ​​of remittance source ID 3015, remittance destination ID 3016, amount 3013, user ID 3011, and fund ID 3012 of online remittance instruction 3000. In addition, the value of remittance date and time 3216 is input with the current date and time.

[0097] Furthermore, the offline remittance instruction reflection function 515 extracts records from the information in the own offline balance 522 in which the values ​​of the user ID 2711 and the fund ID 2712 respectively match the values ​​of the user ID 3011 and the fund ID 3012 of the offline remittance instruction 3000, and subtracts the value of the amount 2713 of the relevant record by the value of the amount 3013 of the offline remittance instruction 3000. Note that if the value of the amount 2713 becomes zero as a result of the subtraction, the relevant record itself is deleted.

[0098] FIG. 34 is an example of an image diagram illustrating the process in which the offline remittance instruction reflecting function 515 of the remittance destination settlement terminal 130 of this embodiment reflects the contents of the offline remittance instruction 3000. The offline remittance instruction reflection function 515 adds the value of the balance 712 of the own balance 521 by the value of the amount 3013 of the offline remittance instruction 3000 .

[0099] Furthermore, the offline remittance instruction reflection function 515 creates and adds a record of its own offline payment history. In the added record, the values ​​of remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, user ID 3214, and fund ID 3215 are respectively input with the values ​​of remittance source ID 3015, remittance destination ID 3016, amount 3013, user ID 3011, and fund ID 3012 of the offline remittance instruction 3000. In addition, the value of remittance date and time 3216 is input with the current date and time.

[0100] In addition, the offline remittance instruction reflection function 515 extracts records from the information of the own offline balance 522 in which the values ​​of the user ID 2711 and the fund ID 2712 match the values ​​of the user ID 3011 and the fund ID 3012 of the offline remittance instruction 3000, and adds the value of the amount 2713 of the record in question by the value of the amount 3013 of the offline remittance instruction 3000.

[0101] If no record that meets the above conditions is found, the offline remittance instruction reflection function 515 creates and adds a record to the own offline balance 522. In the record to be added, the values ​​of the user ID 2711, fund ID 2712, amount 2713, remittable range, and remittance record 2714 are respectively input as the user ID 3011, fund ID 3012, amount 3013, remittable range, and remittance record 3014 of the offline remittance instruction 3000. Thereafter, if the input value of remittance record 2714 contains a portion that corresponds to the value of remittance source ID 3015 to the value of remittance destination ID 3016 of the offline remittance instruction 3000 as a remittance route that is available but has no record (in the figure, if there is a dotted arrow from "A" to "B"), this is selected and the record information is added (in the figure, the arrow from "A" to "B" and "B" are changed to solid lines).

[0102] If there is no part in the entered value of remittance record 2714 that meets the above conditions, select the part of the entered value of remittance record 2714 that indicates a remittance without a remittance destination from the part with the value of remittance source ID 3015 of offline remittance instruction 3000 (in the figure, an arrow with no end point from ``A'') and add the actual information (change it to a solid line in the figure).

[0103] Figure 35 is an example of an image diagram illustrating the process in which the offline remittance instruction reflection function 515 of the remittance destination payment terminal 130 in this embodiment reflects the contents of the offline remittance instruction 3000. The example in Figure 35 assumes the case in Figure 34 where user B receives funds from user A and then remits them to user X.

[0104] Next, a process for synchronizing the offline payment result with the payment server in the payment system of this embodiment will be described. This process corresponds to step 600 in FIG.

[0105] 36 is an example of a flowchart illustrating synchronization of offline payment results with the payment server in the payment system of this embodiment. Hereinafter, the offline payment operation in payment system 100 will be described based on the flowchart in FIG.

[0106] In this embodiment, a scenario is used as an example in which information on offline remittance from user A to user B shown in Figures 33 and 34, and offline remittance from user B to user X shown in Figure 35, is synchronized with the payment server 110.

[0107] Step 3601 is a step performed by the payment terminal 120, 130, or 140. In step 3601, the offline remittance result notification function 517 of the payment terminal 120, 130, or 140 transmits information in the own offline remittance history 523 to the payment server 110. The transmission is performed via the communication interface 304 of the payment terminal, via Internet communication or the like. When it is confirmed that the transmission has been completed successfully, the offline remittance result notification function 517 deletes all information in the own offline remittance history 523.

[0108] Steps 3602 to 3611 are steps performed by the payment server 110. In step 3602, the offline remittance result verification function 413 of the payment server 110 extracts one record from the information of the user offline remittance constraints 425 that has the user ID of the payment terminal that sent the information as the value of user ID 1611, and selects the value of user ID 1611 and the value of fund ID 1612 of that record.

[0109] The processing from step 3603 to step 3606 is carried out for all user ID and fund ID values ​​of all records with the user ID value. In step 3603, the offline remittance result verification function 413 of the settlement server 110 extracts and selects records from the information on the own offline remittance history received in step 3601 that have the values ​​of the user ID and fund ID selected in step 3602 as the values ​​of the user ID 3214 and fund ID 3215, respectively. If no matching records are found, step 3604 is skipped and the process proceeds to step 3605.

[0110] In step 3604, the offline remittance result verification function 413 of the payment server 110 verifies the eligibility of the information of the user's offline remittance history selected in step 3603 by referring to the information in the user information 421, user balance 422, user remittance history 423, and user offline remittance constraints 425.

[0111] Figure 37 is an example of an image diagram illustrating the process of verifying the eligibility of the received offline remittance history in this embodiment. In Figure 37, the following cases are assumed. In step 3601, the information on the result of offline remittance from user A to user B shown in FIG.

[0112] In step 3602, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0113] The offline remittance result verification function 413 references the value of the user ID 3215 selected in step 3602, and extracts records 3701 and 3702 having the same values ​​of user ID 911 and user ID 1011, respectively, from the information of the user information 421 and user balance 422. If records 3701 and 3702 that meet the above conditions are not found, the information of the selected user ID 3215 and fund ID 3216 is notified to the system administrator, and then the process proceeds to step 3602 and continues processing for the next user ID and fund ID.

[0114] The offline remittance result verification function 413 also checks that the extracted record 3701 does not have a valid value in the caution flag 913. If a valid value is entered, it determines that the remittance cannot be made immediately and proceeds to step 3606.

[0115] Additionally, the offline remittance result verification function 413 verifies that the value of the balance 1012 of the extracted record 3702 is equal to or greater than the value of the remittance amount 3213 of the selected own offline payment history 3700. If the value of the balance 1012 is less than the value of the remittance amount 3213, the information of the selected own offline remittance history 3700 is notified to the system administrator, and then the process proceeds to step 3602, where the process continues for the next user ID and fund ID.

[0116] Furthermore, the offline remittance result verification function 413 references the values ​​of the user ID 3215 and fund ID 3216 selected in step 3602, and extracts a record 3703 having the same values ​​of the user ID 1611 and fund ID 1612 from the information of the user offline constraints 425. If no record 3703 that meets the above conditions is found, the information of the selected user ID 3215 and fund ID 3216 is notified to the system administrator, and then the process proceeds to step 3602, where the process continues for the next user ID and fund ID.

[0117] Additionally, the offline remittance result verification function 413 verifies that the value of the amount 1613 of the extracted record 3703 is equal to or greater than the value of the remittance amount 3213 of the selected own offline payment history 3700. If the value of the amount 1613 is less than the value of the remittance amount 3213, the information of the selected own offline remittance history 3700 is notified to the system administrator, and then the process proceeds to step 3602, where the process continues for the next user ID and fund ID.

[0118] The offline remittance result verification function 413 also verifies that the value of the remittance possible range 1614 of the user offline remittance constraints of the extracted record 3703 includes the value of the remittance source ID 3211 of the selected own offline payment history 3700. If the value of the remittance possible range 1614 does not include the value of the remittance source ID 3211, the system administrator is notified of the information of the selected own offline remittance history 3700, and the process proceeds to step 3602, where the process continues for the next user ID and fund ID.

[0119] Furthermore, the offline remittance result verification function 413 references the values ​​of the remittance source ID 3211 and the remittance destination ID 3212 in the own offline payment history 3700 selected in step 3603, and extracts a record group 3706 having the same values ​​of the remittance source ID 1111 and the remittance destination ID 1112 from the information in the user payment history 423. Note that the record group 3706 may be narrowed down to those with relatively recent remittance dates and times 1114 from the information in the user payment history 423 (for example, from the past year).

[0120] In addition to the above, the offline remittance result verification function 413 may also make a judgment based on more advanced analysis (for example, analysis using artificial intelligence using large amounts of data including data from other users). If there are no problems with the above confirmation processing, proceed to step 3605.

[0121] In step 3605, if there are no problems in the confirmation process in step 3604, the offline remittance result reflection function 414 of the payment server 110 reflects the contents of the selected own offline payment history 3700 to the user balance 422, user remittance history 423, and user offline remittance constraints 425.

[0122] Figure 38 is an example of an image diagram illustrating the process of reflecting the received offline remittance history in this embodiment. Figure 38 assumes the following cases. In step 3601, the information on the result of offline remittance from user A to user B shown in FIG. In step 3602, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0123] The offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance source ID 3211 is "A". Furthermore, the offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance destination ID 3212 is "A". The amount that has flowed out of "A" is calculated by taking the difference between the former total amount and the latter total amount. In the example of Figure 38, the value calculated is "110".

[0124] Furthermore, the offline remittance result reflection function 414 extracts, from the information in the user offline remittance constraints 425, a record 3803 in which the value of the user ID 1611 is "A" and the value of the funds ID 1612 is "A001." If it is confirmed that the amounts in the processing amount 1615 and processed amount 1616 are "0," it updates the values ​​of the amount 1613 and processing amount 1615 to "110." Furthermore, for the value of processed amount 1616 of said record 3803, it enters "90," which is the value obtained by subtracting "110" from the initial amount 1613 value of "200."

[0125] Furthermore, the offline remittance result reflection function 414 extracts record 3801 whose user ID 1011 value is "A" from the information of user balance 422, subtracts "110" from the value of balance 1012, and adds "110" to the value of amount in process 1013.

[0126] Furthermore, the offline remittance result reflection function 414 adds a record group 3802 to the information in the user payment history 423. In the records to be added, the remittance source ID 1111, remittance destination ID 1112, remittance amount 1113, and remittance date and time 1114 are set to the values ​​of the remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, and remittance date and time 3216 of the selected offline payment history 3700, respectively. However, if the same record already exists in the user payment history 423, no addition is made.

[0127] Figure 39 is an example of an image diagram illustrating the process of reflecting the received offline remittance history in this embodiment. Figure 39 assumes the following cases. In step 3601, the information on the result of offline remittance from user A to user B shown in FIG.

[0128] In step 3602, "A" is selected as the value of the user ID 3214, and "A002" is selected as the value of the fund ID 3215. In the case of Fig. 39, the selected own offline payment history 3700 does not include any records.

[0129] In this case, unlike the case of FIG. 38, the offline remittance result reflecting function 414 does not add or update the user balance 422 and user payment history 423.

[0130] The offline remittance result reflection function 414 extracts record 3901 whose user ID 1611 value is "A" and whose fund ID 1612 value is "A002" from the information in user offline remittance constraints 425, confirms that the amounts in processing 1615 and processed amount 1616 are "0", and updates the values ​​of the amount 1613 and processing amount 1615 to "0". Furthermore, as the value of processed amount 1616 of record 3803, it enters "20000", which is the original value of amount 1613. Note that if the values ​​of processing amount 1615 and processed amount 1616 of record 3901 were not "0" before the update, the update process is not performed, and the information of the selected self offline remittance history 3700 is notified to the system administrator, and then the process proceeds to step 3602 and continues processing for the next user ID and fund ID.

[0131] Figure 40 is an example of an image diagram illustrating the process of reflecting the received offline remittance history in this embodiment. In Figure 39, the following case is assumed. Information on the result of offline remittance from user B to user X shown in FIG. 35 was previously sent to the server 110 via user X's terminal 140 and has been reflected (steps 3607 and onwards).

[0132] In step 3601, the information on the result of offline remittance from user A to user B shown in FIG.

[0133] In step 3602, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0134] The offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance source ID 3211 is "A". Furthermore, the offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance destination ID 3212 is "A". The amount that has flowed out of "A" is calculated by taking the difference between the former total amount and the latter total amount. In the example of Figure 38, the value calculated is "110".

[0135] Furthermore, the offline remittance result reflection function 414 extracts, from the information of the user offline remittance constraints 425, a record 4004 in which the value of the user ID 1611 is "A" and the value of the funds ID 1612 is "A001." If it is confirmed that the value of the processing amount 1615 is "0" and the amount of the processed amount 1616 is not "0," it calculates the difference between the aforementioned "110" and the value of the processed amount 1616. In the example of Figure 38, the value calculated is "30."

[0136] Furthermore, the offline remittance result reflection function 414 updates the values ​​of the amount 1613 and the amount in process 1615 of the record 4004 to the aforementioned "30".

[0137] Furthermore, the offline remittance result reflection function 414 updates the value of the processed amount 1616 of the record 4004 by adding "90" to it. The value "90" is calculated by subtracting the aforementioned "110" from the sum of "120", which is the value of the amount 1613 before the update, and "80", which is the value of the processed amount 1616.

[0138] If the values ​​of the amount 1613 and the amount in process 1615 become zero as a result of the above processing, the record 4004 is deleted.

[0139] Furthermore, the offline remittance result reflection function 414 extracts record 4001 whose user ID 1011 value is "A" from the information in user balance 422, subtracts "30" from the value of balance 1012, and adds "30" to the value of amount in process 1013.

[0140] Furthermore, the offline remittance result reflection function 414 adds a record group 4002 to the information in the user payment history 423. In the records to be added, the remittance source ID 1111, remittance destination ID 1112, remittance amount 1113, and remittance date and time 1114 are set to the values ​​of the remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, and remittance date and time 3216 of the selected offline payment history 3700, respectively. However, if the same record already exists in the user payment history 423, no addition is made.

[0141] In step 3606, if the verification process in step 3604 determines that the remittance cannot be made immediately, the offline remittance result reflection function 414 of the payment server 110 reflects the contents of the selected self offline remittance result 3700 in the user balance 422 and the remittance instruction waiting for confirmation 424.

[0142] Fig. 41 is an example of an image diagram illustrating the process of reflecting the received offline remittance history 3700 in this embodiment. In Fig. 41, the following cases are assumed. In step 3601, the information on the result of offline remittance from user A to user B shown in FIG.

[0143] In step 3602, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0144] The remittance instruction reflection function 412 adds and records a record 4101 to the remittance instruction waiting for confirmation 424. The remittance source ID 1411, remittance destination ID 1412, remittance amount 1413, and remittance request date and time 1414 of the record 1502 respectively record the values ​​of the remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, and remittance date and time 3216 of the selected self offline remittance result 412.

[0145] Furthermore, the remittance instruction reflection function 412 updates the information of the user balance 422 and the user offline remittance constraints 425 in the same manner as in the case of FIG.

[0146] In step 3607, the offline remittance result verification function 413 of the payment server 110 extracts one record from the information 3700 of the own offline remittance history received in step 3601 that does not have the value of the user ID of the payment terminal that sent the information as the value of the user ID 3211, and selects the value of the user ID 3211 and the value of the funds ID 3212 of that record.

[0147] The processing from step 3608 to step 36011 is performed for all user ID and fund ID values ​​of all records with the user ID value.

[0148] In step 3608, the offline remittance result verification function 413 of the payment server 110 extracts and selects records from the information of the self offline remittance history 3700 received in step 3601 that have the values ​​of the user ID and fund ID selected in step 3607 as the values ​​of user ID 3214 and fund ID 3215, respectively.

[0149] In step 3609, the offline remittance result verification function 413 of the payment server 110 verifies the eligibility of the information of the user's offline remittance history selected in step 3608 by referring to the information in the user information 421, user balance 422, user remittance history 423, and user offline remittance constraints 425.

[0150] The operation in step 3609 is basically the same as that in step 3604. However, if there are no problems in the confirmation process, the process proceeds to step 3610, if it is determined that the remittance cannot be made immediately, the process proceeds to step 3611, and if any other problems are found, the process proceeds to step 3607.

[0151] In step 3610, if there are no problems in the confirmation process in step 3609, the offline remittance result reflection function 414 of the payment server 110 reflects the contents of the selected own offline payment history 3700 to the user balance 422, user remittance history 423, and user offline remittance constraints 425.

[0152] Figure 42 is an example of an image diagram illustrating the process of reflecting the received offline remittance history in this embodiment. Figure 42 assumes the following cases. In step 3601, the information on the result of offline remittance from user B to user X shown in FIG. In step 3607, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0153] The offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance source ID 3211 is "X". Furthermore, the offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance destination ID 3212 is "X". By taking the difference between the latter total and the former total, the amount that flowed into "X" as a net amount is calculated. In the example of Figure 42, the value calculated is "80".

[0154] Furthermore, the offline remittance result reflection function 414 extracts a record 4204 in which the value of the user ID 1611 is "A" and the value of the fund ID 1612 is "A001" from the information in the user offline remittance constraints 425. If it is confirmed that the amount in process 1615 and the amount processed 1616 are "0", it subtracts "80" from the value of the amount 1613 and updates the value of the processed amount 1616 to "80".

[0155] Furthermore, the offline remittance result reflection function 414 extracts record 4201 in which the value of user ID 1011 is "A" and record 4202 in which the value is "X" from the information of user balance 422. It subtracts "80" from the value of balance 1012 of record 4201 and adds "80" to the value of balance 1012 of record 4202.

[0156] Furthermore, the offline remittance result reflection function 414 adds a record group 4203 to the information in the user payment history 423. In the added record, the remittance source ID 1111, remittance destination ID 1112, remittance amount 1113, and remittance date and time 1114 are set to the values ​​of the remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, and remittance date and time 3216 of the selected offline payment history 3700, respectively. However, if the same record already exists in the user payment history 423, no addition is made.

[0157] Figure 43 is an example of an image diagram explaining the process of reflecting the received offline remittance history in this embodiment. In Figure 42, the following case is assumed. The processing content is basically the same as the example in Figure 42. In step 3601, the information on the offline remittance result of User B shown in FIGS. 34 and 35 is received from User B's terminal 130. In step 3607, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0158] Figure 44 is an example of an image diagram illustrating the process of reflecting the received offline remittance history in this embodiment. Figure 44 assumes the following cases. Information on the result of offline remittance from user A to user B shown in FIG. 33 has been sent in advance via user A's terminal 120 to server 110 and has been reflected (steps 3602 and onwards).

[0159] In step 3601, the information on the result of offline remittance from user B to user X shown in FIG.

[0160] In step 3607, "A" is selected as the value of the user ID 3214, and "A001" is selected as the value of the fund ID 3215.

[0161] The offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance source ID 3211 is "X". Furthermore, the offline remittance result reflection function 414 calculates the total remittance amount 3213 for the group of records in the selected own offline payment history 3700 where the remittance destination ID 3212 is "X". By taking the difference between the latter total and the former total, the amount that flowed into "X" as a net amount is calculated. In the example of Figure 42, the value calculated is "80".

[0162] Furthermore, the offline remittance result reflection function 414 extracts a record 4404 in which the value of the user ID 1611 is "A" and the value of the fund ID 1612 is "A001" from the information of the user offline remittance constraints 425. If it is confirmed that the amounts in the processing amount 1615 and processed amount 1616 are not "0", it subtracts "80" from the values ​​of the amount 1613 and processing amount 1615 and adds "80" to the value of the processed amount 1616 to update it.

[0163] Furthermore, the offline remittance result reflection function 414 extracts, from the information of the user balance 422, record 4401 in which the value of user ID 1011 is "A" and record 4402 in which the value is "X." If it is confirmed that the value of the processing amount 1013 in record 4401 is not zero, it subtracts "80" from the value of the processing amount 1013 in record 4401 and adds "80" to the value of balance 1012 in record 4202.

[0164] Furthermore, the offline remittance result reflection function 414 adds a record group 4403 to the information in the user payment history 423. In the records to be added, the remittance source ID 3211, remittance destination ID 3212, remittance amount 3213, and remittance date and time 3216 of the selected offline payment history 3700 are entered as the values ​​of the remittance source ID 1111, remittance destination ID 1112, remittance amount 1113, and remittance date and time 1114, respectively. However, if the same record already exists in the user payment history 423, no addition is made.

[0165] In step 3611, if the verification process in step 3607 determines that immediate remittance is not possible, the offline remittance result reflection function 414 of the settlement server 110 reflects the contents of the selected own offline remittance result 3700 in the user balance 422 and remittance instruction waiting for confirmation 424. The processing content of this step is the same as that of step 3606.

[0166] As described above, the payment system 100 of the above embodiment includes a payment server 110 that manages the user's balance of funds, and multiple payment terminals 120, 130, and 140 that send and receive remittance instructions and remittance results to and from the payment server 110.

[0167] The payment terminal 120 has a remittance result confirmation unit 511 that requests and obtains information on the balance and remittance history of the user of the payment terminal 120 from the payment server 110, a remittance instruction creation unit 512 that creates and sends a remittance instruction message to the payment server 110, an offline remittance instruction creation unit 513 that creates and sends an inter-terminal remittance message to the other payment terminals 130, 140 without going through the payment server 110, an offline remittance instruction verification unit 514 that verifies the validity of the inter-terminal remittance message sent via the offline remittance instruction creation unit 513 based on specified conditions, an offline remittance instruction reflection unit 515 that records the inter-terminal remittance message that the offline remittance instruction verification unit 514 determines to be valid, and an offline remittance result notification unit 517 that sends the inter-terminal remittance message recorded by the offline remittance instruction reflection unit 515 to the payment server 110.

[0168] The settlement server 110 also has a remittance instruction verification unit 411 that verifies the validity of the remittance instruction message sent by the remittance instruction creation unit 512 of the settlement terminal 120 based on the specified conditions, a remittance instruction reflection unit 412 that updates the balance and remittance history of the user based on the remittance instruction message verified by the remittance instruction verification unit 411, an offline remittance result verification unit 413 that verifies the validity of the terminal-to-terminal remittance message sent by the offline remittance result notification unit 517 of the settlement terminal 120 based on the specified conditions, and an offline remittance result reflection unit 414 that updates the balance and remittance history of the user based on the terminal-to-terminal remittance message verified by the offline remittance result verification unit 413.

[0169] Here, the specified conditions for verifying the validity of the terminal-to-terminal remittance message include a condition that the balance of the user is not insufficient for the remittance amount stated in the terminal-to-terminal remittance message.

[0170] The specified conditions for verifying the validity of the terminal-to-terminal remittance message include a remittance limit specified for each remittance destination for the user who is the remitter. The settlement server 110 has an offline remittance constraint calculation unit 415 that calculates the remittance limit specified for each remittance destination.

[0171] The remittance result confirmation unit 511 of the payment terminal 120 receives information on the upper limit of remittance specified for each remittance destination, together with information on the user's balance and remittance history, from the payment server 110. The payment terminal 120 has an offline remittance constraint reflection unit 516 that associates the information on the upper limit of remittance specified for each remittance destination with information on the user's balance and manages it. Here, the terminal-to-terminal remittance message includes information on the upper limit of remittance specified for each remittance destination.

[0172] In addition, the offline remittance constraint calculation unit 415 of the payment server 110 calculates the remittance destination and actual remittance amount of the user based on the remittance history recorded by the remittance instruction reflection unit 412 and the offline remittance result reflection unit 414 of the payment server 110, and calculates information on the upper limit of remittance amount specified for each remittance destination of the user based on the remittance destination and the actual remittance amount.

[0173] Furthermore, the specified conditions for verifying the validity of the terminal-to-terminal remittance message include conditions related to the remittance range that specifies the range of remittance destinations for the user who is the remitter. The information on the upper limit of remittance amount specified for each remittance destination calculated by the offline remittance constraint calculation unit 415 of the payment server 110 is determined according to the upper limit of remittance amount. When updating the balance, the offline remittance instruction reflection unit 515 of the payment terminal 120 also updates information on the upper limit of remittance amount specified for each remittance destination.

[0174] Furthermore, when the offline remittance instruction reflecting unit 515 of the payment terminal 120 has not received the inter-terminal remittance message from the payment terminal of the final recipient of the series of inter-terminal remittances, it writes the amount for which the final recipient is unknown as the amount for which the final recipient is unknown in the information on the user's balance, and when information on the amount for which the final recipient is unknown exists, when the inter-terminal remittance message is received from the payment terminal of the final recipient, it transfers the amount for which the final recipient is unknown to the amount currently available to the user.

[0175] Furthermore, the terminal-to-terminal remittance message includes information identifying the user who is the starting point of a series of terminal-to-terminal remittances. When the offline remittance instruction reflecting unit 515 of the payment terminal 120 has not received the terminal-to-terminal remittance message from the payment terminal of the user who is the starting point of a series of terminal-to-terminal remittances, and has received the terminal-to-terminal remittance message from the final recipient, the offline remittance instruction reflecting unit 515 transfers funds from the balance of the user who is the starting point to the balance of the user who is the final recipient based on the information identifying the user who is the starting point.

[0176] By incorporating the present invention into practical applications in financial payment systems, it becomes possible to achieve fraud risk reduction equivalent to that of online payments even in offline payments. [Explanation of symbols]

[0177] 100 Payment Systems 110 Payment Server 120 payment terminals 130 payment terminals 140 payment terminals

Claims

1. A payment system having a payment server that manages the balances of funds of multiple users, and multiple payment terminals that transmit and receive remittance instructions and remittance results to and from the payment server, Each of the payment terminals a storage unit that stores a personal offline balance; a remittance result confirmation unit that requests and acquires information on the balance and remittance history of the user of the payment terminal from the payment server; a remittance instruction creation unit that creates and transmits a remittance instruction message to the settlement server; an offline remittance instruction creation unit that creates and transmits an inter-terminal remittance message to another of the payment terminals by direct communication between the payment terminals without going through the payment server; an offline remittance instruction verification unit that verifies the validity of the terminal-to-terminal remittance message transmitted via the offline remittance instruction creation unit based on specified conditions; an offline remittance instruction reflecting unit that records the terminal-to-terminal remittance message that the offline remittance instruction verifying unit has determined to be valid; an offline remittance result notifying unit that transmits the inter-terminal remittance message recorded by the offline remittance instruction reflecting unit to the settlement server; and The payment server a remittance instruction verification unit that verifies the validity of the remittance instruction message sent by the remittance instruction creation unit of the payment terminal based on the specified conditions; a remittance instruction reflecting unit that updates the balance and the remittance history of the user based on the remittance instruction message verified by the remittance instruction verifying unit; an offline remittance result verification unit that verifies the validity of the terminal-to-terminal remittance message transmitted by the offline remittance result notification unit of the payment terminal based on the specified conditions; an offline remittance result reflecting unit that updates the balance and the remittance history of the user based on the terminal-to-terminal remittance message verified by the offline remittance result verifying unit, The plurality of payment terminals include: a first payment terminal operated by a first user; a second payment terminal operated by a second user different from the first user; The offline remittance instruction creation unit of the first payment terminal creating the inter-terminal remittance message by referring to the information on the user's own offline balance under the instruction of the first user, and transmitting the inter-terminal remittance message to the second payment terminal; The offline remittance instruction verification unit of the second payment terminal Verify the validity of the received terminal-to-terminal remittance message; Under the instruction of the second user, determine whether or not to accept the received terminal-to-terminal remittance message; If the acceptance is accepted, information indicating acceptance is transmitted to the first payment terminal; The offline remittance instruction reflecting unit of the first payment terminal and the second payment terminal includes: A settlement system characterized in that the contents of the terminal-to-terminal remittance message are reflected in the user's own offline balance.

2. The payment system according to claim 1, The specified conditions for verifying the validity of the end-to-end remittance message are: Including the upper limit of remittance specified for the user who is the remitter, The payment server an offline remittance constraint calculation unit that calculates the upper limit amount; The remittance result confirmation unit of the payment terminal receiving information on the upper limit amount together with information on the user's balance and remittance history from the payment server; The payment terminal is an offline remittance restriction reflecting unit that associates the information on the upper limit with the information on the balance of the user and manages the information; The terminal-to-terminal remittance message is A payment system characterized by including information regarding the upper limit amount.

3. The payment system according to claim 2, The offline remittance constraint calculation unit of the payment server Calculating the remittance destination and actual remittance amount of the user based on the remittance history recorded by the remittance instruction reflecting unit and the offline remittance result reflecting unit of the settlement server; A settlement system characterized by calculating information on the user's upper limit amount based on the remittance destination and the actual remittance amount.

4. The payment system according to claim 3, The specified conditions for verifying the validity of the end-to-end remittance message are: conditions regarding the remittance range that specifies the range of remittance destinations for the user who is the remitter, the information on the upper limit calculated by the offline remittance constraint calculation unit of the payment server is determined according to the remittance possible range, The offline remittance instruction reflecting unit of the payment terminal A payment system characterized in that, when updating the balance, information regarding the upper limit is also updated.

Images