Transaction management system, transaction management method, and transaction management program

Abstract

This transaction management system: acquires a plurality of pieces of transaction information from a transaction database that stores a transaction information group between a plurality of providers and a plurality of users, the transaction information group including relationship information that indicates a creditor-debtor relationship in which one provider is a creditor and one user is a debtor; switches the relationship information in each of the plurality of pieces of transaction information to intermediary debt information in which the provider is a creditor and a transaction supporter is a debtor, and intermediary credit information in which the transaction supporter is a creditor and the user is a debtor; calculates a payment amount to be paid from the transaction supporter to each of the plurality of providers from the intermediary debt information; calculates a billing amount to be charged from the transaction supporter to each of the plurality of users from the intermediary credit information; transmits information on the payment amount calculated for each of the plurality of providers to terminal devices of the plurality of providers; and transmits information on the billing amount calculated for each of the plurality of users to a terminal device of the user.

Description

Transaction management system, transaction management method, and transaction management program

[0001] The present invention relates to a transaction management system, a transaction management method, and a transaction management program.

[0002] It has been known for some time that agents can act as agents for making monetary payments in transactions between companies. For example, Patent Document 1 describes a system in which an accountant transfers money to a contractor on behalf of an orderer, and then collects the costs, plus a predetermined handling fee, from the orderer.

[0003] Japanese Patent Application Laid-Open No. 2022-132879

[0004] However, when multiple businesses conduct transactions with multiple other businesses, billing and payments are required for each transaction between the businesses, making transaction management complicated.

[0005] The disclosed technology aims to simplify the management of transactions and facilitate transactions.

[0006] The disclosed technology is a transaction management system including a computer that communicates via a network with a plurality of terminal devices owned by a plurality of providers of products or services and a plurality of users who request the provision of the products or services, the computer comprising: The method acquires a group of transaction information between the plurality of providers and the plurality of users, each of which includes relationship information indicating a creditor-debtor relationship in which one of the plurality of providers is a creditor and one of the plurality of users is a debtor, from a transaction database that stores such group of transaction information, and switches the relationship information in each of the plurality of transaction information between intermediary debt information indicating a first relationship in which the corresponding provider is the creditor and the transaction supporter is the debtor, and intermediary credit information indicating a second relationship in which the transaction supporter is the creditor and the corresponding user is the debtor, calculates a payment amount to be paid by the transaction supporter to each of the plurality of providers based on the intermediary debt information, calculates a claim amount to be claimed from the transaction supporter to each of the plurality of users based on the intermediary credit information, transmits information on the payment amount calculated for each of the plurality of providers to a terminal device of a corresponding provider among the plurality of terminal devices via the network, and transmits information on the claim amount calculated for each of the plurality of users to a terminal device of a corresponding user among the plurality of terminal devices via the network.

[0007] It simplifies transaction management and facilitates transactions.

[0008] 1 is a diagram showing an example of the system configuration of a transaction management system. FIG. 2 is a diagram showing an example of the hardware configuration of a transaction management device. FIG. 3 is a diagram explaining the functions of the transaction management device possessed by the transaction management system. FIG. 4 is a diagram showing an example of individual information. FIG. 5 is a diagram showing an example of transaction information. FIG. 6 is a diagram showing an example of intermediary debt information. FIG. 7 is a diagram showing an example of intermediary credit information. FIG. 8 is a diagram showing an example of credit information. FIG. 9 is a sequence diagram explaining the operation of the transaction management system. FIG. 10 is a first flowchart explaining the processing of the transaction management device. FIG. 11 is a second flowchart explaining the processing of the transaction management device. FIG. 12 is a third flowchart explaining the processing of the transaction management device. FIG. 13 is a diagram showing another example of transaction information. FIG. 14 is a diagram showing another example of intermediary debt information. FIG. 15 is a diagram showing another example of intermediary credit information. FIG. 16 is a first diagram explaining an example of a display on a terminal device. FIG. 17 is a second diagram explaining an example of a display on a terminal device. FIG. 18 is a diagram showing an example of deposit information. FIG. 19 is a diagram showing an example of agent-received money information. FIG. 19 is a third diagram explaining an example of a display on a terminal device.

[0009] The present embodiment will be described below with reference to the drawings. Fig. 1 is a diagram showing an example of the system configuration of a transaction management system.

[0010] The transaction management system 100 of this embodiment includes a transaction management device 200 and a plurality of terminal devices 300A to 300Y, and the transaction management device 200 and each of the plurality of terminal devices 300A to 300Y are connected via a network N. In the following description, when there is no need to distinguish between the terminal devices 300A to 300Y, they will simply be referred to as terminal devices 300. In this embodiment, the network N may be a wide-area network such as the Internet or a WAN.

[0011] In the transaction management system 100 of this embodiment, each terminal device 300 is linked to a user of the transaction management system 100.

[0012] In the following description, a user who provides a product or service may be referred to as a provider or a partner. In the following description, a user who receives a product or service may be referred to as a user or a customer. In the following description, a business that mediates the transfer of money in a transaction between a provider and a user may be referred to as a transaction supporter. The transaction supporter may be an administrator of the transaction management system 100. In the following description, a user receiving a product or service from a provider, or a provider providing a product or service to a user, may be referred to as a transaction between a user and a provider. In the following description, for simplicity, a user may be referred to as either a provider or a user, but the same user may be both a provider and a user.

[0013] 1, an overview of the transaction management system 100 of this embodiment will be explained by assuming that users associated with each of terminal devices 300A to 300M are users, users associated with terminal devices 300N to 300Y are providers, and the administrator of the transaction management system 100 is a transaction supporter. Note that a user associated with terminal device 300 may be a user who has logged in to a web service provided by transaction management system 100 using terminal device 300, or a user associated with a terminal ID that identifies terminal device 300 and a user ID that identifies the user.

[0014] In the transaction management system 100 of this embodiment, a user associated with the terminal device 300 can be both a provider and a user. Also, in this embodiment, a transaction supporter can be either a provider or a user. Therefore, the provider and user shown in FIG. 1 are merely examples and are not limiting.

[0015] In this embodiment, when a provider provides goods or services to multiple users, the transaction management device 200 converts the monetary debts owed to each of the multiple users into debts of the transaction supporter through exemptive debt assumption, converts the monetary claims owed to each of the providers into claims of the transaction supporter, and generates a right of reimbursement from each of the users to the transaction supporter. The transaction supporter then pays the provider the total of the debts owed to each of the multiple users.

[0016] Specifically, for example, let us consider a case where a user linked to terminal device 300Y is the provider, a user linked to terminal device 300A is the first user, and a user linked to terminal device 300B is the second user, and each of the first user and second user receives a product or service from the provider.

[0017] In this case, separate contracts for transactions are established between the provider and the first user, and between the provider and the second user, and the provision of goods or services is carried out independently between the provider and the first user and between the provider and the second user.

[0018] When each transaction is concluded, the first user and the second user each incur a monetary debt (payment amount) to the provider.

[0019] In this embodiment, the monetary debts thus incurred by each of the multiple users are converted into debts of the transaction supporter through exempt debt assumption, and the transaction supporter pays the provider the amount of payment corresponding to the debts assumed from the multiple users in a lump sum. Also, in this embodiment, the transaction supporter converts the monetary claims of each of the provider's multiple users into claims of the transaction supporter, and bills each of the multiple users for the amount corresponding to the claim.

[0020] Specifically, in the transaction management system 100, the transaction management device 200 acquires first transaction information regarding a transaction conducted between a user linked to terminal device 300Y and a user linked to terminal device 300A, and second transaction information regarding a transaction conducted between a user linked to terminal device 300Y and a user linked to terminal device 300B.

[0021] Next, the transaction management device 200 extracts relationship information from the first transaction information indicating the monetary credit / debt relationship between the provider and the first user, and generates first intermediary debt information in which the debtor has been switched from the first user to the transaction supporter, and first intermediary claim information in which the creditor has been switched from the provider to the transaction supporter. The transaction management device 200 also extracts relationship information from the second transaction information indicating the monetary credit / debt relationship between the provider and the second user, and generates second intermediary debt information in which the debtor has been switched from the user to the transaction supporter, and second intermediary claim information in which the creditor has been switched from the provider to the transaction supporter. The intermediary debt information includes the payment amount paid by the user to the provider, and the intermediary claim information includes the claim amount invoiced by the provider to the user.

[0022] Next, the transaction management device 200 determines the sum of the payment amounts included in the first intermediary debt information and the second intermediary debt information as the payment amount to the user linked to terminal device 300Y. Furthermore, the transaction management device 200 determines the claim amount included in the first intermediary debt information as the claim amount to the user linked to terminal device 300A, and the claim amount included in the second intermediary debt information as the claim amount to the user linked to terminal device 300Y.

[0023] Furthermore, the transaction management device 200 aggregates the payment amount from the transaction supporter to the provider in a transaction in which the user linked to the terminal device 300Y becomes the provider, in accordance with the payment terms agreed upon between the user linked to the terminal device 300Y and the transaction supporter, and notifies the terminal device 300Y of the total aggregated payment amount.

[0024] Furthermore, transaction management device 200 tally up the amounts billed by the transaction assistant to the user in a transaction in which the user linked to terminal device 300A becomes a user, in accordance with billing terms agreed upon between the user linked to terminal device 300A and the transaction assistant, and notifies terminal device 300A of the total amount of billed amounts. Furthermore, transaction management device 200 tally up the amounts billed by the transaction assistant to the user in a transaction in which the user linked to terminal device 300B becomes a user, in accordance with billing terms agreed upon between the user linked to terminal device 300B and the transaction assistant, and notifies terminal device 300B of the total amount of billed amounts.

[0025] In this embodiment, by doing so, the provider does not need to issue invoices or the like to each of the multiple users, and the effort required for managing transactions can be reduced.

[0026] In addition, when a user receives goods or services from multiple providers, the transaction management device 200 of this embodiment converts the monetary claims of each provider into claims of the transaction supporter. The transaction supporter then bills the user for the combined claims of the transaction supporter.

[0027] In addition, when a user receives goods or services from multiple providers, the transaction management device 200 of this embodiment converts the user's monetary debt into a debt of the transaction supporter, and the transaction supporter then pays the debt to each of the multiple providers.

[0028] Below, we will explain a case where a user linked to terminal device 300B is the user, a user linked to terminal device 300X is the first provider, and a user linked to terminal device 300Y is the second provider, and the user receives goods or services from both the first provider and the second provider.

[0029] In this case, separate contracts for transactions are established between the user and the first provider and between the user and the second provider, and the provision of goods or services is carried out independently between the user and the first provider and between the user and the second provider.

[0030] In this case, each of the first provider and the second provider has a monetary claim against the user. In this embodiment, the monetary claims against the user that have arisen from each of the multiple providers are converted into claims from the transaction supporter, and the user is billed in a lump sum for the amount claimed according to the claims. Also, in this embodiment, the monetary debts that the user has incurred against each of the multiple providers are converted into debts from the transaction supporter. Then, in this embodiment, the transaction supporter pays each of the multiple providers an amount corresponding to the debt that the transaction supporter has assumed.

[0031] Specifically, in the transaction management system 100, the transaction management device 200 linked to the transaction assistant acquires third transaction information regarding a transaction conducted between a user linked to terminal device 300B and a user linked to terminal device 300X, and fourth transaction information regarding a transaction conducted between a user linked to terminal device 300B and a user linked to terminal device 300Y.

[0032] Next, the transaction management device 200 extracts relationship information indicating the monetary credit / debt relationship between the user and the first provider, which is included in the third transaction information, and generates first intermediary claim information in which the creditor has been switched from the first provider to the transaction supporter, and third intermediary debt information in which the debtor has been switched from the user to the transaction supporter.Furthermore, the transaction management device 200 extracts relationship information indicating the monetary credit / debt relationship between the user and the second provider, which is included in the fourth transaction information, and generates fourth intermediary claim information in which the creditor has been switched from the user to the transaction supporter, and fourth intermediary debt information in which the debtor has been switched from the user to the transaction supporter.

[0033] Next, the transaction management device 200 determines the total of the claims included in the third intermediary claim information and the fourth intermediary claim information as the claim amount to the user linked to terminal device 300B. Furthermore, the transaction management device 200 determines the payment amount included in the third intermediary debt information as the payment amount to the user linked to terminal device 300X, and the payment amount included in the fourth intermediary claim information as the payment amount to the user linked to terminal device 300Y.

[0034] Furthermore, transaction management device 200 tallies up billing amounts from transaction supporters to users in transactions in which the user associated with terminal device 300B becomes a user, in accordance with billing terms associated with the user associated with terminal device 300B, and notifies terminal device 300B of the total tallied billing amounts. Transaction management device 200 also tallies up payment amounts from transaction supporters to providers in transactions in which the user associated with terminal device 300X becomes a provider, in accordance with payment terms associated with the user associated with terminal device 300X, and notifies terminal device 300X of the total tallied payment amounts. Transaction management device 200 also tallies up payment amounts from transaction supporters to providers in transactions in which the user associated with terminal device 300Y becomes a provider, in accordance with payment terms associated with the user associated with terminal device 300Y, and notifies terminal device 300Y of the total tallied payment amounts.

[0035] In this embodiment, by doing this, the user linked to terminal device 300B does not need to make payments to both the user linked to terminal device 300X and the user linked to terminal device 300Y, and only needs to pay the amount invoiced by the transaction supporter to the transaction supporter.

[0036] In this embodiment, intermediary debt information and intermediary credit information are generated from relationship information indicating monetary credit-debt relationships contained in transaction information, and in transactions between a provider and multiple users, and between a user and multiple providers, the subject of the monetary credit and the subject of the monetary debt are switched to the transaction supporter, thereby realizing the transaction supporter's assumption of the debt without liability and the creation of a monetary credit (right of recourse) for the transaction supporter.

[0037] In this embodiment, by doing so, the user does not need to make payments to each of the multiple providers, which reduces the effort required to manage transactions. Also, in this embodiment, by doing so, the user does not need to make payments to each of the multiple providers, which reduces transfer fees and the like incurred when making payments to each of the multiple providers.

[0038] In addition, the transaction management device 200 of this embodiment may further transmit the amount obtained by offsetting the monetary debt if a user becomes a user and the monetary credit if a user becomes a provider to the terminal device 300 linked to a certain user for each period agreed upon with the user.

[0039] For example, if a user linked to terminal device 300Y was both a user and a provider during a certain specified period, terminal device 300Y may be notified of the amount obtained by offsetting the total amount billed to users linked to terminal device 300Y during the specified period with the total amount paid to users linked to terminal device 300Y.

[0040] In this embodiment, by doing this, the user linked to the terminal device 300Y no longer needs to separately manage the payment of the invoice amount to the transaction supporter and the receipt of the payment amount paid by the transaction supporter, thereby reducing the effort required.

[0041] In this embodiment, when a user becomes a user or provider and transacts with multiple providers or multiple users, the effort involved in managing monetary receivables and debts can be reduced, thereby contributing to the promotion of transactions.

[0042] Next, the hardware configuration of transaction management device 200 of this embodiment will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the hardware configuration of the transaction management device.

[0043] The transaction management device 200 of this embodiment is a computer including an input device 21, an output device 22, a drive device 23, an auxiliary storage device 24, a memory device 25, an arithmetic processing device 26 and an interface device 27, all of which are interconnected by a bus B.

[0044] The input device 21 is a device for inputting various types of information. The output device 22 is a device for outputting various types of information. The interface device 27 includes a LAN card or the like and is used for connecting to a network.

[0045] The transaction management program that realizes each functional unit of transaction management device 200 is at least a part of the various programs that control transaction management device 200. The transaction management program is provided, for example, by distributing recording medium 28 or by downloading from a network. Recording medium 28 on which the transaction management program is recorded can be of various types, including recording media that record information optically, electrically, or magnetically, such as CD-ROMs, flexible disks, and magneto-optical disks, and semiconductor memories that record information electrically, such as ROMs and flash memories.

[0046] When the recording medium 28 on which the transaction management program is recorded is set in the drive device 23, the transaction management program recorded on the recording medium 28 is installed from the recording medium 28 into the auxiliary storage device 24 via the drive device 23. The transaction management program downloaded from the network is installed into the auxiliary storage device 24 via the interface device 27.

[0047] Auxiliary storage device 24 stores the transaction management program installed in transaction management device 200, as well as various files, data, etc. required by transaction management device 200. Memory device 25 reads and stores the transaction management program from auxiliary storage device 24 when transaction management device 200 is started up. Then, processing unit 26 performs various processes, as described below, in accordance with the transaction management program stored in memory device 25.

[0048] The terminal device 300 of this embodiment may be a computer having the same hardware configuration as that shown in Fig. 2. The terminal device 300 may also be a portable terminal device such as a smartphone or a tablet terminal device. In this case, the input device may be a touch panel or the like, and the output device may be a display or the like.

[0049] Next, the functional configuration of transaction management device 200 included in transaction management system 100 of this embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram illustrating the functions of the transaction management device included in the transaction management system.

[0050] The transaction management device 200 of this embodiment includes an individual information storage unit 210, a transaction information storage unit 220, a transaction management information storage unit 230, and a transaction management unit 240.

[0051] The individual information storage unit 210, the transaction information storage unit 220, and the transaction management information storage unit 230 may be realized, for example, by the memory device 25 or auxiliary storage device 24 of the transaction management device 200.

[0052] The individual information storage unit 210 stores individual information 211, which is information about each individual user of the transaction management system 100. The individual information 211 is information stored by the terminal device 300 of the user who uses the transaction management system 100.

[0053] In addition, in this embodiment, when the user ID stores individual information 211 in the transaction management device 200, information indicating that the user has agreed to switch the subject of the monetary claims and monetary debts in the transaction to the transaction supporter (i.e., that the user has agreed to transfer the user's monetary claims and monetary debts to the transaction supporter by way of exempt debt assumption, and that monetary claims will arise in the transaction supporter) may also be stored in the transaction management device 200.

[0054] In other words, the transaction management device 200 of this embodiment acquires agreement information from the terminal device 300, which agrees to the provision that the relationship information indicating the relationship between monetary claims and debts in the transaction information be switched to intermediary debt information and intermediary credit information. Note that the timing at which the transaction management device 200 acquires the agreement information is not limited to the timing at which the individual information 211 is stored in the transaction management device 200. The timing at which the transaction management device 200 acquires the agreement information may be, for example, immediately before a transaction is conducted between a user and a provider.

[0055] The individual information 211 includes user information 212, payment terms information 213, and billing terms information 214, and the user information 212, payment terms information 213, and billing terms information 214 are associated with each other.

[0056] User information 212 is information about a user, including a user ID for identifying the user. Payment terms information 213 is information indicating payment terms for each user. The payment terms information 213 is referenced when a transaction supporter pays the amount due to the user. Billing terms information 214 is referenced when a transaction supporter bills the user for the amount due. The billing terms information 214 includes information indicating the payment method for paying the amount due to the user.

[0057] The transaction information storage unit 220 stores transaction information 221. The transaction information 221 is stored in the transaction information storage unit 220 when an order for a product or service is concluded between a provider and a user. The transaction information 221 of this embodiment includes relationship information indicating a monetary credit-debt relationship in which the user who is the provider is the creditor and the user who is the user is the debtor. The transaction information storage unit 220 of this embodiment is an example of a transaction database. Details of the transaction indicated by the transaction information 221 of this embodiment will be described later.

[0058] The transaction management information storage unit 230 stores transaction management information 231. The transaction management information 231 includes intermediary debt information 232, intermediary credit information 233, credit information 236, and billing / payment amount information 237.

[0059] Therefore, the transaction information storage unit 220 of this embodiment can be said to be an example of a credit database, a payment terms database, and a billing terms database.

[0060] Intermediary debt information 232 is information generated from transaction information 221, and indicates a first relationship in which the provider is the creditor and the transaction supporter is the debtor. Intermediary debt information 233 is information generated from transaction information 221, and indicates a second relationship in which the transaction supporter is the creditor and the user is the debtor.

[0061] The credit information 236 indicates the credit of each user whose transaction information 221 is stored in the individual information storage unit 210. The billing / payment amount information 237 indicates the billing amount that the transaction supporter will bill the user in accordance with the user's billing conditions, and the payment amount that the transaction supporter will pay to the provider in accordance with the provider's payment conditions.

[0062] Details of individual information 211, transaction information 221, and transaction management information 231 will be described later. In the example of Fig. 3, individual information storage unit 210, transaction information storage unit 220, and transaction management information storage unit 230 are provided in transaction management device 200, but this is not limiting. For example, some or all of individual information storage unit 210, transaction information storage unit 220, and transaction management information storage unit 230 may be provided in devices external to transaction management device 200.

[0063] The transaction management unit 240 is realized by the processing unit 26 of the transaction management device 200 reading and executing a transaction management program stored in the memory device 25 or the like.

[0064] The transaction management unit 240 includes a transaction information acquisition unit 241 , an information generation unit 242 , an information update unit 243 , an amount calculation unit 244 , a credit confirmation unit 245 , a display control unit 246 , and a notification output unit 247 .

[0065] The transaction information acquisition unit 241 acquires transaction information 221 from the transaction information storage unit 220. The information generation unit 242 generates intermediary debt information and intermediary credit information from the transaction information 221. In this embodiment, the information generation unit 242 generates intermediary debt information and intermediary credit information using transaction information 221 that satisfies a predetermined condition among the transaction information 221 stored in the transaction information storage unit 220. The predetermined condition may be, for example, that the transaction status described below is "shipped." Note that the predetermined condition may be set arbitrarily by the administrator of the transaction management system 100. The information generation unit 242 may also generate transaction information to be stored in the transaction information storage unit 220.

[0066] The information update unit 243 updates the information stored in the individual information storage unit 210, the transaction information storage unit 220, and the transaction management information storage unit 230. The amount calculation unit 244 adds up the payment amount included in the intermediary debt information and the claim amount included in the intermediary credit information. The credit confirmation unit 245 refers to the credit information 236 to confirm the credit of the user performing the transaction. The display control unit 246 controls various displays on the terminal device 300. The notification output unit 247 issues various notifications to the terminal device 300.

[0067] Next, with reference to FIGS. 4 to 9, the information managed by the transaction management device 200 of this embodiment will be described.

[0068] 4 is a diagram showing an example of individual information. The individual information 211 of this embodiment is stored in the individual information storage unit 210. The individual information 211 includes user information 212, payment condition information 213, and billing condition information 214. Note that the information included in the individual information 211 is not limited to the example shown in FIG. 4.

[0069] User information 212 is information for identifying a user, and includes information items such as user ID, name, and address, and is referenced when identifying a user. Payment terms information 213 indicates payment terms for each user. The payment terms include the closing date for the payment amount and the date on which the transaction supporter will pay the payment amount to the user. The payment date may also be indicated as a payment grace period during which payment is deferred, i.e., the payment due date. Billing terms information 214 indicates billing terms for each user. The billing terms include the closing date for the payment amount, a billing grace period during which the user is given a grace period to pay the bill amount to the transaction supporter, and the user's payment method. The period during which payment of the billing amount is deferred may also be indicated as a billing date.

[0070] The user's payment method included in the user information 212 may be selected by the user when the user information 212 is stored in the transaction management device 200.

[0071] The payment method that the user can select may be installment payment, advance payment, credit card payment, etc. The user's payment method may be changed by the user at any time the user desires.

[0072] In the example of Figure 4, it is assumed that there are users who have selected prepayment and credit card payment as their payment method, but in the following explanation it is assumed that all users have selected deferred payment as their payment method.

[0073] FIG. 5 is a diagram showing an example of transaction information. The transaction information 221 in this embodiment includes information items such as a transaction ID, a user ID of the provider, a user ID of the user, a transaction amount, a transaction type, a status, an order placement date, a shipping date, and transaction details. Note that the information items included in the transaction information 221 are not limited to the example shown in FIG. 5. For example, while FIG. 5 shows the transaction type as shipment of goods, this is not limiting and the transaction type may also be the provision of a service (such as work outsourcing, system use, or goods rental). In other words, the transaction information 221 can also be considered information regarding transactions conducted between users.

[0074] In the transaction information 221 of this embodiment, the transaction ID is identification information for identifying a transaction. The provider user ID is a user ID that identifies a user who has become a provider of a product or service in a transaction identified by the transaction ID. The user user ID is a user ID that identifies a user who has become a user of a product or service in a transaction identified by the transaction ID.

[0075] The provider's user ID and the user's user ID may be determined when an order is placed between the provider and the user. The user ID, which is part of the user information 212 stored in the individual information storage unit 210, is identification information that identifies a user of the transaction management system 100, and it is not determined whether the user identified by this user ID is a provider or a user.

[0076] In the transaction information 221, the transaction amount indicates the amount of money handled in the transaction. In the transaction information 221, the provider's user ID, the user's user ID, and the transaction amount are an example of relationship information that indicates the monetary credit / debt relationship between the provider and the user.

[0077] Furthermore, the transaction type in the transaction information 221 indicates the type of transaction, and the status indicates the status of the transaction. The order placement date indicates the date on which the provider accepted the order placed by the user. In other words, the order placement date indicates the date on which the order was placed. The shipping date indicates the date on which shipping was completed.

[0078] In this embodiment, when shipment from the provider is completed, the user's monetary debt to the provider is switched to the transaction supporter's debt to the provider, and the provider's monetary claim against the user is switched to the transaction supporter's claim against the user.

[0079] In other words, in this embodiment, when a value for the item "shipping date" is entered in the transaction information 221, the subject of the monetary credit and debt in this transaction is switched.

[0080] The timing at which the subject of monetary claims and obligations is switched is not limited to the time when the value of the item "Shipping Date" is entered, and this timing may be arbitrarily decided between the transaction supporter and the user. Also, the timing at which the subject of monetary claims and obligations is switched may be, for example, "when the user completes inspection" or "when the transaction supporter agrees to the transfer of each monetary claim."

[0081] FIG. 6 is a diagram showing an example of intermediary debt information. In this embodiment, the intermediary debt information 232 is generated for each user who will be a provider. In other words, the intermediary debt information 232 is associated with the user ID of the user who will be a provider. In the example of FIG. 6, the intermediary debt information 232 includes, as information items, a transaction ID, a user ID (user), a payment amount, a transaction type, a shipping date, a status, a payment date, etc. The transaction ID indicates identification information for identifying the transaction information 221. The user ID (user) indicates the user ID of the user who was the user in the transaction indicated by the transaction information 221 identified by the transaction ID.

[0082] The payment amount is the amount paid by the transaction supporter to the user who will be the provider. The payment amount is the transaction amount for the transaction indicated by the transaction information 221 identified by the transaction ID. The transaction type indicates the type of transaction indicated by the transaction information 221 identified by the transaction ID. The shipping date indicates the date on which the shipping was completed. The status indicates the status of the transaction indicated by the transaction information 221 identified by the transaction ID. The payment date indicates the payment date on which the transaction supporter pays the payment amount to the user who will be the provider. When the provider notifies the transaction management system 100 of the shipping date from the provider's terminal device 300 after completing shipping, the shipping date, which is the date on which the actual shipping was completed, may differ from the date on which the notification indicating that the shipping was completed is received. In this case, the transaction management system 100 may manage the date on which the actual shipping was completed as the shipping date, or the date on which the notification indicating that the shipping was completed is received as the shipping date.

[0083] 6 is an example of intermediary debt information generated from transaction information 221 when a user identified by user ID "X" becomes a provider, and is associated with user ID "X." Intermediary debt information 232-1 indicates a monetary debt owed by a transaction supporter to a user identified by user ID "X."

[0084] The intermediary debt information 232-2 is an example of intermediary debt information generated from the transaction information 221 when the user identified by the user ID "B" becomes the provider, and is associated with the user ID "B." The intermediary debt information 232-2 indicates the monetary debt of the transaction supporter to the user identified by the user ID "B."

[0085] The intermediary debt information 232-1 is generated from the transaction information 221 with the status "shipped" among the transaction information 221 when the user identified by the user ID "X" becomes the provider.

[0086] The payment amount in the intermediary debt information 232-1 is the transaction amount in the transaction information 221, and is the amount that was treated as a monetary claim of the user identified by user ID "X" in the transaction information 221. In the intermediary debt information 232-1, the monetary debt of each user who was a user in a transaction in which the user identified by user ID "X" was the provider is managed as a debt of the transaction supporter.

[0087] The intermediary debt information 232-2 is generated from the transaction information 221 with the status "shipped" among the transaction information 221 when the user identified by the user ID "B" becomes the provider.

[0088] The payment amount in the intermediary debt information 232-1 is the transaction amount in the transaction information 221, and is the amount that was treated as a monetary claim of the user identified by user ID "B" in the transaction information 221. In the intermediary debt information 232-2, the monetary debts of each user who was a user in a transaction in which the user identified by user ID "B" was the provider are managed as debts of the transaction supporter.

[0089] In addition, the intermediary debt information 232 stored in Figure 6 may be erased from the transaction management information storage unit 230 if the transaction supporter has paid the payment amount notified to the provider by the transaction supporter to the provider (if a payment has been entered into the transaction management system 100).

[0090] FIG. 7 is a diagram showing an example of intermediary claim information. In this embodiment, the intermediary claim information 233 is generated for each user who will be the user. In other words, the intermediary claim information 233 is associated with the user ID of the user who will be the user. In the example of FIG. 7, the intermediary claim information 233 includes, as information items, a transaction ID, a user ID (provider), a billing amount, a transaction type, a shipping date, a status, a billing deadline, etc. The transaction ID indicates identification information for identifying the transaction information 221. The user ID (provider) indicates the user ID of the user who was the provider in the transaction indicated by the transaction information 221 identified by the transaction ID.

[0091] The billing amount is the amount billed by the transaction supporter to the user who will become a user. The billing amount is the transaction amount for the transaction indicated by the transaction information 221 identified by the transaction ID. The transaction type indicates the type of transaction indicated by the transaction information 221 identified by the transaction ID. The shipping date indicates the date on which the transaction management device 200 received notification indicating that the shipment was completed. The status indicates the status of the transaction indicated by the transaction information 221 identified by the transaction ID. The billing deadline indicates the payment due date (i.e., the billing deadline) by which the user, who was a user, pays the billing amount to the transaction supporter.

[0092] 7 is an example of intermediary claim information generated from transaction information 221 when a user identified by user ID "X" becomes a user, and is associated with user ID "X." Intermediary claim information 233-1 indicates a monetary claim owed by a transaction supporter to a user identified by user ID "X."

[0093] The intermediary claim information 233-2 is an example of intermediary debt information generated from the transaction information 221 when the user identified by user ID "B" becomes a user, and is associated with user ID "B." The intermediary claim information 233-2 indicates the monetary claim of the transaction supporter against the user identified by user ID "B."

[0094] The intermediary claim information 233-1 is generated from transaction information with a status of "shipped" among the transaction information 221 when the user identified by the user ID "X" becomes a user.

[0095] The claim amount in the intermediary claim information 233-1 is the transaction amount in the transaction information 221, and is the amount that was treated as a monetary debt of the user identified by user ID "X" in the transaction information 221. In the intermediary claim information 233-1, the monetary claims of each user who was a provider in a transaction in which the user identified by user ID "X" became the user are managed as claims of the transaction supporter.

[0096] The intermediary claim information 233-2 is generated from transaction information with a status of "shipped" among the transaction information 221 when the user identified by the user ID "B" becomes a user.

[0097] The claim amount in the intermediary claim information 233-2 is the transaction amount in the transaction information 221, and is the amount that was treated as the monetary claim of the user identified by user ID "B" in the transaction information 221. In the intermediary claim information 233-2, the monetary claims of each user who was the provider in a transaction in which the user identified by user ID "B" became the user are managed as claims of the transaction supporter.

[0098] In addition, the intermediary claim information 233 stored in Figure 7 may be erased from the transaction management information storage unit 230 when the payment of the claim amount notified to the user by the transaction supporter is made by the user who will become the user to the transaction supporter (when an input is made to the transaction management system 100 indicating that payment of the claim amount has been completed).

[0099] In this manner, in this embodiment, in the intermediary debt information 232, the monetary debt of the user to the provider in the transaction information 221 is managed as a debt of the transaction supporter to the provider, and in the intermediary credit information 233, the monetary credit of the provider to the user in the transaction information 221 is managed as a credit of the transaction supporter to the user.

[0100] This embodiment realizes the transaction supporter assuming the monetary debt without any liability when the user becomes a user.

[0101] 8 is a diagram showing an example of credit information. Credit information 236 is information that associates a user ID, a transaction limit set in advance for each user, and the remaining debt to the transaction supporter and provider when the user conducts a transaction as a user. The transaction limit may be determined by the administrator (transaction supporter) of the transaction management system 100 based on, for example, the number of transactions the user has conducted in the past, whether or not there have been any late payments, the size of the transaction amount, etc.

[0102] Furthermore, the remaining debt to the transaction supporter when a user has conducted a transaction as a user is the sum of the invoice amounts included in the intermediary credit information 233 associated with the user ID of the user. Furthermore, the remaining debt to the provider when a user has conducted a transaction as a user is the sum of the transaction amounts in the transaction information 221 associated with the user ID of the user that does not have a status of "shipped" (transaction information 221 that has not been used to generate the intermediary credit information 233).

[0103] In addition, in this embodiment, if the intermediary claim information 233 for which the invoice amount has been paid is retained in the transaction management information storage unit 230 for a certain period of time, the remaining debt to the transaction supporter when the user conducts a transaction as a user will be the sum of the unpaid invoice amount included in the intermediary claim information 233 associated with the user ID who will become the user.

[0104] In this embodiment, when a payment completion status for an unpaid invoice amount for a user is input into the transaction management device 200, or when the paid amount is input into the transaction management device 200, the remaining debt of the user is changed. Also, while the credit information 236 is information that manages the user, credit limit, and remaining debt in association with each other, this is not limited to this, and for example, the credit balance, which is the credit limit minus the remaining debt, may be managed in association with the user. Furthermore, this credit information 236 may be managed together with user information.

[0105] 9 is a diagram showing an example of billing and payment amount information. Billing and payment amount information 237-1 is information that associates payment terms agreed upon by the user linked to terminal device 300B and the transaction supporter with the payment amount to be paid by the transaction supporter to the user linked to terminal device 300B.

[0106] The payment amount here is the total transaction amount extracted from the transaction information 221 of transactions in which the user associated with terminal device 300B was the provider, among transactions conducted during the period from the day after the closing date agreed upon by the user associated with terminal device 300B and the transaction supporter to the next closing date. The payment amount indicated by the billing / payment amount information 237-1 is 17,000 yen.

[0107] Billing / payment amount information 237-2 is information that associates the billing terms agreed upon by the user linked to terminal device 300B and the transaction supporter with the billing amount to be billed by the transaction supporter to the user linked to terminal device 300B.

[0108] The billing amount here is the total transaction amount extracted from the transaction information of transactions in which the user associated with terminal device 300B was the user, among transactions conducted during the period indicated by the billing conditions agreed upon between the user associated with terminal device 300B and the transaction supporter. The billing amount indicated by billing / payment amount information 237-2 is 28,000 yen.

[0109] Billing / payment amount information 237-3 is information showing the amount obtained by offsetting the payment amount shown in billing / payment amount information 237-1 with the billing amount shown in billing / payment amount information 237-2. Since the payment amount shown in billing / payment amount information 237-1 is 17,000 yen and the billing amount shown in billing / payment amount information 237-2 is 28,000 yen, when the payment amount and the billing amount are offset, the billing amount is 11,000 yen.

[0110] Therefore, the transaction management device 200 may notify the terminal device 300B linked to the user identified by user ID "B" of the invoice amount of "11,000 yen" and the invoice date of "5 / 20" as a result of offsetting the payment amount and the invoice amount.

[0111] The billing / payment amount information 237-4 is information that associates the payment terms agreed upon by the user linked to the terminal device 300X and the transaction supporter with the payment amount to be paid by the transaction supporter to the user linked to the terminal device 300X.

[0112] The payment amount here is the total transaction amount extracted from the transaction information of transactions in which the user associated with terminal device 300X was the provider, among transactions conducted during the period from the day after the closing date agreed upon by the user associated with terminal device 300X and the transaction supporter to the next closing date. The payment amount indicated by billing / payment amount information 237-4 is 36,000 yen.

[0113] Billing / payment amount information 237-5 is information that associates the billing terms agreed upon by the user linked to terminal device 300B and the transaction supporter with the billing amount to be billed by the transaction supporter to the user linked to terminal device 300X.

[0114] The billing amount here is the total transaction amount extracted from the transaction information of transactions in which the user linked to the terminal device 300X was the user, among transactions carried out during the period indicated by the billing conditions agreed upon between the user linked to the terminal device 300X and the transaction supporter. The billing amount indicated by the billing / payment amount information 237-5 is 22,000 yen.

[0115] The billing / payment amount information 237-6 is information indicating the amount obtained by offsetting the payment amount indicated by the billing / payment amount information 237-4 with the billing amount indicated by the billing / payment amount information 237-5. The payment amount indicated by the billing / payment amount information 237-4 is 36,000 yen, and the billing amount indicated by the billing / payment amount information 237-5 is 22,000 yen, so when the payment amount and the billing amount are offset, the payment becomes 14,000 yen.

[0116] Therefore, the transaction management device 200 may notify the terminal device 300B linked to the user identified by user ID "B" of the invoice amount of "11,000 yen" and the invoice date of "5 / 20" as a result of offsetting the payment amount and the invoice amount.

[0117] In this embodiment, the amounts billed and paid to the transaction supporter are tallied and managed for each user.

[0118] Next, the operation of the transaction management system 100 of this embodiment will be described. Figure 10 is a sequence diagram explaining the operation of the transaction management system. Figure 10 shows the operation of the transaction management system 100 when a transaction is conducted in which the user linked to terminal device 300B is the customer and the user linked to terminal device 300X is the provider. In addition, the payment method of the user linked to terminal device 300B is assumed to be installment payment.

[0119] In the following description, the user associated with terminal device 300B will be referred to as the user identified by user ID "B", and the user associated with terminal device 300X will be referred to as the user identified by user ID "X".

[0120] 10 is executed every time a transaction is made between a user and a provider. The processes of steps S1010 to S1013 in FIG. 10 are executed at regular intervals and may be executed at timings independent of the timings at which the processes of steps S1001 to S1009 are executed.

[0121] In transaction management system 100, transaction management device 200 notifies transaction management device 200 of the order specifications from terminal device 300X (step S1001). Transaction management device 200 also receives an order instruction from terminal device 300B to order a product or service for a user associated with terminal device 300X (step S1002). The order specifications may correspond to a usage application sent from the user's terminal device 300B, or may be specifications indicating the products or services that the provider can provide.

[0122] When the transaction management device 200 receives the order instruction, the credit confirmation unit 245 performs a credit confirmation process to confirm the credit of the user associated with the terminal device 300B (step S1003). The process of step S1003 will be described in detail later.

[0123] The processing from step S1004 onwards is processing when installment payment is permitted for the user linked to the terminal device 300B in step S1003.

[0124] When the transaction management device 200 approves the installment payment of the user linked to the terminal device 300B, the notification output unit 247 sends a notification to the terminal device 300B indicating that the order has been received (step S1004).

[0125] Next, the transaction management device 200 performs order entry processing (step S1005). Specifically, the transaction management device 200 uses the information generation unit 242 to generate transaction information 221 corresponding to the order accepted in step S1002 and stores the generated transaction information in the transaction information storage unit 220. The transaction management device 200 may automatically execute order entry processing after the credit confirmation process, or may execute order entry processing after inquiring with the provider about whether the order can be accepted and receiving confirmation from the provider that the order can be accepted. In this embodiment, the transaction ID included in the transaction information 221 may be generated during the order entry processing in step S1005, or the transaction ID may be generated when the transaction management device 200 accepts an order application from the user's terminal device 300B.

[0126] Next, the transaction management device 200 transmits a notification to the terminal device 300X indicating that the order from the user associated with the terminal device 300B has been received (step S1006). This notification may include a transaction ID that identifies the transaction information 221 generated in step S1005.

[0127] Next, when transaction management device 200 receives a notification from terminal device 300X indicating that the shipment of the ordered product has been completed (step S1007), information update unit 243 updates transaction information 221 generated in step S1005 (step S1008). Specifically, information update unit 243 inputs the notified date of completion of shipment into the "shipping date" of transaction information 221 generated in step S1005, and changes the status to "shipped."

[0128] Next, the transaction management device 200 performs a process of switching the subject of the monetary credit and debt in the transaction information 221 generated in step S1005 to the transaction supporter (step S1009). The process of step S1009 will be described in detail later.

[0129] In this manner, in this embodiment, every time a new transaction is made, the intermediary debt information 232 and the intermediary credit information 233 are generated from the new transaction information 221 .

[0130] 10 is performed after the user identified by the user ID "X" has completed shipping, in other words, the process of step S1010 in Fig. 10 is a process for generating the billing / payment amount information 237. This process may be performed at a different timing from the process of steps S1001 to S1006 in Fig. 10.

[0131] The processing of step S1010 in Figure 10 is processing in which the transaction management device 200 calculates the total payment amount and the total billing amount for each user linked to the terminal device 300. In other words, the processing of step S1010 in Figure 10 is processing in which billing / payment amount information 237 for the user identified by user ID "B" and billing / payment amount information 237 for the user identified by user ID "X".

[0132] The process of step S1010 in Fig. 10 is executed according to the payment conditions and billing conditions for each user. The process of step S1010 will be described in detail later.

[0133] The transaction management device 200 transmits the payment amount and invoice amount calculated in step S1010 to the terminal device 300X via the notification output unit 247 (step S1011). The transaction management device 200 also transmits the payment amount and invoice amount calculated in step S1010 to the terminal device 300B via the notification output unit 247 (step S1012).

[0134] Next, the credit confirmation process of transaction management device 200 in step S1003 will be described with reference to Figure 11. Figure 11 is a first flowchart illustrating the process of transaction management device 200.

[0135] The credit confirmation unit 245 of the transaction management device 200 of this embodiment refers to the credit information 236 and obtains the maximum transaction amount associated with the user ID of the user included in the transaction information 221 identified by the transaction ID linked to the terminal device 300 that sent the order instruction in step S1002 (step S1101).

[0136] Next, the transaction management device 200, through the amount calculation unit 244, acquires the planned order amount, which is the planned amount to be ordered by the user linked to the terminal device 300B in the transaction (step S1102).

[0137] Next, the amount calculation unit 244 of the transaction management device 200 references the credit information 236 and obtains the remaining debt associated with the user ID of the user included in the transaction information 221 identified by the transaction ID generated in step S1005. The amount calculation unit 244 then determines whether the sum of the remaining debt and the planned order amount is greater than the upper transaction limit (step S1103).

[0138] In step S1103, if the sum of the remaining debt and the planned order amount is greater than the upper transaction limit, the transaction management device 200 notifies the terminal device 300 associated with the user that the installment payment is prohibited (step S1104).In step S1103, if the sum of the debt and the planned order amount is equal to or less than the upper transaction limit, the transaction management device 200 notifies the terminal device 300 associated with the user that the order is permitted (step S1105).

[0139] In this embodiment, if the sum of the remaining debt and the planned order amount is greater than a predetermined range from the transaction upper limit, the transaction management device 200 may prohibit the installment payment. Furthermore, if the total is within a predetermined range from the transaction upper limit, the transaction management device 200 may notify the transaction supporter that the installment payment is permitted by accepting approval. This process prevents situations where a small excess in credit approval requires a change in payment method, improving transaction convenience. In this embodiment, the credit balance, which is the transaction upper limit minus the remaining debt, may be managed in advance, and the planned order amount may be compared with the credit balance.

[0140] Next, the processing of step S1009 in Fig. 10 will be described with reference to Fig. 12. Fig. 12 is a second flowchart illustrating the processing of the transaction management device.

[0141] The transaction management device 200 of this embodiment extracts relationship information indicating the relationship between the monetary claims and debts between the user and the provider from the transaction information 221 generated in step S1005 (step S1201). Next, the transaction management device 200, using the information generation unit 242, generates intermediary debt information 232 in which the monetary debts of the user to the provider are treated as debts of the transaction supporter to the provider, and adds this to the intermediary debt information 232 associated with the user (step S1202).

[0142] Next, the information generating unit 242 generates intermediary claim information 233 in which the provider's monetary claim against the user is treated as a claim against the transaction supporter's user, and adds the generated intermediary claim information 233 to the transaction supporter (step S1203). Note that the order of the processing of step S1202 and step S1203 is not limited to that shown in FIG. 14.

[0143] In this embodiment, by generating intermediary debt information 232 and intermediary credit information 233 from transaction information 221, the user's monetary debt in the transaction is converted into a debt of the transaction supporter, and the provider's monetary credit in the transaction is converted into a credit of the transaction supporter.

[0144] Next, the transaction management device 200 sums up the payment amounts in the intermediary debt information 232 corresponding to the user ID of the user using the amount calculation unit 244 (step S1204). The summed payment amount may be stored as the payment amount in the billing / payment amount information 237 associated with the user ID of the user.

[0145] The amount calculation unit 244 also sums up the claim amounts in the intermediary claim information 233 corresponding to the user ID of the user who is the provider (step S1205). The summed claim amount may be stored as the claim amount in the claim / payment amount information 237 associated with the user ID of the user who is the provider.

[0146] Next, with reference to FIG. 13, a process in which the transaction management device 200 calculates the total payment amount and the total bill amount for each user associated with the terminal device 300 will be described.

[0147] 13 is a third flowchart illustrating the processing of the transaction management device, showing details of the processing of step S1010 in FIG.

[0148] The amount calculation unit 244 of the transaction management device 200 refers to the billing condition information 214 corresponding to the user ID of each user, and totals the billing amount for each user according to the billing conditions (step S1301).

[0149] Specifically, the amount calculation unit 244 adds up the billing amounts included in the intermediary credit information 233 corresponding to the user ID, whose shipping date is within the billing period determined based on the billing closing date indicated in the billing conditions.

[0150] Next, the amount calculation unit 244 totals the payment amounts to the user according to the payment terms corresponding to the user ID (step S1303). Specifically, the amount calculation unit 244 totals the payment amounts included in the intermediary debt information 232 corresponding to the user ID, the shipping date of which falls within the payment target period determined based on the payment closing date indicated in the payment terms.

[0151] Next, the amount calculation unit 244 calculates an offset amount by offsetting the billed amount totaled in step S1302 with the payment amount totaled in step S1303 (step S1304).

[0152] Next, the amount calculation unit 244 transmits the total billing amount, total payment amount, and offset amount calculated in steps S1302 to S1304 to the terminal device 300 (step S1306). Note that the information transmitted to the terminal device 300 here may be the total billing amount and total payment amount, and the offset amount does not have to be transmitted to the terminal device 300. The offset amount calculated here for each user may be associated with the user ID and stored in the transaction management information storage unit 230 as part of the billing / payment amount information 237.

[0153] In this way, the transaction assistant calculates the total billed amount and the total payment amount in accordance with the billing terms and payment terms agreed upon with the user.

[0154] Therefore, the user of the transaction management system 100 only needs to decide on the billing terms and payment terms with the transaction supporter, and does not need to decide on the billing terms and payment terms individually with other users.

[0155] For example, consider a case where a user identified by user ID "B" conducts transactions with a user identified by user ID "X" and a user identified by user ID "Y." In this case, the user identified by user ID "B" needs to negotiate billing and payment terms individually with each of the users identified by user ID "X" and user ID "Y." In such a case, the user conducting the transaction may be required to compromise on closing dates and payment terms to meet the wishes of the other party.

[0156] In contrast, in this embodiment, even when a user is conducting transactions with multiple users, the billing terms and payment terms can be terms agreed upon only with the transaction supporter.

[0157] In the above embodiment, the case where the transaction type in the transaction information 221 is "shipment" has been described, but the transaction information 221 may include other types in the transaction type. The other types may be, for example, cancellation of a transaction that has already been completed, or changes to the transaction content, including an increase or decrease in the transaction amount.

[0158] The transaction information 221A including "change" in the transaction type will be described below with reference to Fig. 14. Fig. 14 is a diagram showing another example of transaction information.

[0159] The transaction information 221A in Fig. 14 includes information items such as a transaction ID, a user ID of the provider, a user ID of the user, a transaction amount, a transaction type, a status, an order placement date, a shipping date, a change date, and transaction details. Note that the information items included in the transaction information 221 are not limited to the example shown in Fig. 14. The item "change date" in Fig. 14 indicates the date on which the transaction details were changed.

[0160] In the example of Figure 14, if the transaction type is "change," the intermediary debt information 232 and intermediary claim information 233 may be generated based on the transaction information 221A at the time the change date, which is the date on which the transaction content was changed, is entered into the transaction information 221A.

[0161] 14, transaction information 221A includes transaction information 221A-1 and 221A-2 identified by transaction ID "1." Transaction information 221A-1 indicates a transaction in which a user identified by user ID "X" is the provider, a user identified by user ID "B" is the user, and a product is shipped for a transaction amount of 3,000 yen. Transaction information 221A-2 indicates that the transaction amount for the transaction identified by transaction ID "1" is to be changed from 3,000 yen to an amount reduced by 1,000 yen.

[0162] In the transaction management device 200, when transaction information 221A-2 is generated indicating a change in the transaction content of a transaction for which a transaction ID already exists, the information generation unit 242 generates new intermediary debt information 232 and intermediary claim information 233 based on this transaction information 221A-2.

[0163] 14, transaction information 221A includes transaction information 221A-3 and 221A-4 identified by transaction ID "7." Transaction information 221A-3 indicates a transaction in which a user identified by user ID "B" is the provider, a user identified by user ID "X" is the user, and a product is shipped for a transaction amount of 5,000 yen. Transaction information 221A-4 indicates that the transaction amount for the transaction identified by transaction ID "7" is to be changed from 5,000 yen to an amount reduced by 2,000 yen.

[0164] In the transaction management device 200, when transaction information 221A-4 is generated indicating a change in the transaction content of a transaction for which a transaction ID already exists, the information generation unit 242 generates new intermediary debt information 232 and intermediary credit information 233 based on this transaction information 221A-4.

[0165] 15 is a diagram showing another example of intermediary obligation information. Intermediary obligation information 232A-1 shown in FIG. 15 is an example of intermediary obligation information generated from transaction information 221A when a user identified by user ID "X" becomes a provider, and includes a change date in the information fields.

[0166] The intermediary obligation information 232A-11 is intermediary obligation information generated from the transaction information 221A-1, and the intermediary obligation information 232A-12 is intermediary obligation information generated from the transaction information 221A-2.

[0167] In the intermediary debt information 232A-1 in Figure 15, the shipping date of the intermediary debt information 232A-11 and the change date of the intermediary debt information 232A-12 are both included in the payment period up to the payment date, so the payment amount of the intermediary debt information 232A-11 and the payment amount of the intermediary debt information 232A-12 are added together with other payment amounts.

[0168] The intermediary debt information 232A-2 shown in Figure 15 is an example of intermediary debt information generated from transaction information 221A when the user identified by user ID "B" becomes the provider, and includes the change date in the information fields.

[0169] The intermediary obligation information 232A-21 is intermediary obligation information generated from the transaction information 221A-3, and the intermediary obligation information 232A-22 is intermediary obligation information generated from the transaction information 221A-4.

[0170] In the intermediary debt information 232A-2 in Figure 15, the shipping date of the intermediary debt information 232A-21 and the change date of the intermediary debt information 232A-22 are both included in the payment period up to the payment date, so the payment amount of the intermediary debt information 232A-21 and the payment amount of the intermediary debt information 232A-22 are added together with other payment amounts.

[0171] Figure 16 is a diagram showing another example of intermediary claim information. Intermediary claim information 233A-1 shown in Figure 16 is an example of intermediary claim information generated from transaction information 221A when a user identified by user ID "X" becomes a user, and includes the change date as an information item.

[0172] The intermediary claim information 233A-11 is intermediary claim information generated from the transaction information 221A-3, and the intermediary claim information 233A-12 is intermediary claim information generated from the transaction information 221A-4.

[0173] In the intermediary claim information 233A-1 in Figure 16, the shipping date of the intermediary claim information 233A-11 and the change date of the intermediary claim information 233A-12 are both included in the billing period up to the billing deadline, so the billing amount of the intermediary claim information 233A-11 and the billing amount of the intermediary claim information 233A-12 are added together with other billing amounts.

[0174] The intermediary claim information 233A-2 shown in Figure 16 is an example of intermediary claim information generated from transaction information 221A when a user identified by user ID "B" becomes a user, and includes the change date in the information fields.

[0175] The intermediary claim information 233A-21 is intermediary claim information generated from the transaction information 221A-1, and the intermediary claim information 233A-22 is intermediary claim information generated from the transaction information 221A-2.

[0176] In the intermediary claim information 233A-2 in Figure 16, the shipping date of the intermediary claim information 233A-21 and the change date of the intermediary claim information 233A-22 are both included in the billing period up to the billing deadline, so the billing amount of the intermediary claim information 233A-21 and the billing amount of the intermediary claim information 233A-22 are added together with other billing amounts.

[0177] In this embodiment, even if the content (transaction amount) of a past transaction is changed, the subject of the changed monetary credit and debt can be switched to the transaction supporter. More specifically, normally, if an adjustment in the amount occurs after payment in a transaction between user X and user Q, user X must transfer money to the counterparty for each transaction, such as by refunding user Q. However, by switching the monetary credit and debt to the transaction supporter as in this embodiment, even if an adjustment in the amount occurs after payment, the adjustment can be made during the payment or billing process with the transaction supporter, as shown in 233A-1 in FIG. 16.

[0178] In this embodiment, processing for the change may be performed based on the shipping date (the timing for switching between monetary credits and debts), the change date, and the change content. For example, if the change date is before the shipping date, the credit / debt switching process and the invoice payment calculation process may be performed based on the shipping date rather than the change date. Also, if the change date is after the shipping date, the credit / debt processing and the invoice payment process may be performed on the shipping date based on the amount before the change (transaction amount), and the credit / debt switching process and the invoice payment calculation process may be performed on the change date based on the amount of the difference.

[0179] In addition, different processing may be used when the change is a cancellation. For example, if a free cancellation is made before the shipping date, the transaction is not subject to the receivable / debt switching process or the invoice payment amount calculation process. In addition, if a free cancellation is made after the shipping date, the monetary receivables and debts that were switched to the transaction supporter on the shipping date will be extinguished on the change date. In addition, if a paid cancellation is made before the shipping date, the receivable / debt switching process will be performed on the change date for the cancellation amount. In addition, if a paid cancellation is made after the shipping date, the monetary receivables and debts that were switched to the shipping date will be extinguished on the change date, and the receivable / debt switching process will be performed on the change date for the cancellation amount.

[0180] This allows for the switching of monetary claims and obligations due to changes to be processed.

[0181] Next, examples of displays on the terminal device 300 will be described with reference to FIGS.

[0182] Fig. 17 is a first diagram showing an example of a display on a terminal device. Screen 301A shown in Fig. 17 shows an example of a screen when the total billing amount transmitted to terminal device 300B in step S1012 of Fig. 10 is displayed on terminal device 300B.

[0183] Screen 301A has a display area 314, which displays the total billing amount calculated according to the billing conditions of the user identified by user ID "B." The billing amount here is the amount billed by the transaction supporter to the user identified by user ID "B." In other words, the billing amount shown in FIG. 14 is the total monetary debt owed to each of multiple providers by the user identified by user ID "B" as a result of the user receiving goods or services from multiple providers during the billing period specified by the billing conditions. While FIG. 17 displays a breakdown of the amounts of transactions between the trading partner users (Partners X, Y, and M) and each user, a simple total billing amount may be displayed on screen 301A.

[0184] In this embodiment, the transaction supporter bills the user for monetary obligations to multiple providers in a lump sum. Therefore, according to this embodiment, even if a user of transaction management system 100 acts as a user and transacts with multiple providers, the user does not need to make payments to each provider for each transaction.

[0185] 18 is a second diagram showing an example of a display on the terminal device. Screen 301B shown in Fig. 18 shows an example of a screen when the total payment amount transmitted to terminal device 300X is displayed on terminal device 300X.

[0186] Screen 301B has a display area 315 that displays the total payment amount calculated according to the payment terms of the user identified by user ID "X." The payment amount here is the amount paid by the transaction supporter to the user identified by user ID "X." In other words, the payment amount shown in FIG. 18 is the total of monetary claims owed to each of multiple users that arose when the user identified by user ID "X" provided goods or services to those users during the payment period specified by the payment terms. While FIG. 18 displays a breakdown of the amounts of transactions between the trading partner users (customers B, C, D, and E) and each user, a simple total payment amount may also be displayed on screen 301B.

[0187] In this embodiment, the transaction supporter pays the provider a lump sum of the total monetary claims owed to multiple users. Therefore, according to this embodiment, even if a user of the transaction management system 100 acts as a provider and transacts with multiple users, the user who acts as the provider does not need to bill each user for each transaction. Furthermore, the provider does not need to bill each user according to their billing terms, and can receive payment from the transaction supporter based on the provider's payment terms agreed upon between the transaction supporter and the provider.

[0188] Therefore, according to this embodiment, it is possible to simplify the management of transactions and promote transactions.

[0189] In this embodiment, a method for identifying a user (including a user or a provider) associated with the terminal device 300 may involve, for example, storing the device ID of the terminal device 300 in association with a user ID in a storage device, and identifying the user based on the user ID stored in association with the device ID transmitted from the terminal device 300 during communication with the terminal device 300. Also, for example, when a user logs in to a web service provided by the transaction management device 200 via a browser or application on the terminal device 300, the user may be identified based on the user ID used for logging in.

[0190] Here, we will explain the transaction information 221 acquired by the transaction management device 200 of this embodiment. The transaction information 221 of this embodiment may be, for example, transaction information related to transactions conducted on a transaction support platform provided by a business operator that manages the transaction management system 100.

[0191] The transaction support platform is a platform where a transaction supporter supports transactions conducted directly between a provider and a user who is a user of the transaction management system 100. In this case, the transaction management system 100 does not need to have a transaction information storage unit 220, and only needs to acquire transaction information stored in a transaction support database managed by the transaction support platform.

[0192] Furthermore, the transaction information 221 of this embodiment may be, for example, transaction information regarding transactions conducted on a first direct transaction platform provided by a business operator managing the transaction management system 100. The first direct transaction platform may be an EC (Electronic Commerce) site or the like provided by an administrator managing the transaction management system 100. In this case, the transaction management system 100 does not need to have a transaction information storage unit 220, and may simply acquire transaction information stored in a first direct transaction database managed by the first direct transaction platform. Note that the user interface provided by the transaction management system 100 of this embodiment and the user interface provided by the first direct transaction platform may be displayed on the same screen.

[0193] Furthermore, in this first direct trading platform, a user of the trading management system 100 may provide to other users the goods or services purchased from the administrator of the trading management system 100. In other words, in the first direct trading platform, a trading assistant in the trading management system 100 may provide goods or services to multiple providers who are users of the trading management system 100.

[0194] Therefore, the transaction information acquired by the transaction management device 200 from the first direct transaction database includes first direct transaction information including relationship information indicating a monetary credit / debt relationship in which the transaction supporter is the creditor and the user who provided the product or service provided by the transaction supporter to another user is the debtor. In other words, the user who provided the product or service provided by the transaction supporter to another user is the user of the transaction management system 100 who is the provider.

[0195] In this way, by linking the first direct trading platform with the trading management system 100, the amount billed to the user who is the provider in the trading management system 100 can include the amount billed by the trading supporter for the goods or services purchased by the user from the trading supporter.

[0196] Furthermore, the transaction information 221 in this embodiment may be, for example, transaction information regarding transactions conducted on a second direct transaction platform provided by a business operator that manages the transaction management system 100. The second direct transaction platform may be an e-commerce site or the like provided by an administrator that manages the transaction management system 100. In this case, the transaction management system 100 does not need to have a transaction information storage unit 220, and may simply acquire transaction information stored in a second direct transaction database managed by the second direct transaction platform.

[0197] In addition, in this second direct trading platform, users of the trading management system 100 may use products or services provided by the administrator of the trading management system 100. In other words, in the second direct trading platform, users of the trading management system 100 may use products or services provided by the trading assistant.

[0198] Therefore, the transaction information acquired by the transaction management device 200 from the second direct transaction database includes second direct transaction information including relationship information indicating a monetary credit-debt relationship between the transaction supporter as the creditor and the user who has used the product or service provided by the transaction supporter as the debtor. In other words, a user who has used the product or service provided by the transaction supporter is a user among the users of the transaction management system 100.

[0199] In this way, by linking the second direct trading platform with the trading management system 100, the amount billed to a user who becomes a user of the trading management system 100 can include the amount billed by the trading supporter for the goods or services purchased by the user from the trading supporter.

[0200] In addition, the first direct trading platform and the second direct trading platform may be the same platform.

[0201] Furthermore, the transaction information 221 in this embodiment may be, for example, transaction information related to a transaction conducted on a procurement platform provided by a business operator that manages the transaction management system 100. The procurement platform may be an e-commerce site or the like provided by an administrator that manages the transaction management system 100. In this case, the transaction management system 100 does not need to have a transaction information storage unit 220, and may simply acquire transaction information stored in a procurement database managed by the procurement platform.

[0202] In addition, in this procurement platform, an administrator of the transaction management system 100 may procure goods or services from users of the transaction management system 100. In other words, in the procurement platform, an administrator of the transaction management system 100 may use (procure) goods or services provided by users of the transaction management system 100.

[0203] Therefore, the transaction information acquired by the transaction management device 200 from the procurement database includes procurement information including relationship information indicating a monetary credit-debt relationship between the user who provided the product or service to the transaction supporter as the creditor and the transaction supporter as the debtor. In other words, the user who provided the product or service to the transaction supporter is the user of the transaction management system 100 who is the provider.

[0204] In this way, by linking the procurement platform with the transaction management system 100, the amount paid to a user who is a provider in the transaction management system 100 can include the amount paid by the transaction supporter for goods or services provided by this user to the transaction supporter.

[0205] In the above example, the transaction information 221 is managed on a platform, and the transaction management device 200 acquires the transaction information 221 managed on the platform, but this is not limited to this. The transaction information 221 may be provided to the transaction management device 200 via the provider and user conducting the transaction. The transaction information 221 acquired via the provider and user is information regarding transactions conducted on an external platform (non-managed transaction platform) that is not managed by the administrator of the transaction management system 100.

[0206] The transaction management device 200 of this embodiment may acquire transaction information 221 from the terminal device 300 when a user becomes a user in a transaction conducted via an unmanaged transaction platform, or when a user becomes a provider.

[0207] In this way, the transaction management system 100 can be linked to the non-managed transaction platform. Specifically, transactions conducted via the transaction management system 100 and transactions not conducted via the transaction management system 100 can be linked to monetary credit and debt relationships between the transaction supporter and the user, so the user can transfer money by making payments or requests to the transaction supporter without having to manage the requests and payments for each transaction.

[0208] (Variations) Below, a variation of the embodiment will be described with reference to Figures 19 to 21. In this variation, the payment method selected by the user of the transaction management system 100 includes credit card or prepayment. In this case, the transaction management information storage unit 230 of the transaction management device 200 includes deposit information 234 and agent receipt information 235.

[0209] Here, the deposit information 234 and the agent receipt information 235 will be described with reference to FIGS.

[0210] 19 is a diagram showing an example of deposit information. The deposit information 234 is information that associates the amount paid by the user to the transaction supporter as an advance payment with the user ID and the name of the user identified by the user ID.

[0211] 20 is a diagram showing an example of the proxy receipt information. The proxy receipt information 235 is information that associates the amount that a transaction supporter receives from an external financial institution on behalf of a user who is a provider with the user ID of the user who is a provider. The proxy receipt information 235 includes, for example, information items such as a transaction ID, user ID, proxy receipt, and status.

[0212] In addition, as a payment method other than advance payment and credit card payment, proxy payment without payment guarantee to the provider may also be used. For example, in a transaction in which a user incurs a debt of 500,000 yen, the transaction supporter may not pay the provider 500,000 yen until the user pays 500,000 yen, or the transaction supporter may pay the provider 500,000 yen, but if the user does not pay in accordance with the billing terms, the transaction supporter may refund the 500,000 yen paid to the provider. In such a case, the proxy receipt information shown in FIG. 20 may include the amount to be received from the user, whether the user has paid the amount, and a status indicating whether payment to the provider has been completed.

[0213] Furthermore, when a user makes a transaction that exceeds the credit limit, the transaction management system 100 may permit the user to make the transaction by selecting a payment method that accepts payment from an agent other than the user and the transaction supporter, and manage information related to the transaction in the agent receipt information 235. For example, the transaction management system 100 may manage the amount of payment that the transaction supporter receives from an agent, including an external financial institution, and a status indicating the payment status, such as for transactions using credit cards or other installment payment providers (payment methods in which the agent accepts payment from the user after making a payment to the transaction supporter or reserving a payment with the transaction supporter). Furthermore, the transaction supporter may collect the amount from the user, or the agent may collect the amount. Therefore, the agent receipt information 235 may include information such as the user's payment method, including credit card and prepayment, the receivable collection method, and the collection entity. This enables the transaction management system 100 to complete transactions that exceed the user's credit limit.

[0214] Furthermore, when a user makes a transaction that exceeds the credit limit, the transaction management system 100 may allow the user to make a transaction by setting a guarantor who guarantees the transaction between the user and the transaction supporter, and may manage information related to the transaction in the proxy receipt information 235. Note that the guarantor may be different from the user and the transaction supporter.

[0215] For example, when a user makes a transaction that exceeds the credit limit, the transaction management system 100 determines whether the user can assign a guarantor. If a guarantor can be assigned, the transaction management system 100 assigns a guarantor to the user's transaction and permits the user to make the transaction that exceeds the credit limit. In this case, the transaction management system 100 may manage guarantee information, such as a guarantor ID, a maximum guarantee amount, and guarantee conditions, for each transaction (associated with a transaction ID) or for each user (associated with a user ID). The transaction management system 100 may also determine whether to permit a user to make a transaction that exceeds the credit limit based on guarantee information, such as the guarantor's maximum guarantee amount and guarantee conditions, set for the transaction. In this way, the transaction management system 100 allows a third party to guarantee a transaction that exceeds the credit limit, enabling the transaction supporter and provider to appropriately receive payment. The transaction management system 100 may also determine whether to permit a transaction that exceeds the user's credit limit based on pre-set guarantee information, such as the guarantor's guarantee conditions and maximum guarantee amount, before the user makes a transaction that exceeds the credit limit. In addition, in the transaction management system 100, when a user makes a transaction that exceeds the credit limit, instead of the transaction management system 100 setting a guarantor, the user may set guarantee information such as guarantee conditions and maximum guarantee amount, and the transaction management system 100 may determine whether to allow the transaction that exceeds the user's credit limit.

[0216] In a modified example, for example, if a user who has selected installment payment as a payment method is prohibited from installing installment payment during credit verification, a screen for selecting either credit card payment or advance payment may be displayed on the terminal device 300 associated with the user. Also, as described above, if a payment method other than credit card payment or advance payment (such as payment using another agent or payment set by a guarantor) is selectable, the transaction management system 100 may display a screen on the terminal device 300 for the user to select one of these payment methods.

[0217] The transaction management system 100 may also automatically determine the payment method without receiving a selection input from the user. The transaction management system 100 may also determine the user's payment method based on information about the payment method previously set by the user, the credit limit, or the amount exceeding the credit limit.

[0218] The credit limit for each user may be a preset amount. When setting the amount, if the user is both a provider and a user, the amount may be set by adding the payment amount the user receives as a provider to the credit limit, or by subtracting the amount invoiced by the user as a user from the payment amount the user receives as a provider. This allows, for example, when a user who conducts large transactions as a provider conducts transactions using the transaction management system 100 as a user, to reflect the actual transaction status as a provider in addition to the preset credit limit, thereby allowing a more appropriate credit limit to be set. This also allows the user to conduct more transactions because the limit based on the actual transaction status is added to the preset credit limit.

[0219] FIG. 21 is a third diagram illustrating an example of a display on a terminal device.

[0220] The screen 301C shown in FIG. 21 may be displayed on the terminal device 300B in step S1104 of FIG.

[0221] More specifically, the screen 301C is an example of a screen that is displayed on the display of the terminal device 300B when the transaction amount of the user linked to the terminal device 300B is greater than the upper transaction limit.

[0222] Screen 301B has a display area 313 and operation buttons 312, and display area 313 displays selectable payment methods, such as credit card payment and advance payment. In this embodiment, for example, when a payment method is selected on screen 301C and operation button 312 is operated, terminal device 300C notifies transaction management device 200 of the payment method, and information update unit 243 updates user information 212.

[0223] In addition, in a modified example, if there are users who use multiple payment methods during the payment period or billing period for each user, the transaction management unit 240 may refer to the deposit information 234 or the agent receipt information 235 depending on the user's payment method, and calculate the total billing amount and the total payment amount.

[0224] In addition, if the payment method is changed in step S1104 of the credit confirmation processing shown in Figure 11, the transaction management device 200 may send the user's payment method to the provider's terminal device 300X in step S1006 of Figure 10.

[0225] Since the monetary debt that a transaction supporter can undertake is limited to a credit limit, transactions of amounts greater than this (or greater than a specified amount) are paid by other payment methods, such as proxy receipt or prepayment. Therefore, rather than transferring all of the monetary credits and debts of the user or provider to the transaction supporter, it may be possible for only some of the monetary credits and debts of the user or provider to be transferred to the transaction supporter. Furthermore, by performing such processing, the transaction supporter can manage the entire credits and debts of the transaction amount that are not its own credits or debts, including not only installment payments but also prepayments and credit card payments.

[0226] In addition, in this embodiment, the method of processing the confirmed amount may be changed between the time the amount is confirmed and the time the payment is made. For example, the invoice amount and the payment amount for a closing date at the end of May are offset, and if the invoice amount is larger, a notification is sent to invoice in accordance with the invoice terms, and if the payment amount is larger, a notification is sent to pay in accordance with the payment terms. For example, if the invoice amount of 1 million yen confirmed on the May closing date is three months from now, and the payment amount of 500,000 yen confirmed on the May closing date is one month from now, each may be notified as a separate process, or the two may be offset to issue a 500,000 yen invoice with a billing due date three months from now. The relationship between the payment amount and the invoice amount to be offset may be amounts with corresponding closing dates, such as the same month or day, or amounts with corresponding notification dates, such as the same month or day, for the payment amount and the invoice amount.

[0227] Furthermore, in the above-described embodiment, the amount charged to the user is exemplified as the amount related to the transaction, but the amount may also be added together with other amounts such as a payment guarantee or platform usage fee.

[0228] In addition, in this embodiment, each functional unit of the transaction management device 200 may be included in the terminal device 300. In this case, the function may be realized by a web browser included in the terminal device 300 or an application installed on the terminal device 300.

[0229] Although the present invention has been described above based on the embodiments, the present invention is not limited to the requirements shown in the above embodiments. These requirements can be changed without departing from the spirit of the present invention, and can be appropriately determined depending on the application form.

[0230] This international application claims priority based on Japanese Patent Application No. 2024-90193 filed on June 3, 2024, the entire contents of which are incorporated herein by reference.

[0231] 100 Transaction management system 200 Transaction management device 210 Individual information storage unit 220 Transaction information storage unit 230 Transaction management information storage unit 232 Intermediate debt information 233 Intermediate credit information 240 Transaction management unit 241 Transaction information acquisition unit 242 Information generation unit 243 Information update unit 245 Credit confirmation unit 246 Display control unit 247 Notification output unit 300 Terminal device

Claims

1. A transaction management system including a computer that communicates via a network with a plurality of terminal devices owned by a plurality of providers that provide goods or services and a plurality of users that request the provision of said goods or services, wherein said computer: acquires a plurality of transaction information from a transaction database that stores a group of transaction information between said plurality of providers and said plurality of users, wherein each transaction information in said transaction information group includes relationship information indicating a creditor-debtor relationship in which one of said plurality of providers is a creditor and one of said plurality of users is a debtor; switches the relationship information in each of said plurality of transaction information between intermediary debt information indicating a first relationship in which the corresponding provider is the creditor and the transaction supporter is the debtor, and intermediary credit information indicating a second relationship in which the transaction supporter is the creditor and the corresponding user is the debtor; calculates a payment amount to be paid by said transaction supporter to each of said plurality of providers based on said intermediary debt information; calculates a claim amount to be invoiced by said transaction supporter to each of said plurality of users based on said intermediary credit information; and transmits information on the calculated payment amount to each of said plurality of providers to a terminal device of a corresponding provider among said plurality of terminal devices via said network. A transaction management system that transmits information on the amount of billing calculated for each of the plurality of users to a terminal device of a corresponding user among the plurality of terminal devices via the network.

2. The transaction management system of claim 1, wherein the computer acquires the plurality of transaction information from a transaction support database of a transaction support platform where the plurality of users and the plurality of providers execute transactions and which is managed by the transaction supporter.

3. The transaction management system described in claim 2, wherein the computer acquires from each of the plurality of terminal devices agreement information agreeing to the provision that the related information in the transaction information relating to the transaction executed on the transaction support platform will be switched to the intermediary debt information and the intermediary credit information.

4. The transaction management system described in claim 2, wherein the computer obtains credit information of the multiple users participating in the transaction support platform from a credit database, and obtains transaction information relating to users whose credit information meets specified requirements in the group of transaction information from the transaction support database as the multiple transaction information.

5. The transaction management system described in claim 2, wherein the computer obtains credit information of the multiple users participating in the transaction support platform from a credit database, and sends a notification to the terminal device of a user whose credit information in the transaction information group does not meet specified requirements that the specified requirements are not met.

6. The transaction management system described in claim 1, wherein the computer obtains payment terms information from a payment terms database that sets the terms of payment from the transaction supporter to the multiple providers for each provider, and calculates the payment amount to be paid by the transaction supporter to each of the multiple providers based on the payment terms information for each of the multiple providers and the intermediary debt information.

7. A transaction management system as described in claim 1, wherein the computer obtains billing condition information from a billing condition database that sets the conditions for billing from the transaction supporter to the multiple users for each user, and calculates the billing amount to be billed by the transaction supporter to each of the multiple users based on the billing condition information for each of the multiple users and the intermediary claim information.

8. The transaction management system described in claim 1, wherein the computer: obtains from the transaction database first direct transaction information including first relationship information indicating a creditor-debtor relationship in which a first provider among the plurality of providers provides a product or service to a second provider among the plurality of providers, with the first provider being the creditor and the second provider being the debtor; switches the first relationship information in the first direct transaction information to first intermediary debt information indicating a relationship in which the corresponding first provider is the creditor and the transaction supporter is the debtor, and first intermediary credit information indicating a relationship in which the transaction supporter is the creditor and the corresponding second provider is the debtor; and calculates the payment amount to be paid by the transaction supporter to the second provider based on the intermediary debt information and the first intermediary credit information.

9. The transaction management system described in claim 1, wherein the computer: obtains from the transaction database second direct transaction information including second relationship information indicating a creditor-debtor relationship in which a first user among the plurality of users provides a product or service to a second user among the plurality of users, with the first user being the creditor and the second user being the debtor; switches the second relationship information in the second direct transaction information to second intermediary debt information indicating a relationship in which the corresponding first user is the creditor and the transaction supporter is the debtor, and second intermediary credit information indicating a relationship in which the transaction supporter is the creditor and the corresponding second user is the debtor; and calculates the amount to be claimed by the transaction supporter against the first user based on the intermediary credit information and the second intermediary credit information.

10. The transaction management system described in claim 1, wherein the computer obtains first direct transaction information from a first direct transaction database of a first direct transaction platform managed by the transaction supporter, in which the transaction supporter provides goods or services to the multiple providers and which includes information indicating a creditor-debtor relationship in which the transaction supporter is the creditor and at least one of the multiple providers is the debtor, and calculates the payment amount to be paid by the transaction supporter to each of the multiple providers based on the intermediary debt information and the first direct transaction information.

11. The transaction management system described in claim 1, wherein the computer obtains second direct transaction information from a second direct transaction database of a second direct transaction platform managed by the transaction supporter, in which the transaction supporter provides goods or services to the plurality of users and which includes information indicating a creditor-debtor relationship in which the transaction supporter is the creditor and at least one of the plurality of users is the debtor, and calculates the amount to be claimed from the transaction supporter to each of the plurality of users based on the intermediary creditor information and the second direct transaction information.

12. The transaction management system described in claim 1, wherein the computer acquires procurement information from a procurement database of a procurement platform managed by the transaction supporter, the procurement information including information indicating a creditor-debtor relationship in which at least one of the multiple providers is a creditor and the transaction supporter is a debtor, when the transaction supporter procures goods or services from the multiple providers, and calculates the payment amount to be paid by the transaction supporter to each of the multiple providers based on the intermediary debt information and the procurement information.

13. The transaction management system of claim 1, wherein the computer acquires the plurality of transaction information from an unmanaged transaction database of an unmanaged transaction platform on which the plurality of users and the plurality of providers execute transactions and which is not managed by the transaction supporter.

14. The transaction management system described in claim 2, wherein the computer obtains credit information of the multiple users participating in the transaction support platform from a credit database, and determines a payment method to be used by a user whose credit information in the transaction information group does not meet specified requirements to pay the transaction supporter from a specified payment method.

15. A transaction management method using a transaction management system including a computer that communicates via a network with multiple terminal devices owned by multiple providers of goods or services and multiple users who request the provision of said goods or services, wherein the computer: acquires multiple pieces of transaction information from a transaction database that stores transaction information groups, the transaction information groups being between the multiple providers and the multiple users, each transaction information group including relationship information indicating a creditor-debtor relationship in which one of the multiple providers is a creditor and one of the multiple users is a debtor; switches the relationship information in each of the multiple pieces of transaction information between intermediary debt information indicating a first relationship in which the corresponding provider is the creditor and the transaction supporter is the debtor, and intermediary credit information indicating a second relationship in which the transaction supporter is the creditor and the corresponding user is the debtor; calculates a payment amount to be paid by the transaction supporter to each of the multiple providers based on the intermediary debt information; calculates a claim amount to be invoiced by the transaction supporter to each of the multiple users based on the intermediary credit information; and transmits information on the calculated payment amount to each of the multiple providers to a terminal device of the corresponding provider among the multiple terminal devices via the network. A transaction management method comprising transmitting information on the amount of billing calculated for each of the plurality of users to a terminal device of a corresponding user among the plurality of terminal devices via the network.

16. A computer that communicates via a network with multiple terminal devices owned by multiple providers of goods or services and multiple users requesting the provision of said goods or services, respectively, acquires multiple pieces of transaction information from a transaction database that stores a group of transaction information between said multiple providers and said multiple users, wherein each piece of transaction information in the transaction information group includes relationship information indicating a creditor-debtor relationship in which one of said multiple providers is a creditor and one of said multiple users is a debtor; switches the relationship information in each of said multiple pieces of transaction information between intermediary debt information indicating a first relationship in which the corresponding provider is the creditor and the transaction supporter is the debtor, and intermediary credit information indicating a second relationship in which the transaction supporter is the creditor and the corresponding user is the debtor; calculates a payment amount to be paid by said transaction supporter to each of said multiple providers based on said intermediary debt information; calculates a claim amount to be invoiced by said transaction supporter to each of said multiple users based on said intermediary credit information; and transmits information on the calculated payment amount to each of said multiple providers to a terminal device of a corresponding provider among said multiple terminal devices via said network. A transaction management program that executes a process of transmitting information on the billing amount calculated for each of the plurality of users to a terminal device of a corresponding user among the plurality of terminal devices via the network.

Images