WO2021144567A1

WO2021144567A1 - Transaction management system and methods

Info

Publication number: WO2021144567A1
Application number: PCT/GB2021/050072
Authority: WO
Inventors: Oliver SQUIRES; Ashton SQUIRES
Original assignee: Casqol Limited
Priority date: 2020-01-14
Filing date: 2021-01-13
Publication date: 2021-07-22
Also published as: GB2593036A; GB202000498D0; GB202100414D0

Abstract

In a system arranged for settling funds between a purchaser (201) and supplier (202), items are sold using a pricing structure. A purchaser (201) purchases the item at a price determined by a first pricing level, for example, $10.00, from a supplier (202). The transaction proceeds through a payment processor (203), which may utilise a third-party payment processing company (204). However, in some embodiments, payment processing may be undertaken by the supplier (202) or a transaction management system (210), who facilitates the distribution of funds. Once all necessary payment processing fees, if any, are deducted, any residual amount is processed by the transaction management system (210). These fees may include credit card company fees and/or the third-party's payment processing fee. The transaction management system (210) comprises at least three accounts: a system account (212), a ring-fenced account (214), and a manager account (216). Residual amounts are first placed into the system account (212) where they are divided between the other accounts (214, 216) of the transaction management system (210). An amount equivalent to the predetermined administration charge B is transferred to the manager account (216), which is retained by the facilitator who operates the transaction management system (210). The amount transferred to the ring-fenced account (214) is then calculated based on a predetermined formula. Documentation to support each of the transfers will also be produced.

Description

TRANSACTION MANAGEMENT SYSTEM AND METHODS

The present invention relates to a system and method for managing transactions, more particularly transactions with multiple payment sources, and ensuring that accurate payments are received by all parties.

Online marketplaces or e-commerce platforms are routinely provided to facilitate the online purchase of items by customers. Items are typically browsed by a user who then adds the desired items to a virtual shopping cart. Once all items desired by the user have been selected and added to the cart, the user purchases the items, for example by credit card.

Platforms such as this are adequate for straightforward purchases made by individuals, however, transactions between organisations and businesses for the purchase of goods, services and resources, are frequently more complex. Often, they involve the issuance of discounts as well as offering lending facilities and other incentives which are not catered for in current online marketplaces.

During the implementation, management and operation of complex transactions of this nature, difficulties can arise in ensuring the parameters behind the transactions, for example the application of discounts, are accurate. Previous methods such as those described in UK Patent Application No. GB2546289 go some way to resolving these issues. However, there are other complexities which arise when dealing with transactions using multiple funding sources, such as determining the proportion of the price paid from each funding source, and that the correct amount is paid at all times.

Further difficulties may arise in the calculations associated with complex transactions. Previous systems struggle to quickly determine transaction data, such as discounts, when multiple factors are to be considered.

When making commercial decisions, organisations typically rely on internal data. For buyers, this internal data might comprise historic purchasing needs and prices. For suppliers this might comprise what price was a sold product sold at and who purchased it. However, the value of this internal data is increasingly lessening in a world of advancement in technologies.

The sheer number of organisations, and possibilities for purchase/sale, means that it currently too complex for any individual organisation to understand what all others are doing and to leverage this to make an informed commercial decision. As a result, of this communication and calculation challenge, organisations act in isolation from each other and continue to make sub optimal commercial decisions.

Not only are organisations making sub optimal product decisions, they also engage in individual negotiations. This duplication of processes across each commercial relationship takes significant time and resources. The present invention enables organisations to leverage external data - so as a buyer, they can immediately see what all others have bought, and can calculate how if they choose to purchase the same this will unlock more value for both them and other buyers.

The invention enables suppliers to proactively guide customers as a whole to decisions that unlock value for all and eliminates the time and costs of individual negotiation.

Accordingly, the present invention aims to provide a transaction system and method in which the above-mentioned problems are at least partly overcome.

The present invention is defined in the attached independent claims, to which reference should now be made. Further preferred features may be found in the sub-claims appended thereto .

According to a first aspect of the present invention, there is provided a transaction management system comprising one or more communication interfaces operable to receive a plurality of transaction requests for a product; a storage unit operable to store the plurality of transaction requests and account data of a user making each transaction request; a determination unit operable to determine whether a transaction request meets a predetermined condition; and a funding unit operable to charge a funding source associated with the user and determine a credit amount, wherein an account balance associated with the account data is increased by the credit amount based upon a predetermined completion criterion.

The system may configure the storage unit, the determination unit and the funding unit to operate substantially simultaneously and in real time, automatically in response to new product data and/or a new transaction request being received. All purchasers on all purchase platforms may be provided with up to date purchase information substantially simultaneously .

The product may comprise a good, a service and/or another resource.

Preferably, the funding source may be the account balance associated with the account data, a bank account of the user, and/or an agreement, such as a lease agreement or a credit agreement.

The credit agreement may be with the supplier of the products and/or a third party.

The account balance may comprise a credit amount associated with one or more previous transactions.

Optionally, the system may comprise a withdrawal unit operable to enable the account balance to be withdrawn by the user to their associated bank account and/or used for a subsequent transaction. The storage unit may be operable to store product data relating to products being offered for sale.

The product data may comprise a quantity discount schedule (hereinafter referred to as a price curve).

Preferably, the price curve relates to a quantity of products sold to price. Alternatively, and/or additionally, the price curve may relate to a sale time period to price.

The price curve may comprise a series of ranges of quantities, units, volumes or the like, each being associated with a respective price. The step of determining whether predetermined conditions have been met may comprise determining if the number of transaction requests exceeds a limit of one of the quantity ranges. Alternatively, and/or additionally, the step of determining whether predetermined conditions have been met may comprise determining if a particular sale time exceeds a limit of one of the ranges.

Optionally, the determination unit calculates an amount to be transferred to one or more accounts associated with the transaction. The one or more accounts may be a system account, a manager account, a ring-fenced account, a supplier account and/or the funding source associated with the user.

The credit amount is determined based upon the amount charged and the price indicated in the price code data at the time the completion criteria have been satisfied. The completion criteria may include a predetermined number of transaction requests and/or a predetermined sales time period.

Optionally, the system comprises a delay unit operable to wait a predetermined returns time after the completion criterion has been satisfied before determining the credit amount. This enables the method to take into account any customer returns.

The system may be arranged to receive product data from a selling device and/or a selling system.

Preferably, the system further comprises a document generation unit for generating one or more transaction- related documents.

The transaction related documents may be generated by the document generation unit at predetermined periods. The predetermined periods may be determined by one or more of the transfer of the funds from the user to the seller, when the offer conditions are met, and/or the earlier of when the price curve is at a lowest bound and/or when the purchaser wishes to withdraw and/or settle funds.

The documents may include purchase orders and/or invoices that are generated when a user places an order and when a supplier accepts an order.

The components of the system described herein may operate simultaneously in real-time. This enables calculations and procedures (such as some, all or any of: determining whether predetermined conditions have been met, calculating a credit amount, updating one or more associated accounts and producing the relevant documentation) in response to new product data, such as a transaction request, to be done at the same time if desired.

The invention also comprises a program for causing a device to perform a method according to any statement herein.

According to a second aspect of the present invention, there is provided a method of settling funds between a purchaser and a seller using an infrastructure , the method comprising the steps of; registering a purchase by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; updating the price and the price curve; and settling the accounts; wherein the method further comprises a step of transferring funds equivalent to the price including calculating what percentage of the price is paid by each of the one or more funding sources, and allocating the funds to one or more receiving accounts.

Preferably, the one or more receiving accounts includes one or more of: a supplier account, a system-manager account and a ring-fenced account.

The or each ring-fenced account may comprise multiple ring- fenced accounts and be managed by the infrastructure. Optionally, the total funds are transferred to a single receiving account and then divided amongst one or more subsidiary accounts, such as a supplier account and/or a system manager account.

The receiving account may be the supplier account, and the subsidiary accounts may be the system-manager account and the ring-fenced account.

Preferably, the step of settling the accounts comprises: determining the current sale value based upon the price curve and/or discount curve data of the item; determining a difference; transferring an amount to be settled from a first receiving account to a second receiving account; wherein the amount to be settled is equal to the difference.

The difference may be equal to the price minus a minimum price based upon the price curve, preferably, plus a predetermined administration charge.

The difference may be equal to a final price based upon the price curve once the offer conditions have been met, minus a minimum price, based upon the price curve.

Optionally, the step of settling the accounts further comprises; aggregating how much the infrastructure owes the supplier; aggregating how much the supplier owes the infrastructure ; determining a difference between the two amounts; and transferring funds equivalent to the difference from a first receiving account to a second receiving account. The step of transferring from the first receiving account to the second receiving account may occur when the difference exceeds the amount to be settled.

The step of settling the accounts may occur in real time or at predetermined time periods. One of the predetermined time periods may be the time the offer conditions have been met. Alternatively, and/or additionally, one of the predetermined time periods may be the end of a day.

Preferably, a predetermined administration charge is allocated to the system-manager account.

The funds allocated to the supplier may be the lowest price represented minus the predetermined administration charge.

Optionally, the funds allocated to the ring-fenced account are the difference between the lowest price represented in the price curve and the price.

Preferably, the funding source is an account balance associated with the purchaser, a bank account of the purchaser, and/or an agreement. The agreement may be a lease or credit agreement.

Optionally, the credit agreement is with the seller and/or a third party. Preferably, the method further comprises the step of generating one or more documents relating to the transferring of funds.

The step of generating one or more documents may occur; at the transfer of the funds from the purchaser to the seller, when the offer period conditions are met, before payment if and only if the payment is a credit payment, the earliest of when the price curve is at a lowest bound, and/or when the purchaser wishes to withdraw and/or spend settled funds

The price curve data may relate to a quantity of products sold to price. Alternatively, and/or additionally, the price curve data may relate to a sale time period to price.

Preferably, the price curve data comprises a series of ranges of quantities, units, volumes or the like, each being associated with a respective price or discount curve, for example which may be a discount from a market price associated with increases in quantity.

According to a third aspect of the present invention, there is provided a transaction management method, the method comprising the steps of receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; and updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited by the credit amount.

Preferably, the funding source may be the account balance associated with the account information, a bank account of the user, and/or an agreement. The agreement may be a credit or lease agreement.

Optionally, the account balance may be withdrawn by the user to their associated bank account and/or used for a subsequent transaction. The user may withdraw any amount over that which they owe to suppliers (potential or actualised).

The method may comprise storing product data relating to products being offered for sale or lease.

The product data may comprise a price curve or discount curve.

Preferably, the price curve relates to a quantity of products sold to price. Alternatively, and/or additionally, the price curve may relate to a sale time period to price. The price curve (or discount curve) data may comprise a series of ranges of quantities, units, volumes or the like, each being associated with a respective price. The step of determining whether predetermined conditions have been met, may comprise determining if the number of transaction requests exceeds a limit of one of the quantity ranges. Alternatively, and/or additionally, the step of determining whether predetermined conditions have been met may comprise determining if a particular sale time exceeds a limit of one of the ranges.

The credit amount is determined based upon the amount charged and the price indicated in the price curve, at a predetermined time. Preferably, the credit amount is determined at each transaction request and/or at the time the completion criterion has been satisfied.

The credit amount may be issued when the purchaser has paid in full, alternatively the credit amount may be issued at a predetermined time.

The completion criterion may be a predetermined number of transaction requests and/or a predetermined sales time period.

Optionally, the method comprises the step of waiting a predetermined returns time after the completion criterion has been satisfied before determining the credit amount. This enables the method to take into account any customer returns . The method may further comprise updating the account balance.

The method may comprise receiving product data from a selling device and/or a selling system.

According to another aspect of the present invention, there is provided apparatus comprising a processor and a memory having therein computer readable instructions, the processor being arranged in use to read the instructions to cause the performance of a method of settling funds between a purchaser and a seller using an infrastructure , the method comprising the steps of; registering a purchase or lease by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; transferring funds equivalent to the price; updating the price based upon subsequent purchases and the price curve; and settling the accounts; wherein the step of transferring funds comprises calculating what percentage of the price is paid by each of the one or more funding sources, and allocating the funds to one or more receiving accounts.

The invention also includes a computer implemented method comprising settling funds between a purchaser and a seller using an intermediary, the method comprising the steps of; registering a purchase by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; transferring funds equivalent to the price; updating the price based upon subsequent purchases and the price curve; and settling the accounts; wherein the step of transferring funds comprises calculating what percentage of the price is paid by each of the one or more funding sources, and allocating the funds to one or more receiving accounts.

In a further aspect, the invention provides a computer program product on a non-transi tory computer readable storage medium, comprising computer readable instructions that, when executed by a computer, cause the computer to perform a method comprising settling funds between a purchaser and a seller using an infrastructure , the method comprising the steps of; registering a purchase by the purchaser of an item at a selling or leasing event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; transferring funds equivalent to the price; updating the price based upon subsequent purchases and the price curve; and settling the accounts; wherein the step of transferring funds comprises calculating what percentage of the price is paid by each of the one or more funding sources, and allocating the funds to one or more receiving accounts.

According to another aspect of the present invention, there is provided an apparatus comprising a processor and a memory having therein computer readable instructions, the processor being arranged in used to read the instructions to cause the performance of a method of receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; and updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited the credit amount.

The invention also includes a computer-implemented method comprising receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; and updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited the credit amount.

In a further aspect, the invention provides a computer program product on a non-transi tory computer readable storage medium, comprising computer readable instructions that, when executed by a computer, cause the computer to perform a method for receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; and updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited the credit amount.

The invention may include any combination of features or limitations referred to herein, except such a combination of features as are mutually exclusive, or mutually inconsistent.

Preferred embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings, in which:

Figure 1 shows an exemplary pricing structure for use with a system and method according to an embodiment of the present invention;

Figure 2 shows a flowchart of a first embodiment of a system and method according to the present invention;

Figure 3 shows a flowchart of a second embodiment of a system and method according to the present invention;

Figure 4 shows a flowchart of a third embodiment of a system and method according to the present invention;

Figure 5A shows a flowchart of the provision of a credit agreement according to the present invention; Figure 5B shows a flowchart of an alternative provision of a credit agreement according to an embodiment of the present invention;

Figures 6a to 6g show schematically a multi-tiered process in accordance with another embodiment of the invention, in which there is at least one re-seller between the customer and the supplier; and

Figure 7 shows schematically a multi-platform process, in accordance with another embodiment of the invention.

Transactions between organisations and/or businesses for the purchase of services and resources are complex, particularly when carried out in an online environment. Often, they involve the issuance of discounts as well as offering lending facilities and other incentives which are not catered for in current online marketplaces.

The present invention aims to simplify this, by providing a system and method which is adaptable and scalable, as well as being capable of handling various discount schemes.

Economies and supply chains may contain a large number of individual, autonomous organisations, each acting to unlock as much value as possible for their internal organisation. This network is interconnected, insofar that one organisation's actions and decisions impact the payoff that other organisations receive. For organisations to coordinate their decisions with the rest of the decentralised network, and determine the optimal decision given the actions of others, a vigorous exchange of information is required. Including the communication of:

- Real-time update of demand

- the interconnectedness of how the price is affected by demand across all organisations

- Real-time update of Supply

Current technical limitations mean that this information cannot be shared in real-time with the entire network, making it impossible for organisations to unlock the full potential value, as their coordination is limited.

The commercial data of purchases and sales are currently held in silos by the buyer and supplier to each transaction. Traditional communication channels (including emails, telephone calls, procurement platforms) offer a static exchange of information which means that information is often out of date by the time the receiving organisation has processed it. Additionally, each organisation (within the decentralised network) communicates on a one-to-one basis, separately contacting all the others and attempt to gather the necessary information to coordinate decisions.

However, due to: the time cost of gathering this information, the resources required to process this data and understanding the interconnectedness of options, and the continuous purchase and sale by all the other organisations within the network, any data that a single organisation can utilise using traditional digital communication methods is always out of date and of limited value for coordinating decisions.

Without this real-time feedback mechanism and the degree of interconnectedness to what others have done, or plan to do, and the impact of decisions on the organisation, then organisations are effectively acting in isolation, inadvertently making bespoke decisions that negate economies of scale which ultimately cost more for all, duplicating process which increases transaction costs for all, and reducing the rate of learning and adapting to new events across the entire network.

In an exemplary embodiment, a supplier provides information to a central system detailing the items for sale and setting out a pricing structure 100, such as the one shown in Figure 1. The pricing structure 100 details the cost per unit sold or leased and details any discounts which are provided if a particular number of units are purchased by any number of purchasers.

Figure 1 shows a pricing structure 100 with two different pricing levels 110,120. The first pricing level 110 shows the total price P for each unit, for example, $10.00 which is made up of $9.50 supplier price A and $0.50 predetermined administration charge B. The first pricing level 110 is used for any number of purchases between 1 and X units.

If more than X units are sold, a second, and in this embodiment a final, pricing level 120 is used, with a different total price P'. It will be appreciated that in other embodiments, the second pricing level may be used after a predetermined period of time has elapsed. In yet further embodiments, a mixture of time elapsed and/or items sold may be used to determine whether to progress to a second or subsequent pricing level.

The second pricing level 120 shows that the total price P' for each unit is, for example, $5.00 which is made up of $4.50 supplier price A' and $0.50 predetermined administration charge B.

It will be appreciated that other pricing structures 100 may be used. These pricing structures can have any number of pricing levels. Furthermore, whilst the predetermined administration charge portion B of the total price R,R' is shown to be the same at each pricing level 110,120, it will be appreciated that the predetermined administration charge B may vary at each pricing level. The predetermined administration charge B may be fixed, or alternatively may be set at a percentage of the supplier price A,A'. Furthermore, the pricing structure 100 may include other price elements e.g. for additional services, such as delivery, insurance, installation and end-of-life removal. These services may have a fixed price, or alternatively, one or more may be subject to a price curve, i.e. the more items purchased the more expensive the delivery cost, but the delivery cost per unit may decrease.

Figure 2 shows flowchart representative of a first embodiment 200 of a system arranged for settling funds between a purchaser 201 and supplier 202. In the example described below in relation to Figure 2, the pricing structure 100 of Figure 1 will be used. However, it will be appreciated by the skilled person that other pricing structures may be utilised by the system 200.

When items are sold using a pricing structure, such as that shown in Figure 1, a purchaser 201 purchases the item at a price determined by the first pricing level, for example, $10.00, from a supplier 202. The transaction proceeds through a payment processor 203, which may utilise a third-party payment processing company 204. However, in some embodiments, payment processing may be undertaken by the supplier 202 or a transaction management system 210, who facilitates the distribution of funds.

Once all necessary payment processing fees, if any, are deducted, any residual amount is processed by the transaction management system 210. These fees may include credit card company fees and/or the third-party's payment processing fee.

The transaction management system 210 comprises at least three accounts: a system account 212, a ring-fenced account 214, and a manager account 216.

Residual amounts are first placed into the system account 212 where they are divided between the other accounts 214,216 of the transaction management system 210. An amount equivalent to the predetermined administration charge B, for example, $0.50 as provided by the pricing structure 100 of Figure 1, is transferred to the manager account 216, which is retained by the facilitator who operates the transaction management system 210.

The amount transferred to the ring-fenced account 214 is then calculated based on a predetermined formula. Documentation to support each of the transfers will also be produced .

The formula may include calculating the minimum possible sale price P' for an item. In the example given in Figure 1, the minimum sale price P' would be $5.00. Therefore, the amount transferred to the ring-fenced account 214 if an item was purchased at the first pricing level 110 would be $5.00. This is calculated by taking the value P at which an item was purchased at, $10.00, and subtracting the minimum price P'.

The minimum supplier price A' is then transferred to the supplier 202. In this example, the minimum supplier price is $4.50

As the sale process continues, and items are sold/time progresses, the pricing levels will change. For example, if the pricing structure 100 of Figure 1 was used, after X sales, the price per unit would fall to $5.00. The funds in the ring-fenced account 214 would then be allocated back to the buyer 201 in real time or at a predetermined time. If, however, a predetermined time period passes, for example, a long stop time, and the price per unit remains unchanged, the monies in the ring-fenced account 214 would be transferred to the supplier 202. In pricing schemes with multiple pricing levels, it will be appreciated that funds from the ring-fenced account 214 may be split between the purchaser 201 and supplier 202 based upon the reduction in per-item price as indicated in the pricing scheme.

This final step of settling the funds may occur periodically throughout the sale period, such as daily, or in real-time. Alternatively, it may occur at the end of the sale period.

Figure 3 shows a flowchart representative of a second embodiment 300 of a system arranged for settling funds between a purchaser 301 and supplier 302. In the example described below in relation to Figure 3, the pricing structure 100 of Figure 1 will be used, however, it will be appreciated by the skilled person that other pricing structures may be utilised by the system 300.

A purchaser 301 purchases an item at a price determined by the first pricing level 110, for example, $10.00, from a supplier 302. The purchaser 301 may have a pre-existing payment contract with a supplier 302. For example, any product which is purchased by a purchaser 301 may be paid for within 30 days. It will be appreciated by the skilled person that other payment terms may be set.

The system 300 may assign, as per the suppliers' terms, these payment terms for the supplier 302 based on one or more criteria provided by the supplier 302 during set up. The information provided by the supplier 302 may be used to create a form for a new purchaser 301 to complete, and the answers which when provided by the purchaser 301 generate a set of payment terms which are acceptable to the supplier 302 based on the criteria provided. Alternatively, the supplier 302 may specify the payment terms on a case-by-case basis. This process will be described in further detail below with reference to Figures 5A and 5B.

Once payment has been made to the supplier 302 on the agreed payment terms, the supplier 302 transfers a portion of the funds received to the system account 312 of the transaction management system 310. This transfer may occur in real time, and/or the amounts may be aggregated and transferred at agreed periods, such as at the end of a day or end of a week. The amount transferred from the supplier 302 to the system account 312 may be determined by the transaction management system 310. For example, if the pricing scheme 100 of Figure 1 is used for the product being purchased, and the price per unit remains at the initial price P, the amount transferred to the system account 312 would be the price, P, minus the lowest supplier price of an item, A'. In the example of Figure 1, the total amount transferred to the system account would be $5.50 (P - A'). The supplier 302 would retain the residual amount, in this example, $4.50 (A').

Of the amount transferred to the system account 312, the predetermined administration charge B would then be transferred to a manager account 316 and the remaining amount (P - P') is transferred to a ring-fenced account 314. As the sale of the item progresses, if the quantity/time characteristics are such that the pricing scheme 100 moves to the second pricing level 120, and in the example of Figure 1, the price per item is reduced to $5.00, the monies in the ring-fenced account 314 are allocated to the purchaser 301. Documentation will also be produced to indicate the allocation of funds. If, however, the sale process ends at the first pricing level 110, the monies in the ring-fenced account 314 are transferred to the supplier 302.

In pricing schemes with multiple pricing levels, it will be appreciated that funds from the ring-fenced account 314 may be split between the purchaser 301 and supplier 302 based upon the reduction in per item price as indicated in the pricing scheme.

The funds in the ring-fenced account 314 may be transferred back to the purchaser 301 or supplier 302 periodically throughout the sale period, such as daily, or in real-time. Alternatively, the transfer may occur at the end of the sale period.

Figure 4 shows flowchart representative of a third embodiment 400 of a system arranged for settling funds between a purchaser 401 and supplier 402. In the example described below in relation to Figure 4, the pricing structure 100 of Figure 1 will be used, however, it will be appreciated by the skilled person that other pricing structures may be utilised by the system 400.Payment sources may include any of e.g. SW credits, from payment terms, from leases, upfront payment via online card payment(s) and any combination thereof .

A purchaser 401 purchases an item at a price determined by the first pricing level 110, for example, $10.00, from a supplier 402. In this embodiment, the purchaser 401 may wish to pay the supplier 402 but may also wish to make use of some credit provided from one or more previous transactions, or other payment sources. In some embodiments, the purchaser 401 may wish to use some form of leasing agreement. For example, a third-party lender (not shown), such as a bank, acquires title, and the purchaser 401 pays a lease amount at predetermined periods e.g. monthly instalments. In this case, the purchaser 401, pays a portion of the purchase price, for example $1.00 to the supplier 402, either directly or on credit terms, as indicated by arrow X. The balance may then be provided by a credit amount, for example $9.00, received from one or more previous transactions in which the purchaser 401 was due a rebate, this is indicated by arrow Z. In some embodiments, the purchaser may also transfer funds directly to the system account, as indicated by arrow Y.

Due to the transfer of funds to different recipients, such as to the system 410 from the purchaser 401 (via arrow Y) or from the ring-fenced account 414 (via arrow Z) or to the supplier 402 directly from the purchaser 401 (via arrow X), it is necessary to periodically reconcile the accounts 412,414,416 to ensure the funds are correctly allocated.

In some embodiments, the step of reconciling the accounts may occur at predetermined periods, for example when a predetermined amount of funds to be transferred, exists in one of the accounts 412,414,416, or at predetermined time periods, such as daily or weekly. In other embodiments, the reconciling of the funds may occur substantially in real time.

For example, when the amount owed from one account to another, is greater than the difference between P and A', a reconciliation transfer may be initiated. This may occur from the supplier account 402 to the system account 412 (via arrow T) or from the system account 412 to the supplier account 402 (via arrow T').

In the example above, wherein $9.00 is paid via a credit amount from the ring-fenced account 414 and $1.00 is transferred from the buyer 401 directly to the supplier 402, either via a direct purchase or pre-existing credit agreement. A transfer will be initiated automatically when the amount in the system account 412, $9.00, and/or the amount in the supplier account 402 is greater than the difference plus the predetermined administration charge (P - A'), $5.50. Therefore, in order to reconcile the accounts 412,402,414, a number of transfers need to take place. Firstly, $9.00 will be transferred from the ring-fenced account 414 to the system account 412, and $5.00 (i.e. A-A') will be transferred from the system account 412 to the ring- fenced account 414. It will be appreciated that in some embodiments, only the net amount needs to be transferred, that is $4.00 will be transferred from the ring-fenced account 414 to the system account 412. Next, the predetermined administration charge B, $0.50, will be transferred to the manager account 416. The remaining balance, $3.50, in the system account 412 will then be transferred to the supplier 402 via arrow T'. Along with the $1.00 paid directly to the supplier 402, the supplier will then have the correct funds, as per the examples shown in Figure 2 and 3. If at the end of the sale period, the purchase price has not decreased, then, in the example above, $5.00 (i.e. A-A') will be transferred to the supplier 402.

It will be appreciated by the skilled person, that other thresholds may be used to determine when to reconcile the accounts. A similar methodology may be used when the supplier 402 is paid a greater amount than that provided by the ring- fenced account 414. In this example, there will be a transfer of P-A' from the supplier 402 to the system account 412. It doesn't matter which one is more, only that one is above the threshold to trigger payment.

Where a payment is made to the supplier 202,302,402 on credit, any rebate due paid to the purchaser 201,301,401, for example if the pricing level at the end of the process is lower than the pricing level at which the purchaser 201,301,401 purchased the items, will be delayed until any credit amount has been settled between the purchaser 201,301,401 and supplier 202,302,402. This ensures that a purchaser 201,301,401 does not receive rebate amounts for items for which payment has not been received in full. Alternatively, where a product is leased, the rebate amount may be adjusted so as to be based on the portion of the price has been paid. In some embodiments, a rebate amount may be withheld from the purchaser 201,301,401 if they break any terms and conditions, such as missing a payment in a credit agreement with a supplier 202,302,402.

Throughout the processes 200,300,400 documentation will be generated for each transaction. Purchasers 201,301,401 may be provided with documentation indicating what funds are allocated to their account. This may take the form of a single document, or alternatively may be split across multiple documents, for example, one for each supplier

201.301.401 from which they have purchased items. Said documentation may be provided to the purchaser at agreed times, or for example, when an item has been delivered. Said documentation may be produced by the transaction management system 210,310,410, or by the supplier 202,302,402.

In some embodiments, the supplier 202,302,402 may receive all the funds, and hold the funds which in the described embodiments are transferred to the system account

212.312.412. Periodically, or in real time, the supplier

202.302.402 may transfer funds to the system account

212.312.412, when required. For example, if the offer period ends, and the sale price is at a lower bound than the bound in which a purchaser 201,301,401 bought an item, the supplier

202,302,402 may transfer the difference (e.g. A-A') to the system account 212,313,413. At predetermined period, the supplier 212,312,412, may also be required to transfer the predetermined administration charge B, to the system account 212,312,412 for allocation to the manger account 216,316,416. Alternatively, upon receipt of the funds, the supplier may transfer the difference between the lowest bound and the bound in which a purchaser 201,301,401 bought an item (e.g. A-A') to the system account 212,213,413.

Figures 5a and 5b shows how the system aids suppliers 02 in determining whether to provide credit to a purchaser 01. Each supplier 02 may have different requirements for providing credit based on one or more factors, such requirements may be used to provide an indicative score to a purchaser 01. An accurate credit score may then be provided by completing one or more applications.

Figure 5a shows a first method 500 for determining whether to grant credit to a particular purchaser 01. At step 501, a supplier 02 may provide a credit application form containing the necessary questions, parameters and information they wish to consider when determining a credit application. Once provided, the method proceeds to step 502, whereby the system 10 displays the form to a purchaser/potential purchaser 01 enabling them to input the necessary information at step 503. Once the information has been completed, the system 500, at step 504 sends the information to the supplier 02 who assesses and analyses the completed form. The supplier 02 may wish to forward the information to a third-party credit assessor 20 who assesses the information at step 506. Once assessed, the method 500 may progress to step 507. Alternatively, the supplier 02 may be satisfied with the information provided, and progress to step 507 directly without input from a third-party credit assessor 20. At step 507, the supplier 20 sets out the terms of the credit offer, for example, payment terms, credit amount etc. The method then progresses to step 508 whereby the purchaser 01 is provided with this information. If the credit application has been unsuccessful, it is at this point the purchaser 01 may be informed as to why credit was refused. However, this information may not always be provided to the purchaser 01.

Once the terms of credit have been provided to the purchaser 01, the method progresses to step 509, whereby the purchaser 01 is able to purchase items from the supplier 02 against the terms of credit provided. If the item(s) to be purchased exceed the credit amount, the purchaser 01 is able to pay the entire balance on demand, or alternatively pay the difference on demand, and offset the remaining amount against the credit amount. In some embodiments, it may be possible for the purchaser 01 to apply for more credit and use their existing credit as collateral/margin to apply for more.

In an alternative embodiment, as shown in Figure 5b, a method 600 may be used to generalise the process over a number of suppliers 02 who may not already have their own credit application forms to provide to the system 10. In some embodiments, to minimise administration and duplication of tasks, the credit score may be updated and applied across all supplier's matrices.

In this embodiment, the supplier 02, at step 601 completes a credit matrix. The credit matrix may have predetermined thresholds and criteria for granting and/or refusing credit. Once this matrix has been created, generic credit check questions are provided to the purchaser 01, and the method progresses to step 602. In some embodiments, if more than one third-party credit assessor 20 is to be used, the questions will be aggregated to avoid duplication. The purchaser 01 completes this form at step 603, and the method progresses to step 604 and the answers are assessed by a third-party credit assessor 20. The third-party credit assessor 20 may be chosen by the supplier 02 and/or agreed with the supplier 02 in advance. The third-party credit assessor then returns a credit score to the system 10 at step 605, which at step 606 is analysed against the credit matrix criteria provided by the supplier 02. At step 607, the credit terms, such as payment terms, and credit amount etc. are provided to the purchaser 01. The purchaser 01, at step 608, is then able to make purchases against the credit amount as described above in relation to step 509.

This may be periodically re-calculated so that, if the credit status of the buyer changes, the supplier is notified and asked if they would like to change. Alternatively, the supplier can set this change automatically.

The infrastructure stores all available offers in a centralised database. When a qualifying purchase is made, the number of units sold updates in real time. Qualifying purchases can be made on multiple platforms as long as the purchase is made from the relevant offer. This means even when different orders are placed on multiple separate platforms, they will all still update the shared Price Curve and all offer information will remain consistent across all platforms. If a third party has integrated with the infrastructure into their separate platform, then the offer details will be pulled from an API, meaning that the unit price and other offer information will be automatically updated on the third- party platform in real time. When an order is submitted from that offer on the third-party platform, the API will send the order data back into the centralised database to be recorded and sent to the relevant supplier.

Buyers can use their wallet to pay on third party websites that access the infrastructure

The wallet enables buyers to pay into dedicated accounts for the supplier rather than a centralised infrastructure account. Each supplier has visibility of all funds withing their wallet within the infrastructure. Buyers receive their credits back to their wallet, in accordance with the price curve.

Each wallet can have a unique account number.

The term "price curve" used throughout the specification may refer to a set price curve - in which the underlying price is set, or fixed, or else it may refer to a discount price curve - in which the underlying price floats and is discounted from a market, or underlying, price based upon the volume that is sold.

Where one or more re-sellers exist between the supplier and ultimate customer, a multi-tiered structure is required. Figures 6a to 6f depict a series of steps in a multi-tiered movement in which there is a single re-seller between the supplier and customer. The process can be expanded for any number of tiers, i.e. where there are plural resellers.

Figure 6a sets out an example price curve, shown in table form 700 and graphical form 710, that may be used to over multiple tiers.

Figure 6b shows the net position of a price curve over three tiers.

Assuming that the order is within Band 1, the customer C pays the infrastructure I the £90 + supplier margin + reseller margin to the dedicated wallet W1 of the reseller

R.

Upon receipt of monies, the infrastructure I initiates payment of the reseller margin to the reseller R. At the same time the infrastructure initiates payment of the minimum price to the supplier S, which in the example set out in Fig 6a is £70 + supplier margin.

The difference is stored in the wallet W2 of the supplier.

As future purchases are made, that results in the price decreasing in accordance with the price curve. The customer will accordingly earn credits.

Figure 6c shows the full list of transactions that occur across multiple tiers. Assuming that the order is within Band 1 of the price curve, the end customer C pays the infrastructure for the £90 + reseller margin + supplier margin to the reseller wallet W1

The infrastructure I will pay the reseller R the £90 + reseller margin + supplier margin. The reseller R will pay the infrastructure the £90 + supplier margin. In effect, the reseller R will receive the reseller margin as set out in Figure 6a.

The infrastructure I will then pay the supplier the £90 + supplier margin. The supplier will pay the infrastructure the £20. In effect the supplier will receive the £70 + supplier margin. And £20 will remain in the supplier wallet W2.

Figure 6d shows the net position of the initial payments over multiple tiers.

Turning to Figure 6e, in accordance with the price curve, if the cumulative volume of purchases at any point reaches Band 2, then £10 per unit will be paid from the supplier wallet to the reseller wallet. The end customer can then withdraw these to their bank account on demand. If the offer ends with the volume within Band 2, then £10 will be paid back to the supplier as a final payment.

If Band 3 is reached, a further £10 will be allocated from the supplier wallet to the reseller wallet. This will mean a total of £20 per unit will be credit to the buyer for Band 3. And no payment will be due to the supplier account.

Regarding Figure 6f, in accordance with the price curve, if the cumulative volume of purchases at any point reaches Band 2, then £10 per unit will be paid from the supplier wallet to the supplier, and the supplier will pay £10 to the supplier wallet. Consequently, £10 will be sent to the reseller account and £10 will be paid from the reseller account to the reseller wallet. The customer can then withdraw this £10 as cash on demand. If the offer ends with the volume within Band 2, then £10 will be paid back to the supplier as a final payment. If Band 3 is reached, then a further £10 per unit will be paid from the supplier wallet to the supplier, and the supplier will pay £10 to the supplier wallet. Consequently, £10 will be sent to the reseller account and £10 will be paid from the reseller account to the reseller wallet. The customer can then withdraw this further £10 as cash on demand. This will mean a total of £20 per unit will be credit to the customer if Band 3 is reached and no payment will be due to the supplier account. Figure 6g shows the credit payments as set out in Figures 6e and 6f. In addition, a credit note CN will be produced for the supplier to account for the credit payments to the reseller and a separate credit note will be produced by the reseller for the customer. The credit notes can be produced automatically by the infrastructure. When making commercial decisions, organisations lack the external data of what other organisations are doing and how that affects the market. This is due to the fact that organisations hold this data in silos (both physical and political) making it too difficult to share with the rest of the market. Even if it can be shared with the market, it is too complicated to compute the impact that the market's decisions/intentions has on an organisation's decision.

This means organisations make commercial decisions with incomplete information, relying on internal data that results in suboptimal decisions. Embodiments of the present invention enable buyers and suppliers to leverage external data effortlessly to make more informed decisions that unlocks new value.

As the cumulative volume of a product sold increases, the price decreases for all previous buyers. The cumulative volume includes all purchases of a product during an offer on a price curve, regardless of which platform (managed according to the present invention) is used to place the order. When an order is placed on any thus-managed platform, the master offer in the infrastructure updates to reflect the new cumulative volume. The infrastructure then updates all other relevant platforms with this new information.

Figure 7 illustrates the following steps in a multi-platform process : Buyer B1 places an order on platform X for 10 units with a supplier, paying £100 per unit.

The supplier accepts the order which updates the cumulative volume sold (lOunits) in the infrastructure. This also updates the current price on all other empowered platforms.

Buyer B2 places an order on platform Y for 20 units with the supplier, paying £95 per unit.

The supplier accepts the order, updating the cumulative volume sold (30 units). The supplier will issue a credit note for £50 (10 X £5 price decrease) for Buyer B1

Suppliers want to be able to showcase products in their own format and guide customers to their own sites. For example, if platform X was a centralised government marketplace, where all products are displayed in the same way, suppliers may want to offer their products on an additional platform (platform Y) where they can control how their products are displayed, whilst still maintaining the benefits of the collective aggregation used in the Price Curves of the present invention. However, having price curves on multiple platforms automatically linked has not been previously possible.

It should be noted that there can be any number of platforms. Embodiments of the invention enable suppliers to immediately provide all decentralised buyers (whether on one platform or many simultaneously) with dynamic market information such that in real-time, all organisations can view the total number of units bought by all other organisations and the direct visualisation of the benefits in price to coordinate future purchasing decisions by seeing immediately how the price changes depending on future aggregate demand.

Benefits include the automatic aggregation of all purchases across all organisations such that organisations do not have to wait to purchase together to be able to unlock the most value, and settlement of the movement of monies to ensure that all parties, including buyer, supplier and optionally any upstream suppliers receive the correct funds dependent on the total market transactions.

Buyers can view a graphical interface displaying aggregated demand (the total number of units bought per specification by all organisations within the network) and view how the price updates in real-time with additional purchases. The invention can be accessed by prospective purchasers on any number of websites, which are all synchronised.

The system processes payments between the Buyers and the Suppliers to ensure that when the price of an item decreases (when the aggregate demand increases), in real-time: all previous purchasers receive a payment to reflect the decrease in price per unit caused by the increase in aggregate demand, and suppliers are guaranteed the correct funds through a specific combination of payments. The payments are handled automatically by the payment infrastructure .

Where the term "product" is used herein, it should be taken to encompass a product, article or commodity as well as a service.

Whilst endeavouring in the foregoing specification to draw attention to those features of the invention believed to be of particular importance, it should be understood that the applicant claims protection in respect of any patentable feature or combination of features referred to herein, and/or shown in the drawings, whether or not particular emphasis has been placed thereon.

Claims

1. A transaction management system comprising: one or more communication interfaces operable to receive a plurality of transaction requests for a product; a storage unit operable to store the plurality of transaction requests and account data of a user making each transaction request; a determination unit operable to determine whether a transaction request meets a predetermined condition; and a funding unit operable to charge a funding source associated with the user and determine a credit amount; wherein an account balance associated with the account data is increased by the credit amount based upon a predetermined completion criterion, and wherein the system configures the storage unit, the determination unit and the funding unit to operate substantially simultaneously and in real time, automatically in response to new product data and/or a new transaction request being received.

2. The transaction management system of any previous claim, further comprising a withdrawal unit operable to enable the account balance to be withdrawn by the user to their associated bank account and/or used for a subsequent transaction.

3. The transaction management system of any previous claim wherein, the storage unit may be operable to store product data relating to products being offered for sale.

4. The transaction management system of Claim 3, wherein the product data comprises a price curve.

5. The transaction management system of Claim 4, wherein, the price curve relates to a quantity of products sold to price.

6. The transaction management system according to Claim 4 or 5, wherein the price curve comprises a series of ranges of quantities, units, volumes or the like, each being associated with a respective price.

7. The transaction management system of any previous claim, wherein the step of determining whether predetermined conditions have been met, may comprise determining if the number of transaction requests exceeds a limit of one of the quantity ranges.

8. The transaction management system of any previous claim, wherein the step of determining whether predetermined conditions have been met may comprise determining if a sale time exceeds a limit of one of the ranges.

9. The transaction management system of any previous claim, wherein the determination unit calculates an amount to be transferred to one or more accounts associated with the transaction.

10. The transaction management system of any previous claim, wherein the system comprises a delay unit operable to wait a predetermined returns time after the completion criterion has been satisfied before determining the credit amount.

11. The transaction management system of any previous claim, wherein the system comprises receiving product data from a selling device and/or a selling system.

12. The transaction management system of any previous claim, wherein the system further comprises a document generation unit for generating one or more transaction- related documents.

13. The transaction management system of Claim 20, wherein the transaction related documents are generated by the document generation unit at predetermined periods.

14. A method of settling funds between a purchaser and a seller using an infrastructure, the method comprising the steps of: registering a purchase by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; updating the price and the price curve; and settling the accounts; transferring funds equivalent to the price; wherein the step of transferring funds comprises calculating a percentage of the price that is paid by each of the one or more funding sources and allocating the funds to one or more receiving accounts.

15. The method of any of Claim 14, wherein the step of settling the accounts comprises: determining the current sale value based upon the price curve data of the item; determining a difference; transferring an amount to be settled from a first receiving account to a second receiving account; wherein the amount to be settled is equal to the difference.

16. The method of Claim 15, wherein the difference is equal to the price minus a minimum price based upon the price curve.

17. The method of any of Claims 14-16, wherein the step of settling the accounts further comprises; aggregating how much the infrastructure owes the supplier; aggregating how much the supplier owes the infrastructure; determining a difference between the two amounts; and transferring funds equivalent to the difference from a first receiving account to a second receiving account.

18. The method of any of Claims 14-17, further comprising the step of generating one or more documents relating to the transferring of funds.

19. A transaction management method, the method comprising the steps of: receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited by the credit amount.

20. The transaction management method of Claim 19, further comprising storing product data relating to products being offered for sale or lease.

21. The transaction management method of Claim20, wherein the product data comprises a price curve.

22. An apparatus comprising a processor and a memory having therein computer readable instructions, the processor being arranged in use to read the instructions to cause the performance of a method of settling funds between a purchaser and a seller using an intermediary, the method comprising the steps of: registering a purchase by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; updating the price and the price curve; and settling the accounts; transferring funds equivalent to the price; wherein the step of transferring funds comprises calculating a percentage of the price that is paid by each of the one or more funding sources and allocating the funds to one or more receiving accounts.

23. A computer implemented method comprising settling funds between a purchaser and a seller using an infrastructure, the method comprising the steps of: registering a purchase by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; updating the price and the price curve; and settling the accounts; transferring funds equivalent to the price; wherein the step of transferring funds comprises calculating a percentage of the price that is paid by each of the one or more funding sources and allocating the funds to one or more receiving accounts.

24. A computer program product on a non-transitory computer readable storage medium, comprising computer readable instructions that, when executed by a computer, cause the computer to perform a method comprising settling funds between a purchaser and a seller using an infrastructure , the method comprising the steps of: registering a purchase by the purchaser of an item at a selling event, at a price determined by a price curve defining one or more offer conditions; determining one or more funding sources; updating the price and the price curve; and settling the accounts; transferring funds equivalent to the price; wherein the step of transferring funds comprises calculating a percentage of the price that is paid by each of the one or more funding sources and allocating the funds to one or more receiving accounts.

25. An apparatus comprising a processor and a memory having therein computer readable instructions, the processor being arranged in used to read the instructions to cause the performance of a transaction management method comprising the steps of: receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited the credit amount.

26. A computer-implemented method comprising: receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited the credit amount.

27. A computer program product on a non-transitory computer readable storage medium, comprising computer readable instructions that, when executed by a computer, cause the computer to perform a transaction management method, comprising the steps of: receiving a transaction request for a product; determining a funding source; determining whether one or more predetermined conditions have been met; updating account information of one or more users that have previously made transaction requests for the product when the predetermined conditions have been met; and determining a credit amount when a completion criterion has been satisfied; wherein the funding source is charged an amount associated with the transaction request and an account balance associated with the account information is credited the credit amount.