Information processing system, information processing method and program

Abstract

An information processing system, an information processing method, and a program are provided that can improve the processing efficiency of payment processing. [Solution] The information processing system includes at least one processor that executes the following steps: receiving a payment request including multiple pieces of payment data from a terminal device, shuffling the multiple pieces of payment data included in the payment request, allocating the shuffled multiple pieces of payment data to multiple threads, and performing a payment based on the multiple pieces of payment data by outputting the multiple pieces of payment data allocated to the multiple threads in parallel for each thread.

Description

[Technical Field]

[0001] The present invention relates to an information processing system, an information processing method, and a program. [Background technology]

[0002] Conventionally, an information processing system has been disclosed that performs payments by outputting payment data corresponding to the purchase of goods or services, as shown in Patent Document 1. In such an information processing system, when performing payments based on a large amount of payment data, the system is configured to allocate the payment data to multiple threads and output the data in parallel. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6957711 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in such an information processing system, it may take a long time for some of the multiple threads to complete the settlement. [Means for solving the problem]

[0005] An information processing system that solves the above problem is an information processing system having at least one processor, which receives a payment request including multiple payment data from a terminal device, shuffles the multiple payment data included in the payment request, allocates the shuffled multiple payment data to multiple threads, and performs payment based on the multiple payment data by outputting the multiple payment data allocated to the multiple threads in parallel for each of the multiple threads.

[0006] An information processing method that solves the above problem includes at least one processor receiving a payment request including multiple payment data from a terminal device, shuffling the multiple payment data included in the payment request, allocating the shuffled multiple payment data to multiple threads, and performing payment based on the multiple payment data by outputting the allocated multiple payment data in parallel to each of the multiple threads.

[0007] A program for solving the above problem causes at least one processor to receive a payment request including multiple payment data from a terminal device, shuffle the multiple payment data included in the payment request, allocate the shuffled multiple payment data to multiple threads, and perform payment based on the multiple payment data by outputting the multiple payment data allocated to the multiple threads in parallel for each of the multiple threads. [Effects of the Invention]

[0008] According to the present invention, the processing efficiency of the payment process can be improved. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram showing the overall configuration of an information processing system according to the first embodiment. [Figure 2] FIG. 2 is a diagram showing the payment request database of the first embodiment. [Figure 3] FIG. 3 is a diagram showing the payment management database of the first embodiment. [Figure 4] FIG. 4 is a diagram showing control details regarding payment data in the first embodiment. [Figure 5] FIG. 5 is a flowchart showing the payment request management process according to the first embodiment. [Figure 6] FIG. 6 is a flowchart showing the payment control process according to the first embodiment. [Figure 7]FIG. 7 is a flowchart showing the payment result management process according to the first embodiment. [Figure 8] FIG. 8 is a flowchart showing the payment control process according to the second embodiment. [Figure 9] FIG. 9 is a flowchart showing the payment control process according to the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] [First embodiment] An embodiment of an information processing system, an information processing method, and a program will be described. <Configuration of Information Processing System 10> As shown in FIG. 1, the information processing system 10 is a system for making payments. In particular, the information processing system 10 is a system for making periodic payments. Periodic payments are payments that are made periodically or continuously. Periodic payments may be, for example, daily, weekly, monthly, or annual payments.

[0011] The information processing system 10 includes an information processing device 11. The information processing system 10 may include a payment gateway 12. The information processing system 10 may include a payment agency server 13 and a payment server 14. The information processing system 10 may include a plurality of payment agency servers 13 and a plurality of payment servers 14. The information processing system 10 may include a terminal device 19.

[0012] In response to a payment request from the terminal device 19, the information processing device 11 causes the payment server 14 to make a payment via the payment gateway 12 and the payment agent server 13. In particular, the information processing device 11 causes the payment server 14 to make a payment in response to a periodic payment request from the terminal device 19. The payment request includes at least one piece of payment data. The payment data is data related to the payment details for one payment.

[0013] The information processing device 11 outputs payment data to the payment gateway 12. The information processing device 11 includes multiple threads. The information processing device 11 can output payment data sequentially and in parallel via the multiple threads.

[0014] The information processing device 11 receives the payment result from the payment server 14 via the payment gateway 12 and the payment agent server 13. The information processing device 11 transmits the payment result to the terminal device 19.

[0015] Based on the payment data from the information processing device 11, the payment gateway 12 causes the payment server 14 to make the payment via the payment agent server 13. The payment gateway 12 receives payment data output in parallel from multiple threads in the information processing device 11. The payment gateway 12 receives the payment result from the payment server 14 via the payment agent server 13. The information processing device 11 transmits the payment result to the information processing device 11.

[0016] The payment agent server 13 performs payment on behalf of the customer. The payment agent server 13 receives payment data from the terminal device 19 via the information processing device 11 and the payment gateway 12. The payment agent server 13 transmits the payment data to the payment server 14 corresponding to the payment data. The payment agent server 13 receives the payment result from the payment server 14. The payment agent server 13 transmits the payment result to the payment gateway 12. The payment agent server 13 may be managed by an administrator of the payment agent company.

[0017] The payment server 14 is a server that performs payment. The payment server 14 receives payment data from the terminal device 19 via the information processing device 11, the payment gateway 12, and the payment agent server 13. The payment server 14 performs payment based on the payment data. The payment server 14 transmits the payment result to the payment agent server 13. The payment server 14 may be managed by an administrator of the issuer of the credit card.

[0018] The terminal device 19 makes a payment request. The terminal device 19 transmits a payment request to the information processing device 11. The terminal device 19 receives a payment result corresponding to the payment request from the information processing device 11. The terminal device 19 may be managed by the person requesting the payment who made the payment request.

[0019] The information processing device 11, payment gateway 12, payment agency server 13, payment server 14, and terminal device 19 may be able to communicate with each other via a network (not shown). Hereinafter, explanations of communication between the information processing device 11, payment gateway 12, payment agency server 13, payment server 14, and terminal device 19 via a network will be omitted.

[0020] <Configuration of information processing device 11> The information processing device 11 may be realized by at least one computer. The information processing device 11 includes at least one processor 20 and at least one memory 21. The information processing device 11 includes a communication interface 22. In the drawing, the interface is indicated as I / F.

[0021] The processor 20 controls the information processing device 11. The processor 20 is configured to execute processing based on a program 26 stored in the memory 21. The processor 20 may be a CPU (Central Processing Unit), a GPU (Graphic Processing Unit), or an NPU (Neural Network Processing Unit). The processor 20 may include an integrated circuit, such as an application specific integrated circuit, or may be an integrated circuit. The processor 20 may be a combination of these.

[0022] The memory 21 is configured to store a program 26. The memory 21 is a non-transitory computer-readable medium that stores the program 26, but may also include a temporary computer-readable medium. Here, the non-transitory computer-readable medium includes, for example, a magnetic recording medium, a magneto-optical medium, or a semiconductor memory such as a RAM (Random Access Memory). The program 26 may include a dedicated application for using the information processing system 10. The memory 21 stores a database 27. The memory 21 may also be composed of multiple types of non-transitory computer-readable media. For example, the memory 21 may be composed of a magnetic recording medium and a semiconductor memory.

[0023] The communication interface 22 is implemented as hardware, software, or a combination thereof. The communication interface 22 transmits and receives data between the payment gateway 12 and the terminal device 19. The information processing device 11 may also include an input device and a display device.

[0024] The payment gateway 12, payment agent server 13, payment server 14, and terminal device 19 are configured in the same manner as the information processing device 11. Therefore, descriptions of the processors, memories, and communication interfaces provided in the payment gateway 12, payment agent server 13, payment server 14, and terminal device 19 will be omitted.

[0025] <Data structure of Database 27> 2, a payment request database 30 is stored as a database 27 in the memory 21 of the information processing device 11. The payment request database 30 is a database for managing payment requests.

[0026] The payment request database 30 includes at least one data set 30A. Data set 30A associates a request identifier, a requester identifier, payment conditions, the number of payments, and a request type. In the figure, the identifier is indicated as ID.

[0027] The request identifier is data that can identify a payment request. The requester identifier is data that can identify the requester who made the payment request. The payment conditions indicate the conditions for making a payment based on the payment request. The payment conditions may include the payment date for making a payment based on a periodic payment request, or may include the payment date and time. The number of payments is data that indicates the number of payment data included in one payment request. The number of payments may be data that can be set by the requester.

[0028] The request type is data indicating the type of payment request. The request type may include a normal type, a high-speed type, and a low-speed type. The normal type is a type of payment request that includes multiple payment data regardless of processing speed. The high-speed type is a type of payment request that includes multiple payment data with a high processing speed. The low-speed type is a type of payment request that includes multiple payment data with a low processing speed. The request type may be data that can be set by the requester.

[0029] 3, a payment management database 31 is stored as a database 27 in the memory 21 of the information processing device 11. The payment management database 31 is a database related to payment data included in a payment request.

[0030] The payment management database 31 includes at least one data set 31A. Data set 31A associates a request identifier, a payment identifier, a thread identifier, a payment recipient identifier, a payment method, a payment amount, a payment token, a management flag, and a status.

[0031] The payment identifier is data that can identify the payment data. The thread identifier is data that can identify the thread for outputting the payment data to the payment gateway 12. The payment method is data indicating the payment method. The payment method may include multiple payment methods. The payment method may include credit card payment and point payment, or a method that combines credit card payment and point payment. When either credit card payment or point payment is used, the processing speed is faster than when both credit card payment and point payment are used. The payment amount may include at least either the amount to be paid or the points to be paid.

[0032] The payment token is data obtained by tokenizing an identifier for payment. The identifier for payment may include a number associated with a credit card or a number associated with a point card.

[0033] The management flag is data for managing payment data. The management flag may be data that can identify whether the processing speed of the payment process is fast or slow. The management flag may also be data that indicates whether the payment will be invalid. Data that will result in an invalid payment will not actually execute the payment process. Therefore, data that will result in an invalid payment will have a faster processing speed than data that will result in a valid payment.

[0034] The management flag may include data indicating whether the validity period of the credit card has expired. The management flag may include data indicating whether the credit card's maximum credit limit has been reached. The management flag may be data set by the client.

[0035] The status is data indicating the progress of the payment process. The status may include at least one of preparing, waiting for output, waiting for result, waiting for reply, and completed. The preparing status is a status in which preparation for output of payment data is being made after receiving a payment request. The output waiting status is a status in which preparation for output of payment data is complete and an instruction to output the payment data is awaiting. The result waiting status is a status in which output of payment data is complete and awaiting reception of payment results based on the payment data. The reply waiting status is a status in which payment results based on the payment data have been received and an instruction to return the payment results based on the payment data to terminal device 19 is awaiting. The reply waiting status may include data that can identify the payment results based on the payment data. The completed status is a status in which a return of the payment results based on the payment data to terminal device 19 has been completed.

[0036] <Control details regarding payment data> Here, with reference to FIG. 4, the control content relating to the payment data included in the payment request will be described.

[0037] As shown in Fig. 4, a payment request sent from terminal device 19 to information processing device 11 contains multiple pieces of payment data in an arbitrary order. To facilitate understanding of the invention, the following description will be given using an example in which the payment request contains four pieces of payment data.

[0038] A payment request contains two pieces of payment data with slow processing speeds and two pieces of payment data with fast processing speeds. The payment data with slow processing speeds and the payment data with fast processing speeds tend to be stored in a grouped order.

[0039] In information processing device 11, multiple pieces of payment data are distributed among multiple threads and output to payment gateway 12. For example, the first half of the payment data and the second half of the payment data may be distributed to different threads. In this way, the multiple pieces of payment data are output sequentially in parallel among multiple threads.

[0040] In such cases, if payment data with slow processing speeds and payment data with fast processing speeds are stored in a grouped order, the slow and fast processing data may be unevenly distributed across multiple threads, resulting in a concentration of slow processing data in some of the multiple threads.

[0041] For this reason, in this embodiment, the multiple payment data included in a payment request are shuffled and then assigned to multiple threads. This prevents the multiple threads from being unevenly assigned to payment data with slow processing speeds and payment data with fast processing speeds. This prevents the concentration of payment data with slow processing speeds in some of the multiple threads. This improves the processing efficiency of the payment process.

[0042] <Payment request management processing> The payment request management process will be described with reference to Fig. 5. The payment request management process is executed by the processor 20 at predetermined intervals.

[0043] As shown in Fig. 5, in step S10, the processor 20 determines whether or not a payment request has been received from the terminal device 19. If the processor 20 determines that a payment request has not been received from the terminal device 19, it terminates the payment request management process. If the processor 20 determines that a payment request has been received from the terminal device 19, it proceeds to step S11. In this way, the processor 20 receives a payment request including multiple payment data from the terminal device 19.

[0044] In step S11, processor 20 executes a payment request registration process. In this process, processor 20 stores the payment request in memory 21. Processor 20 generates a request identifier corresponding to the payment request. Processor 20 reads out the requester identifier, payment conditions, payment quantity, and request type contained in the payment request. Processor 20 associates the request identifier, requester identifier, payment conditions, payment quantity, and request type and registers them in the payment request database 30.

[0045] Processor 20 generates a payment identifier corresponding to the payment data included in the payment request. Processor 20 reads the payment recipient identifier, payment method, payment amount, payment token, and management flag included in the payment data. Processor 20 associates the request identifier, payment identifier, payment recipient identifier, payment method, payment amount, payment token, and management flag for each of the multiple payment data included in the payment request and registers them in the payment management database 31. Processor 20 registers a preparation status in the payment management database 31 so as to correspond to all of the multiple payment data included in the payment request.

[0046] <Payment control processing> The payment control process will be described with reference to Fig. 6. The payment control process is executed by the processor 20 at predetermined intervals.

[0047] As shown in Fig. 6, in step S20, processor 20 determines whether the payment conditions have been met. Processor 20 refers to payment request database 30 and determines whether the payment conditions have been met based on the payment conditions registered in payment request database 30. The payment conditions are met when the payment date for the periodic payment arrives.

[0048] If the processor 20 determines that the payment conditions are not met, the processor 20 ends the payment control process. If the processor 20 determines that the payment conditions are met, the processor 20 proceeds to step S21.

[0049] In step S21, processor 20 executes a payment data acquisition process. In this process, processor 20 reads multiple pieces of payment data included in a payment request for which the payment conditions have been met from memory 21. As a result, processor 20 acquires multiple pieces of payment data.

[0050] In step S22, processor 20 executes a payment data shuffling process. In this process, processor 20 shuffles the order of the multiple payment data acquired in step S21. In this manner, processor 20 shuffles the multiple payment data included in the payment request.

[0051] In step S23, processor 20 executes a payment data allocation process. In this process, processor 20 allocates the multiple payment data shuffled in step S22 to multiple threads. Based on the result of allocating the multiple payment data to threads, processor 20 registers a thread identifier in payment request database 30 so that it corresponds to the payment identifier. Processor 20 registers an output waiting status in payment management database 31 so that it corresponds to the payment data allocated to one of the multiple threads.

[0052] In step S24, processor 20 executes a payment data output process. In this process, processor 20 references payment management database 31 and outputs payment data corresponding to the thread identifier for each of the multiple threads. Processor 20 may also output payment data corresponding to the thread identifier for each of the multiple threads by calling the API (application programming interface) of payment gateway 12. This allows processor 20 to output payment data to payment gateway 12 in parallel for each of the multiple threads. Processor 20 registers a result waiting status in payment management database 31 corresponding to the payment data output to one of the multiple threads.

[0053] In step S25, processor 20 determines whether the output of all payment data included in the payment request has been completed. In this process, processor 20 determines that the output of all payment data included in the payment request has been completed when the status of all payment data included in the payment request in payment management database 31 has become an output status.

[0054] If processor 20 determines that the output of all payment data included in the payment request has not been completed, it proceeds to step S24. If processor 20 determines that the output of all payment data included in the payment request has been completed, it terminates the payment control process.

[0055] In this way, the processor 20 performs a payment based on the plurality of payment data by sequentially outputting the plurality of payment data allocated to each of the plurality of threads in parallel for each of the plurality of threads.

[0056] <Payment result management processing> The payment result management process will be described with reference to Fig. 7. The payment result management process is executed by the processor 20 at predetermined intervals.

[0057] As shown in Figure 7, in step S40, processor 20 determines whether or not a payment result corresponding to the payment data has been received from payment gateway 12. If processor 20 determines that a payment result has not been received from payment gateway 12, it proceeds to step S42. If processor 20 determines that a payment result has been received from payment gateway 12, it proceeds to step S41. In this way, processor 20 obtains a payment result for each of the multiple payment data.

[0058] In step S41, processor 20 executes a payment result registration process. In this process, processor 20 registers a reply waiting status in payment management database 31 so as to correspond to the payment data for which the payment result has been received. Processor 20 registers data that can identify the payment result as a status in payment management database 31 so as to correspond to the payment data for which the payment result has been received.

[0059] In step S42, processor 20 determines whether or not it has received the payment results for all the payment data included in the payment request. If processor 20 determines that it has not received the payment results for all the payment data included in the payment request, it terminates the payment result management process. If processor 20 determines that it has received the payment results for all the payment data included in the payment request, it proceeds to step S43.

[0060] In step S43, processor 20 executes a payment result transmission process. In this process, processor 20 transmits the payment results of all payment data to terminal device 19. In this way, when processor 20 obtains all payment results corresponding to the multiple payment data included in the payment request, it transmits all payment results to terminal device 19. Processor 20 registers a completion status in payment management database 31 so that the completion status corresponds to all of the payment data for which the payment results have been returned to terminal device 19.

[0061] <Actions and Effects of the First Embodiment> The operation and effects of the first embodiment will be described. (1-1) Processor 20 shuffles the multiple payment data included in the payment request and distributes the shuffled multiple payment data among multiple threads. Processor 20 performs payment based on the multiple payment data by outputting the multiple payment data distributed among the multiple threads in parallel for each thread. This configuration can prevent a bias between payment data with slow processing speeds and payment data with fast processing speeds among the multiple threads. This can prevent a concentration of payment data with slow processing speeds in some of the multiple threads. This can prevent a bias in the time it takes to complete payment among the multiple threads. This can improve the processing efficiency of payment processing.

[0062] (1-2) When processor 20 acquires all payment results corresponding to the multiple payment data included in the payment request, processor 20 transmits all payment results to terminal device 19. This reduces the time required to acquire all payment results corresponding to the multiple payment data included in the payment request. This reduces the time required to transmit all payment results to terminal device 19. This improves the processing efficiency of the payment process.

[0063] [Second embodiment] Next, a second embodiment will be described. In the following description, the same components as those in the already described embodiment will be assigned the same reference numerals, and redundant description will be omitted or simplified.

[0064] <Payment control processing> As shown in FIG. 8, in the second embodiment, in the payment control process, when step S21 is completed, processor 20 proceeds to step S26. In step S26, processor 20 determines whether the division condition is met. The division condition can be met when the number of multiple payment data included in the payment request is equal to or greater than a second threshold. The second threshold corresponds to the number of payment data that does not excessively increase the control load due to shuffling the multiple payment data. The division condition corresponds to an example of the second condition.

[0065] The processor 20 refers to the payment request database 30 and reads out the payment amount corresponding to the payment request for which the payment condition is met. If the payment amount is equal to or greater than the second threshold, the processor 20 determines that the division condition is met.

[0066] If the processor 20 determines that the division condition is not met, the process proceeds to step S28. If the processor 20 determines that the division condition is met, the process proceeds to step S27.

[0067] In step S27, processor 20 executes a payment data division process. In this process, processor 20 divides the payment data included in the payment request into multiple processing groups. A processing group is a group for performing payment processing.

[0068] Specifically, processor 20 may determine the division number based on the number of payments. When the number of payments is a first payment number, processor 20 may set the division number to a larger number than when the number of payments is a second payment number that is smaller than the first payment number. The first payment number and the second payment number are payment numbers equal to or greater than a second threshold. In this way, processor 20 divides the multiple payment data included in the payment request into multiple processing groups when the division condition is met based on the multiple payment data included in the payment request.

[0069] In step S28, processor 20 determines whether a shuffle condition is met. The shuffle condition is met when the number of payment data included in the payment request is equal to or greater than a first threshold. The shuffle condition may also be met when the number of payment data divided into processing groups is equal to or greater than the first threshold. The first threshold corresponds to the number of payment data items that does not significantly slow the processing speed of the payment process even if the multiple payment data items are not shuffled. The first threshold is smaller than the second threshold. The shuffle condition corresponds to an example of the first condition.

[0070] If processor 20 determines that the shuffle condition is not met, it shifts the process to step S23. If processor 20 determines that the shuffle condition is met, it shifts the process to step S22.

[0071] In step S22, processor 20 shuffles the multiple payment data. Processor 20 shuffles the multiple payment data divided into processing groups. Processor 20 does not shuffle the multiple payment data when the shuffle condition is not met, and shuffles the multiple payment data when the shuffle condition is met.

[0072] In the second embodiment, when the processing is divided into multiple processing groups, the processor 20 executes steps S22 to S25 and S28 for each processing group. More specifically, the processor 20 can shuffle the multiple payment data divided into the processing groups. The processor 20 distributes the multiple payment data divided into the processing groups to multiple threads. The processor 20 outputs multiple payment data for each of the multiple threads. When the processor 20 has output all the payment data divided into the multiple processing groups, the processor 20 ends the payment control process.

[0073] <Actions and Effects of the Second Embodiment> The operation and effects of the second embodiment will be described. (2-1) Processor 20 shuffles multiple payment data when a shuffle condition is met. The shuffle condition is met when the number of payment data included in the payment request is equal to or greater than a first threshold. With this configuration, when the number of payment data included in the payment request is less than the first threshold, the processor does not shuffle the multiple payment data. This reduces the control load caused by shuffling multiple payment data.

[0074] (2-2) Processor 20 divides the payment data included in the payment request into multiple processing groups based on the payment data included in the payment request. This configuration allows the multiple payment data to be divided into multiple processing groups based on the payment data included in the payment request. This reduces the control load caused by shuffling multiple payment data.

[0075] (2-3) Processor 20 divides multiple payment data into multiple groups when the division condition is met. The division condition is met when the number of multiple payment data included in the payment request is equal to or greater than a second threshold. With this configuration, even if the number of multiple payment data included in the payment request is equal to or greater than the second threshold, the multiple payment data can be divided into multiple processing groups. This reduces the control load caused by shuffling multiple payment data.

[0076] [Third embodiment] Next, a third embodiment will be described. <Payment control processing> 9, in the third embodiment, in the payment control process, when step S21 is completed, processor 20 proceeds to step S29. In step S29, processor 20 executes a payment data determination process. In this process, processor 20 determines whether the processing speed is high or low for each of the multiple payment data items based on the multiple payment data items included in the payment request.

[0077] The processor 20 refers to the payment management database 31 and reads out a management flag for each of the plurality of payment data. The processor 20 may determine that the payment data associated with a management flag indicating a high processing speed of the payment process is the payment data with a high processing speed.

[0078] Specifically, the processor 20 may determine that payment data for which the payment is invalid is payment data with a high processing speed. The processor 20 may also determine that payment data associated with a management flag indicating a low processing speed of the payment process is payment data with a low processing speed.

[0079] Processor 20 references payment management database 31 and reads out the payment method for each of the multiple payment data. Processor 20 may determine that payment data that uses either credit card payment or point payment is payment data with a high processing speed. Processor 20 may determine that payment data that uses both credit card payment and point payment is payment data with a low processing speed. In other words, processor 20 may determine that payment data that includes multiple payment methods is payment data with a low processing speed for each of the multiple payment data.

[0080] In step S28, processor 20 determines whether the shuffle condition is met. In the third embodiment, the shuffle condition is met when the proportion of payment data determined to have a high processing speed among the multiple payment data included in the payment request is less than a specified proportion. For example, the specified proportion may be 80%. In this way, processor 20 determines whether the shuffle condition is met based on the result of the determination in step S29.

[0081] The processor 20 may refer to the payment request database 30 and determine whether the shuffle condition is met based on the request type. The processor 20 may determine that the shuffle condition is met when the request type is the normal type or the low-speed type. The processor 20 may determine that the shuffle condition is not met when the request type is the high-speed type.

[0082] If processor 20 determines that the shuffle condition is not met, it shifts the process to step S23. If processor 20 determines that the shuffle condition is met, it shifts the process to step S22.

[0083] When step S23 is completed, processor 20 proceeds to step S30. In step S30, processor 20 executes a distribution result determination process. In this process, processor 20 determines, for each of the multiple threads, the proportion of payment data with a high processing speed among the payment data distributed to each of the multiple threads in step S23.

[0084] In step S31, processor 20 determines whether the confirmation condition is met. The confirmation condition is met when the difference in the proportion of payment data determined to have a high processing speed among the payment data allocated to each of the multiple threads is equal to or less than a third threshold. The third threshold corresponds to a value that does not cause the processing speed of payment processing in the multiple threads to become extremely high. The confirmation condition corresponds to an example of the third condition. The confirmation condition does not have to be met if the shuffle condition is not met and the process proceeds to step S23.

[0085] If processor 20 determines that the determination condition is met, it shifts the process to step S24. If processor 20 determines that the determination condition is not met, it shifts the process to step S22 again.

[0086] In this way, processor 20 repeatedly shuffles the multiple payment data until the allocation condition is met. In this way, processor 20 shuffles the multiple payment data so as to minimize the difference in processing speed for each of the multiple threads.

[0087] <Actions and Effects of the Third Embodiment> The operation and effects of the third embodiment will be described. (3-1) Processor 20 determines whether the processing speed is high or low for each of the multiple payment data. Processor 20 shuffles the multiple payment data to minimize the difference in processing speed for each of the multiple threads. With this configuration, by determining whether the processing speed is high or low for each of the multiple payment data, the difference in processing speed for each of the multiple threads can be minimized. This improves the processing efficiency of the payment process.

[0088] (3-2) For each of the multiple payment data, processor 20 determines that payment data that invalidates the payment is payment data with a high processing speed. With this configuration, by determining that payment data that invalidates the payment is payment data with a high processing speed, it is possible to reduce the difference in processing speed among multiple threads. Therefore, it is possible to improve the processing efficiency of the payment process.

[0089] (3-3) For each of the multiple payment data, processor 20 determines that payment data containing multiple payment methods has a low processing speed. This configuration reduces the difference in processing speed among multiple threads by determining that payment data containing multiple payment methods has a low processing speed. This improves the processing efficiency of the payment process.

[0090] (3-4) The multiple payment methods include credit card payment and point payment. With this configuration, by determining that payment data that includes both credit card payment and point payment methods has a low processing speed, the difference in processing speed among multiple threads can be reduced. This improves the processing efficiency of payment processing.

[0091] (3-5) The shuffle condition is met when the proportion of payment data determined to have a high processing speed among the multiple payment data included in the payment request is less than a specified proportion. According to this configuration, the multiple payment data are shuffled when the proportion of payment data determined to have a high processing speed among the multiple payment data included in the payment request is less than a specified proportion. When the proportion of payment data determined to have a high processing speed among the multiple payment data included in the payment request is equal to or greater than a specified proportion, the multiple payment data are not shuffled. This allows the multiple payment data to be shuffled as needed, taking into account the proportion of payment data with a high processing speed among the multiple payment data included in the payment request. Therefore, the control load due to shuffling multiple payment data can be reduced and the processing efficiency of the payment process can be improved.

[0092] (3-6) Processor 20 repeatedly shuffles multiple payment data until a confirmation condition is met. The confirmation condition is met when the difference in the proportion of payment data determined to have a high processing speed among the payment data allocated to each of the multiple threads is equal to or less than a third threshold. This configuration allows payment data to be shuffled and allocated to each of the multiple threads so that the difference in the proportion of payment data with a high processing speed is equal to or less than the third threshold. This improves the processing efficiency of the payment process.

[0093] [Example of change] This embodiment can be modified as follows: This embodiment and the following modifications can be combined and implemented within the scope of technical compatibility.

[0094] In the second embodiment, the processor 20 may determine whether the division condition is met based on the data size of the multiple payment data included in the payment request and the storage capacity of the memory 21. The storage capacity of the memory 21 here refers to, for example, the storage capacity of a semiconductor memory. For example, the processor 20 may determine that the division condition is met when the data size of the payment data included in the payment request is larger than the storage capacity of the memory 21. The data size of the payment data included in the payment request here refers to, for example, the storage capacity of the semiconductor memory based on the capacity that can load the payment data into the semiconductor memory.

[0095] In the second embodiment, the processor 20 may determine whether the division condition is met based on the data volume of the payment request. The processor 20 may determine whether the division condition is met based on the data volume of the payment data included in the payment request.

[0096] In the second embodiment, the processor 20 may determine that payment data has a high processing speed based on at least one of whether the payment is invalid or whether the payment data includes multiple payment methods.

[0097] In the third embodiment, the processor 20 may determine whether the processing speed is high or low based on the data volume of the payment data. The processor 20 may determine that the processing speed is low when the data volume of the payment data is large.

[0098] In the third embodiment, the processor 20 may satisfy the confirmation condition when, for each of a plurality of threads, the proportion of payment data included in the payment request that has a fast processing speed is within an allowable range including an average proportion.

[0099] In the third embodiment, the processor 20 may determine whether the processing speed is high or low based on the type of payment method. For example, the processor 20 may determine payment data for which the payment method is credit card payment as payment data with a fast processing speed, and payment data for which the payment method is point payment as payment data with a slow processing speed. For example, the processor 20 may determine payment data for which the payment method is point payment as payment data with a fast processing speed, and payment data for which the payment method is credit card payment as payment data with a slow processing speed.

[0100] In the third embodiment, the processor 20 may determine whether the processing speed is high or low based on the payment token. The processor 20 may also determine whether the processing speed is high or low based on the payment destination identifier. For example, the processor 20 may determine, based on the payment token or the payment destination identifier, payment data for a first country as payment data with a fast processing speed, and payment data for a second country as payment data with a slow processing speed. For example, the processor 20 may determine, based on the payment token or the payment destination identifier, payment data for a domestic payment destination as payment data with a fast processing speed, and payment data for a foreign payment destination as payment data with a slow processing speed.

[0101] In the third embodiment, the shuffle condition may be met when at least one of the following conditions is met: the proportion of payment data with high processing speed is less than a specified proportion, and the request type is a normal type or a low-speed type. The shuffle condition may be met when both the proportion of payment data with high processing speed is less than a specified proportion, and the request type is a normal type or a low-speed type.

[0102] The processor 20 may execute the payment data shuffling process and the payment data allocation process as the same process. The above embodiments may be combined as appropriate. For example, the processor 20 may execute the payment data division process of the second embodiment and the payment data determination process and allocation result determination process of the third embodiment.

[0103] The processor 20 may set a management flag based on the payment token. Specifically, the processor 20 may send an inquiry request as to whether the payment will be invalid to the payment server 14 via the payment gateway 12 and the payment agent server 13. The inquiry request may include the payment token. The processor 20 may receive an inquiry result from the payment server 14 and set a management flag indicating whether the payment will be invalid based on the inquiry result. The processor 20 may send an inquiry request as to whether the payment will be invalid to a point management server (not shown). The processor 20 may receive an inquiry result from the point management server and set a management flag indicating whether the payment will be invalid based on the inquiry result.

[0104] The processor 20 may set the request type based on the management flag. The processor 20 may determine the proportion of payment data with a high processing speed among all payment data included in the payment request based on the management flag, and set the request type as the high-speed type when the proportion is equal to or greater than a predetermined proportion.

[0105] The request type may be classified into two levels (slow speed and high speed) instead of three levels (normal speed, low speed, and high speed), or may be classified into four or more levels. The request type does not need to be included in the payment request.

[0106] The payment number may not be set by the client and may not be included in the payment request. In such a case, the processor 20 may count the number of payment data included in the payment request as the payment number and register it in the payment request database 30.

[0107] In the information processing device 11, the processor 20 may read a program from a memory provided in a device other than the information processing device 11 and execute processing based on the read program. The device other than the information processing device 11 may or may not be included in the information processing system 10. In other words, the information processing system 10 may or may not include a memory in which a program is stored.

[0108] The payment gateway 12 may receive payment data from a device other than the information processing device 11. For example, the payment gateway 12 may receive payment data from an e-commerce server that handles e-commerce transactions. For example, the payment gateway 12 may receive payment data from a reservation server that handles reservations for accommodations, etc. For example, the payment gateway 12 may receive payment data from a payment management server that handles payments other than regular payments.

[0109] The information processing device 11, payment gateway 12, payment agency server 13, payment server 14, and terminal device 19 may each be managed by the same or different managers. For example, the information processing device 11 and the payment gateway 12 may each be managed by the same manager. For example, the multiple payment agency servers 13 and multiple payment servers 14 may include a server managed by the same manager as the information processing device 11 and the payment gateway 12, and a server managed by a different manager than the information processing device 11 and the payment gateway 12.

[0110] The information processing device 11 may be configured with at least one server, or may be configured with multiple servers. When the information processing device 11 is configured with multiple servers, the functions of the information processing device 11 may be divided among the multiple servers.

[0111] The information processing system 10 does not have to include the payment gateway 12 and the payment agency server 13. In such a case, the information processing device 11 may include some or all of the functions of the payment gateway 12 and the payment agency server 13. In this way, the information processing system 10 only needs to include at least one server including the information processing device 11. In other words, the information processing system 10 may be the information processing device 11 alone.

[0112] The phrase "at least any" used herein means one or more of the desired options. As an example, when the number of options is two, the phrase "at least any" used herein means only one option or both options. As another example, when the number of options is three or more, the phrase "at least any" used herein means only one option or any combination of two or more options.

[0113] [Note] The technical concepts grasped from the above-described embodiment and modified examples will be described below. [1] An information processing system includes at least one processor, and the at least one processor performs the following operations: receiving a payment request including multiple payment data from a terminal device; shuffling the multiple payment data included in the payment request; allocating the shuffled multiple payment data to multiple threads; and outputting the multiple payment data allocated to the multiple threads in parallel for each of the multiple threads, thereby performing payment based on the multiple payment data.

[0114] [2] In the information processing system described in [1], shuffling the plurality of payment data includes shuffling the plurality of payment data when a first condition is met, and the first condition can be met when the number of payment data included in the payment request is equal to or greater than a first threshold.

[0115] [3] An information processing system as described in [1] or [2], wherein the at least one processor executes dividing the plurality of payment data included in the payment request into a plurality of processing groups based on the plurality of payment data included in the payment request, and shuffling the plurality of payment data includes shuffling the divided plurality of payment data for each of the plurality of payment data divided into the plurality of processing groups.

[0116] [4] [3] An information processing system as described in [3], wherein dividing the plurality of payment data into a plurality of pieces includes dividing the plurality of payment data into a plurality of pieces when a second condition is met, and the second condition can be met when the number of the plurality of payment data included in the payment request is equal to or greater than a second threshold.

[0117] [5] An information processing system described in any one of [1] to [4], wherein the at least one processor acquires a payment result for each of the plurality of payment data, and when all payment results corresponding to the plurality of payment data included in the payment request have been acquired, transmits all of the payment results to the terminal device.

[0118] [6] An information processing system described in any one of [1] to [5], wherein the at least one processor executes a determination as to whether the processing speed is high or low for each of the plurality of payment data, and shuffling the plurality of payment data includes shuffling the plurality of payment data so as to reduce the difference in the processing speed for each of the plurality of threads.

[0119] [7] [6] In the information processing system described above, determining whether the processing speed is high or low includes determining, for each of the plurality of payment data, payment data that will result in an invalid payment as payment data with a high processing speed.

[0120] [8] In the information processing system described in [6] or [7], making a determination regarding the processing speed includes determining, for each of the plurality of payment data, payment data that includes multiple payment methods as payment data with a low processing speed.

[0121] [9] [8] An information processing system according to the present invention, wherein the plurality of payment methods include credit card payment and point payment.

[10] An information processing system described in any one of [6] to [9], wherein shuffling the plurality of payment data includes shuffling the plurality of payment data when a first condition is met, and the first condition can be met when the proportion of the plurality of payment data included in the payment request that is determined to be payment data with a high processing speed is less than a specified proportion.

[0122]

[11] An information processing system according to any one of [6] to

[10] , wherein shuffling the plurality of payment data includes repeatedly shuffling the plurality of payment data until a third condition is met, and the third condition can be met when the difference in the proportion of payment data determined to have a high processing speed among the payment data allocated to each of the plurality of threads is equal to or less than a third threshold.

[0123]

[12] An information processing method includes at least one processor receiving a payment request including multiple payment data from a terminal device, shuffling the multiple payment data included in the payment request, allocating the shuffled multiple payment data to multiple threads, and outputting the allocated multiple payment data in parallel to each of the multiple threads to perform payment based on the multiple payment data.

[0124]

[13] The program causes at least one processor to receive a payment request including multiple payment data from a terminal device, shuffle the multiple payment data included in the payment request, allocate the shuffled multiple payment data to multiple threads, and perform payment based on the multiple payment data by outputting the multiple payment data allocated to the multiple threads in parallel for each of the multiple threads. [Explanation of symbols]

[0125] 10...information processing system, 11...information processing device, 20...processor, 21...memory, 30...payment request database, 31...payment management database.

Claims

1. An information processing system comprising at least one processor, The at least one processor receiving a payment request including a plurality of payment data from a terminal device; shuffling the plurality of payment data included in the payment request; Allocating the shuffled payment data to each of a plurality of threads; outputting the plurality of payment data allocated to each of the plurality of threads in parallel for each of the plurality of threads, thereby performing a payment based on the plurality of payment data; To execute Information processing system.

2. 2. The information processing system according to claim 1, shuffling the plurality of payment data includes shuffling the plurality of payment data when a first condition is met; The first condition can be met when the number of payment data included in the payment request is equal to or greater than a first threshold. Information processing system.

3. 2. The information processing system according to claim 1, The at least one processor executes dividing the plurality of payment data included in the payment request into a plurality of processing groups based on the plurality of payment data included in the payment request; shuffling the plurality of payment data includes shuffling the plurality of payment data divided into each of the plurality of processing groups. Information processing system.

4. 4. The information processing system according to claim 3, Dividing the plurality of payment data into a plurality of pieces includes dividing the plurality of payment data into a plurality of pieces when a second condition is met, the second condition can be met when the number of the plurality of payment data included in the payment request is equal to or greater than a second threshold. Information processing system.

5. 2. The information processing system according to claim 1, The at least one processor acquiring a payment result for each of the plurality of payment data; When all payment results corresponding to the plurality of payment data included in the payment request are acquired, transmitting all of the payment results to the terminal device; To execute Information processing system.

6. 6. The information processing system according to claim 1, the at least one processor executes a determination as to whether a processing speed is high or low for each of the plurality of payment data; shuffling the plurality of payment data includes shuffling the plurality of payment data so as to reduce a difference in processing speed for each of the plurality of threads; Information processing system.

7. 7. The information processing system according to claim 6, determining whether the processing speed is high or low includes determining, for each of the plurality of payment data, payment data for which the payment is invalid as the payment data having a high processing speed; Information processing system.

8. 7. The information processing system according to claim 6, determining whether the processing speed is high or low includes determining, for each of the plurality of payment data, payment data that includes a plurality of payment methods as the payment data with a low processing speed; Information processing system.

9. 9. The information processing system according to claim 8, The plurality of payment methods include credit card payment and point payment. Information processing system.

10. 7. The information processing system according to claim 6, shuffling the plurality of payment data includes shuffling the plurality of payment data when a first condition is met; the first condition can be met when a ratio of the plurality of payment data included in the payment request that are determined to have a high processing speed is less than a specified ratio. Information processing system.

11. 7. The information processing system according to claim 6, shuffling the plurality of payment data includes repeatedly shuffling the plurality of payment data until a third condition is met; the third condition can be met when a difference between the proportion of payment data determined to have a high processing speed among the payment data allocated to each of the plurality of threads is equal to or less than a third threshold. Information processing system.

12. At least one processor receiving a payment request including a plurality of payment data from a terminal device; shuffling the plurality of payment data included in the payment request; Allocating the shuffled payment data to each of a plurality of threads; outputting the allocated plurality of payment data in parallel for each of a plurality of threads, thereby performing a payment based on the plurality of payment data; To execute Information processing methods.

13. At least one processor receiving a payment request including a plurality of payment data from a terminal device; shuffling the plurality of payment data included in the payment request; Allocating the shuffled payment data to each of a plurality of threads; outputting the plurality of payment data allocated to each of the plurality of threads in parallel for each of the plurality of threads, thereby performing a payment based on the plurality of payment data; Execute program.

Images