BACKGROUND OF THE INVENTION In today's information age, traditional forms of commerce are quickly being augmented or replaced by new forms of commerce that use various types of electronic media. Such new forms of commerce enable all or a portion of a commercial transaction to be effected electronically.

Even with this migration toward electronic commerce, it is still common for commercial transactions to be wholly paper-based. It is also common for commercial transactions to be initiated electronically but completed using traditional paper-based exchanges. A simple commercial transaction might involve the seller receiving an order (e. g., in the mail, over the phone, by fax, or through an electronic order entry system), mailing an invoice to the buyer, manually processing the invoice by the buyer, mailing a payment (such as a paper check) by the buyer to the seller, and manually processing the payment by the seller in order to reconcile the payment and deposit the check. Other types of commercial transactions may require additional forms of electronic or paper documentation and additional steps in order to complete the commercial transaction.

Such paper-based exchanges have a number of disadvantages. For one, the traditional paper-based exchange is slow, particularly due to the mailing time and the manual processing. Also, the traditional paper-based exchange is error-prone, particularly due to the manual processing and the number of steps required to complete the transaction.

Additionally, the traditional paper-based exchange is expensive. The transaction cost may be increased if third party service providers are used to process payments remitted through

a"paper lockbox."To make matters worse, the traditional paper-based exchange is susceptible to fraud (such as forgery, alteration, or duplication of a check), which increases the risk of the transaction for both the buyer and the seller. These problems are exacerbated as the commercial transactions become more complex, requiring more steps to complete and more documentary evidence for confirmations and accounting.

One way to improve commercial transactions is for payments to be completed using some form of electronic payment. An electronic payment is a payment that is remitted and processed electronically. The electronic payment may be remitted using electronic mail (Email) or other electronic means. Any funds transfers from the payor to the payee may also be handled electronically, specifically through any of a number of settlement systems. The electronic payment eliminates paper and reduces the manual processing involved with the payment.

One form of electronic payment is an electronic check (Echeck). Electronic checking is described in an article entitled Electronic Checks-A Detailed Preview by John Doggett, published in the Journal of Retail Banking Services, Volume XVIH, No. 2 (Summer 1996), and also in an article entitled The Electronic Check Architecture by Milton M. Anderson, Version 1.0.2, published by the Financial Services Technology Consortium (FSTC) on September 29,1998, both of which are hereby incorporated by reference in their entireties. The format of an Echeck is described in the United States Patent No. 5,677,955 entitled Electronic Funds Transfer Instruments, which was issued on October 14,1997, and is hereby incorporated by reference in its entirety. An electronic checking system is described in the United States Patent No. 5,848,400 entitled Electronic Check Exchange, Clearing, and Settlement System, which was issued on December 8, 1998, and is hereby incorporated by reference in its entirety. An electronic bill payment system is described in the United States Patent No. 5,884,288 entitled Method and System for Electronic Bill Payment, which was issued on March 16,1999, and is hereby incorporated by reference in its entirety. Various forms of electronic documents are described in the United States Patent No. 6,021,202 entitled Method and System for Processing Electronic Documents, which was issued on February 1, 2000, and is hereby incorporated by reference in its entirety.

Briefly, an Echeck is an all-electronic payments and deposit-gathering instrument that can be initiated from a variety of devices, such as a personal computer, screen phone, Automatic Teller Machine (ATM), or payments accounting system. The Echeck provides rapid and secure settlement of financial accounts between trading partners over open public or proprietary networks, without requiring pre-arrangement, by interconnection with the existing bank clearing and settlement systems infrastructure.

The Echeck is modeled on the paper check, but is initiated electronically, and uses digital signatures for signing and endorsing and digital certificates for authentication.

Among other things, the Echeck includes fields for such information as a payor name, a payor bank, a payor bank account number, a check number, a payee name, and a payment amount, and also includes a memo field, a conditions field, and a restrictions field. The memo field is used like the memo field of a paper check, that is, for including a notation on the Echeck. The conditions field is used to enter conditions for the payee, such as "payment in full."The restrictions field is used to enter restrictions for the bank, such as "deposit only."The Echeck also includes a number of issuer-defined parameters that can be used to make the Echeck resemble other financial payment instruments, such as an electronic charge card slip, a traveler's check, or a certified check, and so is more flexible than a paper check.

The Echeck is delivered by either direct transmission or by public electronic mail (Email) systems. Payments (deposits) consisting of Echecks are gathered by banks via Email, and are cleared through standard banking channels, such as Electronic Check Presentment (ECP) or Automated Clearing House (ACH) networks.

Other forms of electronic payment, such as electronic cash (Ecash) and various forms of electronic payment orders, are also possible.

Unfortunately, simply using an electronic payment does not mitigate all of the above-mentioned problems. For example, even using an electronic payment, much of the commercial transaction is still paper-based, and requires substantial manual processing by the various parties to the transaction. As a result, the commercial transaction remains slow and expensive.

In addition, information and instructions related to such exchanges, as well as the identity of the parties and the persons issuing such information and instructions, should be transmitted through secure means and should be capable of authentication.

Thus, there is a need for a mechanism for coordinating and facilitating transaction exchanges electronically.

SUMMARY OF THE INVENTION In accordance with one aspect of the invention, a service provider maintains an electronic transaction facilitator for coordinating and facilitating commercial transactions.

In accordance with another aspect of the invention, an electronic transaction facilitator coordinates and facilitates commercial transactions. Email is preferably used to exchange transaction information, although other electronic means may also be used.

In accordance with another aspect of the invention, the electronic transaction facilitator determines and obtains the types of transaction information that are needed to complete a transaction. The electronic transaction facilitator determines the type of transaction and determines therefrom the types of transaction information that are involved with the transaction.

In accordance with another aspect of the invention, the electronic transaction facilitator authenticates the information and instructions it receives. Secure means for transmitting information and instructions are preferably used. Authentication is preferably performed using digital signatures.

In accordance with another aspect of the invention, the electronic transaction facilitator provides escrow services and generates associated electronic or documentary evidence in support of its transaction processing services.

In accordance with another aspect of the invention, the electronic transaction facilitator determines a disposition for a payment (i. e., whether to accept the payment, reject the payment outright, or hold the payment pending further instructions from the payee) as part of its transaction processing services.

In accordance with another aspect of the invention, the electronic transaction facilitator provides immediate funds to the payee for a payment. The electronic transaction facilitator may purchase the payment or extend a loan that is secured by the payment.

In accordance with another aspect of the invention, the electronic transaction facilitator obtains immediate funds for the payee from a third party service provider. The electronic transaction facilitator may coordinate a purchase or loan by the third party service provider. The electronic transaction facilitator may utilize a bidding process, such as an auction or reverse-auction, to obtain the purchase or loan.

In accordance with another aspect of the invention, the electronic transaction facilitator guarantees a payment for the payor.

In accordance with another aspect of the invention, the electronic transaction facilitator provides a billing service on behalf of a payee.

In accordance with another aspect of the invention, the electronic transaction facilitator provides a bill payment service on behalf of a payor. The electronic transaction facilitator receives an invoice from a payee including an invoice amount due, and evaluates the invoice in order to determine whether to submit a payment and the amount of the payment. The electronic transaction facilitator may confirm such information as the number of items ordered, the price per item, and any discounts or penalties reflected in the invoice amount due, among other things. The electronic transaction facilitator may determine that the actual amount due is different from the invoice amount due. Based upon instructions provided by the payor, the electronic transaction facilitator may submit an electronic payment for the actual amount due on behalf of the payor.

In accordance with another aspect of the invention, the electronic transaction facilitator assigns a risk score to a transaction. Specifically, the electronic transaction facilitator maintains credit information for various parties, and is also able to obtain additional credit information electronically. The electronic transaction facilitator uses the credit information to assess the risks associated with the transaction, and assigns the risk score accordingly. The risk score can be used by the electronic transaction facilitator or by a third party service provider.

In accordance with another aspect of the invention, the electronic transaction facilitator provides currency conversion services.

In accordance with another aspect of the invention, the electronic transaction facilitator provides currency"hedging"services to limit or exploit the risks associated with potential currency conversion rate changes.

In accordance with another aspect of the invention, the electronic transaction facilitator provides accounting information to one or more parties. The electronic transaction facilitator provides the accounting information to a particular party in the accounting format that is used by that party.

In accordance with another aspect of the invention, the electronic transaction facilitator provides information mining services. The electronic transaction facilitator can analyze individual transactions, or can statistically analyze multiple transactions in order to provide valuable statistical information to various parties.

In accordance with another aspect of the invention, the electronic transaction facilitator provides record-keeping services.

In accordance with another aspect of the invention, the electronic transaction facilitator can be used to provide a direct income stream to the service provider.

In accordance with another aspect of the invention, the electronic transaction facilitator sells payments to third party service providers. The payments can be sold individually or in blocks. The electronic transaction facilitator can assign a risk score to an individual payment or to a block of payments. The risk score can be used by the electronic transaction facilitator to determine a discount rate for the purchase, and also can be used by the third party service provider to assess the risks associated with the payment (s).

In accordance with another aspect of the invention, the electronic transaction facilitator auctions payments to third party service providers. The payments can be auctioned individually or in blocks. The electronic transaction facilitator can assign a risk score to an individual payment or to a block of payments.

In accordance with another aspect of the invention, an electronic transaction instrument is used to exchange transaction information and instructions electronically. A preferred electronic transaction instrument can be modified to include additional

transaction information as the transaction progresses. A preferred electronic transaction instrument is in XML format, and includes digitally signed transaction information and instructions. An entire electronic transaction instrument is typically digitally signed and transmitted using a secure communication mechanism.

BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other objects and advantages of the invention will be appreciated more fully from the following further description thereof with reference to the accompanying drawings wherein: FIG. 1 is a block diagram showing an electronic commerce system in which an electronic transaction facilitator is used to coordinate and facilitate transactions in accordance with an embodiment of the present invention; FIG. 2 is a block diagram showing relevant logic blocks of an exemplary electronic transaction facilitator in accordance with an embodiment of the present invention; FIG. 3 is a block diagram showing an electronic commerce system in accordance with an embodiment of the present invention; FIG. 4 is a logic flow diagram showing exemplary transaction processing logic for processing transaction information in accordance with an embodiment of the present invention; FIG. 5 is a logic flow diagram showing exemplary transaction processing logic for completing the transaction in accordance with an embodiment of the present invention; FIG. 6A is a logic flow diagram showing exemplary transaction processing logic for determining the disposition of the payment based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due in accordance with an embodiment of the present invention; FIG. 6B is a logic flow diagram showing exemplary transaction processing logic for determining the disposition of the payment based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due, wherein the transaction processing logic determines the actual amount due based upon any applicable

discount terms and penalty terms in accordance with an embodiment of the present invention; FIG. 6C is a logic flow diagram showing exemplary transaction processing logic for determining the disposition of the payment based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due, wherein the transaction processing logic performs a currency conversion on the payment and/or the actual amount due in order to determine whether the payment matches the actual amount due or is acceptably close to the actual amount due in accordance with an embodiment of the present invention; FIG. 7 is a logic flow diagram showing exemplary transaction processing logic for purchasing a payment from the payee in accordance with an embodiment of the present invention; FIG. 8 is a logic flow diagram showing exemplary transaction processing logic for extending a loan to the payee for the payment in accordance with an embodiment of the present invention; FIG. 9 is a logic flow diagram showing exemplary transaction processing logic for certifying a payment in accordance with an embodiment of the present invention; FIG. 10 is a logic flow diagram showing exemplary transaction processing logic for obtaining a purchase or loan for the payment from a third party service provider in accordance with an embodiment of the present invention; FIG. 11 is a block diagram showing the general format of an electronic transaction instrument in accordance with an embodiment of the present invention; FIG. 12A is a block diagram showing an exemplary electronic transaction instrument including a header, an invoice descriptor, and a terms descriptor, in accordance with an embodiment of the present invention; FIG. 12B is a block diagram showing an exemplary electronic transaction instrument including a header, an invoice descriptor, a terms descriptor, and a payment descriptor, in accordance with an embodiment of the present invention;

FIG. 12C is a block diagram showing an exemplary electronic transaction instrument including a header, an invoice descriptor, a terms descriptor, and an endorsed payment descriptor, in accordance with an embodiment of the present invention; FIG. 13 is a message flow diagram showing types of transaction information exchanged during an exemplary commercial transaction in accordance with an embodiment of the present invention; FIGs. 14A-14E show an SGML Document Type Definition (DTD) for an exemplary XML-based Digital Payment Authorization (DPA) document in accordance with an embodiment of the present invention; FIG. 15 is a logic flow diagram showing exemplary disburser client application logic for converting payment and remittance information into a payment file in accordance with an embodiment of the present invention; FIG. 16 is a logic flow diagram showing exemplary ETF logic for generating a settlement system file from payment and remittance information received in a payment file in accordance with an embodiment of the present invention; FIG. 17 is a logic flow diagram showing exemplary ETF logic for processing the payment file in accordance with an embodiment of the present invention; FIG. 18 is a block diagram showing an exemplary ETF system for coordinating and facilitating commercial transactions in accordance with an embodiment of the present invention; and FIG. 19 is a logic flow diagram showing exemplary ETF logic for authenticating received transaction information in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT An embodiment of the present invention coordinates and facilitates all manner of transactions electronically. Specifically, a service provider maintains an Electronic Transaction Facilitator (ETF) for coordinating transaction exchanges and providing related value-add services to various parties. The ETF includes rules-based logic for processing

electronic documentary information associated with certain types of transactions. The ETF typically uses Email for exchanging transaction information among the various parties to the commercial transaction, although the transaction information may be exchanged using other types of information exchanges (e. g., file transfer) over various types of private, semi-private (e. g., virtual private networks), and public communication networks. The ETF provides most services with little or no human intervention according to instructions provided by one or more of the parties. Consequently, the ETF is able to process transactions and provide value-add services quickly and at a relatively low cost.

The service provider receives compensation, such as subscription fees and commissions for services rendered, in exchange for providing such services.

The ETF can coordinate and facilitate many different types of transactions including, but in no way limited to, purchases, exchanges of goods, returns, exchanges, credits, and billing. The ETF may coordinate an entire transaction from start to finish, or may coordinate only a portion or subtransaction relating to a larger transaction. The transaction or subtransaction may or may not involve a payment or transfer of funds. The transaction or subtransaction may involve an exchange of goods or services, for example, between trading partners or bartering partners.

The ETF obtains electronic transaction information from various sources, including the parties themselves and other sources. The transaction information can be obtained before the transaction, at the time of the transaction, and/or during the transaction. The electronic transaction information may include invoice information (such as an invoice number and an amount due), payment information (such as the payor account number, the payment amount, and the payee name), and/or other information relating to the commercial transaction (such as transaction terms, purchase order, shipping receipts, customs documents, inspection documents, exchanger documents, third party authorizations, and other information). The ETF may obtain some or all of the transaction information directly from accounts payable and accounts receivable systems maintained by the payor and payee, respectively. The ETF typically authenticates both the electronic transaction information and the party or parties that provided the electronic transaction

information, and processes the electronic transaction information according to instructions that are provided by one or more of the parties.

In order to facilitate completion of a commercial transaction, the ETF evaluates any received transaction information in order to determine whether sufficient transaction information is available to complete the transaction. The ETF may be provided with a list of the types of transaction information that are needed to complete the transaction, or else the ETF may determine the types of transaction information based upon the type of transaction. If the ETF does not have sufficient transaction information for completing the transaction, the ETF may wait for additional transaction information, if such additional transaction information is expected to be forthcoming, or else the ETF may actively solicit the additional transaction information from one of the parties or from an independent source. When sufficient transaction information is available to complete the transaction, the ETF completes the transaction.

A typical transaction requires some sort of payment. The present invention is in no way limited to any particular types of payments, forms of payments, timing of payment, payor (s), payee (s), or other payment-related considerations. Therefore, the ETF can handle virtually any kind of electronic payment. The ETF typically correlates a payment to a particular transaction or invoice, although a payment may be related to more than one transaction or invoice, may be subdivided and paid to multiple payees (contemporaneously or at different times and after different conditions are met), or may be unrelated to any particular transaction or invoice.

If the transaction includes a payment, then the ETF determines a disposition for the payment, for example, based upon instructions provided by the payee. For example, the ETF may accept the payment, reject the payment outright, or hold the payment pending further instructions from the payee. The ETF may provide for payor/payee aggregation, for example, where the payor is not the invoiced party (i. e., pay on behalf of...), where there are multiple payors for a single payment, or where there are multiple payees/collectors for a single payment. The ETF may provide for installment payments, where multiple payments are made over a period of time for a particular transaction or invoice. The ETF may provide for advance payments, where payments are made in

advance of services rendered and are typically held for crediting against services rendered.

The ETF typically provides for handling post-dated payments, expired payments (e. g., a check more than one year old), partial payments, deposits, and other special cases. The ETF may be permitted to credit payments toward past-due amounts.

The ETF may handle implied payments, where the"payor"does not submit an actual payment to the ETF, but rather instructs the ETF to effectuate a payment. For one example, the ETF may be instructed to automatically pay any amount due that meets certain criteria, in which case the ETF automatically completes a payment for any such amount due. For another example, the ETF may receive an approval of some payment amount from the"payor" (e. g., an approval of a particular invoice) rather than receiving an actual payment from the"payor,"in which case the ETF completes a payment for the approved payment amount.

The ETF can act as an agent on behalf of a party in order for the party to participate in the transaction. For example, the ETF can be used to provide a billing service on behalf of a payee. In this case, the ETF receives account receivable information from the payee, and generates the appropriate invoices to solicit payments from a number of payors. The ETF may apply any applicable discounts or penalties in order to determine the invoice amount due. Also, the ETF can be used to provide a bill paying service on behalf of a payor. In this case, the ETF receives an invoice from a payee including an invoice amount due, and evaluates the invoice in order to determine whether to submit a payment and the amount of the payment. The ETF may confirm such information as the number of items ordered, the price per item, and any discounts or penalties reflected in the invoice amount due, among other things. The ETF may determine that the actual amount due is different from the invoice amount due. Based upon instructions provided by the payor, the ETF may submit an electronic payment for the actual amount due on behalf of the payor. Many other such services are possible.

The ETF can be used by the service provider to provide certain services that essentially interject the service provider as a party to the transaction. Specifically, the service provider (via the ETF) may provide any of a variety of services, together with the associated electronic or documentary evidence, that may be necessary to complete the

transaction. For example, in a certain class of transactions, the seller does not want to ship goods until a payment is made, but the buyer does not want to make the payment until the seller ships the goods. In such transactions, the ETF can be used to hold the payment in escrow and provide electronic or documentary evidence that the payment has been made.

This allows the buyer to make the payment before there is proof that the seller has shipped the goods, and the payment is not released until such proof is available. Similarly, the service provider can hold the goods and provide documentary evidence (via the ETF) that the goods have been shipped. This allows the seller to ship the goods before there is proof that the buyer has made the payment, and the goods are not released until such proof is available. Many other types of services are possible.

As part of, or in addition to, its transaction processing services, the ETF may provide any of a variety of value-add services to the various parties. The ETF can provide value-add services at virtually any stage of the commercial transaction. The types of value-add services that can be provided by the ETF are almost limitless. The value-add services may be related to the transaction processing services, or may be ancillary to the transaction processing services. Some exemplary value-add services that are related to the transaction processing services include delaying the settlement of a transaction until good funds are collected from the seller, purchasing a payment from the payee at a discount, securing a loan to the payee using the payment as collateral, obtaining a purchase or loan for the payment from a third party service provider (perhaps using an online auction to find a purchaser or lender), guaranteeing a payment, handling currency conversions (including currency"hedge"services to limit or exploit the risks associated with potential currency conversion rate changes), and providing accounting information to the various parties.

The disposition of the payment may depend upon, or be conditioned upon, the availability of certain value-add services. The ETF may evaluate the creditworthiness of various parties in order to evaluate the risks associated with providing certain value-add services, such as purchasing a payment, securing a loan for a payment, or guaranteeing a payment.

Some value-add services that are ancillary to the transaction processing services include collecting and analyzing information ("information mining") and record keeping.

Information mining, in particular, can be used to provide important statistical information to the various parties. Many other types of value-add services are possible.

The service provider utilizes the ETF as part of a business model. As described above, the service provider receives compensation from one or more parties in exchange for providing various services. Additionally, the service provider may utilize the ETF for producing a direct income stream. The avenues for producing a direct income stream using the ETF are almost limitless. One way the service provider can produce a direct income stream from the ETF is by capitalizing on payments that are held by the ETF, purchased from the payee, or assigned to the service provider as part of a loan extended to the payee by the ETF. For example, payments can be sold or auctioned to third party purchasers individually or in blocks. Even here, the ETF can provide value-add by evaluating the creditworthiness of the payor and/or the payee and assigning a risk score to each payment or block of payments based upon the creditworthiness of the payor and/or the payee, thereby allowing potential third party purchasers to assess the risks of acquiring the payment (s). Another way the service provider can produce a direct income stream from the ETF is by selling statistical or other information that is compiled by the ETF.

Many other opportunities are available for producing a direct income stream from the ETF.

FIG. 1 is a block diagram showing an electronic commerce system 100 in which an Electronic Transaction Facilitator (ETF) 104 is used to coordinate transactions between two parties. For transactions that involve some form of payment, the party making the payment is referred to as the payor and is depicted as the Payor 102, while the party receiving the payment is referred to as the payee and is depicted as the Payee 106. The ETF 104 is coupled to both the Payor 102 and the Payee 106 (and possibly other entities) over a communication network, such as the Internet, and preferably provides at least an Email interface over which the ETF 104 exchanges transaction information with both the Payor 102 and the Payee 106. The ETF 104 preferably also provides a World Wide Web (WWW) interface through which the Payor 102 and the Payee 106 access ETF 104 web pages, specifically for subscribing to ETF 104 services and monitoring transaction status, among other things. The ETF 104 is may also be coupled to a Settlement System 110, which is capable of accepting and processing electronic remittance information from the

ETF 104 in order to make the appropriate monetary transfers to and from a payor account in the Payor Bank 108 and a payee account in the Payee Bank 112.

In order to coordinate transactions between the Payor 102 and the Payee 106, at least one of the Payor 102 and the Payee 106 subscribe to the service provided by the ETF 104. The ETF 104 maintains an electronic mailbox for the Payee 106 through which the ETF 104 receives electronic transaction information from the Payor 102, the Payee 106, and possible from other entities (not shown in FIG. 1). The ETF 104 also maintains context information (i. e., a profile) for the relationship between the Payor 102 and the Payee 106. The context information typically includes pertinent information about the Payor 102 and the Payee 106, such as Email addresses, bank names, and bank account numbers, as well as relational information, such as rules for making and accepting payments. The context information may also include transaction information relating to a particular commercial transaction between the Payor 102 and the Payee 106. The context information is described in more detail throughout the remainder of the specification.

FIG. 2 is a block diagram showing the relevant logic blocks of an embodiment of the ETF 104. At the heart of the ETF 104 is a Transaction Processor 206 that coordinates transactions between a number of payors, such as the Payor 102, and a number of payees, such as the Payee 106. The ETF 104 receives transaction information in electronic form through a Network Interface 202, preferably in the form of Email messages (although any of a number of other electronic means can also be used, and all means may incorporate or use security measures such as encryption technology). The ETF 104 includes an Email Interface 203 for sending and receiving Email messages over the Network Interface 202, including receiving transaction information in the form of Email messages. Each unit of transaction information received through the Network Interface 202 is associated with a particular payee, and the ETF 104 preferably maintains a separate Payee Mailbox 204 for each payee. Email messages for a particular payee are directed to the corresponding Payee Mailbox 204, and are stored in a corresponding File Directory 205. The Transaction Processor 206 is operably coupled to the File Directories 205 for receiving Email messages containing transaction information for the various payees, and is also operably

coupled to the Email Interface 203 for sending Email messages and to the Network Interface 202 for sending utilizing other network services.

In order to coordinate transactions between a particular payor, such as the Payor 102, and a particular payee, such as the Payee 106, the ETF 104 includes a Data Warehouse 208 in which pertinent information, such as context information and a transaction log, is stored. Context information includes such things as pertinent information about the payor and payee (e. g., Email address), relational information (e. g., transaction terms), and transaction information. Context information can be provided directly by one of the parties, and can be updated by the Transaction Processor 206 based upon transaction information received while processing a transaction. The Transaction Processor 206 also maintains a transaction log in the Data Warehouse 208. The transaction log includes transaction-related information that can be viewed by the various parties. The ETF 104 preferably includes a WWW Interface 207 for providing the parties with access to the information stored in the Data Warehouse 208 over the Network Interface 202.

The ETF 104 may also include a Settlement System Interface 210 for interfacing to the Settlement System 110, typically through the Federal Reserve Bank or a commercial bank. The Transaction Processor 206 is operably coupled to the Settlement System Interface 210 for sending remittance information to the Settlement System 110.

In the course of a typical commercial transaction, various types of transaction information, such as various forms of documentary evidence, may be generated by the various participants to the transaction. Different types of commercial transactions involve different types of transaction information. Among other things, the transaction information may include such things as an invoice, payment information, bank account information, shipping information, authorizations (by a party to the transaction or a third party), and even negotiated terms (such as penalties and discounts). In a typical paper- based transaction exchange, this transaction information must be evaluated and acted upon by the various parties in order to complete the transaction. Likewise, the ETF 104 must be able to evaluate such transaction information in order to complete the transaction on behalf of the parties.

Therefore, in an embodiment of the present invention, the ETF 104 receives certain types of transaction information (but not necessarily all transaction information) in the form of an Electronic Transaction Instrument (ETI). The ETI may be used to exchange electronic transaction information between the Payor 102, the ETF 104, the Payee 106, and possibly other entities (not shown in FIG. 1). Like an Echeck, the ETI is an all-electronic instrument that can be used as an electronic payment vehicle. However, the ETI is not limited to the format or content of an Echeck, and can be used to transport the various types of transaction information in electronic form with or without digital signatures.

Furthermore, the ETI may take on different forms, such as Electronic Data Interchange (EDI), a markup language (XML, FSML, HTML), or other electronic format. The ETI is described in more detail below.

Thus, the ETF 104, and particularly the Transaction Processor 206, includes transaction processing logic for processing transaction information for transactions between the payor and the payee. The transaction processing logic can range from a simple rules-based system that can perform basic operations to an expert system that can perform complex operations.

In order to complete a commercial transaction on behalf of a payor, such as the Payor 102, and a payee, such as the Payee 106, the ETF 104 must determine the type of transaction and determine therefrom the types of transaction information required to complete the transaction. As the transaction progresses, the ETF 104 receives certain transaction information relating to the transaction, for example, within an ETI or otherwise. The ETF 104 may store such transaction information as context information in the Data Warehouse 208 so that the transaction information will be available to complete the transaction. The service provider (via the ETF) may also become a party to the transaction, for example, by holding a payment or goods in escrow and providing electronic or documentary evidence of such escrow services.

The ETF 104 evaluates all received transaction information to determine whether sufficient transaction information is available to complete the transaction. If the ETF 104 does not have sufficient transaction information to complete the transaction, then the ETF 104 may wait for additional transaction information, or else may actively solicit such

additional transaction information from the buyer/payor, the seller/payee, or some other entity. When the ETF 104 has sufficient transaction information to complete the transaction, the ETF 104 processes the transaction information to complete the transaction in accordance with instructions provided by the payor and/or the payee.

AN EXEMPLARY EMBODIMENT OF THE INVENTION In an exemplary embodiment of the invention, the ETF is used to establish an electronic payment mechanism between a single disburser (payor) and a single collector (payee). Such an electronic payment mechanism might be established, for example, between a company and one of its suppliers, where the company is the disburser (payor) and the supplier is the collector (payee). The ETF coordinates fund transfers between the disburser and the collector using existing banking accounts for both parties (i. e., users are not required to open special bank accounts in order to use ETF services).

In this exemplary embodiment, both the disburser and the collector subscribe to the service provided by the ETF. Among other things, the ETF maintains a profile for both the disburser and the collector as well as various business rules for handling payments and payment-related information from the disburser and the collector. The profiles and the business rules are typically configured by a service provider administrator. The business rules include various service provider business rules such as maximum individual transaction limits for both the disburser and the collector, maximum daily limits for both the disburser and the collector, and rules for suspending/rejecting payments; various disburser business rules, such as Email options (encrypted or unencrypted), a contact list, rules for handling duplicate payments (e. g., defining a duplicate payment and determining whether to suspend or reject a duplicate payment), and maximum signing limits for each disburser user; and various collector business rules, such as Email options (encrypted or unencrypted), a contact list, and the preferred format for remittance information sent to the collector. The ETF also maintains various transaction logs, including notification logs for both the disburser and the collector for providing various status and error information to the disburser and the collector.

The disburser typically submits payment orders to the ETF in the form of Digital Payment Authorizations (DPAs), specifically by transmitting to the ETF an electronic DPA document (i. e., an ETI) containing one or more DPAs. The disburser typically uses a disburser client application, which is typically provided by the service provider, in order to generate DPA documents containing DPAs (for example, from payment information obtained by the disburser client application from an accounts payable system or from payment information provided to the disburser client application manually) and transmit the DPA documents electronically to the ETF. The disburser typically executes each DPA document with a digital signature or other authentication mark. The DPA documents are transmitted to the ETF in a secure manner over a synchronous (e. g., HTTP or HTTPS) or asynchronous (e. g., Email) mechanism. An exemplary disburser client application is described in more detail below.

An exemplary DPA document is an Extensible Markup Language (XML) document that conforms to the Financial Services Markup Language (FSML). FSML is described in the FSML Version 2.0 Draft 4 specification, which was published by the Financial Services Technology Consortium (FSTC), and is hereby incorporated herein by reference in its entirety.

The exemplary DPA document includes a root element and a number of blocks.

The root element uniquely identifies the DPA document, for example, by a time stamp.

The blocks provide various payment and payment-related information.

The root element <fsml-doc> has two attributes, namely a document name <docname> attribute and a document type <type> attribute. The document name attribute is typically a session identifier in the form of a time stamp that is based upon GMT and includes the year, month, day, hour, minute, second, and millisecond at which the DPA document was created. Each DPA document typically has a unique document name. The document type attribute may be used to designate a file extension that is used by the ETF to store the DPA document (e. g.,"xml").

An exemplary session identifier is in the form"yyyyMMddHHmmssSSS,"where "yyyy"is the year,"MM"is the month of the year,"dd"is the day of the month,"HH"is the hour of the day,"mm"is the minute,"ss"is the second, and"SSS"is the millisecond.

Exemplary DPA document blocks include an action block, a disburser data block (including various certificate sub-blocks), a payment block (including various DPA data sub-blocks, remittance sub-sub-blocks, and signature sub-blocks), and a document statistics block. Certain blocks are standard FSML blocks, while other blocks are extensions of existing FSML blocks, and conform to the FSML 2.0 Extension Block Types as described in the FSML Version 2.0 Draft 4 specification. For convenience, the letters "x-"are used herein to indicate an extended FSML block. The relevant FSML and extended FSML blocks are described below.

Each block typically includes at least a block name <blkname> field, a critical <crit> field, and a version <vers> field. The block name field indicates the name of the block, which is typically (but not universally) a concatenation of the block type and version number separated by a dash. The critical field indicates whether the block is critical (true) or non-critical (false). The version field indicates a version number for the block. Blocks may include other fields.

An action <action> block is used to indicate that the DPA document is a payment document. An An action block includes a block name field, a critical field, a version field, a function <function> field, and a reason <reason> field.

A version 1.0 of the action block is defined as follows: <action> <blkname>string</blkname> <crit>true</crit> <vers> 1. 0</vers> <function>string</function> <reason>string</reason> </action> The function <function> field is used to indicate that the action is a payment. The reason <reason> field indicates whether the payment is a test or an actual payment to be processed.

The disburser data <x-disburserdata> block is used to provide disburser data that is common to all payments and remittances inside a given DPA document, and provides the authorization for the service provide to make payments on behalf of the disburser. The disburser data block includes a block name field, a critical field, a version field, a date issued <dateissued> field, an expiration date <datexpires> field, a disburser name <disbursername> field, a disburser identifier <disburserid> field, a disburser authorization <disburserauth> field, an optional legal notice <legalnotice> field, and a number of certificate sub-blocks.

A version 2.0 of the disburser data block is defined as follows: <x-disburserdata> <blkname>string</blkname> <crit>true</crit> <vers>2.0</vers> <dateissued>string</dateissued> <BR> <BR> <datexpires>string</datexpires><BR> <disbursername>string</disbursername><BR> <disburserid>string</disburserid> <disburserauth>string<disburserauth> <cert>... </cert> </x-disburserdata> The date issued <dateissued> field is used to indicate the date on which the payment authorization is issued. The expiration date <datexpires> field is used to indicate an expiration date for the payment authorization after which the DPA cannot be processed.

The disburser name <disbursername> field is used to indicate the disburser name. The disburser identifier <disburserid> field is used to indicate a disburser identifier that is used to identify the disburser to the ETF. The disburser authorization <disburserauth> field is used to include a textual message explicitly authorizing the ETF to process the payment.

The legal notice <legalnotice> field is used to define a legal system under which the

transaction the processed.

Each certificate <cert> sub-block is used to provide a certificate for authentication.

A certificate sub-block includes a block name field, a critical field, a version field, a certificate type <certtype> field, a certificate issuer <certissuer> field, a certificate serial number <certserial> field, and a certificate data <certdata> field.

A version 1.5 of the certificate sub-block is defined as follows: <cert> <BR> <blkname>string</blkname><BR> <crit>string</crit> <vers>1. 5</vers> <certtype>string</certtype> <certissuer>string</certissuer> <certserial>string</certserial><BR> <certdata>string</certdata> </cert> The certificate type <certtype> field is used to indicate the type of certificate contained in the certificate block (e. g., x509v3). The certificate issuer <certissuer> field is used to indicate the entity that issued the certificate (e. g., TrustMint or Digital Signature Trust), typically by indicating an organizational unit, an organization, and a country, among other things. The certificate serial number <certserial> field is used to indicate a serial number for the certificate, which is unique for each certificate issuer. The certificate data <certdata> field holds an ASCII encoded binary value of the certificate.

It should be noted that a DPA document may include multiple certificate sub- blocks. The block name field must be unique for each certificate sub-block in the DPA document. The block name field for a particular certificate sub-block is typically the letters"cert"followed by an integer. For example, in a DPA document with 2 certificate sub-blocks, the first certificate sub-block would have a block name"certl"and the second certificate sub-block would have a block name"cert2."

The payment <x-payment> block is used to specify a payment. The payment block includes a block name field, a critical field, a version field, and multiple DPA data <x- dpa> and signature <signature> sub-blocks. A DPA data sub-block may include a remittance <x-remit> sub-sub-block.

A version 2.0 of a payment block including three DPAs, of which only the third has no associated remittance data, is defined as follows: <x-payment> <blkname>string </blkname> <crit>true</crit> <vers>2.0</vers> <x-dpa>...

<x-remit>... </x-remit> </x-dpa> <signature>... </signature> <x-dpa>...

<x-remit>... </x-remit> </x-dpa> <signature>... </signature> <x-dpa>... </x-dpa> <signature>... </signature> </x-payment> Each DPA data <x-dpa> sub-block is used to include required information for the ETF to create the appropriate debit and credit clearing transactions for the disburser. A DPA data sub-block includes a block name field, a critical field, a version field, a payment number <paymentnum> field, an optional country <country> field, a routing code <routingcode> field, an account number <accountnum> field, an optional priority <priority> field, a collector identifier <collectorid> field, an optional collector address <collectoraddr> field, an optional collector postal code <collectorpostalcode> field, a

payment amount <payamount> field, and a currency <currency> field.

A version 2.0 of the DPA data sub-block is defined as follows: <x-dpa> <blkname>string</blkname><BR> <crit>true</crit> <vers>2.0</vers> <BR> <BR> paymentnum>string</paymentnum><BR> <country>string</country><BR> <routingcode>string</routingcode> <accountnum>string</accountnum> <priority>string</priority > <collectorid>string</collectorid><BR> <collectoraddr>string</collectoraddr> <collectorpostalcode>string</collectorpostalcode> ; <payamount>string</payamount> <currency>string</currency> </x-dpa> The payment number <paymentnum> field is used to identify the payment, and is typically a unique number generated by the disburser or disburser accounts payable system. The country <country> field is used to indicate a country. The routing code <routingcode> field is used to indicate a routing transit number for the payment. The account number <accountnum> field is used to indicate the account number from which the funds are to be debited. The priority <priority> field is used to indicate a priority for the payment (e. g., high or low). The collector identifier <collectorid> field is used to indicate the collector for the payment, and is typically an external identifier recognized by the ETF. The collector address <collectoraddr> field is used to indicate a mailing address for the collector. It should be noted that the DPA data sub-block may include multiple collector address fields. The collector postal code <collectorpostalcode> field is used to

indicate a mailing postal code for the collector. The payment amount <payamount> field is used to indicate the authorized payment amount. The currency <currency> field is used to indicate a currency for the payment.

It should be noted that the payment block may include multiple DPA data sub- blocks. The block name field must be unique for each DPA data sub-block. The block name field for a particular DPA data sub-block is typically the letters"dpa"followed by an integer. For example, in payment with 2 DPA data sub-blocks, the first DPA data sub- block would have a block name"dpal"and the second DPA data sub-block would have a block name"dpa2." It should be noted that the DPA data sub-block may include additional date information (i. e., in addition to the date issued and expiration date in the disburser data block) in order to further limit the payment authorization.

A DPA data sub-block optionally includes one or more remittance <x-remit> sub- sub-blocks. There are two types of remittance sub-sub-blocks, namely a remittance list <remittancelist> sub-sub-block and an external file <externalfile> sub-sub-block. A DPA data sub-block may include multiple remittance sub-sub-blocks, although a DPA data sub- block can include at most one remittance list sub-sub-block. The block name field must be unique for each remittance sub-sub-block. The block name field for a particular remittance sub-sub-block is typically the letters"remit"followed by an integer. For example, in payment with 2 remittance sub-sub-blocks, the first remittance sub-sub-block would have a block name"remitl"and the second remittance sub-sub-block would have a block name"remit2." A remittance list sub-sub-block includes a block name field, a critical field, a version field, an optional reference identification qualifier <referenceidqualifier> field, an optional reference identification <referenceidentification> field, an optional payment action code <paymentactioncode> field, an optional adjustment reason <adjustmentreason> field, and an optional free text <freetext> field.

A version 2.0 of the remittance list sub-sub-block is defined as follows: <x-remit>

<blkname>string</blkname> <crit>true</crit> <vers>2.0</vers> <remittancelist> <referenceidqualifier>string</referenceidqualifier& gt; <referenceidentification>string</referenceidentific ation> <paymentactioncode>string</paymentactioncode> <adjustmentreason>string</adjustmentreason> <freetext>string</freetext> </remittancelist> </x-remit> The reference identification qualifier <referenceidqualifier> field is used to provide a qualifier for the reference identification field. Among other things, the reference identification qualifier field may be used to indicate that the reference identification is an account number, master account number, accounts receivable number, insurance policy number, or seller's invoice number, for example, as in ASC X12 Finance Subcommittee CSP Billing and Payment Guide. The reference identification <referenceidentification> field is used to provide reference information as defined by the reference identification qualifier, for example, as in ASC X12 Finance Subcommittee CSP Billing and Payment Guide. The payment action code <paymentactioncode> field is used to specify accounts receivable open item (s). Among other things, the payment action code may be used to specify an evaluated receipts settlement, a payment in advance, a payment on account, or a partial payment, for example, as in Roadway express-Payment Order/Remittance Advise.

The adjustment reason <adjustmentreason> field is used to indicate a reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment, for example, as in Roadway express-Payment Order/Remittance Advise.

An external file sub-sub-block is used to provide base64 data supplied in an encoded binary format. The external file sub-sub-block includes a block name field, a critical field, a version field, and external file information. The external file information

includes a block name field, a critical field, a version field, a remittance file name <remitfilename> field, a content type <contentype> field, and a remittance data <remitdata> tag.

A version 2.0 of the external file sub-sub-block is defined as follows: <x-remit> <blkname>string</blkname> <crit>true</crit> <vers>2.0</vers> <BR> <BR> <externalfile><BR> <remitfilename>string</remitfilename> <contentype>string</contentype> <remitdata> Mime-version 1.0 Content-Type: application/XXX Content-Transfer-Encoding: base64 Content-Disposition: filename= cccccccccccc. XXX OA130F42616E6B426F73746F6E205465737431143012060355040B130B65 436865636B<BR> 20546573743081F13081A906072A8648CE38040130819D024100BA3A57CF 5954A451<BR> 7CF915FF18ED7947B942092C8BOB8FOEAEA3A2595FF214350EA1D55212C9 79B9D<BR> A308201 E4308201A0020500B6000005300B06072A8648CE3804030500303731 OB3009<BR> 06035504061302555331123010060355040A130946535443205465737431 143012060355 </remitdata> </externalfile> </x-remit> The remittance file name <remitfilename> field is used to indicate the file name for

external remittance data file (s). The same name is typically used to store those files at the ETF. The content type <contentype> field is used to identify the type of data format that is in the base64 encoded remittance data tag. The remittance data <remitdata> tag may contain standard Mime Headers identifying the type of data in the <remitdata>. To assist in processing, the filename and content-type information is typically included in the <remitfilename> and <contentype> fields, respectively.

The following is a brief description of possible header information: Mime-version 1.0-identifies the version of the Mime Standard in use.

Content-Type: application/XXX-identifies what type of data format is in the base64 encoded data. Examples of the XXX include jpg (JPEG Files), bmp (bitmap Files), x12 (X12 EDI Standard formatted Data), BAI (BAI formatted data), edi820 (EDI 820 Standard), among others. A typical embodiment also includes a provider-specific data format and corresponding content-type identifier.

Content-Transfer-Encoding: base64-identifies the encoding standard in which the following data is encoded.

Content-Disposition: filename=ccccccccc. XXX-identifies the filename of the encoded data. If the encoded data is not a file, then this Mime Heading is not required.

The actual encoded data, which is typically encoded in base64, follows the Mime Headers.

A signature <signature> sub-block is used to digitally sign an individual DPA in conjunction with the blocks that are associated with it. A signature sub-block includes a block name field, a critical field, a version field, signature data <sigdata> fields, and a signature encoding field. The signature data fields include a block reference <blockref> field including an optional"required" (req) attribute, a hash <hash> field including an "algorithm" (alg) attribute, a nonce <nonce> field, a signature type <sigtype> field, a certificate issuer <certissuer> field, a certificate serial number <certserial> field, an algorithm <algorithm> field, a signer identifier <signerid> field, a sequence number <sequence> field.

It should be noted that a payment block may include multiple signature sub-blocks.

The block name field must be unique for each signature sub-block in the DPA document.

The block name field for a particular signature sub-block is typically the letters"sig" followed by an integer. For example, in a payment block with 2 signature sub-blocks, the first signature sub-block would have a block name"sigl"and the second signature sub- block would have a block name"sig2." Within the payment block, each DPA data <x-dpa> sub-block is digitally signed.

For a generic signature (as opposed to a counter-signature), hashed values of the action <action> block, the disburser data <x-disburserdata> block, and the DPA data <x-dpa> blocks are hashed into single 160 bit message digests and encrypted using the Digital Signature Algorithm (DSA) and the disburser's private key. For a counter-signature, the hashed values of the same blocks as well as the hash value of the"sigl"<signature> block are hashed into a single 160 bit message digest and encrypted using DSA and the disburser's private key.

A version 2.0 of the signature block is defined as follows: <signature> <BR> <BR> <blkname>string</blkname><BR> <crit>true</crit> <vers>2.0</vers> <sigdata> <blockref req="string">string<blockref> <hash alg="string">string</hash> <nonce>string</nonce> <sigtype>string</sigtype> <certissuer>string</certissuer> <BR> <BR> <certserial>string</certserial><BR> <algorithm>string</algorithm> <signerid>string</signerid> <sequence>string</sequence> </sigdata> <sig>string</sig>

</signature> The block reference <blockref> field is used to indicate a unique block name for the block being signed. All block references typically appear immediately before their respective hashes. The optional"required" (req) attribute can be used to indicate whether the referenced block is required (true) or not required (false). The referenced block is considered to be required if the req attribute is omitted. If the referenced block is required, then removal of the referenced block invalidates the signature. The hash <hash> field is used to provide an actual hash of the respective block. The"algorithm" (alg) attribute is used to indicate the hash algorithm that was used to compute the hash. The nonce <nonce> field is used to provide a pseudo-random number that is inserted into the top of the hash string to provide entropy of the hash result. The default value is zero. The signature type <sigtype> field is used to indicate the type of signature (e. g., generic or counter-signature). The certificate issuer <certissuer> field and the certificate serial number <certserial> field are used together to indicate the certificate block that corresponds to this signature sub-block. The algorithm <algorithm> field is used to indicate the signature algorithm (e. g., md5/rsa, shal/dsa, sha/rsa, sha/ecdsa). The signer identifier <signerid> field is used to identify the signer, and is typically a concatenation of the <certissuer> and <certserial> fields. The sequence number <sequence> field is used to provide a unique number for the signature sub-block (defaults to zero). The signature encoding field is used to indicate the encoding for the signature, which is typically base64.

It should be noted that, in addition to digitally signing individual DPAs, an entire DPA document may also be digitally signed. An entire document is signed outside of the XML portion of the document by the disburser. The outside signature is used to verify that the entire document has not been modified since it was created. The process for this signature is similar to that of signing an individual DPA. A message digest is created using a string of the entire document and SHA-1 as the algorithm. This message digest is signed using the Digital Signature Algorithm (DSA).

The document statistics <x-docstats> block is used to summarize various <x- payment> descriptive information and statistics, for example, to account for the detailed

data in the <x-payment> block. The document statistics block is typically the last block in a document. The document statistics block includes a block name field, a critical field, a version field, a client version <clientversion> field, a date created <datecreated> field, a number of DPA data sub-blocks <numdpas> field, a number of remittance sub-sub-blocks <numremits> field, a total amount <totalamount> field, and a currency <currency> field.

A version 2.0 of the document statistics block is defined as follows: <x-docstats> <BR> <BR> <blkname>string</blkname><BR> <crit>true</crit> <vers>2.0</vers> <clientversion>string</clientversion> <datecreated>string</datecreated> <numdpas>string</numdpas> <numremits>string</numremits> <totalamount>string</totalamount> <currency>string</currency> </x-docstats> The client version <clientversion> field is used to indicate the release number of disburser client application that is used to generate DPA documents and perform other transaction-related functions. The date created <datecreated> field is used to indicate the date on which the DPA document was created. The number of DPA data sub-blocks <numdpas> field is used to indicate the number DPA data <x-dpa> sub-blocks included in the DPA document. The number of remittance sub-sub-blocks <numremits> field is used to indicate the number of remittance <x-remit> sub-sub-blocks included in the DPA document. The total amount <totalamount> field is used to indicate the total of all payments contained in the DPA document (i. e., the sum of the <payamount> fields from all DPA data <x-dpa> sub-blocks contained in the DPA document). The currency <currency> field is used to indicate the currency for the payments contained in the DPA

document. In a typical embodiment of the invention, the currency indicated in the <currency> field of the document statistics <x-docstats> block matches the currency for all of the payments contained in the DPA document (i. e., the <currency> field from all DPA data <x-dpa> sub-blocks contained in the DPA document).

FIGs. 14A-14E shows an SGML Document Type Definition (DTD) for the DPA document.

As described above, the disburser typically uses a disburser client application to generate and transmit DPA documents to the ETF. The disburser client application is essentially a document creation application, applet, or script that is based upon open industry standards including the Internet Protocol (IP) for network communications, an XML payment document, X. 509 version 3 digital certificates for authentication, digital signatures for non-repudiation, and proven encryption mechanisms for confidentiality.

The disburser client application obtains payment and remittance information, for example, from direct entry, from a manual payment application (e. g., a spreadsheet application), or from an accounts payable interface, and generates a payment file in the form of a DPA document. The payment file is digitally signed by an authorized user, and may be transmitted to the ETF in a secure manner, for example, using the Secure Hypertext Transfer Protocol (HTTPS) over the Secure Sockets Layer (SSL) version 3.0 protocol, the Hypertext Transfer Protocol (HTTP), or the Simple Mail Transfer Protocol (SMTP), with Secure Multi-Purpose Internet Mail Extensions (S/MIME) encryption.

The disburser assigns various users who are authorized to access the disburser client application. User access is password protected, and each user is assigned an initial password and is permitted to change the password at any time. Each user is given certain privileges, including a signing limit that indicates the maximum amount of payment for which the user can sign. A user with"first signer"privileges is typically permitted to import payment data into the disburser client application, reject payment authorizations, digitally sign the payment file, and transmit the payment file to the ETF. A user with "second signer"privileges is typically permitted to perform a limited subset of functions (although the user with"second signer"privileges may be assigned a higher signing limit than a user with"first signer"privileges). A default user, referred to as the

"administrator,"is permitted to perform such administrative functions as changing user- defined default directories, assigning user privileges, assigning signing limits, and creating login accounts and initial passwords, but is not permitted to generate or transmit the payment file.

The disburser client application typically supports two modes of operations, namely a production mode and a test mode. The production mode is used to send actual payment and remittance information to the ETF for processing. The test mode is used to send test payment and remittance information to the ETF. The mode is typically selected by the user at login.

Payment and remittance information is typically provided to the disburser client application in the form of a delimited format file that is created by the manual payment application or accounts payable interface. The delimited format file includes one or more payment entries, and may include remittance entries. A payment entry typically includes such information as an item number, country, from bank, from account, account type, pay to, pay to identifier, organization identifier, effective date, effective time, payment amount, currency, and ETF identifier. A remittance entry typically includes such information as a type of remittance, vendor identifier, check number, reference number, amount, discount, net amount, date, item reference number, and currency. The remittance information may be included in a web page, in which case the remittance entry indicates a URL for the web page.

The disburser client application imports and processes the delimited format file.

The disburser client application typically begins by reviewing the delimited format file in order to verify the syntax of the payment and remittance entries. The disburser client application typically also provides an opportunity for the user to add remittance information and/or reject individual payment instructions during this review. The disburser client application then generates the payment file from any payment and remittance information, specifically in the form of a DPA document. The disburser client application digitally signs each DPA using a digital certificate associated with the user.

The user is permitted to review the payment file, and is also permitted to transmit the payment file to the ETF. In order to sign the payment file, the user is typically required to

enter a PIN that is associated with the user's digital certificate. The disburser client application uses a private key to digitally sign the entire payment file. It should be noted that the digital certificate used to sign individual DPAs may be different from the digital certificate used to sign the entire payment file. After digitally signing the payment file, the disburser client application transmits the payment file to the ETF in a secure manner, for example, using the Secure Hypertext Transfer Protocol (HTTPS) over the Secure Sockets Layer (SSL) version 3.0 protocol, the Hypertext Transfer Protocol (HTTP), or the Simple Mail Transfer Protocol (SMTP), with Secure Multi-Purpose Internet Mail Extensions (S/MIME) encryption.

FIG. 15 shows exemplary disburser client application logic 1500 for converting disburser payment and remittance information into a payment file. Beginning in step 1502, the logic opens a delimited format file containing payment and remittance information, in step 1504, and proceeds to verify the delimited format file, in step 1506, specifically by verifying the syntax of the payment and remittance information. If the delimited format file is invalid (NO in step 1508, then the logic terminates in step 1599 without processing the payment and remittance information. If the delimited format file is valid (YES in step 1508), then the logic proceeds to process the payment and remittance information by providing an opportunity for the user to add remittance information and/or reject individual payments, in step 1510. The logic then generates a payment file from the payment and remittance information, in step 1512, typically in the form of a DPA document containing one or more DPAs. In order to transmit the payment file to the ETF, the logic digitally signs the payment file, in step 1514, and transmits the payment file to the ETF using a secure communication mechanism, in step 1516. The logic 1500 terminates in step 1599.

Before processing any payment files from a disburser user, the ETF validates the disburser user. If the disburser user connects to the ETF using a synchronous connection (e. g., HTTP or HTTPS), then the ETF validates the disburser user at the time the connection is established. If the disburser user connects to the ETF using an asynchronous connection (e. g., Email), then the ETF validates the disburser user at the time information is received. The ETF typically stops all processing of payment information from the

disburser user and notifies the disburser (e. g., via Email) if the disburser user is invalid or is not actively enrolled for the service.

When the ETF receives a payment file from the disburser user, and after validating the disburser user (if necessary), the ETF typically stores the payment file in its entirety with a unique identifier for tracking, archival, and fault recovery purposes.

After storing the payment file, the ETF typically decrypts the payment file and validates the digital signature for the payment file. The ETF typically stops all processing of the payment file and notifies the disburser (e. g., via Email) if the digital signature for the payment file is invalid.

Assuming the digital signature for the payment file is valid, the ETF continues processing the payment file by parsing the payment file to verify the syntax of the payment file. The ETF typically stops all processing of the payment file and notifies the disburser (e. g., via Email) if the payment file is invalid.

Assuming the payment file is valid, the ETF continues processing the payment file by checking for duplicate payments. The ETF is typically capable of detecting duplicate payments within the same payment file as well as duplicate payments across multiple payment files (for example, within all payments received in a single day). The ETF typically suspends or rejects any duplicate payments as indicated by the business rules, and notifies the disburser (e. g., via Email).

The ETF attempts to process each DPA contained in the payment file. The ETF typically suspends any transaction that violates a service provider business rule. The ETF typically suspends or rejects any transaction that violates a disburser business rule, as indicated by the disburser business rules. The ETF typically rejects any transaction that attempts to draw funds from an unauthorized or unregistered account. The ETF processes any remittance information associated with each payment. The ETF generates appropriate notifications to the disburser, the collector, and service provider administrator for providing status and error information.

The ETF generates a settlement system file from the payment file. The settlement system file includes fund transfer information in a form that is compatible with the settlement system (e. g., an ACH system). The ETF typically creates the settlement system

file at predetermined intervals (e. g., once per day) according to the business rules. The settlement system file is submitted to the settlement system at an appropriate time, either by the ETF or by the service provider administrator.

The ETF typically enables the disburser to stop a payment before the corresponding fund transfer has been submitted to the settlement system. To stop a payment, the disburser typically contacts the service provider administrator, who instructs the ETF to stop the payment through an ETF management interface. The stopped payment may be treated as a suspended payment or a rejected payment. In either case, the ETF typically notifies the disburser (e. g., via Email) when it is instructed to stop a payment.

The ETF typically enables a suspended payment to be reinstated for processing at a later time. This is typically handled by a service provider administrator. A rejected payment cannot be reinstated for processing at a later time, but instead must be resubmitted by the disburser as a payment.

The ETF typically enables transaction information to be viewed by, or distributed to, various entities in various formats. Specifically, the ETF can typically generate various electronic and documentary reports. Exemplary reports include an accounts payable payment report, an accounts payable exceptions report, an accounts receivable transactions report, an accounts receivable exceptions report, a bank transaction report, a transactions received report, a reconciliation report, and an exception report.

It should be noted that transactions for bank clearing systems (such as billing and chargebacks), which are originated outside of a DPA, are typically transmitted in separate files or batches from transactions that come directly from a DPA.

FIG. 16 shows exemplary ETF logic 1600 for generating a settlement system file from payment and remittance information received in a payment file. Beginning in step 1602, and upon receiving a payment file from the disburser using a secure communication mechanism, in step 1604, the logic validates the disburser user if the disburser user had not already been validated, in step 1606. If the user is invalid (NO in step 1608), then the logic terminates in step 1699 without processing the payment file. If the user is valid (YES in step 1608), then the logic stores the payment file, in step 1610, decrypts the payment file, in step 1612, and verifies the digital signature of the payment file, in step

1614. If the signature is invalid (NO in step 1616, then the logic terminates in step 1699 without processing the payment file. If the signature is valid (YES in step 1616), then the logic proceeds to process the payment file, in step 1618, and generate a settlement system file, in step 1620. The logic 1600 terminates in step 1699.

FIG. 17 shows exemplary logic 1700 for processing the payment file pursuant to step 1618 shown in FIG. 16. Beginning in step 1702, the logic verifies the payment file, in step 1704, specifically by verifying the syntax of the payment file. If the payment file is invalid (NO in step 1706), then the logic terminates in step 1799 without processing payments. If the payment file is valid (YES in step 1706), then the logic checks for duplicate payments and either rejects or suspends any duplicate payments as indicated by the business rules, in step 1708. The logic processes each payment and its associated remittance information as indicated by the business rules, in step 1710. The logic 1700 terminates in step 1799.

ALTERNATIVE EMBODIMENTS OF THE INVENTION In the exemplary embodiment described above, the ETF provides payment services for disburser/collector pairs. However, the present invention is in no way limited to payment services or to transactions between a single disburser and a single collector. In various alternative embodiments of the invention, the ETF is used to provide a wide range of transaction-related services that can include multiple payors and/or multiple payees as well as various third party participants.

Certain aspects of the present invention can be demonstrated with reference to an exemplary commercial transaction. FIG. 13 shows some of the many types of transaction information that may be exchanged during an exemplary commercial transaction. The exemplary commercial transaction begins with a Request For Information (RFI) 1302 sent by the buyer to the seller. In response to the RFI 1302, the seller sends the requested information 1304 to the buyer. The buyer then sends a Request For Quotation (RFQ) 1306 to the seller in order to obtain information such as item costs, item availability, acceptable payment types (check, certified check, charge, etc.), payment terms (including discounts

and penalties), shipping terms (including shipment costs), return/exchange terms, warranty terms, and other information. In response to the RFQ 1306, the seller sends a quotation 1308 to the buyer including the requested information. The buyer then submits a purchase order 1310, which may attempt to change some of the terms that were specified by the seller in the quotation 1308. Assuming the seller accepts the purchase order 1310 and any modified terms therein, the seller makes a shipment 1312 to the buyer. Among other things, the shipment 1312 may include such information as a tracking number for tracking the shipment and a bill of lading. The seller may also send a receipt 1314 to the buyer.

The seller sends an invoice/bill 1316 to the buyer in order to collect payment. Upon receipt of the invoice/bill 1316, the buyer sends a payment/remittance 1318 to the seller.

Thus, the buyer is the payor for the commercial transaction, and the seller is the payee for the commercial transaction. It should be noted that the seller may make the shipment 1312 after receiving the payment/remittance 1318 or after the seller is assured that the payment/remittance 1318 has been made by the buyer (for example, through an escrow service provided by the ETF 104). Similarly, the buyer may send the payment/remittance 1318 after receiving an assurance that the seller has made the shipment 1312 (for example, through documentary evidence provided by the ETF 104). Many alternative transaction scenarios are possible.

Such a commercial transaction may be coordinated by the ETF 104 using various techniques of the present invention. Specifically, the ETF 104 receives certain transaction information and processes the transaction information in order to complete the transaction.

For example, the ETF 104 may receive the invoice 1316, the payment 1318, and possibly other information such as various terms associated with the transaction included in the quotation 1308 and/or the purchase order 1310. The ETF 104 evaluates the payment 1318 with respect to the invoice 1316 and the other transaction information, and processes the payment 1318 according to instructions provided by the seller/payee and/or the buyer/payor. Among other things, the instructions provide the rules for accepting the payment 1318, rejecting the payment 1318 outright, and holding the payment 1318 pending further instructions from the seller/payee. The ETF 104 also provides any value- add services ordered by the buyer/payor and seller/payee.

For example, rather than mailing the invoice 1316 to the buyer/payor, the seller/payee may generate an ETI incorporating the invoice 1316, and send the ETI to the buyer/payor electronically. The invoice 1316 typically includes an invoice number, and specifies the buyer/payor and the invoice amount due. The buyer/payor sends the payment 1318 to the ETF 104, for example, by adding the payment 1318 to the ETI and sending the ETI to the ETF 104 electronically. Upon receiving the ETI including the payment information, the ETF 104 processes the ETI based upon the information contained in the ETI as well as a set of instructions specified by the seller/payee. It should be noted that the instructions may be existing instructions stored as context information in the Data Warehouse 208 and/or instructions that are incorporated into the ETI by the seller/payee, for example, along with the invoice 1316.

A typical decision for the ETF 104 relates to the disposition of a payment 1318.

Typically, the ETF 104 can either accept the payment 1318, reject the payment 1318 outright, or hold the payment 1318 pending further instructions from the seller/payee or action from a third party (e. g., an inspection or customs certification). Considerations include the type of payment (check, certified check, promissory note, payment through the ETF, etc.), the payment amount, whether the payment matches the actual amount due (which is based upon the invoice amount and factors such as currency conversion rates, discounts, and penalties) or is acceptably close to the actual amount due, the payment due date, whether the payment is post-dated, and whether the payment is marked as a"payment in full,"among other things.

In one exemplary embodiment, the ETF 104 is instructed to take a particular action based upon the payment type. Payments can be made in many different forms. There are many possible actions that can be based upon the payment type. For example, the ETF 104 may be instructed to accept only certain types of payments (such as certified checks) or to reject certain types of payments (such as promissory notes).

In another exemplary embodiment, the ETF 104 is instructed to take a particular action based upon the payment amount. There are many possible actions that can be based upon the payment amount. One exemplary action is for the ETF 104 to accept the payment only if the payment amount is less than a predetermined maximum acceptable

payment amount. Another exemplary action is for the ETF 104 to take one action if the payment amount is less than a first threshold value and take a second action if the payment amount is greater than a second threshold value. Yet another exemplary action is for the ETF 104 to accept the payment if it is less than a first threshold value, hold the payment pending further instructions if the payment is between the first threshold value and a second threshold value, and reject the payment outright if the payment is greater than the second threshold value.

In another exemplary embodiment, the ETF 104 is instructed to take a particular action based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due (for example, within a predetermined percentage of the actual amount due). The ETF 104 determines the actual amount due based upon the invoice amount and possibly other factors, such as discount and penalty terms. The ETF 104 then determines whether the payment matches the actual amount due or is acceptably close to the actual amount due (which may involve currency conversion considerations) and takes the appropriate action. There are many possible actions that can be based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due. One exemplary action is for the ETF 104 to accept the payment if the payment matches the actual amount due or is acceptably close to the actual amount due.

Another exemplary action is for the ETF 104 to reject the payment outright or hold the payment pending further instructions if the payment does not match the actual amount due or is not acceptably close to the actual amount due. Yet another exemplary action is for the ETF 104 to accept a payment that is less than the actual amount due as a partial payment toward amounts due by the buyer/payor (but see discussion regarding"payment in full"below).

In order to determine the actual amount due, the ETF 104 may need to account for any discounts or penalties that apply to the transaction. Therefore, the ETF 104 may be provided with discount/penalty terms that apply to the transactions, typically by the seller/payee. The ETF 104 may be provided with the discount/penalty terms prior to the transaction or during the transaction, for example, within the ETI. Upon receiving the payment, the ETF 104 determines any applicable discounts and/or penalties and

determines the actual amount due by applying any applicable discounts and any applicable penalties to the invoice amount.

For example, the buyer/payee may receive a discount for a payment that is received on or before a specified due date. The due date can be specified as a calendar date or as an offset from another date, such as the invoice date (for example, within 14 days of invoice) or shipment date. Therefore, upon receiving the payment, the ETF 104 determines whether the payment date is on or before the specified due date. If the payment date is on or before the specified due date, then the ETF 104 uses the discount information provided by the seller/payee to calculate the actual amount due, specifically by decreasing the invoice amount accordingly.

The buyer/payee may also receive a discount if the invoice amount is greater than a predetermined amount (for example, 10 percent off all orders above $100). Therefore, upon receiving the payment, the ETF 104 determines whether the invoice amount is greater than the predetermined amount. If the invoice amount is greater than the predetermined amount, then the ETF 104 uses the discount information provided by the seller/payee to calculate the actual amount due, specifically by decreasing the invoice amount accordingly.

The buyer/payee may be penalized for a payment that is received after a specified due date. The penalty is typically in the form of a surcharge or interest, and can be computed according to any type of penalty formula. For example, the penalty can increase the longer the payment is due (e. g., interest rate X if the payment overdue by more than 60 days, interest rate Y is the payment is overdue by more than 120 days), or the penalty can be applied retroactively (e. g., interest accrues from the due date if the payment is received more than 60 days after the due date). The due date can be specified as a calendar date or as an offset from another date, such as the invoice date (for example, after 14 days from invoice) or shipment date. Therefore, upon receiving the payment, the ETF 104 determines whether the payment date is after the specified due date. If the payment date is after the specified due date, then the ETF 104 uses the penalty information provided by the seller/payee to calculate the actual amount due, specifically by increasing the invoice amount accordingly.

The ETF 104 may also combine discounts and penalties. The buyer/payor may receive a discount, for example, because the invoice amount is greater than a predetermined amount, and also receive a penalty, for example, because the payment is after a specified due date. In this case, the ETF 104 calculates the actual amount due based on a predetermined set of rules and/or instructions. In one embodiment, the ETF 104 applies any applicable discounts first, and then applies any applicable penalties. For example, if the buyer/payor receives a discount because the invoice amount is greater than a predetermined amount and a penalty because the payment is after the due date, then the ETF 104 preferably calculates the discount first, and then adds the penalty for the late payment.

If the payment and the actual amount due are denominated in different currencies, then the ETF 104 may need to convert one or both to a common currency in order to determine whether the payment matches the actual amount due or is acceptably close to the actual amount due. Thus, the ETF 104 may need to obtain currency conversion information. The ETF 104 may obtain the currency conversion information from one of the parties or from some other source, such as a bank or card network.

In yet another exemplary embodiment, the ETF 104 is instructed to take a particular action based upon the payment due date irrespective of the payment amount.

There are many possible actions that can be based upon payment due date. One exemplary action is for the ETF 104 to reject the payment outright if the payment is overdue by more than a predetermined amount of time (e. g., more than 120 days overdue). Another exemplary action is for the ETF 104 to send a reminder that the payment is overdue. Yet another exemplary action is for the ETF 104 to send a new invoice indicating the amount due, which may change over time due to penalties, interest, discounts, or other considerations.

In still another exemplary embodiment, the ETF 104 is instructed to take a particular action based upon whether the payment is marked as a"payment in full."When a seller/payee accepts a payment that is marked as"payment in full,"the seller/payee may be deemed to have accepted the payment for discharge of all amounts due by the buyer/payor. Therefore, the ETF 104 may be instructed to reject a"payment in full"

payment outright or hold the"payment in full"payment pending further instructions.

In another exemplary embodiment, the ETF 104 is instructed to take a particular action based upon the effective date of the payment. There are many possible actions that can be based upon the effective date of the payment. For example, if the payment is post- dated, the ETF 104 may reject the payment outright, accept the post-dated payment and process the post-dated payment as it would any other payment, or accept the post-dated payment and hold the post-dated payment until the payment date. If the payment is expired (e. g., a check more than one year old), then the ETF 104 may reject the payment.

In another exemplary embodiment, the ETF 104 suspends certain actions until a payment clears. For example, the ETF 104 may withhold certain information (e. g., a shipping authorization, a credit authorization, an accounts receivable update) until a payment clears.

As part of the decision regarding the disposition of the payment, the ETF 104 may be instructed to make certain ancillary evaluations and decisions. For example, the ETF 104 may be instructed to require a countersignature if the payment amount is greater than a predetermined payment amount (e. g., require countersignature if payment amount is greater than $25,000).

If the ETF 104 holds a particular payment pending further instructions from the seller/payee or action from a third party, then the ETF 104 may notify the seller/payee that the payment is being held, preferably by sending an Email message to the seller/payee.

The ETF 104 then awaits further instructions from the seller/payee regarding the disposition of the held payment. The seller/payee may provide instructions to the ETF 104, for example, via Email, through the WWW interface 207, or other mechanism.

If the ETF 104 accepts a particular payment, then the ETF 104 processes the payment according to instructions provided by the seller/payee. Basically, the seller/payee can choose to have the ETF 104 process the payment, or the seller/payee may be able to choose from among a number of payment-related value-add services provided by the ETF 104 (some of which are described below).

Assuming the seller/payee instructs the ETF 104 to process the payment, then the ETF 104, and specifically the transaction processing logic of the Transaction Processor

206, obtains any required endorsements or authorizations for the payment, and prepares to send payment information to the Settlement System 110 in order to effect a transfer of funds from the Payor 102 to the Payee 106, and more particular from a payor bank account in the Payor Bank 108 to a payee bank account in the Payee Bank 112. The type of payment information depends upon the type of Settlement System 110 as well as the type of transfer to be completed. Examples of Settlement System 110 types include, but are in no way limited to, an Electronic Check Presentment (ECP) system, an Automated Clearing House (ACH) system, an ATM system, a credit card system, a wire transfer system, and a SWIFT system. If the Settlement System 110 is an Electronic Check Presentment (ECP) system, then the payment information may be in the form of an ECP. If the Settlement System 110 is a Automated Clearing House (ACH) system, then the payment information may be in the form of a direct withdrawal from the payor bank account and a corresponding direct deposit into the payee bank account using NACHA formats. The ETF 104 may send the payment information directly to the Settlement System 110 via the Settlement System Interface 210, or the payment information may be stored in a file for later submission to the Settlement System 110 either through the Settlement System Interface 210 or otherwise.

Either as part of the decision regarding the disposition of a payment or after a payment has been accepted, the seller/payee and/or the buyer/payor may be able to choose from among a number of payment-related value-add services provided by the ETF 104.

Among other things, these payment-related value-add services can be used to guarantee the payment or provide immediate funds to the seller/payee, for example, in the form of a loan or purchase of the payment. Therefore, these payment-related value-add services may be particular useful to the seller/payee for payments that do not mature for some period of time, such as post-dated checks and promissory notes. The ETF 104 may provide the funds itself, in which case the ETF 104 needs to assess the associated risks in order to decide whether or not to provide the funds to the seller/payee and determine the terms under which the funds are provided (such as a discount rate or interest rate, among other things). Alternatively, the funds may be provided to the seller/payee by a third party service provider, in which case the ETF 104 acts as a go-between for the seller/payee and

the third party service provide. The ETF 104 receives some form of compensation for providing such payment-related value-add services, such as interest on a loan, the discounted amount of a purchase, or a commission for acting as a go-between for the seller/payee and the third party service provider. The decision whether or not to accept the payment may be conditioned on the ability of the ETF 104 to obtain or provide a purchase or loan for the payment.

The ETF 104 can also coordinate and facilitate various post-transaction functions, such as credits (e. g., an after-sale discount), exchanges, and returns.

FIG. 3 is a block diagram showing an electronic commerce system 300 in which an Electronic Transaction Facilitator (ETF) 104 is used to coordinate transactions between a Payor 102, a Payee 106, and possibly a Third Party Service Provider 302. The ETF 104 is coupled to the Payor 102, the Payee 106, the Third Party Service Provider 302, and possibly a Credit Reporting System 304, and preferably communicates with the Payor 102, the Payee 106, the Third Party Service Provider 302, and the Credit Reporting System 304 using Email or other electronic means. The ETF 104 is also coupled to a Settlement System 110, which is capable of accepting and processing electronic remittance information from the ETF 104 in order to make the appropriate monetary transfers between a payor account in the Payor Bank 108, a payee account in the Payee Bank 112, and an ETF account in an ETF Bank 306.

In one exemplary embodiment, the ETF 104 purchases the payment from the seller/payee at a discounted rate. The seller/payee endorses or otherwise assigns the payment to the ETF 104, and the ETF 104 sends the appropriate information to the Settlement System 110 in order to effect a transfer of funds from the ETF account in the ETF Bank 306 to the payee account in the Payee Bank 112. The ETF 104 deposits the payment in the ETF account in the ETF Bank 306 through the Settlement System 110, and assumes certain risks associated with the payment (for example, that there will be insufficient funds in the payor account to cover the payment). The ETF 104 decides whether to purchase the payment, and may determine a discount rate for the payment, based upon this risk. The ETF 104 assesses the risk based upon, among other things, credit information for the Payor 102. In an embodiment of the present invention, the ETF

104 maintains credit information for the Payor 102 in the Data Warehouse 208, taking into consideration such things as credit information provided by the Payor 102, credit information obtained from the Credit Reporting System 304, bank account information obtained through the Settlement System 110, and the history of transactions processed by the ETF 104 involving the Payor 102.

In another exemplary embodiment, the ETF 104 provides a loan to the seller/payee.

The loan can be structured in many different ways. The ETF 104 assumes certain risks that depend upon how the loan is structured (for example, that the Payee 106 will be unable to repay the loan and/or that there will be insufficient funds in the payor account to cover the payment). The ETF 104 decides whether to extend the loan and determines an interest rate for the loan (and other loan-related parameters) based upon these risks. The ETF 104 assesses these risks based upon, among other things, credit information for the Payor 102 and/or the Payee 106. In an embodiment of the present invention, the ETF 104 maintains credit information for the Payor 102 and/or the Payee 106 in the Data Warehouse 208, taking into consideration such things as credit information provided by the Payor 102 and/or the Payee 106, credit information obtained from the Credit Reporting System 304, bank account information obtained through the Settlement System 110, and the history of transactions processed by the ETF 104 involving the Payor 102 and/or the Payee 106.

In yet another exemplary embodiment, the ETF 104 coordinates a purchase of the payment or a loan to the Payee 106 by the Third Party Service Provider 302 based upon instructions provided by the Payee 106. The ETF 104 may have a pre-arranged relationship with the Third Party Service Provider 302 for purchasing or lending against payments, or the ETF 104 may actively search for a third party purchaser or lender when the payment is received (for example, through an advertisement or a bidding process). The ETF 104 does not assume any particular risk, and receives a commission from the Payee 106 and/or the Third Party Service Provider 302.

When actively searching for a third party purchaser or lender for the payment or deciding whether to accept the payment, the ETF 104 may determine a risk score for the payment. The risk score indicates a relative risk for the payment, and can be used by the

ETF 104 and/or a potential third party purchaser or lender to assess the risks associated with the payment. The ETF 104 determines the risk score for a particular payment based upon, among other things, credit information for the Payor 102 and/or the Payee 106. In an embodiment of the present invention, the ETF 104 maintains credit information for the Payor 102 and/or the Payee 106 in the Data Warehouse 208, taking into consideration such things as credit information provided by the Payor 102 and/or the Payee 106, credit information obtained from the Credit Reporting System 304, bank account information obtained through the Settlement System 110, and the history of transactions processed by the ETF 104 involving the Payor 102 and/or the Payee 106.

In still another exemplary embodiment, the ETF 104 guarantees a payment for the buyer/payor. This service may be used, for example, when the seller/payee requires a guaranteed payment (such as certified Echeck). In order for the buyer/payor to obtain an actual certified Echeck, the buyer/payor pays a bank to generate the certified Echeck or to otherwise certify the Echeck electronically. This is an additional step in the transaction, and has a specific cost to the buyer/payor. Therefore, rather than obtaining a certified Echeck from a bank, the buyer/payor submits a non-certified payment (such as an Echeck) to the ETF 104. The ETF 104 decides whether to guarantee the payment based upon certain risks (for example, that there will be insufficient funds in the payor account to cover the payment). The ETF 104 assesses the risk based upon, among other things, credit information for the Payor 102. In an embodiment of the present invention, the ETF 104 maintains credit information for the Payor 102 in the Data Warehouse 208, taking into consideration such things as credit information provided by the Payor 102, credit information obtained from the Credit Reporting System 304, bank account information obtained through the Settlement System 110, and the history of transactions processed by the ETF 104 involving the Payor 102. If the ETF 104 decides to guarantee the payment, the ETF 104 transfers the full payment amount (not a discounted amount, as when the ETF 104 purchases the payment from the seller/payee) to the seller/payee in exchange for assignment of the payment to the ETF 104. The ETF 104 then assumes all risks for the payment. The buyer/payor pays a fee to the ETF 104, which can be a fixed amount or can vary based upon the risk associated with guaranteeing the payment.

In still another exemplary embodiment, the ETF 104 provides a currency conversion service for payor and/or the payee. The currency conversion service can be employed at various stages of the transaction. For example, the currency conversion service can be used to determine the disposition for a payment or perform a currency conversion after accepting the payment. The ETF 104 can be provided with currency conversion information, or the ETF 104 can obtain currency conversion information, for example, from a bank or credit card network. The ETF 104 uses the currency conversion information to convert funds from one currency to another.

In conjunction with the currency conversion service, the ETF 104 can provide a currency"hedge"service to limit or exploit the risks associated with potential currency conversion rate changes. Specifically, the ETF 104 can use currency conversion information to determine currency conversion timing as well as the timing for crediting the payee account and debiting the payor account in order to benefit one or both of the parties.

As the ETF 104 processes transactions on behalf of a number of payors, including the Payor 102, and a number of payees, including the Payee 106, the ETF 104 logs certain transaction-related information in the transaction log in the Data Warehouse 208. Each log entry in the transaction log includes transaction-related information for a particular transaction, such as a payor identifier, a payee identifier, a transaction identifier, a transaction status, payment information, and other transaction-related information. Each payor and payee can view its respective transaction information, for example, through a password-protected World-Wide Web (WWW) interface or other interface to the ETF 104.

This allows each payor and payee to monitor the status of its various transactions at will.

In addition to logging transaction information in the transaction log, the ETF 104 may explicitly notify the payor and/or the payee of certain events, such as when the ETF 104 completes a transaction or transfers funds for the payor and/or the payee. Such notification may be made via Email or other electronic means. The ETF 104 may provide such information as an invoice number, the payment status (accepted or rejected), and the amount credited to or debited from the account. It should be noted that the amount credited to the payee account may be less than the amount debited from the payor account

(or less than the payment amount), particularly if the ETF 104 is instructed to automatically adjust the amount credited to the payee account and/or the amount debited from the payor account for any fees or commissions for value-add services.

As part of, or in addition to, explicitly notifying the payor and/or the payee when the transaction is completed, the ETF 104 may provide the payor and/or the payee with accounting information in a format that is compatible with their respective accounting systems. This is a value-add service provided by the ETF 104, typically for a fee. Many accounting systems include a mechanism for importing a file containing one or more accounting entries and updating the accounting records (for example, crediting or debiting an accounting record) based upon the accounting entries in the file, thereby eliminating manual entry of the data into the accounting system. Therefore, when the ETF 104 completes the transaction, the ETF 104 creates a file or otherwise adds to a file an accounting entry that is compatible with the respective payor or payee accounting system.

It should be noted that the payor and the payee may use different accounting systems, and therefore the accounting entries for the payor and the payee may be different. At some point (for example, at the end of each day), the payor and the payee retrieve their respective files from the ETF 104 for importing into their respective accounting systems.

This can be done, for example, via Email or a file transfer from the ETF 104.

In the course of processing transactions, the ETF 104 has access to various types of information that can be collected and analyzed ("information mining"). Such information can be useful to the various parties. One example of information mining involves analysis of individual transactions in order to determine such things as documentary evidence that is missing and the party expected to provide the missing documentary evidence, documentary evidence that is incorrect or incomplete, additional documentary evidence that may be useful to the party, and other things. Such information can be used by the various parties to determine transaction status. Another example of information mining involves statistical analysis across multiple transactions in order to monitor various transaction characteristics, such as the types of transactions, the products being purchased, the products being returned or exchanged, billing disputes, payment types, payment patterns, supplier history, discounts, and other transaction characteristics. Such

information can be used to provide important statistical information to the various parties, or even to trigger certain activities by the ETF 104 itself (such as consolidating or "stitching together"multiple transactions to take advantage of volume discounts or other transaction terms).

Certain aspects of the present invention are described with reference to the following figures. FIG. 4 is a logic flow diagram showing exemplary transaction processing logic 400 for processing transaction information in the ETF 104, and particularly in the Transaction Processor 206. Beginning in step 402, and upon receiving transaction information, in step 404, the transaction processing logic authenticates the received transaction information, in step 405, and determines whether sufficient authenticated transaction information is available to complete the transaction, in step 406.

If sufficient authenticated transaction information is available to complete the transaction (YES in step 406), then the transaction processing logic completes the transaction based upon the received transaction information, in step 414. However, if sufficient authenticated transaction information is unavailable (NO in step 406), then the transaction processing logic proceeds to determine the unavailable transaction information that is needed to complete the transaction, in step 408. The transaction processing logic then determines whether the unavailable transaction information will be received as the transaction progresses, in step 410. If the transaction processing logic determines that the unavailable transaction information will be received as the transaction progresses (YES in step 410), then the transaction processing logic recycles to step 404 to await additional transaction information. However, if the transaction processing logic determines that the unavailable transaction information will not be received as the transaction progresses (NO in step 410), then the transaction processing logic solicits the unavailable transaction information from the appropriate party, in step 412, and recycles to step 404 to await additional transaction information. The logic 400 terminates in step 499.

FIG. 19 shows exemplary logic 1900 for authenticating the received transaction information, for example, as in step 405 as shown and described with reference to FIG. 4 above. Beginning in step 1902, and upon receiving transaction information, in step 1904, the logic typically decrypts the received transaction information, in step 1906. The logic

then authenticates the transaction information and the identity of the transaction information provider, in step 1908. If either the transaction information or the transaction information provider is not authentic (NO in step 1910), then the logic 1900 terminates in step 1999 without processing the transaction information. If the transaction information and the transaction information provider are authentic (YES in step 1910), then the logic verifies that the transaction information provider is authorized to submit the transaction information, in step 1912. If the transaction information provider is authorized to submit the transaction information (YES in step 1914), then the logic processes the transaction information, in step 1916. If the transaction information provider is not authorized to submit the transaction information (NO in step 1914), then the logic 1900 terminates in step 1999 without processing the transaction information.

When sufficient transaction information is available for the transaction to be completed, the transaction processing logic completes the transaction. FIG. 5 is a logic flow diagram showing exemplary transaction processing logic 500 for completing the transaction. Beginning in step 502, the transaction processing logic determines a disposition for the payment, in step 504, specifically based upon instructions provided by the payee. The disposition of the payment may be based upon any of a number of considerations, including, but in no way limited to, the payment type, the payment amount, whether the payment matches the actual amount due or is acceptably close to the actual amount due, the payment due date, the effective date of the payment (particularly whether the payment is post-dated), whether the payment is a payment in full, and whether a purchase or loan can be obtained for the payment.

The transaction processing logic may accept the payment, reject the payment outright, or hold the payment pending further instructions from the payee. If the transaction processing logic accepts the payment (YES in step 506), then the transaction processing logic may provide any of a number of optional payment-related value-add services. For example, at the request of the payee, the transaction processing logic may obtain or provide a purchase or loan for the payment, in step 508. Alternatively, or additionally, at the request of the payor, the transaction processing logic may guarantee the payment, in step 510.

Whether or not the transaction processing logic accepts the payment, the transaction processing logic typically provides certain transaction-related information to the payor and/or the payee. Specifically, the transaction processing logic updates the transaction log, in step 512, to reflect certain transaction-related activities. For example, the transaction processing logic may update the transaction log to reflect such things as transaction status, transaction completion, payment disposition, and fund transfers. The transaction log is preferably accessible by the payor and/or the payee through a WWW interface or other electronic interface, enabling the payor and/or the payee to monitor the status of transactions at will. The transaction processing logic may also explicitly notify the payor and/or the payee of certain transaction-related activities, in step 514, for example, via Email or other electronic means.

At the request of the payor and/or the payee, the transaction processing logic may generate accounting information. If the payor and/or the payee requests this value-add service, the transaction processing logic generates accounting information for the payor and/or the payee upon completion of the transaction, in step 516. The accounting information generated for the payor is compatible with the payor accounting system, and can be imported into the payor accounting system to automatically reconcile the transaction. The accounting information generated for the payee is compatible with the payee accounting system, and can be imported into the payee accounting system to automatically reconcile the transaction. The logic 500 terminates in step 599.

In order to determine the disposition for the payment, the transaction processing logic evaluates the transaction information with respect to the instructions provided by the payee in order to determine whether to accept the payment, reject the payment outright, or hold the payment pending further instructions from the payee. The disposition of the payment may be based upon any of a number of considerations, including, but in no way limited to, the payment type, the payment amount, whether the payment matches the actual amount due or is acceptably close to the actual amount due, the payment due date, the effective date of the payment (particularly whether the payment is post-dated), whether the payment is a payment in full, and whether a purchase or loan can be obtained for the payment.

FIG. 6A is a logic flow diagram showing exemplary transaction processing logic for determining the disposition of the payment based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due. Beginning in step 602, the transaction processing logic proceeds to determine the actual amount due, in step 604, specifically based upon the invoice amount due and other factors. The transaction processing logic then determines whether the payment matches the actual amount due, in step 606. If the payment matches the actual amount due (YES in step 606), then the transaction processing logic accepts the payment, in step 612. If the payment does not match the actual amount due (NO in step 606), then the transaction processing logic determines whether the payment is acceptably close to the actual amount due (e. g., whether the payment is within a predetermined percentage of the actual amount due), in step 608. If the payment is acceptably close to the actual amount due (YES in step 608), then the transaction processing logic accepts the payment, in step 612. If the payment is not acceptably close to the actual amount due (NO in step 608), then the transaction processing logic decides whether to hold the payment, in step 610, specifically based upon instructions provided by the payee. If the transaction processing logic decides to hold the payment (YES in step 610), then the transaction processing logic holds the payment pending further instructions from the payee, in step 614. If the transaction processing logic decides not to hold the payment (NO in step 610), then the transaction processing logic rejects the payment outright, in step 616. The logic terminates in step 699.

FIG. 6B is a logic flow diagram showing exemplary transaction processing logic for determining the disposition of the payment based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due, wherein the transaction processing logic determines the actual amount due based upon any applicable discount terms and penalty terms. The transaction processing logic may obtain the discount terms and penalty terms prior to the transaction, at the start of the transaction, or during the transaction, for example, from the payee or within the transaction information.

Beginning in step 602, the transaction processing logic proceeds to determine any applicable discount terms and penalty terms, in step 603. The transaction processing logic then applies the applicable discount terms and penalty terms to the invoice amount due in

order to determine the actual amount due, in step 604. In one embodiment of the present invention, the transaction processing logic applies the discount terms first and then applies the penalty terms, although the discount terms and the penalty terms can be applied pursuant to other rules or instructions. The transaction processing logic then determines whether the payment matches the actual amount due, in step 606. If the payment matches the actual amount due (YES in step 606), then the transaction processing logic accepts the payment, in step 612. If the payment does not match the actual amount due (NO in step 606), then the transaction processing logic determines whether the payment is acceptably close to the actual amount due (e. g., whether the payment is within a predetermined percentage of the actual amount due), in step 608. If the payment is acceptably close to the actual amount due (YES in step 608), then the transaction processing logic accepts the payment, in step 612. If the payment is not acceptably close to the actual amount due (NO in step 608), then the transaction processing logic decides whether to hold the payment, in step 610, specifically based upon instructions provided by the payee. If the transaction processing logic decides to hold the payment (YES in step 610), then the transaction processing logic holds the payment pending further instructions from the payee, in step 614. If the transaction processing logic decides not to hold the payment (NO in step 610), then the transaction processing logic rejects the payment outright, in step 616. The logic terminates in step 699.

FIG. 6C is a logic flow diagram showing exemplary transaction processing logic for determining the disposition of the payment based upon whether the payment matches the actual amount due or is acceptably close to the actual amount due, wherein the transaction processing logic performs a currency conversion on the payment and/or the actual amount due in order to determine whether the payment matches the actual amount due or is acceptably close to the actual amount due. Beginning in step 602, the transaction processing logic proceeds to determine the actual amount due, in step 604, specifically based upon the invoice amount due and other factors. The transaction processing logic then obtains currency conversion information and converts the payment and/or the actual amount due to the same currency based upon the currency conversion information, in step 605. The transaction processing logic then determines whether the payment matches the

actual amount due, in step 606. If the payment matches the actual amount due (YES in step 606), then the transaction processing logic accepts the payment, in step 612. If the payment does not match the actual amount due (NO in step 606), then the transaction processing logic determines whether the payment is acceptably close to the actual amount due (e. g., whether the payment is within a predetermined percentage of the actual amount due), in step 608. If the payment is acceptably close to the actual amount due (YES in step 608), then the transaction processing logic accepts the payment, in step 612. If the payment is not acceptably close to the actual amount due (NO in step 608), then the transaction processing logic decides whether to hold the payment, in step 610, specifically based upon instructions provided by the payee. If the transaction processing logic decides to hold the payment (YES in step 610), then the transaction processing logic holds the payment pending further instructions from the payee, in step 614. If the transaction processing logic decides not to hold the payment (NO in step 610), then the transaction processing logic rejects the payment outright, in step 616. The logic terminates in step 699.

FIG. 7 is a logic flow diagram showing exemplary transaction processing logic for purchasing a payment from the payee. This logic can be applied as part of the payment disposition determination (i. e., whether to accept the payment) or after the payment is accepted. Beginning in step 702, the transaction processing logic may obtain payor credit information from a credit reporting service, in step 704. Alternatively, or additionally, the transaction processing logic may obtain payor bank account information from the settlement system, in step 706. The transaction processing logic then evaluates the payor credit information and/or the payor bank account information, in step 708, and determines a risk for the purchase, in step 710. The transaction processing logic proceeds to decide whether to complete the purchase based upon the risk, in step 712. If the transaction processing logic decides to complete the purchase (YES in step 714), then the transaction processing logic determines a discount rate for the purchase based upon the risk, in step 716, and purchases the payment from the payee at the discount rate, in step 718.

FIG. 8 is a logic flow diagram showing exemplary transaction processing logic for extending a loan to the payee for the payment. This logic can be applied as part of the

payment disposition determination (i. e., whether to accept the payment) or after the payment is accepted. Beginning in step 802, the transaction processing logic may obtain payee credit information from a credit reporting service, in step 804. Alternatively, or additionally, the transaction processing logic may obtain payor bank account information from the settlement system, in step 806. The transaction processing logic then evaluates the payee credit information and/or the payor bank account information, in step 808, and determines a risk for the loan, in step 810. The transaction processing logic proceeds to decide whether to complete the loan based upon the risk, in step 812. If the transaction processing logic decides to complete the loan (YES in step 814), then the transaction processing logic determines an interest rate for the purchase based upon the risk, in step 816, and provides the loan to the payee at the interest rate, in step 818.

FIG. 9 is a logic flow diagram showing exemplary transaction processing logic for guaranteeing a payment. This logic is typically applied prior to accepting a payment.

Beginning in step 902, the transaction processing logic obtains payor credit information, in step 904. In a preferred embodiment of the present invention, payor credit information (including transaction histories) is maintained in the Data Warehouse 208. Additional credit information may be obtained from a credit reporting service through the Credit Reporting System 304 or from other sources. Bank account information may be obtained through the Settlement System 110. The transaction processing logic then evaluates the payor credit information, in step 908, and determines a risk for the guaranteeing the payment, in step 910. The transaction processing logic proceeds to decide whether to guarantee the payment based upon the risk, in step 912. If the transaction processing logic decides to guarantee the payment (YES in step 914), then the transaction processing logic determines a fee for guaranteeing the payment, for example, based upon the risk, in step 916, and provides a guaranteed payment to the payee, in step 918. The logic terminates in step 999.

FIG. 10 is a logic flow diagram showing exemplary transaction processing logic for obtaining a purchase or loan for the payment from a third party service provider.

Beginning in step 1002, the transaction processing logic finds a third party service provider to purchase the payment or provide a loan for the payment, in step 1004. The

transaction processing logic may have a pre-arranged relationship with the third party service provider, or else the transaction processing logic may actively solicit a third party service provider to provide the purchase or loan (for example, through advertising or bidding). Once the transaction processing logic finds a third party service provider to provide the purchase or loan, the transaction processing logic coordinates the purchase or loan transaction between the third party service provider and the payee, in step 1006.

As described above, transaction information may be exchanged using an ETI.

There may be different forms of ETIs, although a preferred ETI can be dynamically modified to include additional transaction information as a transaction progresses. Such additional transaction information can be used to add additional documentary evidence to the transaction, and also can be used to modify or remove (by addendum) existing documentary evidence. Digital signatures may be used (although not necessarily) for authenticating the ETI or specific transaction information within the ETI.

In order for the ETF 104 to process the transaction information included in the ETI, the ETF 104 must be able to identify the various types of transaction information within the ETI. The ETI may contain individual units of transaction information, or may include entire documents (or references to documents) that contain transaction information.

Individual units of transaction information may be identified by a field name or other identifier. Documents and references to documents may be included within electronic document descriptors, where each electronic document descriptor includes a number of common fields, such as a field for indicating the type of transaction information, and also includes a number of fields that are specific to the particular type of transaction information.

Many types of transaction information are used in commercial transactions, and therefore there may be many different types of electronic document descriptors for conveying transaction information. One exemplary electronic document descriptor may be used to convey payment information, including a payment type, a payor name, a payor bank, a payor bank account, a transaction number, a payee name, a payment amount, and other pertinent payment information. Another exemplary electronic document descriptor may be used to convey invoice information, such as an invoice number and a invoice

amount due. Another exemplary electronic document descriptor may be used to convey contractual information, such as discount and penalty terms for the commercial transaction. Another exemplary electronic document descriptor may be used to reference an external electronic document. Each of the many other types of transaction information that may be processed by the ETF 104 requires an electronic document descriptor specifically formatted to include relevant fields. It should be noted that an ETI, or an electronic document descriptor for conveying payment information, may take the form of an Echeck or an Echeck attachment.

FIG. 11 is a block diagram showing the general format of an exemplary ETI 1100.

The ETI 1100 includes an ETI Header 1102 and a number of Descriptors (1104,1106).

The ETI Header 1102 differentiates the ETI 1100 from other types of messages. Each Descriptor (1104,1106) carries transaction information.

FIG. 12A is a block diagram showing an exemplary ETI 1200 including an ETI Header 1202, an Invoice Descriptor 1204, and a Terms Descriptor 1206. The Invoice Descriptor 1204 includes invoice information, such as an invoice number and amount due (in a specified currency). The Terms Descriptor 1206 includes transaction terms, such as discount and penalty terms. Such an ETI 1200 might be sent by a seller/payee in order to solicit payment from the buyer/payor.

FIG. 12B is a block diagram showing an exemplary ETI 1208 including the ETI Header 1202, the Invoice Descriptor 1204, the Terms Descriptor 1206, and a Payment Descriptor 1210. The Payment Descriptor 1210 includes payment information, such as a payor name, a payor bank, a payor bank account, a payee name, and a payment amount (in a specified currency). The Payment Descriptor 1210 may be in the form of an Echeck.

Such an ETI 1208 might be sent by a buyer/payor, for example, as a payment in response to receiving the ETI 1200 shown in FIG. 12A.

FIG. 12C is a block diagram showing an exemplary ETI 1212 including the ETI Header 1202, the Invoice Descriptor 1204, the Terms Descriptor 1206, and a Payment Descriptor 1214. The Payment Descriptor 1214 includes the payment information from the Payment Descriptor 1210 shown in FIG. 12B, and may also include an endorsement from the seller/payee, a certification from a certifying authority (in the case of an Echeck),

and possibly an assignment to the service provider. Such an ETI 1212 might be sent by the seller/payee, for example, in response to receiving the ETI 1208 shown in FIG. 12B.

It should be noted that the ETF 104 may be embodied as a single device or as multiple devices working in conjunction. For example, the ETF 104 may be a system of interconnected devices including a transaction processing server and one or more other servers, such as an Email server, a database server, and a web server. FIG. 18 shows an exemplary ETF system 1800 including a transaction processing server 1804 coupled to an Email server 1806 for sending and receiving Email messages over an Email network 1810, a web server 1808 for sending and receiving information over the Internet 1812, and a database server 1802 for storing and retrieving information.

It should be noted that there is no requirement that the ETF 104 receive all transaction information in a single ETI. The ETF 104 may receive transaction information from many sources and in many forms. A typical ETI is capable of transporting many different types of transaction information, and the various types of transaction information can be added to the ETI as the transaction progresses. However, the ETF 104 may receive certain transaction information by other means, including Email or through the WWW interface, or may import certain transaction information as needed. All such transaction information is considered to be part of the context for the transaction.

The various transaction coordinating/facilitating and value-add services described herein are used to demonstrate by example some of the many services that can be provided by the ETF 104. In no way should the various transaction coordinating/facilitating and value-add services described herein be considered an exhaustive list of possible transaction coordinating/facilitating and value-add services. Practically any type of transaction or value-add service that can be done manually can be provided by the ETF 104, specifically by including such services in the transaction processing logic of the Transaction Processor 206 and providing electronic means for providing the appropriate transaction information to the ETF 104. All such transaction and value-add services are intended to fall within the scope of the present invention.

It should be noted that the term"server"is used herein to describe a communication device that may be used in a communication system, and should not be

construed to limit the present invention to any particular communication device type.

Thus, a communication device may include, without limitation, a bridge, router, bridge- router (brouter), switch, node, or other communication device.

It should also be noted that the logic flow diagrams are used herein to demonstrate various aspects of the invention, and should not be construed to limit the present invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e. g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention. Often times, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e. g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing from the true scope of the invention.

The present invention may be embodied in many different forms, including, but in no way limited to, computer program logic for use with a processor (e. g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e. g., a Field Programmable Gate Array (FPGA) or other PLD), discrete components, integrated circuitry (e. g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof. In a typical embodiment of the present invention, predominantly all of the disburser client logic and ETF logic is implemented as a set of computer program instructions that is converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor within the disburser computer and ETF, respectively, under the control of an operating system.

Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, a source code form, a computer executable form, and various intermediate forms (e. g., forms generated by an assembler, compiler, linker, or locator). Source code may include a series of computer program instructions implemented in any of various programming languages (e. g., an object code, an assembly language, or a high-level language such as Fortran, C, C++, JAVA, or HTML) for use with various operating systems or operating environments.

The source code may define and use various data structures and communication messages.

The source code may be in a computer executable form (e. g., via an interpreter), or the source code may be converted (e. g., via a translator, assembler, or compiler) into a computer executable form.

The computer program may be fixed in any form (e. g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e. g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e. g., a diskette or fixed disk), an optical memory device (e. g., a CD-ROM), or other memory device. The computer program may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies. The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e. g., shrink wrapped software), preloaded with a computer system (e. g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e. g., the Internet or World Wide Web).

Hardware logic (including programmable logic for use with a programmable logic device) implementing all or part of the fimctionality previously described herein may be designed using traditional manual methods, or may be designed, captured, simulated, or documented electronically using various tools, such as Computer Aided Design (CAD), a hardware description language (e. g., VHDL or AHDL), or a PLD programming language (e. g., PALASM, ABEL, or CUPL).

Programmable logic may be fixed either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e. g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e. g., a diskette or fixed disk), an optical memory device (e. g., a CD-ROM), or other memory device. The programmable logic may be fixed in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking

technologies, internetworking technologies, smartcard technologies, and security token technologies. The programmable logic may be distributed as a removable storage medium with accompanying printed or electronic documentation (e. g., shrink wrapped software), preloaded with a computer system (e. g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e. g., the Internet or World Wide Web).

The present invention may be embodied in other specific forms without departing from the true scope of the invention. The described embodiments are to be considered in all respects only as illustrative and not restrictive.