WO2008036998A1

WO2008036998A1 - Financial transaction processing method and system

Info

Publication number: WO2008036998A1
Application number: PCT/AU2007/001395
Authority: WO
Inventors: Anthony Hynes; Cameron Oreo; Daniel Stones
Original assignee: Psp Corporation Pty Ltd
Priority date: 2006-09-29
Filing date: 2007-09-22
Publication date: 2008-04-03

Abstract

A system and method for providing financial transactions between sellers and providers based on originating transactions between the sellers and purchasers. The originating transaction between the seller and purchaser provokes a credit request from the provider. The provider reviews the request and issues credit from a credit account. The credit is limited to reconciling the credit for preferably only the originating transaction between the purchaser and seller, and is preferably non-applicable to other transactions or providers. Reconciliation of the credit account completed by payment by the seller. The operation of the system and method is preferably automated.

Description

FINANCIAL TRANSACTION PROCESING METHOD AND SYSTEM

FIELD OF THE INVENTION

This invention relates to a system and method of conducting and providing financial transactions between a provider and a reseller of the provider.

BACKGROUND OF THE INVENTION

A typical sales arrangement includes at least one customer, a reseller, and an end service provider. In this sales arrangement, the reseller offers (for sale, purchase, lease, etc.) to a consumer one or more goods/services of the provider. The consumer obtains the goods/services from the reseller, and in turn, the reseller assumes a financial obligation to the provider for the value of the goods/services.

The conventional process for payment of goods/services in a "customer/reseller/end-service-provid er" model mandates that a series of interdependent financial transactions be processed in order to transfer value (such as for example "money," "assets," or "funds") from the customer through to the reseller , who is then required to pay an amount to the end service provider. For example, a consumer of airline tickets may consult a travel agency (i. e. , the. reseller) for tickets from an airline (Le. , the provider). Accordingly, in a typical sale (Le., purchase) of an airline ticket by the consumer, the consumer purchases the ticket from the reseller, who would then be required to pay a corresponding amount to the provider, as commonly arranged in a trade agreement between the reseller and the provider.

Thus, once the customer arranges payment for the transaction with the reseller, the transaction between the two parties is effectively complete (notwithstanding delivery of the goods/services purchased). A second transaction must then occur between the reseller and the provider, as the reseller must pay the provider for the goods/services purchased.

Under many trade agreements, access to a line of credit is typically established prior to the transaction. The line of credit defines the terms for settling invoices raised for goods/services sold on the end service provider's behalf. Conventionally, the terms of credit are expressed as a value (the total amount of funds up to which the end service provider will allow the reseller to defer payment) and a time period (which defines the length of time over which payment may be deferred). As a result, if the reseller has available funds and elects to be invoiced for the transaction value of the originating transaction, then the end service provider will not receive payment until the end of the credit time period is reached. While the practice of allowing trade credit Is widely accepted, it is not an optimal situation for the end service provider, who would have no choice but to assume the risks associated with offering credit (e.g., whether payment will be made by the reseller), regardless of the fact that the good/services may be consumed in the meantime.

To facilitate the clearance and settlement of funds between each party in the conventional sales/reseller model, a level of control and vigilance over the billing and settlement process by the end service provider is generally required. These controls are primarily concerned with the relationship between the reseller and the end service provider and include, for example, the establishment of trading terms (trade credit accounts), and maintenance of credit balances against purchases made (managing and observing credit limits and validating available credit prior to purchasing). Additionally, there must also exist an agreed upon processing arrangement involving at least one mechanism that would ensure mat sufficient payment methods {e.g. , cash, credit, or check) exist and that me value (of the funds) can be readily transferred from the reseller to fhe end service provider in accordance with the credit terms established. These controls are typically and collectively referred to as "billing and settlement" controls. The responsibility for establishing the billing and settlement controls is typically the domain of the end service provider and day-to-day governance of the controls is often outsourced to a third party. In some cases, the third party billing and settlement controller may act on behalf of a single end service provider, or may, in fact, operate as a primary billing and settlement controller offering this service on behalf of participants across an entire industry. Moreover, conventionally, while a customer settles the originating transaction with the reseller or previous to the originating transaction in a trade agreement, the provider may typically extend credit to the reseller for a predetermined period. For example, the end service provider may provide some value and/or time to pay the outstanding balance. Upon expiration of the agreed credit period, the party responsible for controlling billing and settlement will typically attempt to extract the funds owed from the reseller. The methods for collection generally include the use of one or more of the following: bank checking accounts, credit card accounts, debit and charge accounts.

The conventional system of credit transactions as described above allows the reseller to receive payment immediately from the customer and having access to the funds for the duration of the credit term as per the arrangement with the end service provider. The financial institutions (e.g., banks, credit card companies) benefit from the terms of transaction fees and the interest collected. Additionally, the external billing and settlement provider, if used to control billing and settlement, would also enjoy similar benefits.

The conventional system and methods for conducting credit transactions has a number of drawbacks, however, particularly with respect to the financial welfare of the provider. Primarily, the conventional system and methods create a high level of fragmentation, making the processing of credit transactions inefficient and costly. Typically, the end service provider must carry significant receivables risk due to lengthy delays in receiving money owed or otherwise settling outstanding debts. As the process tends not only to be inefficient, but may prove to be costly as an end-service-provider typically has no choice but to carry significant receivables risk. This problem is exacerbated due to the length of time during which credit is extended, which has negative impacts on cash flow and may also lead to increases in a number of subsequent operation costs and the cost associated with obtaining business finance.

There is a need in the art for a method and system of providing financial transactions that streamlines the process of arranging payment and reconciling outstanding debts due to issued credit, preferably from a provider to a reseller.

The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

SUMMARY OF THE INVENTION

The present invention provides a streamlined and efficient system and method of providing financial transactions, such as the seamless extension (i.e., issuance) of credit from a provider to a reseller of the provider's transaction items, such as goods and/or services of the provider. According to a first aspect of the invention, there is provided a method for conducting a financial transaction comprising: providing to a seller the right to transfer a transaction item from a provider; conducting an originating transaction to transfer the transaction ftem from the seller to a buyer for a determined amount; electronically receiving a request for credit by the seller corresponding to the determined amount; validating the request for credit to confirm the identity of the seller and to determine the credit available to the seller; electronically issuing the credit to the seller, wherein the credit is associated only with the originating transaction; and settling the credit

According to a second aspect of the invention, there is provided a method for conducting a financial transaction comprising: electronically receiving a request for credit by a seller corresponding to a predetermined amount; validating the request for credit to confirm the identity of the seller and to determine the credit available to the seller, and electronically issuing the credit to the seller, wherein the credit is associated only with an originating transaction.

In some preferred embodiments, the request for the credit is for the determined amount and in some embodiments, the originating transaction comprises a limited number of transactions which are preferably substantially concurrent. In a particularly preferred embodiment the originating transaction comprises one transaction.

In some embodiments the credit only applies to the provider issuing the credit and the credit is issued corresponding only to the originating transaction. The credit available to the seller may be of any suitable type, for example, it may he a credit limit, assigned to the seller minus any cumulative credit that is outstanding from the provider to the seller when the request is validated. The invention is suitable for use irrespective of the finance-status of the purchaser. Thus for example in some embodiments, (sometimes called a finance model), the purchaser may have obtained pre-approved finance so that there may be an associated credit period, for example 30 days. In other embodiments or situations, there may be no finance facility so that the credit period is effectively set to zero or does not exist as an option.

Settlement may occur by any suitable means, for example in some embodiments, settling comprises: identifying the seller provided with the credit; determining the amount of the credit due to the provider; and collecting payment to the provider for the amount of the credit due within a predetermined time period. In some embodiments, the transaction item is in inventory of the provider at the time of the originating transaction. The various roles performed in the method of the present invention may be performed by any suitable parties. Thus in some embodiments, a first bank in which the provider has an account conducts the receiving, the validating and the issuing. Collection of funds may be undertaken by any suitable player - for example the finance provider, or a third party according to standard business practice

Some preferred embodiments comprise the step of generating an identifier that uniquely identifies the credit issued corresponding to the originating transaction. The identifier according to these embodiments may be of any suitable type, for example, it may conform to ISO standard 7812. In some embodiments, the identifier is not used for any transaction or credit issuance other the originating transaction and the credit issued thereto.

The request for credit may be transmitted at any appropriate time. Thus in some embodiments, the request for credit is transmitted substantially concurrent with the originating transaction. Information may be communicated in any suitable way, for example, a request for credit may be transmitted over a first communication network and the issuing of the credit is transmitted to the seller on a second communication network.

In a third aspect of the invention, there is provided a system for conducting a financial transaction, comprising: a receiving network for communicating a credit request from a seller to a provider, wherein the credit is specifically for an amount corresponding to a originating transaction between the seller and a buyer; a credit processor connected to the network and configured for identifying the seller and assessing the credit available to the seller when the request is received; a credit issuer connected to the processor and configured to issue the credit to the seller; a credit reconciliator configured for enabling the settlement of the credit upon payment of an incurred debt based on the credit issued; and a settlement system for settling credit. In a fourth aspect of the present invention, there is provided a system for conducting a financial transaction, comprising: a receiving network, for communicating a credit request from a seller to a provider, a credit processor connected to the network and configured for identifying the seller and assessing the credit available to the seller when the request is received; and a credit issuer connected to the processor and configured to issue the credit Io the seller. In some embodiments, the credit processor is connected to communicate with a plurality of computers to receive credit requests from a plurality of sellers.

The provider may be any suitable organisation or person, in some embodiments, the provider is a bank.

Storage and maintenance of the various components of the present system may be done in any suitable way. Thus, in some embodiments, the credit processor, the credit issuer, and the credit reconciliator are stored on a computer readable medium.

Some preferred embodiments comprise a processing system configured and adapted to communicate with a plurality of computers, wherein the processing system is arranged to accept communication from a plurality of sellers.

Preferred embodiments of the present invention are directed to methods for conducting financial transactions. In accordance with the method, a seller is provided with the right to transfer a transaction item from a provider. An originating transaction is conducted to transfer the transaction item from the seller to a buyer for a determined amount. In some variations, the transaction item is in the inventory of the provider at the time of the originating transaction. A request is electronically transmitted, preferably substantially concurrent with the originating transaction, and received by the provider for issuance of credit to the seller corresponding to, and preferably for, the defermined amount The request for credit is validated to confirm the identity of the seller and to determine the credit available to the seller and (the credit, which is associated only with the originating transaction, is electronically issued to the seller. The credit is ultimately settled by the seller. In some variations, the provider's bank conducts the receiving, the validating and the issuing steps disclosed herein.

In some embodiments of the present invention, the originating transaction comprises a limited number of transactions, such as one transaction, which may be substantially concurrent

In other embodiments of the present invention, the credit only applies to the provider issuing the credit and the credit is issued corresponding only to the originating transaction, In certain embodiments of the present invention, the credit available to the seller is a credit limit assigned to the seller minus any cumulative credit that is outstanding from the provider to the seller when the request is validated. In yet other embodiments, the reconciling step includes identifying the seller provided with the credit, determining the amount of the credit due to the provider; and then collecting payment to the provider for the amount of the credit due within a predetermined time period.

In yet other preferred embodiments, the method includes generating an identifier that uniquely identifies the credit issued corresponding to the originating transaction. Preferably, the identifier conforms to ISO standard 7812. In addition, in some embodiments, the identifier may not be used for any transaction or credit issuance other than, the originating transaction and the credit issued thereto. It is preferred that the request for credit is transmitted over a first communication network and the issuing of the credit is transmitted to the seller on a second communication network.

Other embodiments of the present invention include a financial transaction system for conducting financial transactions. The system includes a receiving network that ^: communicates a credit request from a seller to a provider, such as a bank. Preferably, the credit is specifically for an amount corresponding to an originating transaction between the seller and a buyer. Additionally, the system may include a credit processor connected to the network and configured for identifying the seller and assessing the credit available to the seller when the request is received. In some variations, the credit processor is connected to communicate with a plurality of computers to receive credit requests from a plurality of sellers. A credit issuer is preferably included in the system and is connected to the processor and configured to issue the credit to the seller. Moreover, a credit reconciltator, which is configured for enabling the settlement of the credit upon payment of an incurred debt based on the credit issued, is included in the system, In addition, a settlement system is used for settling the credit In certain preferred variations, a processing system that is configured and adapted to communicate with a plurality of computers is also included. The processing system is preferably arranged to accept communication from a plurality of sellers.

In yet other embodiments, the credit processor, the credit issuer, and the credit , reconciliator are stored on a computer readable medium. Any of the embodiments illustrated above and below stand independently or features may be combined to achieve preferred embodiments. Additional advantages and embodiments of the invention will also become more apparent to those of ordinary skill in the art upon review of the teachings of the present application.

Throughout this specification (including any claims which follow), unless the context requires otherwise, the word 'comprise', and variations such as 'comprises' and 'comprising', will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a process flow diagram illustrating a method of issuing a Virtual

Account Number ("VAN") to pay for goods/services ultimately provided by an end service provider, according one embodiment of the invention;

Figure 2 is an event driven process diagram for the generation of VANs, according to one embodiment of the invention; Figure 3 is an event driven diagram outlining a method for meeting the settlement and processing requirements, according to one embodiment to the invention;

Figure 4 presents hardware, software or a combination thereof that may he implemented in one or more computer systems or other processing systems to carry out the functionality, of the present invention, in accordance with one embodiment of the present invention; and

Figure 5 presents an exemplary system diagram of various hardware components and other features, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS The present invention encompasses business to business ("B2B") and/or business to consumer ("B2C") financial transactions including a transfer of a transaction item from a provider to a purchaser via a seller. As used hereto, the "purchaser" is also referred to herein as a "buyer" or "payor." In some instances, such as in a retail sales environment, the buyer is commonly referred to as a "customer" or "consumer," in which the buyer is a non-business entity. When the consumer is not a business, but the provider or seller is a business, the transaction is deemed to be B2C. In other instances, the buyer is a business entity. Generally, a purchaser is defined as any party obtaining the rights to a good/service through a transfer for value.

The seller has acquired from the provider the right to transfer the transaction item to the buyer. The seller can be a reseller, in the case that it purchases the transaction item from the provider and resells it; a consignee, in the case that it has the right to sell or otherwise -transfer the transaction item from the provider, such as for a commission; a retailer; an agent; an intermediate consumer (or non-business entity) seeking to further transfer rights in the transaction item, or can have another relationship with the provider to transfer the item to a buyer. The buyer can actually purchase the transaction item outright or obtain another right thereto, such as a lease, an option, or a share. The provider can be a primary seller, who sells the transaction item to the seller; a consignor, who retains ownership of the transaction item until the item is sold the buyer on consignment; an end service provider, or can have another relation to the seller, buyer, and the transaction item. The provider in this embodiment can also be the creditor or payee. As used herein, an "originating transaction" involves the seller and the buyer, in which the seller transfers a good/service to the buyer in exchange for value.

As used, herein, "reconciling" encompasses "balancing." "payment," or "settling" the debt incurred by the seller as a result of assuming the credit issued by the provider.

The invention disclosed herein provides an improved automated system and method of conducting and reconciling (le. , settling outstanding balances) between business parties, such as sellers and providers, for example, which are two parties that typically have a trade relationship with one another.

The present invention allows the reduction of the risks associated with offering credit, most particularly, whether payment will be made by the seller. Embodiments of the present invention provide the provider with instantaneous, preferably real time, information as to whether a particular seller has available funds. If credit is issued, the present invention allows the provider to avoid traditional invoicing of the seller. Payment of funds to the provider is expedited through the issuance of a virtual credit card. As a result, payments are typically made in a timely fashion , as opposed to the payment in the conventional art in which payment is not typically provided until the end of the credit time period is reached, thereby negatively affecting the cash flow of the provider. Generally, the present invention provides a system and method of providing financial transactions that provides credit, preferably a VAN identifying said credit, and/or a credit account on behalf of the seller, in which, the credit account is specifically linked to one or more transactions, and preferably one transaction (Le., the originating transaction) between a seller of the provider's goods/services and a purchaser. Generally, the seller must repay the outstanding cost of the goods/services transferred to the purchaser, such as by sale, lease, rental, offer, or other provision of the goods/services.

The present invention relates to the balancing of the seller's outstanding debt to the provider. In embodiments of the present invention, credit accounts are established based on efficient processing of the seller's credit profile. Additionally, the credit account and credit extended are linked to processes to efficiently and systematically reconcile the outstanding debt, for instance, through a billing and settlement and payment processing and clearing service.

In certain embodiments, systems and methods are provided to create and issue a limited use, preferably one time use, virtual credit card or the like {eg., a VAN) to a seller from a provider. The virtual credit card may be used as currency allowing the seller to acquire goods/services from the provider, and in preferred embodiments, to transfer funds to settle the virtual credit card debt owed to the provider.

Figure 1 illustrates an exemplary overview of the transactional scheme encompassed by certain embodiments of the present invention. As discussed, the transactional scheme is based on an originating transaction between one or more purchasers and a seller of the provider's goods/services. Once the purchaser pays the seller for the transfer, as would be understood to those skilled in the art, the originating transaction is confirmed and complete (notwithstanding delivery of the goods/services purchased, if applicable). Following the completion of, or substantially concurrent with the completion of, the originating transaction, the seller and provider would engage in a subsequent transaction (interchangeably referred to herein as the "credit transaction"), which represents on agreement between the seller and provider for the seller to pay the provider for the goods/services acquired by the purchaser. Preferably, the agreement provides the seller access to a line of credit from the provider.

As used herein, "substantially concurrently" encompasses any time proximal to the completion of the originating transaction, in which the costs associated with the transaction are known, and preferably locked in place. In preferred embodiments, the initiation of the credit transaction occurs within about 30 minutes of the close of the originating transaction, more preferably within about 10 or 2 minutes, and most preferably within one minute, and more preferably within about 30 or 10 seconds of the close of the originating transaction. As defined herein, "completion" or "close" of the originating transaction encornpasses an agreement by the purchaser and seller to engage in a transaction, preferably in which the purchaser agrees to repay the provider with fluids for the seller's goods/services. In preferred embodiments, a closed originating transaction, is an executed purchase agreement between the purchaser and 1he seller.

In other embodiments, the initiarion of credit encompasses a period after the completion of the originating transaction. That is, the initiation of the credit transaction can occur at any agreed upon time after the close of the originating transaction. In some variations, the initiation of credit can be done in batches and sent, at a predetermined time, for example, once a day, once a week, etc. When the initiation of credit is done in batches of transactions, some of the transactions can be concurrent with the initiation of credit

The seller sends a communication requesting the issuance of credit to the provider (e.g., a VAN request message). In the communication, the seller requests the issuance of credit and/or the establishment of a credit account for credit corresponding to the originating transaction, as generally depicted by Figure 1, and more specifically illustrated in Figure 2.

The communication between the seller and me provider is preferably conducted on a preferably dedicated communication channel or network of an Integrated System that communicably links one or more sellers and the provider. In certain embodiments, the Integrated System may functionally include additional operations, such as performing the function of a distribution channel, specifically the sourcing of goods/services available by the purchaser from the provider's inventory and confirming and recording any resulting purchase made by the seller on behalf of a purchaser. For example, Integrated Systems within the travel and tourism industry can include Airline Internet Booking Engines ("IBEs"), Global Distribution Systems ("GDSs"), GDS New Entrants("GNEs") and Centralized Airline Ticketing Systems ("CATS").

Following receipt of the request, the modalities of the present invention generate a credit card number for the seller using an credit cord issuing system (e.g., the VAN Issuing System), preferably operating on a second communication channel or network of an Issuing System, as discussed below. A response message, generated, for example, by a processor that is able to analyze the issuance of credit, is delivered to the seller. Accordingly, information is provided as to whether credit bas been issued, and if so, a credit issuing feature, such as a credit issuer, for example, may provide other pertinent information, such as the predetermined time to remit payment and/or the amount of the credit, for instance.

At the predetermined time after issuance of the credit, the settlement process is conducted to collect payment for the seller's assumed credit debt In certain embodiments, the provider conducts the settlement process, using, for example a credit τeconciliator and/or a settlement system. In some embodiments, the credit reconciliator comprises the settlement system and is configured to affect the credit upon payment In embodiments, the reconciliator settles the credit In other embodiments, the reconciliator sends one or more signals to a settlement system, which can be, for example, a bank, computer, person, etc., that settles the credit debt

In some embodiments, the settlement process is conducted by one or more third parties, such as banks, financial institutions, and the like, as would be understood to one skilled in the art In these embodiments, the settlement process includes the submission by the credit issuing bank of the credit for clearance to the seller's (i.e., debtor's) bank. Settlement is facilitated and payment is made to the service provider.

The Issuing System, as used herein preferably includes the functionality related to issuing credit to the seller and is preferably controlled by the provider to issue credit (e.g, the credit associated with a VAN) to a party, such as the seller, In preferred embodiments, a VAN is used as a form of payment to use the credit to expedite financial settlement between sellers and end service providers, by for instance, facilitating the transfer of funds to an end service provider for goods/services purchased by the seller is provided. The Issuing System may create the VAN preferably upon the receipt of an incoming request from the Integrated System. The benefits and functionality provided by the present invention are enhanced by communication between the Issuing System and the Integrated Systems.

Additionally, in some variations, the Issuing System may handle multiple functions. For example, according to some embodiments of the invention, the Issuing System can provide one or more of the following features: 1) a system that allows for the registration, creation and storage of client profiles which contain information related to all parties and systems that need a credit profile or distribute the provider's goods/services; 2) a verification method that ensures that all Integrated Systems, processes and transaction parties that are used and/or referenced within the request messages can be validated and are, in tact, authorized to communicate with the Issuing System; 3) a credit management system to act as a control that provides for a validation check capable of ensuring that a VAN can only be issued for transactions in which the payer has sufficient available funds to complete the transactions; 4) a system capable of generating a virtual credit card number and associated account information that conforms to standard credit card account issuing requirements; and 5) a clearance system capable of generating the necessary output data files, which are used to ensure that transactions are processed and funds are cleared to end service providers. The implementation of the Issuing System preferably considers the risks associated with issuing credit to the seller. Fn some embodiments, the terms of credit, are preferably expressed as a value (the total amount of funds up to which the end service provider will allow the seller to defer payment) and a time period (which defines the length of time over which payment may be deferred). For example, the Issuing System may be configured so that the issuance of credit is predicated upon the availability of funds to the seller. Thus, according to this embodiment, the provider may set a requirement that the total value of credit issued may be limited in some way, for example to a certain aggregate value. In this instance, the credit, and an associated VAN, would be issued if the seller has enough credit (available funds) remaining against the seller's account The processes controlling and confirming the security associated with the issuance of credit are collectively referred to herein as "validation." Validation may involve one or more levels of clearance or security, including confirmation of credit status, account confirmation, and risk assessment. Certain aspects of the Issuing System are preferably responsible for the registration and ongoing management of authorized parties. A registered entity database according to this aspect of the invention may perform various useful functions. For example, it may verify that all parties requesting credit and the generation of a corresponding VAN are appropriately authorized.

Figure 2 describes an exemplary validation process upon receipt of the incoming request by the Issuing System and the generation of VAN corresponding to the credit issued, as shown in system 400. The first action to be taken is referred to in the diagram as 1^st Level validation, as shown by step 401. This step includes a series of checks against information stored on the database and validates the origin and syntax (format and content), of the incoming message, as shown in step 402. Once the syntax of the message is validated, a check is made to ensure the request has been made froxn an authorized system. According to this embodiment of the invention, all incoming credit request messages contain a set of data used to identify the Integrated System responsible for making the request for issuance of credit and generation of a corresponding VAN. The same data string is stored in the Issuing System database and an attempt to match the two valves would be made to ensure that the system sending the message does exist and has supplied the correct credentials within the request message. If a match is not found and validation at this point fails, as shown in step 405, a detailed error message is returned and the request ignored without any further processing. If 1 ^st level validation is successful, as shown in step 403, then the system will proceed to 2^nd level validation which is referred to as Credit Management, as shown in step 404.

The second validation, tor example, includes a check that the information - supplied in the credit request message matches the information stored on the database. More specifically a validation takes place to ensure that the seller responsible for paying the end service provider is defined to the Issuing System and that sufficient funds are available.

In this example, sufficient funds exist only when the purchase amount contained in the incoming request message - when added to the total credit already issued to the seller in certain embodiments — does not represent an amount greater than the credit limit amount set by the end service provider which is stored on the database. Accordingly, only if the system ascertains that the seller has sufficient funds will a one-time use VAN be generated, as shown in step 407. If it is determined that the seller does not have sufficient funds then a detailed error message is returned to the Integrated System and the request for issuance of credit is ignored without any further processing, or returned with an error signal in certain variations. Preferably only after successful validation at the first and second level will a new

VAN be created . At a hase level in yet other embodiments, this involves the creation of a virtual credit card account conforming to the standards outlined in ISO standard 7812, as encompassed - by step 408. The standard dictates that all credit card numbers contain a certain amount of internal structure, and share a common numbering scheme. As such, all VANs created by the Issuing System contain a six-digit issuer identifier number (UN), an account number, and a single digit checksum or check digit The check digit, as it is commonly referred to, is derived by employing the Luhn algorithm to ensure that the string created represents what is known as a MOD10 compliant number. The present invention provides a system under which the generation of such a number is automated.

VANs, which are associated with the credit issued, may be generated from a procedure stored on the Issuing System which involves the usage of specific account number parameters stored on the Issuing System database. The information stored on the database contains a record of all possible IIN/check digit combinations available for use (the IIN being first 6 digits making up the VAN and the check digits being the final digit in, the VAN to be generated (numbers 0-9)). Also stored against each IIN/check digit combination is the last conforming nine digit account number generated. The last account number fills the space between the IIN and the check digit

According to one embodiment of the invention, the method employed by the system responsible for VAN generation calls for an available BIN and check digit combination to be selected at random from the database. The system then generates the next available and valid number for the selected ITN/check digit combination. This is done by adding 1 to the last Account Number value and running the Luhn algorithm to verify the IIN-ACCOUNT NUMBER-CHECK DIGIT combination is valid and that the MOD10 is compliant

If the number is not valid, the Issuing System increments the last account number attempted by a factor of one and re-runs title Luhn algorithm to satisfy the requirement for the number to be MOD10 compliant. This process is repeated until a valid combination is found, at which point it is stored in the Account Number field ready to be incremented by one and used as the starting point for the next request

Once a valid 16 digit VAN has been generated, en expiry data is then generated and expressed as MM/YY where MM equals month and YY equals the year. This represents the time after which me card is no longer able to be used.

Lastly, a cardholder name may be assigned and a series of restrictions may be added to the account created which may for example ensure that the card is unable to be used for any other purpose outside of the intended transaction that is to be completed between the seller and end service provider as defined in the incoming VAN generation and credit request message, as described generally by step 408. Such an approach provides significant advantages. For example, in preferred embodiments, the credit and associated VAN are only issued based on an incoming request, which details the conditions under which it can be used. Thus, the VAN is electronically generated with specific attributes including, but not limited to, the locking of the card limit to the total value of the transaction between the seller and the end service provider. Additionally, any attempt to process the transaction is limited to paying only the end service provider or merchant as nominated within the original request message.

Once the VAN has been created, the next step requires that a pre-authorization code 13 generated, as shown in step 409. This step further ensures that the card is rendered inactive or "dead" before it is even known to exist by any other party. A valid authorization code is a six digit numeric string and is commonly used in credit processing as proof that the required funds are available on a credit card and furthermore ensures that a block has been placed on the card for the required amount so that they it may be captured at a later date. The amount for which the pro-authorization code is generated according to this embodiment of the invention will equal the total amount of funds available on the card. The advantage being that any subsequent transaction attempt on the newly issued VAN would be declined on the basis of insufficient funds being available for any subsequent purchase.

Upon completion of virtual account creation and the generation of the Authorization code according to these embodiments, a new transaction record is inserted into the database, as shown in step 410. The record consists of the virtual account details, as shown in step 411, the authorization code and the transaction specific information such as the seller details, the end service provider details and the amount of the transaction. Once stored, the interaction between the Issuing System and the Integrated System may be completed with a detailed confirmation response message being sent back the Integrated System, as shown in step 412.

In some embodiments, pending successful validation, there is a trigger for the generating of a VAN that is treated thereafter as a traditional credit card and is then used as the method of payment and the financial instrument responsible for ensuring funds are processed to the end service provider without having to effect a transaction from the seller at the same time. In these embodiments pf the invention, apart from the single permitted use, the issued VAN is inactive from the moment it is created. In other words, from the moment it is created, the issued VAN is unable to be used to make any other purchase except that for which it was created. This provides increased security and provides a considerable and immediate level of fraud prevention. In preferred embodiments, the issuance of the credit and the corresponding VAN is based on the originating transaction. In preferred embodiments, therefore the VAN may be issued fnr the exact amount due to be paid from the seller to the provider, and thus, it cannot be used to make subsequent purchases. Moreover, in preferred embodiments, the VAN can be "locked" so that it may only be used to pay a single pre-defined merchant, and thus, the VAN cannot be used to pay anyone but the end. service provider. Additionally, at the time the credit is issued, the VAN is pre-authorized. Thus, any funds available on the VAN are already claimed (or "frozen") and may only be used to balance the value of the originating transaction. As the credit is tied to a single transaction and also includes a future expiry date, all VANs can be issued in a unique fashion, thereby ensuring that each VAN is unique (non repeated) and generated in a seemingly random fashion.

Additionally, the system provides a method for affecting payment between the seller and an end service provider which expressly observes the settlement timing requested by the end service provider, i.e., the "predetermined time period," as typically specified m the credit terms between the provider and seller under the trade agreement. Accordingly, embodiments of the present invention may include any suitable time period for payment, as agreed upon by the contracting parties. In some embodiments, a daily cut off time is set, as shown in step 301 of Figure 3. The daily cut off time is determined by the provider typically, and initiates the start of the daily settlement process when a predetermined time period is over. That is, if a predetermined time period ends on October 25^th, for example, the daily cut off time on October 25^th officially ends the predetermined time period.

In accordance with step 302 in Figure 3, the Issuing System provides a method for generating a series of data output files, which, according to one embodiment of the invention, ensures all VAN accounts are submitted in to clearing and settlement networks via third party card processing systems. According to another embodiment of the invention, at any given point, a procedure stored on the Issuing System may be triggered to generate a series of files for uses other than that of clearance and settlement. Such uses may, for example, include providing reconciliation data to banking institutions for import into existing physical card Issuing Systems. According to one embodiment, step 303 in the settlement (i.e., billing) procedure is to review and scan the registration and profile data stored on the database to ascertain which end service providers are due to receive funds according to rules previously configured and stored on the Issuing System. Once step 303 has been completed, existing transaction records are searched for payments in which the end service provider (requiring settlement) has been nominated as the payee (i. e. , the provider is owed money). For each matching payment identified, the data record is then updated with a series of settlement particulars including, but not limited to, a settlement TD and the date and time at which the settlement was run, as illustrated in step 304. Additionally, as shown in step 305, a new status for the transaction record is also inserted into the data record to designate that the record is not to be reprocessed under any circumstance and payment processing is complete.

A procedure contained within the Issuing System is invoked to create and write a portion of the transaction records identified to new output file(s) which are stored within the Issuing System and may subsequently he transferred into the credit card clearing and settlement system or made available to other authorized recipients, as shown in step 306. In this example, the file is submitted into, the clearing and settlement network, which facilitates a transaction between the issuing bank and the acquiring bank to settle the transactions. The acquiring bank may concurrently credit the provider's designated bank account

The present invention may be implemented using hardware, software, or a combination thereof and may be implemented in one or more computer systems or other processing systems. In one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example of such a computer system is shown in Figure 4.

Computer system 200 includes one or more processors, such as processor 204. The processor 204 is connected to a communication infrastructure 206 (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures. Computer system 200 can include a display interface 202 that forwards graphics, text, and other data from the communication infrastructure 206 (or irom a frame buffer not shown) for display on the display unit 230. Computer system 200 also includes a main memory 208, preferably random access memory (RAM), and may also include a secondary memory 210. The secondary memory 210 may include, for example, a hard disk drive 212 and/or a removable storage drive 214, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 214 reads from and/or -writes to a removable storage unit 218 in a well-known manner. Removable storage unit 218, represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to removable storage drive 214. As will be appreciated, the removable storage unit 218 includes a computer usable storage medium having stored therein computer software and/or data.

Ih alternative embodiments, secondary memory 210 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 200. Such devices may include, for example, a removable storage unit 222 and an interface 220. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 222 and interfaces 220, which allow software and data to be transferred from the removable storage unit 222 to computer system 200.

Computer system 200 may also include a communications interface 224. Communications interface 224 allows software and data to be transferred between computer system 200 and external devices. Examples of communications interface 224 may include a modem, a network interface (e.g. , an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 224 are in the form of signals 228, which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 224. These signals 228 are provided to communications interface 224 via a Communications path (e g., channel) 226. This path 226 carries signals 228 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and/or other communications channels. In this document, the terms "computer program medium" and "computer usable medium" are used to refer generally to media such as a removable storage drive 214, a hard disk installed in hard disk drive 212, and signals 228. These computer program products provide software to the computer system 200. The Invention is directed to such computer program products.

Computer programs (also referred to as computer control logic) are stored in main memory 208 and/or secondary memory 210. Computer programs may also be received via Communications interface 224. Such computer programs, when executed, enable the computer system 200 to perform the features of me present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor 204 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 200.

In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 200 using removable storage drive 214, hard drive 212, or communications interface 224. The control logic (software), when executed by the processor 204, causes the processor 204 to perform the functions of the invention as described herein. In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components, such as application specific integrated circuits (ASIGs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using a combination of both hardware and software.

As shown in Figure 5, in an embodiment of the present invention, the multimedia application operates, for example, on a network. A user 40, such as an applicant or application processor inputs information, via a terminal 41, suoh as a personal computer (PC), minicomputer, mainframe computer, microcomputer, telephone device, personal digital assistant (PDA), or other device having a processor and input capability.

As further shown in Figure 5, m one embodiment, the terminal 41 is coupled to a server 43, such as a PC, minicomputer, mainframe computer, microcomputer, or other device having a processor and a repository for data or connection to a repository for maintained data, via a network 44, such as the Internet, via couplings 45, 46, such as wired, wireless, or fiber optic connections. The specification and figures are to be regarded in an illustrative manner, rather than a restrictive one, and all such modifications are intended to be included within the scope of present invention. Although preferred embodiments of the invention have been described in the foregoing description, it will be understood that the invention is not limited to the specific embodiments disclosed herein but is capable of numerous modifications by one of ordinary skill in the art It will be understood that the materials used and technological details may be slightly different or modified from the descriptions herein, without departing from the methods and compositions disclosed and taught by the present invention. Many variations and modifications will be apparent to those of ordinary skill in the art Benefits, advantages, solutions to problems, and any elements) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all the claims.

Claims

THE CLAlMSWhat is claimed:

1. A method for conducting a financial transaction comprising: providing to a seller the right to transfer a transaction item from a provider; conducting an originating transaction to transfer the transaction item from the seller to a buyer for a determined amount; electronically receiving a request for credit by the seller corresponding to the determined amount; validating the request for credit to confirm the identity of the seller and to determine the credit available to the seller; electronically issuing the credit to the seller, wherein the credit is associated only with the originating transaction; and settling the credit

2. The method of claim 1, wherein the request for the credit is for the determined amount

3. The method of claim I, wherein the originating transaction comprises a limited number of transactions.

4. The method of claim 3, wherein the limited number of transactions are substantially concurrent

5. . The method of claim 3, wherein the originating transaction comprises one transaction.

6. The method of claim 1, wherein the credit only applies to the provider issuing the credit and the credit is issued corresponding only to the originating transaction.

7. The method of claim 1 , wherein the credit available to the seller is a credit limit assigned to the seller minus any cumulative credit that is outstanding from the provider to the seller when the request is validated.

8. The method of claim 1 , wherein settling comprises: identifying the seller provided with the credit; determining the amount of the credit due to the provider; and collecting payment to the provider for the amount of the credit due within a predetermined time period.

9. The method of claim 1 , wherein the transaction item is in inventory of the provider at the time of the originating transaction.

10. The method of claim 1. wherein a flτst bank in which the provider has an account conducts the receiving, the validating and the issuing.

11. The method of claim 1, further comprising generating an identifier that uniquely identifies the credit issued corresponding to the originating transaction.

12. The method of claim 11 , wherein the identifier conforms to ISO standard 7812.

13. The method of claim 11, wherein the identifier is not used for any transaction or credit issuance other the originating transaction and the credit issued thereto.

14. The method of claim 1, wherein the request for credit is transmitted substantially concurrent with the originating transaction.

15. The method of claim 1 , wherein the request is transmitted over a first communication network and the issuing of the credit is transmitted to the seller on a second. communication network.

16. A method for conducting a financial transaction comprising: electronically receiving a request for credit by a seller corresponding to a predetermined amount; validating the request for credit to confirm the identity of the seller and to determine the credit available to the seller; and electronically issuing the credit to the seller, wherein the credit is associated only with an originating transaction.

17. A system for conducting a financial transaction, comprising: a receiving network for communicating a credit request from a seller to a provider, wherein the credit is specifically for an amount corresponding to a originating transaction between the seller and a buyer; a credit processor connected to the network and configured for identifying the seller and assessing the credit available to the seller when the request is received; a credit issuer connected to the processor and configured to issue the credit to the seller, a credit reconciliator configured for enabling the settlement of the credit upon payment of an incurred debt based on the credit issued; and a settlement system for settling credit;

18. The system of claim 17, wherein the credit processor is connected to communicate with a plurality of computers to receive credit requests from a plurality of sellers.

19. The system, of claim 17, wherein the provider is a bank.

20. • The system of claim 17, wherein the credit processor, the credit issuer, and the credit reconciliator are stored on a computer readable medium,

21. The system of claim 17, further comprising a processing system configured and adapted to communicate with a plurality of computers, wherein the processing system is arranged to accept communication from a plurality of sellers.

22. A system foτ conducting a financial transaction, comprising : a receiving network for communicating a credit request from a seller to a provider; a credit processor connected to the network and configured for identifying the seller and assessing the credit available to the seller when the request is received; and a credit issuer connected to the processor and configured to issue the credit to the seller.