WO2001058242A2 - Electronic factoring - Google Patents

Description

ELECTRONIC FACTORING

Background of the Invention Field of the Invention The invention relates to the field of electronic commerce.

Description of the Related Art

Factoring includes buying and selling accounts receivable and credit insuring. Accounts receivable are purchased based upon the assumption that the accounts receivable are valid and collectable. Accounts receivable are sold in order to quickly obtain cash for cash flow purposes, rather than to retain them as receivable. Accounts receivable are also frequently used as an asset upon which to borrow money, in order to finance other unrelated transactions. Credit insuring occurs when an entity insures payment of an account receivable for a vendor, so that if the buyer does not pay, the insurer will. With the recent rapid growth of information applications on the Internet, computer networks have the potential to establish a new kind of open market place for goods and services. Buyers and sellers increasingly want to use the Internet to conduct their business electronically. This new method of doing business is referred to as electronic commerce, or "e-commerce."

The timely and costly process of processing paper requests for transactions such as the buying and selling of accounts receivable, as well as goods and services, plagues business transactions. Furthermore, buyers and sellers must expend significant resources to make appropriate credit decisions regarding a transaction. In procurement transactions, it is customary for the transaction to involve some form of credit, such as "open account trade credit," provided by the seller generally at no charge to the buyer but for a set period of time, normally thirty days. Buyers generally do not explicitly pay for the receipt of open account trade credit, and consider this free credit part of the established buyer/seller relationship. Credit cards are also available for relatively small purchases and operate by having a financial institution issue the credit card, and a vendor bank provide the cardholder with a revolving line of credit that can be used to buy goods from sellers who accept the credit card. This allows the cardholder to pay for credit card purchases over a period of time at an interest rate set by the vendor bank. Other types of credit devices are travel and entertainment cards, which unlike credit cards, are considered to be open-ended credit with payment in full due at the time of billing, no extension of revolving credit to the buyer is provided by use of these cards, or cardholder. Credit, travel and entertainment cards provide a uniform level of risk assessment to the seller and the seller pays a pre-determined interchange fee regardless of the actual credit risk presented by the buyer. Commercial transaction are evolving to include electronic communication of financial transactions. Advances in computer networks and communication systems now apply to processing purchase and credit transactions. An important application of new computer technology is electronic commerce, which includes using electronic networks as a marketplace for business and consumer transactions. Electronic commerce services can include electronic brokerages, distributorships or clearinghouses that facilitate trade with electronic interchange media, such as public networks, for example the Internet, or proprietary access networks.

Electronic commerce, however, does not currently offer financial services to sellers, such as payment and credit assessments of buyers, electronic factoring and credit insuring of transactions. This need is usually fulfilled by relying on traditional techniques of credit analysis and payment before a transaction can be completed.

Various patents discuss methods of performing e-commerce wherein buyers and sellers are connected, but none address the issue of electronic factoring and credit insurance. U.S. Patent No. 4,992,940 to Dworkin, entitled "System and Method for Automated Selection of Equipment for Purchase Through Input of User Desired Specifications," discloses an automated system that assists the user in locating and purchasing goods and services sold by a variety of vendors. U.S. Patent No. 5,732,400, to Mandler, et al., entitled "System and Method for a Risk-Based Purchase of Goods," discloses a financial clearinghouse for receiving requests for goods or services from a buyer and making a real-time determination of a risk classification of the buyer using an online repository of credit information. U.S. Patent No. 5,757,917, to Rose, et al., entitled "Computerized Payment System for Purchasing Goods and Services on the Internet," discloses a computerized payment system that prequalifies and pays a buyer's order through a third party, but is not a guarantee-of-payment mechanism. U.S. Patent No. 5,822,737, to Ogram, entitled "Financial Transaction System," discloses an automated payment system allowing a consumer to purchase goods or services over the Internet with a credit card that is verified before making the payment. U.S. Patent No. 5,802,497, to Manasse, entitled "Method and Apparatus for Conducting Computerized Commerce," discloses the use of a broker, broker scrip, vendor scrip, and currency to sell parts and services and deliver to the consumer. U.S. Patent No. 5,745,886 to Rosen, entitled "Trusted Agents for Open Distribution of Electronic Money," discloses using a customer trusted agent and vendor trusted agent and establishing a crypto-graphically secure session, and to provide electronic money purchase or sale information and an account credential to the vendor trusted agent. U.S. Patent No. 5,557,518, also to Rosen, entitled "Trusted Agents for Open Electronic Commerce," also discloses the use of trusted agents, establishing a crypto-graphically secure session and electronically transferring funds in purchasing merchandise. U.S. Patent No. 5,717,923, to Dedrick, entitled "Method and Apparatus for Dynamically Customizing Electronic Information to Individual End Users," discloses maintaining a personal profile database to store consumer information and a consent adapter to compare electronic information received by a client system to consumer information in the personal profile database.

U.S. Patent No. 5,717,989, to Tozzoli, et al., entitled "Full Service Trade System," discloses storing criteria specified by a funder relative to trade transactions for buyers and sellers and comparing the criteria with a proposed purchase order in order to determine whether the system can generate a payment guarantee on behalf of the funder for the buyer to the seller. U.S. Patent No. 5,826,241 to Stein, et al., entitled "Computerized System for Making Payments and Authenticating Transactions Over the Internet," discloses a payment system that provides cardholder accounts for first and second Internet users and making queries to the first user on whether to proceed with payment to the second user. U.S. Patent No. 5,842,178, to Giovannoli, entitled "Computerized Quotation System and Method," discloses a computer-based communications network of members for processing requests for quotes for goods and services, as well as storage containing the identification of the members and means for transmitting and broadcasting requests for quotes. U.S. Patent No. 5,694,551, to Doyle et al., entitled "Computer Integration Network for Channeling Customer Orders Through a Centralized Computer to Various Suppliers," discloses an electronic requisitioning system that channels customer orders to internal suppliers and outside vendors, and processes invoices. U.S. Patent No. 5,671,280, to Rosen, entitled "System and Method for Commercial Payments Using Trusted Agents," discloses a system for electronic payment using a customer trusted agent and a vendor trusted agent. U.S. Patent No. 5,664,1 15, to Fraser, entitle d"Interactive Computer System to Match Buyers and Sellers of Real Estate, Businesses and Other Property Using the Internet," discloses automatically connecting sellers of property with potential buyers, preferably over the Internet, wherein the host system stores records regarding the properties and can be searched by potential buyers, and the system permits evaluation of potential buyers to screen them.

Various articles have been written which disclose forms of electronic payment methods, but these methodologies only relate to moving money around, from one account to another, electronically and do not address the need in the marketplace for electronic factoring.

Summary of the Invention The invention comprises a method and system for electronic factoring. The inventive system overcomes all of the limitations of the prior art and addresses the need for an electronic commerce version for factoring. The system enables buyers to purchase goods from vendors with a third party guarantee to the vendor via electronic factoring that guarantees the payment. By using the system, electronic factoring, including credit insurance, is performed in an efficient manner. The invention enables buyers to obtain goods and services immediately without having to pay for them at the time of the transaction.

The invention also comprises a credit database set up for all users that assigns a credit limit to the customers for credit as well as a credit instrument for guarantee of payment to vendors. Payment is guaranteed through a banking partner, the guaranteeing financial institution, who guarantees all receivables that are created through the sales on the platform (entitled "ProfitScape" in the Figures) to ensure payment and security of the transaction. The system tracks and maintains a database that details credit dollar amounts available and account activity for each user. The invention defines a credit-worthy marketplace that enables users, who become members, to purchase goods and services on credit based on their respective financial positions which have been evaluated by the guaranteeing financial institution.

In one embodiment, the method comprises the steps of providing an electronic platform for guaranteeing payment of receivables; inputting information from users into a profile database upon the electronic platform; assigning buyers a credit limit; and guaranteeing payment to vendors for users who purchase from the vendor. Additionally, the method comprises linking at least two users, the users being either buyers, vendors, international licensees, or financial institutions for guaranteeing payment via the platform. Guaranteeing payment to vendors preferably comprises aligning the platform with a guaranteeing financial institution. Aligning the platform with a guaranteeing financial institution preferably comprises aligning the platform with that institution in order to perform a factoring-type such as credit insuring, full-factoring, or lending. The electronic factoring method can further comprise the steps of producing a symbol to represent each user's profile and exchanging information between users via the symbol on the electronic platform. Guaranteeing payment to vendors can comprise electronically sending the vendor the user's symbol in order to show the vendor that payment is guaranteed by the platform. The method can further comprise the steps of electronically sending the user's symbol to the guaranteeing financial institution and sending a guarantee of compensation from the guaranteeing financial institution to the vendor. Guaranteeing payment to vendors can comprise the steps of issuing each user an identifying card showing membership on the platform; purchasing from the vendor with the identifying card; and accessing the user's credit availability via the platform with the identifying card.

Providing an electronic platform preferably comprises providing an Internet web site having the platform for users to access, and optionally comprises the step of providing Internet web site links for users to access other users' web sites. The step of inputting information from users into a profile database preferably comprises the steps of inputting data such as name, address, contact information, primary industry, credit insured amount, payment history, credit usage, target marketplace, products offered, services offered, inventory, buying trend data, and Internet usage data.

The electronic factoring method further can comprise the steps of verifying a user as a member of the platform and purchasing from the vendor. Purchasing from the vendor can comprise first searching the profile database with a search engine, from the vendor preferably comprises purchasing from the vendor with a line of credit within the credit limit established by the profile database.

Guaranteeing payment to vendors can comprise the steps of reassigning the receivable to the guaranteeing financial institution; making payment to the platform; and forwarding payment from the platform to the vendor. Guaranteeing payment to vendors can alternatively comprise reassigning the receivable to the guaranteeing financial institution; making payment to the guaranteeing financial institution; and forwarding payment from the guaranteeing financial institution to the vendor. In yet another embodiment, guaranteeing payment to vendors comprises accessing the platform directly by the vendor for verification of credit availability and forwarding payment to the vendor upon accessing the guaranteeing financial institution directly by the vendor for verification of credit availability and forwarding payment to the vendor upon verification. In still another embodiment, guaranteeing payment to vendors comprises accessing the guaranteeing financial institution directly by the vendor for verification of credit availability and forwarding payment to the vendor upon verification. Still another embodiment of guaranteeing payment to vendors comprises accessing the platform for verification of credit availability; paying the guaranteeing financial institution for purchases; and forwarding payment from the guaranteeing financial institution to the platform and vendor bank so that the vendor bank can credit the vendor.

The electronic factoring method also can comprise the steps of maintaining user credit records on the platform and periodically reviewing credit records by the financial institution for buyer credit availability. Linking at least two users can comprise the steps of creating offers by the vendor; sending the offers to an offer database on the platform for storage; comparing the offer database with the user profiles in the profile database; creating a list of matching offers and user profiles; and offering users those offers that match the user's profile upon log-in.

In one embodiment, the invention also comprises a method of electronic factoring comprising the steps of assigning buyers a credit limit upon a guaranteeing platform; verifying the buyer's identification as a member of the guaranteeing platform; verifying the buyer's credit amount when the buyer attempts to make a purchase; subtracting the purchase amount from the buyer's available credit limit upon making a verified purchase; notifying the vendor of the purchase order; reassigning the receivable to a guaranteeing financial institution via the guaranteeing platform; billing the buyer for the purchase order; and forwarding payment to the vendor. Forwarding payment to the vendor optionally comprises forwarding payment to the vendor from either the buyer, the guaranteeing financial institution, or the guaranteeing platform.

In one embodiment, the invention also comprises an electronic factoring system for guaranteeing payment of receivables and comprises an electronic platform; a profile database upon the electronic platform for inputting information from users; means for assigning buyers a credit limit; and means for guaranteeing payment to vendors for users who purchase from the vendor. The electronic factoring system can additionally comprise means for linking at least two users wherein the users consist of buyers, vendors, international licensees, and financial institutions for guaranteeing payment via the platform. Means for guaranteeing payment to vendors may comprise means for aligning the platform with a guaranteeing financial institution, and wherein said means for aligning the platform with a guaranteeing financial institution comprises aligning with a guaranteeing financial institution so that that institution can perform factoring such as credit insuring, full-factoring, or lending. The electronic system can further comprise means for producing a symbol to represent each user's profile, and means for exchanging information between users via the symbol on the electronic platform. Means for guaranteeing payment to vendors can comprise means for electronically sending the vendor the user's symbol in order to show the vendor that payment is guaranteed by the platform. The system can comprise means for electronically sending the user's symbol to the guaranteeing financial institution and means for sending a guarantee of compensation from the guaranteeing financial institution to the vendor. Means for guaranteeing payment to vendors can alternatively comprise an identifying card issued to each user showing membership on the platform; means for purchasing from the vendor with the identifying card, and means for accessing the user's credit availability via the platform with the identifying card.

The electronic platform of the electronic factoring system may comprise an Internet web site having the platform available for users to access. The Internet web site can further comprise links for users to access other users' web sites. The profile database of the electronic factoring system may comprise a profile database for inputting data from users. This data can consist of any of the following: name, address, contact information, primary industry, credit insured amount, payment history, credit usage, target marketplace, products offered, services offered, inventory, buying trend data, and Internet usage data.

The electronic factoring system can further comprise means for verifying a user as a member of the platform and means for purchasing from the vendor. Means for purchasing from the vendor can comprise means for first searching the profile database with a search engine. Means for purchasing from the vendor preferably comprises means for purchasing from the vendor with a line of credit within the credit limit established by the profile database. Means for guaranteeing payment to vendors can comprise means for reassigning the receivable to the guaranteeing financial institution; means for making payment to the platform; and means for forwarding payment from the platform to the vendor. Alternatively, means for guaranteeing payment to vendors comprises means for reassigning the receivable to the guaranteeing financial institution; means for making payment to the guaranteeing financial institution; and means for forwarding payment from the guaranteeing financial institution to the vendor. In still another embodiment, means for guaranteeing payment to vendor comprises means for accessing the platform directly by the vendor for verification of credit availability and means for forwarding payment to the vendor upon verification. In still another embodiment, the means for guaranteeing payment to vendors comprises means for accessing the guaranteeing financial institution directly by the vendor for verification of credit availability and means for forwarding payment to the vendor upon verification. In yet another embodiment, the means for guaranteeing payment to vendors comprises means for accessing the platform for verification of credit availability; means for paying the guaranteeing financial institution for purchase; and means for forwarding payment from the guaranteeing financial institution to the platform and vendor bank so that the vendor bank can credit the vendor.

The electronic factoring system can further comprise means for maintaining user credit records on the platform and means for periodically reviewing credit records by the financial institution for buyer credit availability. Means for linking at least two users can comprise means for creating offers by the vendor; means for sending the offers to an offer database on the platform for storage; means for comparing the offer database with the user profiles in the profile database; means for creating a list of matching offers and user profiles; and means for offering users those offers that match the user's profile upon login.

The invention also comprises an electronic factoring system for guaranteeing payment of receivables comprising means for assigning buyers a credit limit upon a guaranteeing platform; means for verifying the buyer's identification as a member of the guaranteeing platform; means for verifying the buyer's credit amount when the buyer attempts to make a purchase; means for subtracting the purchase amount from the buyer's available credit limit upon making a verified purchase; means for notifying the vendor of the purchase order; means for reassigning the receivable to a guaranteeing financial institution via the guaranteeing platform; means for billing the buyer for the purchase order; and means for forwarding payment to the vendor. Means for forwarding payment to the vendor can comprise means for forwarding payment to the vendor from either the buyer, the guaranteeing financial institution, or the guaranteeing platform. One aspect of the invention can provide unique profiled information that is delivered through an electronic system using software agents that enable credit and/or a guarantee of compensation to vendors for buyers.

Another aspect of the invention can include a unique database profile which is created incorporating specific sales and product information detailing what each user has to sell, terms, company history, unique product information, and the category of transaction, be it either a retail or wholesale target market.

Another aspect of the invention can provide unique profiled information and open access to both buyers and vendors to find information and make purchases guaranteed for payment. Yet another aspect of the invention can enable users to find unique information that matches their targeted request and enables them to purchase and consummate transactions electronically.

Yet another aspect of the invention comprises amethod of conducting electronic commerce, the method comprising: receiving an electronic authorization request from a vendor for a payment guarantee, wherein the authorization request identifies a transaction amount between the vendor and a buyer; and electronically transmitting to the vendor a guarantee of payment for the transaction amount, wherein the guarantee is conditional to the occurrence of one or more events. One of the events may be the receipt of an invoice from the vendor. A transaction fee may be charged regardless of the occurrence of the conditions. The transaction fee can be based at least in part upon either the transaction fee or a payment due date. The method may also comprise: receiving an invoice from the seller, wherein the invoice identifies an actual transaction amount of a transaction between the buyer and the seller; storing the actual transaction amount in a database; and transmitting the invoice to a guarantor. The method may also comprise gauranteeing payment based at least in part upon a credit limit of the buyer. The method may also comprise receiving an invoice from the seller, wherein the invoice identifies a payment due date; and determining, based at least in part upon the due date, a fee that is due by the seller. The method may also comprise receiving payment from the buyer; and sending payment to the vendor subsequent to subtracting the determined fee. Gauranteeing payment may comprise insuring payment by the seller or purchasing a receivable from the vendor. Another aspect of the invention comprises a system for conducting electronic commerce, the system comprising: means for receiving an electronic authorization request from a vendor for a payment guarantee, wherein the authorization request identifies a transaction amount between the vendor and a buyer; and means for electronically transmitting to the vendor a guarantee of payment for the transaction amount, wherein the guarantee is conditional to the occurrence of one or more events. Brief Description of the Drawings

The accompanying drawings, which are incorporated into and form a part of the specification, illustrate several embodiments of the invention and, together with the description, serve to explain the principles of the invention. The drawings are only for the purpose of illustrating a preferred embodiment of the invention and are not to be construed as limiting the invention. In the drawings:

Fig. 1 A is a block diagram of a first embodiment of the invention showing the flow of purchase and fulfillment between buyer and vendor using the electronic commerce web site platform of the invention; Fig. IB is a block diagram of a second embodiment of the invention showing the flow of purchase and fulfillment between buyer and vendor using the electronic commerce web site platform;

Fig. IC is a block diagram of a third embodiment of the invention showing the flow of purchase and fulfillment between buyer and vendor using the electronic commerce web site platform; Fig. 2 is a block diagram of another embodiment of the invention wherein the buyer makes payment directly to the guaranteeing institution;

Fig. 3 is a block diagram of the post-shopping experience for a user of the invention; Fig. 4 is a block diagram of the functions that an existing customer or new user proceeds through when visiting the web site platform of the invention; Fig. 5 is a block diagram showing the functions that a user proceeds through with customer service;

Fig. 6 is a block diagram showing a user searching the database of the invention and consummating a transaction with a link to other web sites;

Figs. 7a-7e demonstrate the algorithmic methods of communication for the various embodiments of the invention;

Fig. 8 is a flow diagram showing the first international licensee embodiment of the invention in the first page;

Fig. 9 is a flow diagram showing the first international licensee embodiment of the invention in the second stage; Fig. 10 is a flow diagram of a second international licensee embodiment of the invention in the first stage wherein the financial institution of guarantee works directly with the international licensee;

Fig. 1 1 is a flow diagram of a second international licensee embodiment of the invention in the second stage; Fig. 12 is a third international licensee embodiment of the invention; Fig. 13 is a fourth international licensee embodiment of the invention;

Fig. 14 is a flow chart showing the connection being made between user and vendor;

Fig. 15 is a flow chart showing the user application for credit;

Fig. 16 is a flow chart showing the user log-in to the invention; Fig. 17 is a flow chart showing the user making a purchase through the methodology of the invention;

Fig. 18 is a flow diagram of an alternative embodiment of the invention wherein both a guarantor bank and a vendor bank are used in the process;

Fig. 19 is a flow diagram of another alternative embodiment of the invention wherein both a guarantor bank and vendor bank are used;

Fig. 20 is a flow diagram of the preferred user login to a web site according to the invention;

Fig. 21 is a flow diagram of the preferred purchase transaction according to the invention;

Fig. 22 is a flow diagram of a first interaction with two guarantor banks; Fig. 23 is a flow diagram of a second interaction with two guarantor banks;

Fig. 24 is a flow diagram of a preferred lockbox of the invention;

Fig. 25 is an illustrative approval screen in a web page according to the invention prior to submission;

Fig. 26 is an illustrative approval screen in a web page according to the invention after submission;

Fig. 27 is an illustrative edit screen;

Fig. 28 is a top-level flow diagram of the preferred web site of the invention in conjunction with customer web sites;

Fig. 29 is an illustrative purchase screen; Fig. 30 is an illustrative invoice screen;

Fig. 31 is an illustrative payment screen;

Fig. 31 A is an illustrative first confirmation screen;

Fig. 3 IB is an illustrative second confirmation screen;

Fig. 32 is a flowchart illustrating vendor recruitment; Fig. 33 is a flowchart illustrating buyer recruitment;

Fig. 34 is a flowchart illustrating an exemplary trade show purchase;

Fig. 35 is a flowchart illustrating shipment of a trade show purchase;

Fig. 36 is an exemplary network that may be used in conjunction with electronic platform of the invention; Fig. 37 is yet another exemplary network that may be used in conjunction with the electronic platform of the invention;

Figs. 38, 39, and 40 are each a diagram illustrating the contents of selected fields of the database during an exemplary transaction; and Fig. 41 is a screen display showing an exemplary report that is presented that shows the transaction history for a user of the electronic platform of Figs. IA, I B, IC and 2.

Detailed Description of the Invention

In one embodiment, the invention comprises a payment or credit arrangement process wherein payment of all transactions are guaranteed through a platform, and aligned guaranteeing financial institution (or guarantor bank). All users, whether buyers or sellers ("vendors") are put into a profile database that defines their credit amount, credit used, and credit available. A unique number is then assigned to each user that will be used as an identifying symbol to be held in the electronic database. This symbol, or digital representation thereof, represents a profile enabling users to obtain and utilize credit to facilitate purchases of goods, services, and other intangibles through the system. The information and implementation of the invention is preferably distributed electronically over data lines into a worldwide web platform to facilitate users' purchase transactions or vendors' sales needs.

The digitally produced symbol is delivered electronically via data lines to find targeted information, and enables the buyer to purchase goods, services, or other intangibles ordered through the system. A search engine is used to locate the required information over a network of profiled vendors. The same process operates in reverse to also link vendors to buyers. Information using software agents can be accessed electronically based on an Alchemy model that enables users to seek and match their specific requests. The unique symbol that is assigned for the vendor's profile, as well as a specific symbol representing the targeted audience of buyers, with additional symbols or digital representations for other information, allows for an efficient and easy-to-use exchange of information. Additionally, proprietary profiles can be maintained to facilitate electronic commerce for users within the database to exchange information and to target specific information to a targeted audience.

Vendors benefit by reaching buyers through the system and offering credit to purchase their goods, services, or other intangibles. Competing advertising members can use the system to reach the attention of users who wish to seek information residing on the system as well. Vendors can use the credit system to sell to buyers within the profile database to ensure future payment of goods that are sold on a time-delay process unique to each of the profiled users.

By electronically transmitting the symbol, the user can deliver a promise of compensation to be paid immediately, or in the future. By using software agents, the electronic database transmits digital information electronically to those users who are seeking to receive compensation in exchange for releasing the items that the user/buyer has requested. The digitally produced symbol simultaneously instructs a third party to deliver a guarantee of compensation on behalf of each user. The third party guarantees compensation to the vendor in the form of either credit insuring, full-factoring, or lending based upon accounts receivable.

The platform streamlines the buying process and saves time by alleviating the need for C.O.D., prepayment with a Visa or MasterCard and excessive paperwork necessary for approval through multiple factoring banks.

Often the vendor will need their money before they can ship the order: perhaps the money is needed to produce the order. In this case, called factoring, the vendor pays a higher fee to ProfitScape in order to obtain their money early. The vendor sells the receivable to the factor: once payment is made, the payment will be sent to the factor. This is done with or without the knowledge of the cardholder. Actors

The following table documents some of the roles played by users of the system and a summary of how users interact with the system. A role or actor refers to one, possibly of many, motivations driving a user to interact with the system. The same user may have different roles at different times.

HSΠHI DSEI32E1

Use Cases A use-case is a single scenario depicting how users are interacting with the system to achieve a specific goal. Process Pre-Approved Batch

This case depicts the card issuer receiving a large number of proposed cardholders from a third party. The card issuer eliminates duplicates, creates the cardholder accounts, and submits their information to a guarantor for credit line approval.

In one embodiment, an association submits a file to the card issuer, who in turn attempts to submit the file to the system. The system verifies file contents (headers, counts, formats, etc). The entire file is either accepted or rejected. If accepted, the file creates a batch in the database for processing. The card issuer processes batch, creating cardholder accounts where needed and marking each batch entry with the account number. Existing accounts are left alone, since the original association receives the fee (if any) for sourcing those records. The system marks any created cardholder records with the association as the source. In some cases the association will receive a permanent fee percentage of all transactions. The system generates batches for guarantors for credit line approvals. The card issuer submits credit line request batches to one or more guarantors. In response, guarantors submit a credit line response batch to the card issuer.

The card issuer processes credit line batch, updating customer records. The card issuer prints a processing report (to printer or file) for the association to track results.

Cards are then ready to be issued or other responses are generated. For example, customer service representatives for the card issuer can contact the applicant to counsel them towards getting approval, possibly from a different guarantor. Process Vendor Batch Associations can submit large groups of vendor records. Also, Vendors may sign themselves up for the service. Web portals may submit vendor batches as well. An exemplary process is set forth below that describes a process for creating new vendor accounts.

An association or some other verified source submits a file to the card issuer. A CSR representative for the card issuer verifies file contents and either accepts or rejects the entire file. If accepted, a New Vendor Accounts batch is created, waiting to be processed. Next, the card issuer processes file, creating vendor accounts where needed, and marking each batch record with the account number and status. In one embodiment, existing accounts are left alone. Letters are then issued to vendor informing them of their account, status, and usage procedures. Create Cardholder

The card issuer can create a single cardholder account at a time as well as the batch pre- approved process. Issuing Cards

One or more cards are issued to specific people within a company. The credit line authorization of a company can be divided among one or multiple card users. Even with multiple cards, the total authorization will not exceed the total credit line of a company.

A company can: (i) authorize the entire credit amount to one person on one card; (ii) divide the entire credit amount among multiple people, each having their own card; (iii) allow a "key signatory" to access to the entire credit amount on a card, plus divide the entire credit amount among multiple people, each having their own card, or (iv) authorize the entire credit amount to multiple people, each having their own cards. As discussed, cards may be issued in large batches, sent out for embossing, or one at a time like temporary cards at a trade show. Again, batches are created, edited, posted.

The following table summarizes each of the foregoing situations:

In one embodiment of the invention, the card can be co-branded by a credit card provider. In this embodiment, at a point of purchase, the user can request to use the card as a credit card, or, alternatively, as a card as is described for use with the embodiments of the invention shown in Figures 1-41. Furthermore, in this embodiment, the card is associated with at least two credit limits: the first credit limit identifying a credit limit with respect to the credit card provider and a second credit limit associated with the use of the card in conjunction with the system shown in Figures 1 -41. Furthermore, in one embodiment of the invention, the card contains two sets of account information: a first set is associated with the credit card provider and a second set is associated with respect to the use of the card in conjunction with the system shown in Figures 1-41. Tradeshow

In one embodiment of the invention, custom cards are issued as part of a tradeshow. In this embodiment, the cards have identifying information displayed on the card thereby serving as a badge. The card may be activated by providing the credit vendor a credit application and requesting the credit vendor to activate the card. Once activated, the credit vendor provides an insignia to the buyer. The buyer places the insignia on or near the card via an adhesive. The insignia identifies to sellers that the buyer has at least a threshold level of credit. In another embodiment of the invention, upon approving the buyer's application for a card, the buyer is provided a card having a certain color that is different than the individuals that have not been approved to receive credit. Create Vendor

The card issuer can create a single vendor account at a time as well as part of the batch pre- approved process. Purchase Guarantee Payment The following describes a process of guaranteeing payment for a transaction. First, a cardholder places order, e.g., verbal, PO, with a vendor.

The vendor submits authorization request to ProfitScape/system (card #, expiration name, name, amount, PO). The system verifies credit balance, issues authorization code, decline, pending, or other response message. Exemplary response codes may be found in the Visa 2 Specification.

If amount requested puts cardholder over the cardholder's credit limit, a PENDING response is issued and submitted to the guarantor. The guarantor can approval the transaction and/or or increase the cardholder's credit limit. The card issuer can generate reports of PENDING authorizations to ensure that they are being answered in a timely manner. The vendor ships goods, sends invoice to the card issuer with an authorization code. The vendor sends an invoice to the cardholder requesting the cardholder to remit payment to the guarantor, or alternatively, the card issuer. In one embodiment, the card issuer has online forms for vendors to submit invoices.

In one embodiment, the vendor incurs a payment term guarantee fee at the time of approval of the transaction. Each vendor obtains an approval for a specific buyer (i.e., one cardholder). Each approval can cover multiple invoices for a specific buyer (i.e., one cardholder). Each approval incurs a fee, relative to the total invoice amount. If an invoice is larger than the approved amount (e.g., due to taxes or shipping fees), a 2'/2% fee (or more depending on length of terms) may be automatically charged against the extra amount. Receive Invoice After shipping the goods, the vendor sends the invoice to both the cardholder and to the card issuer. After the card issuer receives invoice(s), each invoice is marked with the authorization code. The invoice specifies the payment terms. Depending on the payment terms, a selected fee may be charged by the card issuer for the service of guaranteeing the total approved amount. In one embodiment, the fees are accessed on the basis of the total invoice amount, including tax and shipping charges. In one embodiment, the fee schedule varies according to the length of time until the payment is due. The following table illustrates an exemplary fee schedule.

If more than one invoice is received from a vendor, the vendor should include a summary sheet having totals for verification.

The card issuer inputs an authorization code to find the transaction in the database, and then inputs the invoice number and total. The card issuer logs the invoice and sends the invoice to the guarantor of the transaction both physically and as an electronic item. Guarantor Receives Payments

Payments are received by the guarantor, which sends an electronic log of settlements to the card issuer. It is noted that in one embodiment, the buyer sends the payments directly to the card issuer. The system creates the appropriate payment transactions and computes the guarantor's fee, creating a transaction object in the platform for that as well. The card issuer applies payments to the invoice. The guarantor takes a fee, based on the total amount of the invoice, and then send the payments on to the card issuer. One payment may be applied to multiple invoices. A partial payment may be applied to an invoice.

The card issuer distributes to the vendor the payment, less fees any transaction fees. The vendor receives the payment, less fees, based on the total amount of the INVOICE (not the amount received). The vendor may bill the buyer for the difference between the total invoice and the amount remitted. In the event the payment is less than the total invoice amount due to payment terms (e.g., 2%/10 Net 30), the vendor is responsible for issuing a credit for the buyer.

Card Issuer Issues Vendor Checks

A payables batch is created in the system. After editing, the batch is sent to a A/P system to actually print checks. Optionally, the card issuer can print the checks. Cycle End Processing

The vendors each receive a cycle-end statement summarizing all transactions and providing updated information. This marks a regular contact point, where marketing materials may be included with the mailing. Some may elect to receive such transmissions electronically, e.g., CD-ROM, diskette, ftp, email. Issue Cards (Batch. Single. Re-issue)

Cards may be issued in large batches, sent out for embossing, or one at a time. Buyer Credit Advance

The buyer is responsible for paying for the goods and services that have been purchased from the seller within a predetermined time period, e g., 30, 60, 90 days. In one embodiment, the start of the due date time period is triggered after the seller transmits the goods to the buyer or, alternatively, after the seller performs services for the buyer.

In one embodiment of the invention, the buyer may defer payment by paying a selected fee. In return, the recipient of the selected fee pays all or some of the funds that are owed by the buyer.

For example, with respect to the system shown in Fig. 1 B, the buyer may request the credit vendor to defer payment to the re-factor company. In exchange for receiving the selected fee, the credit vendor pays the seller after the predetermined time period. Also, the credit vendor transmits a selected fee to the re-factor company for the re-factor company's involvement with the initial transaction between the buyer and the seller. Alternatively, instead of the credit vendor, the re- factor company can accept delayed payment and in return for the delayed payment, charge the fee and pay the credit vendor prior to the expiration of the predetermined time periods, e.g., 30, 60, 90 days. The credit vendor then pays the seller the monies owed the seller by the buyer minus any transaction fees. Furthermore, for example, with respect to the system shown in Fig. IC, the buyer may request the credit vendor to receive delayed payment for a fee. In return for the fee, the credit vendor pays the seller prior to the expiration of the predetermined time period. View Accounts

In one embodiment, buyers and sellers may retrieve their account information from the credit server. Account information can include: credit limits, past transactions, billing information, etc. In this embodiment, the credit vendor maintains a server computer that is operably connected to a network. The network may include any type of electronically connected group of computers including, for instance, the following networks: Internet, Intranet, Local Area Networks (LAN) or Wide Area Networks (WAN). In addition, the connectivity to the network may be, for example, remote modem, Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink Interface (FDDI) or Asynchronous Transfer Mode (ATM). Note that computing devices may be desktop, server, portable, hand-held, set-top, or any other desired type of configuration. As used herein, an Internet includes network variations such as public internet, a private internet, a secure internet, a private network, a public network, a value-added network, an intranet, and the like. Using a client computer that is connected to the network, the client computer can retrieve account information. An exemplary report showing account information is shown in Figure 41. In one embodiment, the server computer allows the user to contest certain transactions that are identified in the account information. Upon contesting a transaction, the contesting party is afforded an opportunity to associate one or more messages with the contest. In this regard, each transaction has an electronic storage bin to hold communications between the buyer and the seller for the selected transaction.

In one embodiment, if the transaction is contested by the buyer, the message is automatically transmitted via electronic mail to an agent for the seller and stored in the electronic storage bin. Furthermore, in one embodiment, if the transaction is contested by the seller, the message is automatically transmitted via electronic mail to an agent for the buyer and stored in the electronic storage bin. Once received by the non-contesting party, the contesting party is presented with an opportunity to reply via electronic mail. Using the storage bin, the communication history between the buyer and seller may be reviewed. Furthermore, in one embodiment of the invention, the non-contesting party can change the terms of the transaction to end the dispute.

In one embodiment of the invention, a buyer is afforded an opportunity to delay payment with respect to one or more of the transactions. In this embodiment, when the user views their past transactions, the buyer is presented a selectable icon proximate to each of the transactions for which that buyer owes payment. By selecting the selectable icon, the user indicates a request to extend the due date for paying the due fees. In response to the selection, the server computer adjusts the due date for the transactions and assigns a due date extension fee to the buyer's account. Furthermore, at a predetermined point, the server computer pays the seller the monies that are owed to seller by the buyer.

In another embodiment of the invention, a seller is afforded an opportunity to receive payment prior to agreed upon terms with the credit vendor. In this embodiment, when the seller views past transactions, the seller is presented with a selectable icon proximate to each of the transactions in which the seller is to receive payment. By selecting the selected icon, the seller indicates a request to receive payment for the funds immediately. In response to the selection, the server computer pays the seller the monies owed minus an advance fee. It is noted that since a buyer may also be a seller to other buyers, the buyer and seller reporting screens may be integrated into a single screen display.

System Description Attention is now directed to the figures. Fig. I A is a flow diagram of a first embodiment of the invention showing the purchase and fulfillment between a buyer, vendor and guaranteeing financial institution using the method of the invention. Referring to Fig. 1, the buyer makes a purchase from the vendor with a guaranteed credit line as established in the profile database 10. The purchase order is then being forwarded to the vendor for fulfillment 12. Then the receivable is reassigned to the guaranteeing financial institution for a guarantee of the receivables 14, the purchase order is returned to the buyer for the buyer's records 16. The vendor ships the order with a copy of the invoice and terms back to the buyer 18, for example, net 30, net 60, or net 90. Then the vendor sends shipment confirmation and a copy of the invoice to the platform for the invention, which in one embodiment, is entitled "ProfitScape" (hereinafter referred to as the platform), on an e-commerce web site 20. Next the buyer makes payment to the platform based upon the vendor terms 22, and the platform forwards payment to the vendor 24, minus a negotiated percentage. The platform profile database maintains credit records and transfers all monies from the buyer to the vendor minus a negotiated percentage or transaction fee, for example 8-12% of the transaction. The guaranteeing financial institution will review the accounts periodically, for example every 90 days, for buyer credit line limits. Also periodically, for example every 30 days, the platform reconciles with the guaranteeing financial institution for a percentage of all gross revenue of the platform's guaranteed electronic commerce transactions.

Fig. I B is another embodiment of the invention. Fig. I B is a flow diagram of a second embodiment of the invention showing the purchase and fulfillment between a buyer, seller and a credit vendor. It is noted that although only one buyer is shown, the electronic platform can be used in connection with large numbers of buyers.

Referring to Fig. I B, at a step 51 , a buyer provides credit information via an application to a credit vendor. Next, at a step 52, the credit vendor forwards the information to a re-factor company. The re-factor company evaluates the credit information and determines a credit limit for the buyer. At a step 53 the re-factor company transmits the credit limit for the buyer to the credit vendor. Continuing to a step 54, the credit vendor transmits one or more cards to the buyer. In one embodiment, the card has an electronic strip having a magnetically imprinted card number. Furthermore, the card may have an associated personal identification number.

Moving to a step 55, the buyer contacts a seller and offers to purchase goods or services that are provided by the seller. At the step 55, the buyer provides the seller their card or alternatively the buyer's account information. Next, at a step 56, the seller provides the credit vendor, via a transaction device, the transaction information. The transaction device can include: a computer, a hand held device, a cash register, or other electronic device. In one embodiment of the invention, the transaction information comprises a merchant identifier, the buyer account number (the card number), the name on the card, an expiration date that is associated with the card, and an estimated transaction amount.

The credit vendor determines whether the transaction amount would cause the buyer to spend in excess of the buyer's credit limit. Assuming the buyer has sufficient credit, the process moves to a step 57 wherein the credit vendor transmits approval to the seller computer for the transaction. Furthermore, the credit vendor records the transaction information to facilitate evaluating further purchases of the buyer.

Continuing to a step 58, the seller ships the goods or performs the services specified by the contract. In return, the seller receives from the credit vendor the right to receive payment no later than a predetermined period. In one embodiment of the invention, the predetermined period is no later than 180 days or whenever the re-factor company receives payment, whichever is sooner.

Next, at a step 61 , the buyer makes payment to the re-factor company. Continuing to a step 62, the re-factor company pays the credit vendor minus a first transaction fee. Proceeding to a state 63, the re-factor company pays the seller minus a second transaction fee. It is noted that in one embodiment of the invention, for a predetermined fee, the seller can borrow against the guaranteed received payment.

Fig. IC is a flow diagram of a third embodiment of the invention showing the purchase and fulfillment between a buyer, vendor and guaranteeing financial institution. It is noted that although only one buyer is shown, the invention can be used in connection with large numbers of buyers.

Referring to Fig. IC, at a step 71, a buyer provides credit information via an application to a credit vendor. Next, at a step 72, the credit vendor forwards the information to a credit insurer.

The credit insurer evaluates the credit information and determines whether it will insure the transaction. At a step 73, the credit insurer transmits the credit limit for the buyer to the credit vendor. The credit vendor may transmit one or more cards to the buyer.

Moving to a step 74, the buyer contacts a seller and offers to purchase goods or services that are provided by the seller. Upon agreeing to the terms of a deal, the buyer provides the seller their card or alternatively provides the buyers account information.

Next, at a step 75, the seller provides the credit vendor, via a transaction device, the transaction information. In one embodiment of the invention, the transaction information comprises a merchant identifier, the buyer account number (the card number), the name on the card, an expiration date that is associated with the card, and an estimated transaction amount. The credit vendor determines whether the transaction amount would cause the buyer to spend in excess of the buyer's credit limit. Assuming the buyer has sufficient credit, the process moves to a step 76 wherein the credit vendor transmits approval to the seller's transaction device.

Furthermore, the credit vendor records the transaction information to facilitate evaluating further purchases of the buyer.

Continuing to a step 77, the seller ships the goods or performs the services specified by the contract. In return, the seller receives from the credit vendor the right to receive payment no later than a predetermined period. In one embodiment of the invention, the predetermined period is no later than 180 days or whenever the credit vendor receives payment, whichever is sooner. Next, at a step 78, the buyer makes payment to the credit vendor. It is noted that in one embodiment of the invention, for a predetermined fee, the seller can borrow against the guaranteed received payment. Moving to a step 79, the credit vendor pays the seller. Fig. 2 is another embodiment of the invention. In Fig. 2, the buyer makes a purchase through the guaranteeing financial institution with a guaranteed credit line 26. In one embodiment, the vendor then obtains from the guaranteeing financial institution an authorization code for the amount of the intended purchase, including tax and shipping if known. Once authorization is obtained (usually within seconds), the vendor may ship the order knowing that payment is guaranteed. The purchase order is then forwarded to the vendor for fulfillment 28 and the purchase order is then returned to the buyer for the buyer's records 30. Then the vendor ships the order with a copy of the invoice and terms to the buyer 32, and the vendor sends shipment confirmation and a copy of the invoice to the guaranteeing financial institution 34. In one embodiment, the vendor notes on the buyer's copy of the invoice to remit payment to the guaranteeing financial institution 34. The buyer the makes payment to the guaranteeing institution based upon the vendor's terms 36, and the institution forwards payment to the vendor minus the institution's negotiated percentage 38. Fig. 3 is a block diagram demonstrating the post-shopping experience of the buyer using the methodology of the invention. The user first shops and then views their order, and before checking out, chooses a form of payment, be it either a credit card, or through the platform of the invention. If a credit card is chosen as the method of payment, the transaction proceeds through the platform of the invention. If the user is enrolled in the platform of the invention, their transaction is guaranteed. The user is also offered the choice of joining and becoming a member of the platform.

Fig. 4 shows the process that a user proceeds through when first logging on to the platform of the invention. First the existing customer or the new user visits the web site having the platform of the invention 40. The new user applies for membership and a line of credit with guaranteed receivables 42. An existing user is shown logging in with their user name and password 44, and the existing customer or new user is forwarded to the appropriate web sites for purchases 46. Applications for credit and guarantees are forwarded to the financial institution for review 48. If the application for credit has been denied, the customer is then notified 50. If the application for credit has been approved, the customer is assigned a guaranteed credit limit 52, as well as an "ID" and is then entered into the user profile database.

Fig. 5 is a block diagram demonstrating an approved customer 54 being forwarded to customer service so that customer service can gather information 56 and create a user database profile on their company, products, target market, history, terms, etc. Example data collected for the user's profile includes: name, address, contact information, primary industry, credit insured amount, payment history, credit usage, target marketplace, products offered, services offered, inventory, buying trend data, and Internet usage data.

Fig. 6 is a block diagram demonstrating a user searching the profile database. A user queries the database through a search engine for specific information 58. Data is searched from the database and returned to the user 60. Then the user accesses a web site from a returned data link 62, and the user consummates an electronic commerce transaction 64 such as that shown in Fig. 1.

Fig. 7 shows the algorithm methods for the various embodiments of the invention. In Fig.

7a the buyer, seller, and guaranteeing institution cannot communicate with each other but only with the platform for the invention. In Fig. 7b the buyer and seller only communicate with the guaranteeing institution and not with each other. In Fig. 7d the buyer and guaranteeing institution can each only communicate with the seller, but the seller can communicate with either or both of the buyer and guaranteeing institution. In Fig. 7e the seller and the guaranteeing institution can each only communicate with the buyer, but the buyer can communicate with either or both of them.

Fig. 8 shows a flow diagram of an embodiment of the invention wherein the method of the invention includes an international licensee. First a user applies for a credit line through the international licensee 66. Then an application is entered into the database of the invention 68, and that application is forwarded to the guaranteeing financial institution 70. Then the applicant who is approved is assigned a line of credit and a user ID, and the database is then updated with their information 72. The user and licensee are then notified 74. At this point, the process proceeds as shown in Fig. 9. If the application is denied, the applicant and licensee are notified accordingly 76. Fig. 9 demonstrates the process that proceeds after the applicant has been approved in Fig.

8. The international buyer accesses the marketplace through a licensee 78. Then the platform's buyer makes an international purchase on the platform with the user's ID 80. Next the user ID and credit availability are checked through the database and the guaranteeing financial institution 82 and 82'. Then the seller receives the order with the guaranteed receivables 84, and the transaction has been completed and the order is shipped to the buyer 86. Fig. 10 is a flow diagram for a second embodiment of the international licensee application of the invention. First the user applies for a credit line through an international licensee 88. Then the application is forwarded to the guaranteeing financial institution 90. If the application is approved, the applicant is then assigned a line of credit and a user ID 92. The user and licensee are then notified. At this point, the process proceeds as shown in Fig. 1 1. If the application is denied, the applicant and licensee are accordingly notified 94.

Fig. 1 1 represents the next stage in the process after having completed those steps in Fig. 10. In Fig. 1 1, the international buyer accesses the marketplace through a licensee 96 and the platform buyer makes an international purchase 98 on the platform of the invention with the user ID. Then the user ID and credit availability are checked through the guaranteeing financial institution 100. The seller receives the order with the guaranteed receivables 102, the transaction is completed and the order is shipped to the buyer 104.

Fig. 12 is a third embodiment of the international licensee application of the invention. In Fig. 12, the guaranteed buyer makes a purchase from a vendor on an international licensee platform 106. Then the user ID and password are passed to a module 108 which allows the communication with the database of the invention, and the ID and credit availability are checked through the database, as well as the guaranteeing financial institution 1 10 and 1 10'. The vendor web site receives verification 1 12, and the transaction is completed and the order is then shipped to the buyer 1 14. Fig. 13 is a fourth embodiment of the international licensee application of the invention wherein the communication occurs directly with the guaranteeing financial institution. First, the guaranteed buyer makes purchases from a vendor on the international licensee platform 1 16. Then the user ID and password are passed to a module which allows communication with the database of the invention 1 18. Next the user ID and credit availability are checked through the guaranteeing financial institution 120. The vendor web site receives verification 122, and the transaction is completed and the order is then shipped to the buyer 124.

Fig. 14 is a flow chart demonstrating vendors' direct marketing to existing registered users (buyers) of the invention. The buyer logs on and sees offers being retrieved from the database, and chooses whether or not to accept the offer. If the offer is accepted, the transaction is concluded. If the offer is not accepted, the user continues on through the web site. The vendor creates offers and then sends them to the database for storage. The vendor then creates a user profile from the information off of the database. The database then compares the profile created by the vendor with existing customer profiles. The invention then creates a list of matching users who wish to see offers of this type and proceeds to offer them to those users the next time that they log on. Fig. 15 is a flow chart showing the user applying for credit with the methodology of the invention. The user first applies for a credit line, and that information is then added to the database. The information is then submitted to a financial institution and the financial institution either approves or disapproves the credit application. If the application is not approved, the user is informed of the result. If the application is approved, the amount of credit is recorded for the user and the user is accordingly informed of approval and the amount of credit. For example, an applicant applies for a "net 30 card." This card is similar in appearance to a credit card. Should the applicant be approved for the net 30 card, then they will be able to purchase goods and services immediately, and upon receipt the guaranteeing institution or platform of the invention will guarantee payment within thirty days to the vendor. The applicant can apply for the card either manually or electronically. Information received from the candidate is then entered into a database which is forwarded to a guaranteeing financial institution. The guaranteeing financial institution then reviews the application information and issues an insured line of credit if the applicant is approved. Once the applicant is approved, the guaranteeing financial institution notifies the platform of the insured credit line and guarantees payment of receivables. Then the net 30 card is issued to the applicant, who is now a registered user of the platform of the invention. The user's transactions are then checked through the platform profile database for available credit and amounts adjusted. At the end of each day, the platform of the invention keeps the guaranteeing financial institution updated on all user accounts' status. This methodology insures the vendor's receivables.

Fig. 16 is a flow chart demonstrating the steps that a user proceeds through in logging on to the web site containing the platform of the invention. The user first arrives at the public Web site and enters their login ID. The site then compares their ID and password to those recorded in the database. If the log-in is not valid, then the user is refused access and is returned to the public Web site. If the log-in is valid, then the user preferences are retrieved from the database and are customized to provide a personalized page displayed to the user. The user then continues with member-only options within the system.

Fig. 17 is a flow chart demonstrating a user making a purchase using the methodology of the invention. The user first attempts to conclude the transaction and the platform of the invention ascertains the user's identity and compares their transaction with an available credit balance stored in the database. If their available balance is not adequate, then the transaction is denied. If the available balance is adequate, then the transaction proceeds and the invention subtracts the transaction total from the available balance, and the order is confirmed to the user, the vendor is notified of the purchase order, and the user receives a copy of the purchase order. Next, the receivables are reassigned to the financial institution and the vendor receives notification of the purchase order and fulfills the purchase order. Once the receivables are reassigned to the financial institution, then the financial institution receives notification of that reassignment. Once the vendor notifies the platform of the fulfillment of the order and has sent the user the merchandise, the user is then billed. If the user does not pay the bill, then the financial institution is notified who then pays the platform who in turn pays the vendor. If the user does pay the bill, then their payment is added to the available credit in their account.

Fig. 18 is a flow diagram of a third embodiment of the invention. First the buyer selects the platform guaranteed receivables method as the method of payment 126. The e-commerce backend forwards purchase information to the platform profile database 128. Available credit is checked from the user's profile and new applicants are processed 130. Then the profile database is updated accordingly 132. The buyer is notified and if approved, the vendor, or seller, is also notified to ship 134 and 134'. Then the buyer makes payment to the guarantor bank according to the terms set forth by the vendor, or seller 138. The profile database is then updated accordingly 140. The guarantor bank processes the payment and forwards payment to the platform and vendor bank 142. Then the vendor bank credits the vendor, or seller 144.

Fig. 19 is a flow diagram of a fourth embodiment of the invention. In this embodiment, the buyer selects the platform guaranteed receivables method as the method of payment 146. The e-commerce backend forwards purchase information to a processor 148. The processor forwards information to the guaranteed receivables issuer which is the platform of the invention 150. Then the available credit is checked, new applicants are processed, and the profile database is updated accordingly 152. The buyer is notified of either approval or rejection of their application 154. If approved, the vendor, or seller, is notified to ship. The buyer makes payments to the guarantor bank lock box according to the terms set forth by the vendor, or seller 156. Next, the database and credit limit are updated accordingly 158. Then the guarantor bank processes payment and forwards payment to the platform and vendor bank 160. Then the vendor bank credits the vendor 162.

Figs. 20-40 further illustrate the invention as noted in the brief figure descriptions, above. The embodiments presented in the figures are not meant to limit the applications of the invention. The methodology of the invention has application in buying and selling, as well as lending based upon accounts receivables, in addition to credit insuring purchases.

Abstract Model The platform comprises one or more computer implemented modules. As can be appreciated by one of ordinary skill in the art, each of the modules comprise various sub-routines, procedures, definitional statements, and macros. Each of the modules are typically separately compiled and linked into a single executable program. The modules may be arbitrarily redistributed to one of the other modules, combined together in a single module, or made available in a shareable dynamic link library. Optionally, as can be appreciated by one skilled in the art, one or more of the modules may be designed using hardware.

The modules may be written in any programming language such as C, C++, BASIC, Pascal, Java, and FORTRAN and ran under the well-known operating system. C, C++, BASIC, Pascal, Java, and FORTRAN are industry standard programming languages for which many commercial compilers can be used to create executable code.

The following sections describe exemplary software-implemented classes that may be defined by selected ones of the modules. Company

The company class provides a common base class for the four types of companies involved in the system: Merchants, Cardholders, Factors, and Guarantors.

Code

The Code class represents all fields that store a coded value, referenced within the Codes table.

CompanyName

CompanyName represents a single company name, which may be one of many names a company goes by.

CompanyName name: String The company name.

Address

Address provides a postal address.

Contact

The Contact class represents a person and their contact information as well as a company's primary contact information.

Merchant

The Merchant class provides information regarding a single merchant within the system.

MerchantHome

The MerchantHome class provides methods for creating, finding, and deleting Merchants.

Cardholder

The cardholder class represents a single cardholder within the system.

CardholderHome

The CardholderHome class provides methods for creating, finding, and deleting Cardholders.

Card

The Card class represents a single card issued to a Cardholder.

Guarantor The Guarantor class represents a guarantor, such as GMAC.

Guarantor extends Company

GuarantorHome

The GuarantorHome class provides methods for creating, finding, and deleting Guarantors.

GuarantorHome same as MerchantHome Factor

The factor class represents a single factor.

FactorHome

The FactorHome class provides methods for creating, finding, and deleting Factors.

Association

The Association Class represents a company with a business relationship.

Association Home

The AssociatonHome class provides methods for creating, finding, and deleting associations.

Transaction

The transaction class represents a transaction.

TransactionHome

The TransactionHome class provides methods for creating, finding, and deleting

Transactions. Various other classes may be used to represent other portions of the system such as merchant invoices, cardholder payment, and a merchant statement/check.

Although the invention has been described in detail with particular reference to these preferred embodiments, other embodiments can achieve the same results. Variations and modifications of the invention will be obvious to those skilled in the art and it is intended to cover in the appended claims all such modifications and equivalents. The entire disclosures of all references, applications, patents and publications cited above are hereby incorporated by reference.

Appendix A

Database Schema It is noted that a number of different database schemas may be used with respect to the platform profile database. Set forth below are exemplary tables that may be used in conjunction with one embodiment of the platform profile database.

Table 1: System Users

CREATE TABLE SYΞTUSR

ID INTEGER NOT NULL, unique id }

LGNID CHAR (15) NOT NULL, lgin id }

CDUSRID INTEGER NOT NULL, user class }

P D CHAR (15) NOT NULL, password }

PWDDT DATE NOT NULL, password date }

NAM CHAR(50) NOT NULL, full name }

ACT CHAR(l) NOT NULL, active Y/N }

LGNCNT INT NOT NULL, login count }

LGNBAD INT NOT NULL, login bad count }

LGNDTTM DATETIME YEAR TO SECOND, last login date }

ATDTTM DATETIME YEAR TO SECOND, last login attmp }

ACTDT DATE , active date }

EXPDT DATE , expire date }

DTA CHAR(50), any data to associate to user }

CRTUSRID CHAR (15) NOT NULL, create user id } CRTDTTM DATETIME create datetime }

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, create server } CRTCLNT CHAR (15) NOT NULL, create client } CHGUSRID CHAR (15) NOT NULL, change by user } CHGDTTM DATETIME change datetime }

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, change server } CHGCLNT CHAR (15) NOT NULL, change client } PRIMARY KEY (ID) CONSTRAINT SYSCUSRPK, CHECK (ACT IN ('Y', 'N')) CONSTRAINT SYSCUSR1, UNIQUE (LGNID) CONSTRAINT SYSCUSR2 ) LOCK MODE ROW,

Table 2: User Groups (Map a user to a set of zero or more groups)

CREATE TABLE SYSTUSRG

(

ID INTEGER NOT NULL, { unique id } USRID INTEGER NOT NULL, { user id } GRPUSRID INTEGER NOT NULL, { group user id }

PRIMARY KEY (ID) CONSTRAINT SYSCUSRGPK,

UNIQUE (USRID, GRPUSRID) CONSTRAINT SYΞCUSRG1,

FOREIGN KEY (USRID) REFERENCES SYSTUSR (ID) CONSTRAINT SYSCUSRGFKl,

FOREIGN KEY (GRPUSRID) REFERENCES SYSTUSR (ID) CONSTRAINT SYSCUSRGFK2

) ,

Table 3: System Menu

CREATE TABLE SYSTMNU

ID INTEGER NOT NULL, { unique id }

TYP CHAR(l) NOT NULL, { M = Menu, F = Function, L = Link }

FNAM CHA (100) , { public alias for program

PNAM CHAR (100) , { program name

DESC CHAR (100) NOT NULL, { human description of function

MNUID INTEGER, { parent menu

PRIMARY KEY (ID) CONSTRAINT SYSCMNUPK,

FOREIGN KEY (MNUID) REFERENCES SYSTMNU (ID) CONSTRAINT SYSCMNUFKl,

CHECK (TYP IN CM', 'F', 'L')) CONSTRAINT SYSCMNU1

LOCK MODE ROW, Table 4: User Permissions

CREATE TABLE SYSTUSRP

ID INTEGER NOT NULL, { unique id }

MNUID INTEGER NOT NULL, { menu id }

USRID INTEGER NOT NULL, { user id }

PRM CHAR(l) NOT NULL, { N = No Access, R = Read, F = Full }

PRIMARY KEY (ID) CONSTRAINT SYSCUΞRPPK, UNIQUE (MNUID, USRID) CONSTRAINT SYSCUΞRP1,

FOREIGN KEY(MNUID) REFERENCES ΞYSTMNU(ID) CONSTRAINT SYSCUSRPFKl

) LOCK MODE ROW;

Table 5: Unique IDs

CREATE TABLE SYSTID (

NM CHAR (20) NOT NULL, LSTID INT8 NOT NULL,

PRIMARY KEY(NM) ) LOCK MODE ROW;

Table 6: Authorization Responses

CREATE TABLE N 0TCDRSP (

ID INTEGER NOT NULL, DESC CHAR (20) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 7: Application Status

CREATE TABLE N₃0TCDAST

ID INTEGER NOT NULL , DESC CHA (20) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 8: Payment Terms

CREATE TABLE N₃0TCDPMT

(

ID INTEGER NOT NULL, DESC CHAR (20) NOT NULL, FEE DECIMAL ( 8, 4) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 9: Transaction Types

CREATE TABLE N₃0TCDTRN

ID INTEGER NOT NULL, DESC CHAR (20) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 10: Transaction Detail Types

CREATE TABLE N₃0TCDTRND

ID INTEGER NOT NULL,

DESC CHAR (50) NOT NULL,

BADJ MONEY (1 , 2) NOT NULL ,

CADJ MONEY ( 14 , 2 ) NOT NULL ,

PRIMARY KEY (ID) UNIQUE (DESC) ) LOCK MODE ROW;

Table 11: Industry Codes CREATE TABLE N30TCDIND

ID INTEGER NOT NULL, DESC CHA (50) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 12: US State Codes

CREATE TABLE N30TCDUSS

CD CHAR (2) NOT NULL, DESC CHAR (20) NOT NULL,

PRIMARY KEY (CD) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 13: ISO 3166 Country Codes

CREATE TABLE N30TCD3166

(

CD CHAR (2) NOT NULL,

DESC CHAR (20) NOT NULL,

PRIMARY KEY (CD) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 14: Contact Type Codes

CREATE TABLE N30TCDCON

ID INTEGER NOT NULL,

DESC CHAR (20) NOT NULL,

PRI CHAR(l) NOT NULL CHECK (PRI IN CY' , 'N') ) , PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 15: Card Status

CREATE TABLE N30TCDCHCS

(

ID INTEGER NOT NULL, DESC CHAR (20) NOT NULL, AUTH CHAR(l) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 16: Credit Status

CREATE TABLE N30TCDCHΞ

(

ID INTEGER NOT NULL, DESC CHAR (20) NOT NULL, AUTH CHAR(l) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW;

Table 17: Credit Application

CREATE TABLE N30TAPP

(

ID INTEGER NOT NULL,

CH CHARACTER (1) ,

EMAIL CHARACTER (30) ,

FNAM CHARACTER (30 ) ,

LNAM CHARACTER (30) ,

MNAM CHARACTER (30),

CPNAM CHARACTER (40 ) , PHO CHARACTER (20 ) ,

FAX CHARACTER (20) ,

ADR1 CHARACTER (30),

ADR2 CHARACTER (30 ) ,

ADR3 CHARACTER (30),

CTY CHARACTER (25),

ST CHARACTER (2 ) ,

ZIP CHARACTER ( 10) ,

CTRY CHARACTER (2 ) , BFNAM CHARACTER (30) , BLNAM CHARACTER (30) , BPHN CHARACTER (20 ) ,

BADR1 CHARACTER (30) ,

BADR2 CHARACTER (30) ,

BADR3 CHARACTER (30) ,

BCTY CHARACTER (25) ,

BST CHARACTER (2 ) ,

BZIP CHARACTER ( 10 ) ,

BCTRY CHARACTER (2 ) ,

OFF CHARACTER (30),

OFFT CHARACTER (30),

CON CHARACTER (30) , CDINDID INTEGER NOT NULL,

DUNS CHARACTER (20) ,

DBA CHARACTER (30) ,

PCPY CHARACTER (30) ,

TAXID CHARACTER ( 20 ) ,

ASLS CHARACTER (20) ,

EDATE CHARACTER (20) ,

LOCΞ CHARACTER (5) ,

EMPS CHARACTER (5) ,

TBUS CHARACTER (20),

BKNAM CHARACTER (30) ,

BKCON CHARACTER (30) ,

BKADR CHARACTER (40) ,

BKCTY CHARACTER ( 25 ) , BKST CHARACTER ( 2 ) ,

BKZIP CHARACTER (10) ,

BKPHO CHARACTER ( 20 ) ,

CKGNUM CHARACTER (20),

ΞAVNUM CHARACTE (20) ,

TR1NAM CHARACTER (30),

TR1ADR CHARACTER (40) ,

TR1CTY CHARACTE (25) ,

TR1ST CHARACTER ( 2 ) ,

TR1ZIP CHARACTER (10) ,

TR2NAM CHARACTER (30),

TR2ADR CHARACTER (40) ,

TR2CTY CHARACTER (25) ,

TR2ST CHARACTER ( 2 ) ,

TR2ZIP CHARACTER ( 10 ) ,

SGI CHARACTER (1) ,

ΞG2 CHARACTER ( 1 ) ,

APPDT DATETIME YEAR TO SECOND

MAIL CHARACTER(l) ,

FINFO CHARACTER ( 1) ,

EINFO CHARACTER(l) ,

STAT CHARACTER (20) ,

ACCID INTEGER, account assigned or null

ACCGID INTEGER, guarantor account }

LDT DATE , limit date }

LAMT DECIMAL (14, 2) , limit amount }

LSRC CHAR(25), limit source }

GFEE DECIMAL (8, 4) , guarantor fee }

GCST CHAR (25), guarantor customer id }

ACCAID INTEGER, association }

AFEE DECIMAL (8 , 4 ) , association fee }

CNAM1 CHAR (35),

CNUM1 CHA (16) ,

CNAM2 CHAR(35),

CNUM2 CHAR (16),

CNAM3 CHAR (35) , CNUM3 CHAR (16),

SRC CHA (25) NOT NULL, { source SNTDTTM DATETIME YEAR TO SECOND,

RSPDTTM DATETIME YEAR TO SECOND,

PRIMARY KEY (ID) ) lock mode row,

Table 18: NE T30/Accounts

CREATE TABLE N30TACC

ID INTEGER NOT NULL, { account id TYP CHAR(l) NOT NULL, { account type CDINDID INTEGER NOT NULL, { industry code TAXID CHAR(1 ) , { federal tax id o vat } CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create datetime

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change datetime

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CACCPK,

CHECK (TYP IN ('A' , 'C , 'F' , 'G' , 'I' , 'M' ) ) CONSTRAINT N30CACC1 ) LOCK MODE ROW,

Table 19: NET30/Account Names

CREATE TABLE N30TACCNAM

ID INTEGER NOT NULL, { name id }

ACCID INTEGER NOT NULL, { account id }

PRI CHAR(l) NOT NULL, { Y/N, N = DBA }

NAM CHAR (100) NOT NULL, { name } CNAM CHAR (100)

DEFAULT "NOT DONE" NOT NULL, (compress name

-- TODO: constraint to make sure there is one primary and zero or more non-primary.

PRIMARY KEY (ID) CONSTRAINT N₃0CACCNAMPK,

FOREIGN KEY (ACCID) REFERENCES N₃0TACC (ID) CONSTRAINT N₃0ACCNAMFK1 ,

CHECK (PRI IN CY', 'N')) CONSTRAINT N30ACCNAM1 ) LOCK MODE ROW,

CREATE INDEX N30IACCNAM1 ON N30TACCNAM (NAM, ACCID) ; CREATE INDEX N30IACCNAM2 ON N30TACCNAM (CNAM) ;

Table 20: NET30/Account Contacts

CREATE TABLE N30TACCCON

ID INTEGER NOT NULL, contact id }

ACCID INTEGER NOT NULL, account id }

CDCONID INTEGER NOT NULL, contact type }

LNM CHAR(25) , last name }

FNM CHAR(25) , first name }

MNM CHAR(25) , middle name }

JOB CHAR(40) , ₃ob title }

DPT CHAR (40), department }

URL CHAR(IOO) , www url }

EML CHAR(80) , email address }

PHN CHAR(20) , voice phone }

FAX CHAR(20) , fax number }

MBL CHAR(20) , mobile phone }

PGR CHAR (20), pager number }

NTS CHAR(IOOO) , notes }

ATTN CHAR(40) , attn: line }

ADDR1 CHAR(40) , address 1 }

ADDR2 CHAR(40) , address 2 }

ADDR3 CHAR(40) , address 3 }

STCODID CHAR(2) , state code }

CYCODID CHAR (2), { country code

-- TODO: Need FK constraints on codes.

PRIMARY KEY (ID) CONSTRAINT N30CACCCONPK,

FOREIGN KEY (ACCID) REFERENCES N30TACC (ID) CONSTRAINT N30CACCCONFK1 ) LOCK MODE ROW; CREATE UNIQUE INDEX N30IACCCON ON N30TACCCON (ACCID, CDCONID) ;

Table 21: NET30/Account Balances

CREATE TABLE N 0TACCBAL

ID INT8 NOT NULL, { unique id }

YR INTEGER NOT NULL, { year, 2000... }

PD INTEGER NOT NULL, { period }

ACCID INTEGER NOT NULL, { account id }

BBL MONEY (14,2) NOT NULL, { current pd beg balance }

EBL MONEY (14,2) NOT NULL, { current/ending balance }

CBBL MONEY (14,2) NOT NULL, { pd beg auth balance }

CEBL MONEY (14,2) NOT NULL, { current/ending auth bal }

PRIMARY KEY (ID) , UNIQUE (YR, PD, ACCID) ,

FOREIGN KEY (ACCID) REFERENCES N30TACC (ID) CONSTRAINT N₃0CACCBALFK1 ) LOCK MODE ROW;

Table 22: NET30/Account Audit History

CREATE TABLE N30TACCAUD

(

ID INT8 NOT NULL , { id

ACCID INTEGER NOT NULL , { account number

ATTR CHAR ( 20 ) NOT NULL , { attribute

OVAL CHAR ( 20 ) NOT NULL , { old value

NVAL CHA ( 20 ) NOT NULL , { new value

CRTUSRID CHAR (15) NOT NULL, { create user id }

CRTDTTM DATETIME { create datetime } YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server } CRTCLNT CHAR (15) NOT NULL, { create client } CHGUSRID CHA (15) NOT NULL, { change by user } CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL, CHGSRVR CHA (15) NOT NULL, { change server } CHGCLNT CHAR (15) NOT NULL, { change client }

PRIMARY KEY (ID) CONSTRAINT N30CACCAUDPK,

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCAUDFK1 ) LOCK MODE ROW;

Table 23: NET30/Merchant Account Master

CREATE TABLE N30TACCM (

ID INTEGER NOT NULL, { account id

STDT DATE ,

PRIMARY KEY (ID) , FOREIGN KEY (ID) REFERENCES N30TACC(ID) ) LOCK MODE ROW;

Table 24: Networks

CREATE TABLE N30TNTWRK

(

ID INTEGER NOT NULL, { unique id NAM CHAR (20) NOT NULL, { network name

CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create datetime

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change datetime

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, change server } CHGCLNT CHA (15) NOT NULL, change client }

PRIMARY KEY (ID) CONSTRAINT N30CNTWRKPK ) LOCK MODE ROW;

Table 25: Merchant Terminals

CREATE TABLE N30TACCMTRM

(

ID INTEGER NOT NULL, { unique id ACCMID INTEGER NOT NULL, { merchant id NTWRKID INTEGER NOT NULL, { network id TRMADDR CHAR (20) NOT NULL, { terminal address ACT CHAR(l) NOT NULL,

CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create datetime

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change datetime

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CACCMTRMPK, UNIQUE (NTWRKID, TRMADDR) CONSTRAINT N30CACCMTRM2 , FOREIGN KEY (ACCMID) REFERENCES N30TACCM (ID) , FOREIGN KEY (NTWRKID) REFERENCES N30TNTWRK (ID) ) LOCK MODE ROW;

Table 26: NE I^'30/Guarantor Account Master

CREATE TABLE N30TACCG

ID INTEGER NOT NULL, { account id MIN MONEY (14, 2) NOT NULL, PRIMARY KEY (ID) , FOREIGN KEY (ID) REFERENCES N30TACC1ID) ) LOCK MODE ROW,

Table 27: NET30/Association Account Master

CREATE TABLE N30TACCA

ID INTEGER NOT NULL, { account id SRC CHAR (20) NOT NULL,

PRIMARY KEY (ID) ,

FOREIGN KEY (ID) REFERENCES N30TACC(ID) ) LOCK MODE ROW;

Table 28: NET30/Issuer Account Master

CREATE TABLE N30TACCI (

ID INTEGER NOT NULL, { account id ATR CHAR (10) NOT NULL,

PRIMARY KEY ( ID) ,

FOREIGN KEY ( ID) REFERENCES N30TACC ( ID ) ) LOCK MODE ROW ;

Table 29: NET30/Card Holder Account Master

CREATE TABLE N30TACCCH

ID INTEGER NOT NULL, { account id

GACCID INTEGER NOT NULL, { guarantor accid

GCID CHAR(20) , { guarantor cust id

GFEE DECIMAL (6, ) NOT NULL, { guarantor fee %

CDCHSID INTEGER NOT NULL, { credit status

AACCID INTEGER, { assoc acct id

AFEE DECIMAL (6, 4) , { assoc fee %

LAMT MONEY (14,2) , { limit amt

LDT DATE , { limit date LΞRC CHAR (20) , { limit source SRC CHAR(20), { cr line source

PRIMARY KEY (ID) CONSTRAINT N30CACCCHPK,

FOREIGN KEY (ID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHFK1 , FOREIGN KEY (GACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHFK2 , FOREIGN KEY (AACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHFK3

) LOCK MODE ROW;

--CREATE UNIQUE INDEX N30IACCCH1 ON N30TACCCH (GACCID, GCID) ;

Table 30: NET30/Card Holder Cards

CREATE TABLE N30TACCCHC

(

ID INTEGER NOT NULL, { card id} CNUM INT8 NOT NULL, { card number ACCID INTEGER NOT NULL, { account id NM CHAR (50) NOT NULL, { name on card IDT DATE NOT NULL, { issue date EDT DATE NOT NULL, { expire date CDCHCSID INTEGER NOT NULL, { card status PIN CHAR (15) , { pin code or null ACCCHCBID INTEGER, { card batch or null }

PRIMARY KEY (ID) CONSTRAINT N30CACCCHCPK,

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHCFK1,

UNIQUE (CNUM) CONSTRAINT N30CACCCHC3 ) LOCK MODE ROW; CREATE UNIQUE INDEX N30IACCCHC1 ON N30TACCCHC (ACCID, ID) ;

Table 31: NET30/Card Holder Credit Limit History

CREATE TABLE N30TACCCHL

ID INT8 NOT NULL, {unique id }

ACCID INTEGER NOT NULL, { account id

LAMT MONEY (14,2), { limit amt

LDT DATE , { limit date

LSRC CHAR (20) , { limit source CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create datetime

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change datetime

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N 0CACCCHLPK,

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHLFK1 ) LOCK MODE ROW,

I able 32: NET30/Card Holder Authorization Attempts

(Logs failed or successful attempt to authorize against a card Only APPROVhD authorizations make it into the transaction table)

CREATE TABLE N30TACCCHA

ID INT8 NOT NULL, { AUTH id }

ACCCHID INTEGER, [ card holder }

ACCCHCID INTEGER, [ card }

CNUM CHAR (16), [ card number entered }

ACCMID INTEGER NOT NULL, { merchant -- maybe invalid, but req }

DOC CHAR (20), { po, mv, etc }

DTTM DATETIME { actual date/time

YEAR TO SECOND NOT NULL,

CDRSPID INTEGER NOT NULL, { auth response }

ACCTRNID INT8 NOT NULL, {auth tran id }

CRBAL MONEY (14,2) , {avail cr }

NAM CHAR (35), { name on card }

EXP CHAR (10), { expiration given }

CRTUSRID CHAR(15) NOT NULL, { create user id } CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL,

CRTSRVR CHAR (15) NOT NULL, { create server } CRTCLNT CHAR (15) NOT NULL, create client } CHGUSRID CHAR (15) NOT NULL, change by user } CHGDTTM DATETIME change datetime }

YEAR TO SECOND NOT NULL,

CHGSRVR CHAR (15) NOT NULL, change server } CHGCLNT CHAR (15) NOT NULL, change client }

PRIMARY KEY (ID) CONSTRAINT N30CACCCHAPK ) LOCK MODE ROW;

Table 33: NET30/Account Transaction Master Table

(Describes a single authorization invoice receipt, payment receipt, merchant check, promotional, balance adjustment, etc )

CREATE TABLE N30TACCTRN

ID INT8 NOT NULL, { tran id }

CDTRNID INTEGER NOT NULL, { transaction type }

YR INTEGER NOT NULL, { year }

PD INTEGER NOT NULL, { period }

GRP INT8 NOT NULL, { group id

ACCCHID INTEGER NOT NULL, { card holder

ACCCHCID INTEGER NOT NULL, { card

ACCMID INTEGER NOT NULL, { merchant

AMT MONEY (14, 2) NOT NULL, { amount

DOC CHAR (20), { po, mv, chk#, etc

DTTM DATETIME { actual date/time

YEAR TO SECOND NOT NULL,

CDPMTID INTEGER NOT NULL, { terms

ACCGSLID INT8, { sales batch id

CRTUSRID CHAR (15) NOT NULL, { create user id } CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server } CRTCLNT CHAR (15) NOT NULL, { create client } CHGUSRID CHAR (15) NOT NULL, { change by user } CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server } CHGCLNT CHAR (15) NOT NULL, { change client }

PRIMARY KEY ( ID) CONSTRAINT N30CACCTRNPK ) LOCK MODE ROW; CREATE INDEX N30 IACCTRN1 ON N30TACCTRN (CRTDTTM , CDTRNID) ;

Table 34: NET30/Λccount Transaction Detail

CREATE TABLE N30TACCTRND

ID INT8 NOT NULL, { tran id YR INTEGER NOT NULL, { year

PD INTEGER NOT NULL, { period ACCID INTEGER NOT NULL, { account id ACCTRNID INT8 NOT NULL, {paren tran CDTRNDID INTEGER NOT NULL, {tran type DTTM DATETIME { tran timestamp

YEAR TO SECOND NOT NULL AMT MONEY (14,2) NOT NULL , { tran amount EBL MONEY (14,2) NOT NULL, { new bal amount CEBL MONEY (14,2) NOT NULL, { new cr bal amt STMT INT8 NOT NULL, { statement id

CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create datetime

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change datetime

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CACCTRNDPK,

FOREIGN KEY (ACCTRNID) REFERENCES N30TACCTRN (ID) CONSTRAINT N30CACCTRNDFK1 ) LOCK MODE ROW;

Table 35: CREATE TABLE N30TACCS

ID INT8 NOT NULL, stmt id

ACCSBID INTEGER NOT NULL, stmt batch id

FRDT DATE NOT NULL, from date

THDT DATE NOT NULL, through date

ACCID INTEGER NOT NULL, account id

BBL MONEY (14, 2) NOT NULL, beg bal

CBB MONEY (14, 2) NOT NULL, beg cr bal

EBL MONEY (14, 2) NOT NULL, end bal

CEBL MONEY (14, 2) NOT NULL, end cr bal

LAMT MONEY (14, 2) , cr limit if ch

AVL MONEY (14, 2), available cr bal

CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create datetime

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change datetime

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CACCSPK,

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCSFK1 ) LOCK MODE ROW;

VIEW: NET30/Card Holder Fees

CREATE VIEW N30VACCCH1 AS

SELECT ID, GACCID, GFEE, AACCID, AFEE

FROM N30TACCCH; VIEW: NET30/Transaction Detail → Statement create view n30vacctrndl as select det.yr, det.pd, det.accid, det .acctrnid, det id, det dttm, det.amt as damt, det.ebl, det.cebl, ddsc.desc as ddesc, det stmt, ddsc. bad], ddsc cad₃ , chnam nam as chnam, crd.cnum, mernam.nam as mernam, trn amt as tamt, trn.doc, trn. dttm as tdttm, tdsc desc as tdesc from n30tacctrnd as det, n30tcdtrnd as ddsc, n30tacctrn as trn, n30tcdtrn as tdsc, outer n30taccnam as chnam, outer n₃0taccnam as mernam, outer n₃0taccchc as crd where det . cdtrndid = ddsc. id and det. acctrnid = trn id and trn.cdtrnid = tdsc id and trn.accchid = chnam accid and chnam. ri = ' Y¹ and trn.accmid = mernam. accid and mernam. pri = 'Y' and trn accchcid = crd id

Table 36: Guarantor Sales Batch

CREATE TABLE N30TACCGSL

ID INT8 NOT NULL, { UNIQUE ID }

ACCGID INTEGER NOT NULL, { GUARANTOR ACCOUNT ID } SIZ INTEGER NOT NULL, { DETAIL ITEM COUNT } CRB CHAR ( 1 ) { credit/debit batch }

CHECK (CRB IN ( 'Y' 'N') ) ,

TXDTTM DATETIME { TRANSMIT DATETIME }

YEAR TO SECOND,

CRTUSRID CHAR (15) NOT NULL, { create user id } CRTDTTM DATETIME { create datetime } YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, create server } CRTCLNT CHAR (15) NOT NULL, create client } CHGUSRID CHAR (15) NOT NULL, change by user } CHGDTTM DATETIME change datetime }

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, change server } CHGCLNT CHAR (15) NOT NULL, change client }

PRIMARY KEY (ID) CONSTRAINT N30CACCGSLPK,

FOREIGN KEY(ACCGID) REFERENCES N30TACCG(ID) CONSTRAINT N30CACCGSLFK1

Table 37: Card Batch Statuses

CREATE TABLE N30TCDCHCB (

ID INTEGER NOT NULL, DESC CHAR (20) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW,

Table 38: Card Printing/Embossing Batches

CREATE TABLE N30TACCCHCB

ID INTEGER NOT NULL, { unique id }

CDCHCBID INTEGER NOT NULL, { batch status } CNT INTEGER NOT NULL, { number of cards }

SELDTTM DATETIME { select timestamp }

YEAR TO SECOND, RCVDTTM DATETIME { receiv timestamp }

YEAR TO SECOND, CRTUSRID CHAR (15) NOT NULL, { create user id } CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server } CRTCLNT CHAR (15) NOT NULL, { create client } CHGUSRID CHAR (15) NOT NULL, { change by user } CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL,

CHGSRVR CHAR (15) NOT NULL, { change server } CHGCLNT CHAR (15) NOT NULL, { change client }

PRIMARY KEY (ID) CONSTRAINT N30CACCCHCBPK

) LOCK MODE ROW;

Table 39: Card Holder Application

CREATE TABLE N30TAPPCH

ID INTEGER NOT NULL,

FNAM CHARACTER (30 ) NOT NULL,

LNAM CHARACTER ( 30 ) NOT NULL,

MNAM CHARACTER (30),

CPNAM CHARACTER (40) NOT NULL,

ADR1 CHARACTER ( 30 ) NOT NULL,

ADR2 CHARACTER (30 ) ,

ADR3 CHARACTER (30) ,

CTY CHARACTER (25) NOT NULL,

ST CHARACTER (2) NOT NULL,

ZIP CHARACTER (10) NOT NULL,

CTRY CHARACTER (2 ) ,

PHO CHARACTER (20) NOT NULL,

FAX CHARACTER (20),

EMAIL CHARACTER (30),

BADR1 CHARACTER (30) NOT NULL,

BADR2 CHARACTER (30) ,

BADR3 CHARACTER (30) ,

BCTY CHARACTER (25) NOT NULL,

BST CHARACTER (2) NOT NULL,

BZIP CHARACTER(IO) NOT NULL,

BCTRY CHARACTER (2 ) , OFF CHARACTER (30) NOT NULL, OFFT CHARACTER ( 30 ) NOT NULL, CON CHARACTER ( 30 ) NOT NULL, CONT CHARACTER (30) NOT NULL, CDINDID INTEGER NOT NULL, LOCΞ INTEGER NOT NULL, DUNS CHARACTER (20) , DBA CHARACTER (30) , PCPY CHARACTER (30) , TAXID CHARACTER (20) ,

ASLS INTEGER NOT NULL, EDATE CHARACTER (20) NOT NULL, EMPS INTEGER NOT NULL, CNA 1 CHARACTER (35) NOT NULL, CNUM1 CHARACTER (16) ,

CNAM2 CHARACTER (35) , CNUM2 CHARACTER (16) , CNAM3 CHARACTER (35) , CNUM3 CHARACTER (16) , BKNAM CHARACTER (30) ,

BKCON CHARACTER (30) , BKADR CHARACTER (40) , CKGNUM CHARACTER (20) , BKCTY CHARACTER (25) , BKST CHARACTER (2) ,

BKZIP CHARACTER (10) , BKPHO CHARACTER (20) , BKCTRY CHARACTER (2) , SAVNUM CHARACTER (20) , B1NAM CHARACTER ( ₃0 ) ,

B1PHN CHARACTER (20) , B1ADR1 CHARACTER (30) , B1ADR2 CHARACTER (30) , B1ADR3 CHARACTER (30) , B1CTY CHARACTER (25) , BIST CHARACTER (2) , B1ZIP CHARACTER (10) ,

B1CTRY CHARACTER (2) ,

B2NAM CHARACTER (30) ,

B2PHN CHARACTER (20) ,

B2ADR1 CHARACTER (30) ,

B2ADR2 CHARACTER (30) ,

B2ADR₃ CHARACTER (30) ,

B2CTY CHARACTER (25) ,

B2ST CHARACTER (2 ) ,

B2ZIP CHARACTER (10) ,

B2CTRY CHARACTER (2) ,

SIG1 CHARACTER (1) NOT NULL CHECK (SIG1 IN CY' 'N' ) :

APPDT DATETIME YEAR TO SECOND,

CDAST INTEGER NOT NULL,

ACCCHID INTEGER, { account assigned or null }

ACCGID INTEGER, { guarantor account }

LDT DATE, { limit date }

LAMT DECIMAL (14, 2) { limit amount }

LSRC CHARACTER (25) { limit source }

GFEE DECIMAL (8, 4), { guarantor fee }

GCST CHARACTER (25 ) , { guarantor customer id

ACCAID INTEGER, { association }

AFEE DECIMALI8 ,4), { association fee }

SRC CHARACTER (25) NOT NULL, { source }

SNTDTTM DATETIME YEAR TO SECOND,

RSPDTTM DATETIME YEAR TO SECOND,

CRTUSRID CHA (15) NOT NULL, { create user id }

CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL,

CRTSRVR CHARACTER (15) NOT NULL, { create server } CRTCLNT CHARACTER (15) NOT NULL, { create client } CHGUSRID CHARACTER (15) NOT NULL, { change by user } CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL,

CHGSRVR CHARACTER (15) NOT NULL, { change server } CHGCLNT CHARACTER (15) NOT NULL, { change client } PRIMARY KEY ( ID) ) lock mode row,-

Table 40: Merchant Agreement

CREATE TABLE N30TAPPM

ID INTEGER NOT NULL,

CPNAM CHARACTER (40) NOT NULL,

ADR1 CHARACTER (30) NOT NULL,

ADR2 CHARACTER (30),

ADR3 CHARACTER (30),

CTY CHARACTER (25) NOT NULL,

ST CHARACTER (2) NOT NULL,

ZIP CHARACTER (10) NOT NULL,

CTRY CHARACTER (2 ) ,

PHO CHARACTER (20) NOT NULL,

FAX CHARACTER (20),

MADR1 CHARACTER (30),

MADR2 CHARACTER (30),

MADR3 CHARACTER (30 ) ,

MCTY CHARACTER ( 25 ) ,

MST CHARACTER (2 ) ,

MZIP CHARACTER (10) ,

MCTRY CHARACTER (2 ) ,

TAXID CHARACTER (20) ,

CDINDID INTEGER NOT NULL,

PFNAM CHARACTER (30) NOT NULL,

PLNAM CHARACTER (30) NOT NULL,

PMNAM CHARACTER (30 )

PADR1 CHARACTER (30 )

PADR2 CHARACTER (30),

PADR3 CHARACTER (30)

PCTY CHARACTER (25)

PΞT CHARACTER (2 ) ,

PZIP CHARACTER (10) , PCTRY CHARACTER ( 2 ) ,

PPHO CHARACTER (20) ,

PEMAIL CHARACTER (30 ) ,

AFNAM CHARACTER (30 ) ,

ALNAM CHARACTER (30),

AADR1 CHARACTER (30 ) ,

AADR2 CHARACTER (30 ) ,

AADR3 CHARACTER (30) ,

ACTY CHARACTER (25),

AST CHARACTER (2) ,

AZIP CHARACTER ( 10 ) ,

ACTRY CHARACTER (2 ) ,

APHO CHARACTER (20),

SIGl CHARACTER(l) NOT NULL CHECK (SIGl IN CY¹, 'N'

SRC CHARACTER (25) NOT NULL, { source }

APPDT DATETIME YEAR TO SECOND,

CDAST INTEGER NOT NULL,

ACCMID INTEGER, { account assigned or null }

CRTUSRID CHAR (15) NOT NULL, { create user id }

CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL,

CRTSRVR CHAR (15) NOT NULL, { create server }

CRTCLNT CHAR (15) NOT NULL, { create client }

CHGUSRID CHAR (15) NOT NULL, { change by user }

CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL,

CHGSRVR CHAR (15) NOT NULL, { change server }

CHGCLNT CHAR (15) NOT NULL, { change client }

PRIMARY KEY (ID)

) lock mode row;

Table 41: NE 130/Card Holder Line Request Statuses

CREATE TABLE N30TCDCHLPS

ID INTEGER NOT NULL , DESC CHAR (20) NOT NULL,

PRIMARY KEY (ID) , UNIQUE (DESC) ) LOCK MODE ROW,

Table 42: NET30/Card Holder Line Requests

CREATE TABLE N30TACCCHLR

ID IN 8 NOT NULL, { request id} ACCGID INTEGER NOT NULL, { guarantor } ACCCHID INTEGER NOT NULL, { card holder id } RQAMT DECIMAL (14, 2) NOT NULL, { requested amount, possibly zero } SNTDTTM DATETIME YEAR TO SECOND, { timestamp sent to guarantor } RSPDTTM DATETIME YEAR TO SECOND, { timestamp received from guarantor } RΞPAMT DECIMAL (14, 2) , { amount approved } CDCHLRSID INTEGER, { response code from guarantor - our own code }

PRIMARY KEY (ID) CONSTRAINT N30CACCCHLRPK,

FOREIGN KEY (ACCGID) REFERENCES N30TACCG(ID) CONSTRAINT N30CACCCHLRFK1 , FOREIGN KEY (ACCCHID) REFERENCES N30TACCCH (ID) CONSTRAINT N30CACCCHLRFK2 , FOREIGN KEY (CDCHLRSID) REFERENCES N30TCDCHLRS ( ID) CONSTRAINT N30CACCCHLRFK3 ) LOCK MODE ROW,

Table 43: References

CREATE TABLE N30TACCREF

ID INTEGER NOT NULL,

ACCID INTEGER NOT NULL,

LOCS INTEGER NOT NULL,

DUNS CHARACTER (20) ,

PCPY CHARACTER (30) ,

ASLS INTEGER NOT NULL,

EDATE CHARACTER (20) NOT NULL,

EMPΞ INTEGER NOT NULL,

BKNAM CHARACTER (30) ,

BKCON CHARACTER (30) , BKADR CHARACTER (40) ,

CKGNUM CHARACTER (20) ,

BKCTY CHARACTER ( 25 ) ,

BKST CHARACTER (2) ,

BKZIP CHARACTER ( 10 ) ,

BKPHO CHARACTER (20 ) ,

BKCTRY CHARACTER (2 ) ,

SAVNUM CHARACTER (20 ) ,

B1NAM CHARACTER (30) ,

B1PHN CHARACTER (20) ,

B1ADR1 CHARACTER (30) ,

B1ADR2 CHARACTER (30),

B1ADR3 CHARACTER (30 ) ,

B1CTY CHARACTER ( 25 ) ,

BIST CHARACTER (2) ,

B1ZIP CHARACTER ( 10 ) ,

B1CTRY CHARACTER ( 2 ) ,

B2NAM CHARACTER (30 ) ,

B2PHN CHARACTER (20) ,

B2ADR1 CHARACTER ( 30 ) ,

B2ADR2 CHARACTER (30),

B2ADR3 CHARACTER (30) ,

B2CTY CHARACTER (25) ,

B2ST CHARACTER ( 2 ) ,

B2ZIP CHARACTER (10) ,

B2CTRY CHARACTER (2 ) ,

CRTUSRID CHAR (15) NOT NULL, { create user id

CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL,

CRTSRVR CHARACTER (15) NOT NULL, { create server }

CRTCLNT CHARACTER (15) NOT NULL, { create client }

CHGUSRID CHARACTER ( 15 ) NOT NULL, { change by user }

CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL,

CHGSRVR CHARACTER (15) NOT NULL, { change server }

CHGCLNT CHARACTE (15) NOT NULL, { change client } PRIMARY KEY (ID) CONSTRAINT N30CACCREFPK,

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCREFFK1 ) lock mode row;

Table 44:

CREATE TABLE N30TACCSB

ID INTEGER NOT NULL,

PRTDT DATE,

THDT DATE NOT NULL, { through date

CRTUSRID CHAR (15) NOT NULL, { create user id }

CRTDTTM DATETIME { create datetime }

YEAR TO SECOND NOT NULL,

CRTSRVR CHARACTER (15) NOT NULL, { create server }

CRTCLNT CHARACTER (15) NOT NULL, { create client }

CHGUSRID CHARACTER (15) NOT NULL, { change by user }

CHGDTTM DATETIME { change datetime }

YEAR TO SECOND NOT NULL,

CHGSRVR CHARACTER (15) NOT NULL, { change server }

CHGCLNT CHARACTER(15) NOT NULL, { change client }

PRIMARY KEY (ID) CONSTRAINT N30CACCSBPK ) lock mode row;

VIEW: NET30/Card Holder Line Requests

CREATE VIEW N30VACCCHLR1 ( ID , ACCCHID) AS

SELECT MAX ( ID) , ACCCHID

FROM

N30TACCCHLR

GROUP BY

ACCCHID;

Expand SYSTID.NM

ALTER TABLE SYSTID MODIFY NM CHAR (20) ;

Table 45: Sales Status CREATE TABLE N30TCDSLSST (

ID INTEGER DEFAULT 10 NOT NULL, DESC CHAR (30) NOT NULL,

PRIMARY KEY (ID) CONSTRAINT N30CCDSLSSTPK,

UNIQUE (DESC) CONSTRAINT N30CCDSLSST1 ) LOCK MODE ROW, INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TCDSLSST" , 30),

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (10, "New Lead"),

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (20, "Waiting on Agreement"),

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (30, "Mail Agreement"),

INSERT INTO N30TCDSLΞΞT (ID, DESC) VALUES (40, "See At Show"), INSERT INTO N30TCDSLSST (ID, DESC) VALUES (50, "Need decision maker"),

INSERT INTO N30TCDΞLΞΞT (ID, DESC) VALUES (60, "Not Interested"),

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (70, "No Answer"),

INSERT INTO N30TCDSLΞST (ID, DESC) VALUES (80, "Other"),

Table 46: Agreement Status

CREATE TABLE N30TCDAGST

ID INTEGER DEFAULT 40 NOT NULL, DESC CHAR (30) NOT NULL,

PRIMARY KEY (ID) CONSTRAINT N30CCDAGSTPK, UNIQUE (DESC) CONSTRAINT N30CCDAGΞT1 ) LOCK MODE ROW,

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TCDAGST" , 30),

INSERT INTO N30TCDAGST (ID, DESC) VALUES (10, "Faxed"),

INSERT INTO N30TCDAGST (ID, DESC) VALUES (20, "Mailed"), INSERT INTO N30TCDAGST (ID, DESC) VALUES (30, "Complete"),

INSERT INTO N30TCDAGST (ID, DESC) VALUES (40, "Not Sent"),

Table 47: App Status Reason CREATE TABLE N30TCDASTR ( ID INTEGER NOT NULL, DESC CHAR (30) NOT NULL,

PRIMARY KEY (ID) CONSTRAINT N30CCDASTRPK, UNIQUE (DESC) CONSTRAINT N30CCDASTR1 ) LOCK MODE ROW;

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TCDASTR" , 30),

INSERT INTO N30TCDASTR (ID, DESC) VALUES (10, "Not interested"); INSERT INTO N30TCDASTR (ID, DESC) VALUES (20, "No such company"); INSERT INTO N30TCDASTR (ID, DESC) VALUES (30, "Duplicate"),

NEW statuses FOR apps

INSERT INTO N30TCDAST (ID, DESC) VALUES (5, "Data quality waiting");

INSERT INTO N30TCDAST (ID, DESC) VALUES (6, "Sales waiting"),

INSERT INTO N30TCDAST (ID, DESC) VALUES (7, "In process") ,

INSERT INTO N30TCDAST (ID, DESC) VALUES (8, "Suspended");

NEW statuses FOR apps

INSERT INTO N30TCDAST (ID, DESC) VALUES (5, "Data quality waiting"), INSERT INTO N30TCDAST (ID, DESC) VALUES (6, "Sales waiting"); INSERT INTO N30TCDAST (ID, DESC) VALUES (7, "In process"); INSERT INTO N30TCDAST (ID, DESC) VALUES (8, "Suspended");

Card Holder Changes

ALTER TABLE N30TAPPCH ADD NTS TEXT, { Comments }

ALTER TABLE N30TAPPCH ADD CDSLSSTID INTEGER; { Sales Status }

ALTER TABLE N30TAPPCH ADD CONSTRAINT FOREIGN KEY (CDSLSSTID) REFERENCES N30TCDSLSST (ID) CONSTRAINT N30CAPPCHFK1 ;

ALTER TABLE N30TAPPCH ADD CDAGΞTID INTEGER; { Agreement Status ALTER TABLE N30TAPPCH ADD CONSTRAINT FOREIGN KEY (CDAGΞTID) REFERENCES N30TCDAGST (ID) CONSTRAINT N30CAPPCHFK2 ,

ALTER TABLE N30TAPPCH ADD CDASTRID INTEGER, { App Status Reason } ALTER TABLE N30TAPPCH ADD CONSTRAINT

FOREIGN KEY (CDASTRID) REFERENCES N30TCDASTR (ID) CONSTRAINT N30CAPPCHFK3 ,

ALTER TABLE N30TAPPCH ADD AGNUSRID INTEGER, { agent systusr id working } ALTER TABLE N30TAPPCH ADD CONSTRAINT

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR (ID) CONSTRAINT N30CAPPCHFK4 ,

ALTER TABLE N30TAPPCH ADD SUSDTTM DATETIME { suspense until datetime } YEAR TO SECOND, ALTER TABLE N30TAPPCH ADD TOPLEAD CHAR(l) DEFAULT 'N'

NOT NULL CHECK (TOPLEAD IN ( ' Y ' , 'N')), { Top Lead Flag }

Merchant Changes

ALTER TABLE N30TAPPM ADD NTS TEXT, { Comments

ALTER TABLE N30TAPPM ADD CDSLSSTID INTEGER, { Sales Status }

ALTER TABLE N30TAPPM ADD CONSTRAINT FOREIGN KEY (CDSLSSTID) REFERENCES N30TCDΞLSST (ID) CONSTRAINT N30CAPPMFK1,

ALTER TABLE N30TAPPM ADD CDAGSTID INTEGER, { Agreement Status }

ALTER TABLE N30TAPPM ADD CONSTRAINT

FOREIGN KEY (CDAGSTID) REFERENCES N30TCDAGΞT (ID) CONSTRAINT N30CAPPMFK2,

ALTER TABLE N30TAPPM ADD CDASTRID INTEGER, { app Status Reason }

ALTER TABLE N30TAPPM ADD CONSTRAINT

FOREIGN KEY (CDASTRID) REFERENCES N30TCDASTR ( ID) CONSTRAINT N30CAPPMFK3,

ALTER TABLE N30TAPPM ADD AGNUSRID INTEGER, { agent systusr id working } ALTER TABLE N30TAPPM ADD CONSTRAINT

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR (ID) CONSTRAINT N30CAPPMFK4,

ALTER TABLE N30TAPPM ADD SUSDTTM DATETIME { suspense until datetime } YEAR TO SECOND, ALTER TABLE N30TAPPM ADD TOPLEAD CHAR(l) DEFAULT 'N'

NOT NULL CHECK (TOPLEAD IN CY', 'N')), { Top Lead Flag

Table 48: Sales History

CREATE TABLE N30TSAHIST (

ID INTEGER NOT NULL, id

AGNUSRID INTEGER NOT NULL, { agents user id } CALLDTTM DATETIME { call date time

YEAR TO SECOND NOT NULL, APPID INTEGER NOT NULL, { application id } CALLTIME INTEGER NOT NULL, { call time in seconds } CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create date time }

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server } CRTCLNT CHAR (15) NOT NULL, { create client } CHGUSRID CHAR(15) NOT NULL, { change by user } CHGDTTM DATETIME { change date time }

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server } CHGCLNT CHAR (15) NOT NULL, { change client }

PRIMARY KEY (ID) CONSTRAINT N3 OCSAHISTPK, FOREIGN KEY (AGNUSRID) REFERENCES ΞYΞTUSR(ID) CONSTRAINT N30CΞAHISTFK1 ) LOCK MODE ROW, INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TSAHIST" , 1000),

Table 49: Sales Scripts

CREATE TABLE N30TSASCRP

(

ID INTEGER NOT NULL, { script id NM CHAR (30) NOT NULL, { script name SCRP TEXT NOT NULL, { script CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create date time YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHA (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change date time

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CSASCRPPK ) LOCK MODE ROW; INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TSASCRP" , 1000),

Table 50: Script Relationships

CREATE TABLE N30TSASCRPREL

ID INTEGER NOT NULL, id

PSASCRPID INTEGER NOT NULL, { parent script id CSASCRPID INTEGER NOT NULL, { child script id

CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create date time

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change date time

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CΞASCRPRELPK, FOREIGN KEY (PSASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N30CSASCRPRELFK1, FOREIGN KEY (CSASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N30CSASCRPRELFK2

) LOCK MODE ROW,

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TSASCRPREL" , 1000), Table 51 : Sales Agent Queue

CREATE TABLE N30TSAQ (

ID INTEGER NOT NULL, { queue id } TYPE CHAR(l) NOT NULL, { 'M' Merchant, ' C Cardholder

}

DESC CHAR (80) NOT NULL, { description } SQL CHAR (300) NOT NULL, { sql statement

SASCRPID INTEGER, script for this queue }

CRTUSRID CHAR (15) NOT NULL, { create user id }

CRTDTTM DATETIME { create date time }

YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHAR (15) NOT NULL, { change by user CHGDTTM DATETIME { change date time

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CSAQPK,

FOREIGN KEY(SASCRPID) REFERENCES N30TSASCRP ( ID) CONSTRAINT N30CSAQFK1,

CHECK (TYPE IN CM¹, 'C')) CONSTRAINT N30CSAQ1 ) LOCK MODE ROW, INSERT INTO SYSTID (NM, LSTID) VALUES ("N30TSAQ", 1000);

Table 52: Sales Agent Assignment

CREATE TABLE N30TSAASGN

ID INTEGER NOT NULL, { id }

AGNUSRID INTEGER NOT NULL, { agent systusr.id SEQ INTEGER NOT NULL, { sequence }

SAQID INTEGER NOT NULL, { queue id CRTUSRID CHAR (15) NOT NULL, { create user id CRTDTTM DATETIME { create date time YEAR TO SECOND NOT NULL, CRTSRVR CHAR (15) NOT NULL, { create server CRTCLNT CHAR (15) NOT NULL, { create client CHGUSRID CHA (15) NOT NULL, { change by user CHGDTTM DATETIME { change date time

YEAR TO SECOND NOT NULL, CHGSRVR CHAR (15) NOT NULL, { change server CHGCLNT CHAR (15) NOT NULL, { change client

PRIMARY KEY (ID) CONSTRAINT N30CSAASGNPK, UNIQUE (AGNUSRID, SEQ) CONSTRAINT N30CSAASGN1,

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR (ID) CONSTRAINT N30CSAASGNFK1, FOREIGN KEY(SAQID) REFERENCES N30TSAQ(ID) CONSTRAINT N30CSAASGNFK2

) LOCK MODE ROW;

INSERT INTO SYSTID (NM , LSTID) VALUES ( "N30TSAASGN" , 1000 ) ;

VIEW: Card Holder Apps Waiting TO be Processed

Notes: Either IN SalcsWaiting status OR Suspended but suspense-until has expired.

CREATE VIEW N30VAPPCH1

AS

SELECT *

FROM N30TAPPCH

WHERE CDAST = 6

OR (CDAST=8 AND SUSDTTM IS NOT NULL AND SUSDTTM < (CURRENT YEAR TO SECOND) )

VIEW: Merchant Apps Waiting

CREATE VIEW N30VAPPM1 AS

SELECT * FROM N30TAPPM WHERE CDAST = 6 OR (CDAST=8 AND SUSDTTM IS NOT NULL AND SUSDTTM < (CURRENT YEAR TO SECOND))

MODIFY constraints ON cards TO allow multiple OF same card NUMBER AS LONG AS FOR different dates

ALTER TABLE N30TACCCHC DROP CONSTRAINT N30CACCCHC3 ;

ALTER TABLE N30TACCCHC ADD CONSTRAINT UNIQUE (CNUM , EDT) CONSTRAINT N30CACCCHC3 ;

ADD NEW card status FOR lost/stolen INSERT INTO N30TCDCHCS (ID, DESC, AUTH) VALUES (30, 'Lost/Stolen', 'N')

VIEW: Merchant Apps Dups

CREATE VIEW N30VAPPM2 (ID) AS

SELECT MAX (ID) FROM N30TAPPM WHERE CDAST = 1 GROUP BY CPNAM;

VIEW: Card Holder Apps Dups

CREATE VIEW N30VAPPCH2 (ID) AS

SELECT MAX (ID) FROM N30TAPPCH WHERE CDAST = 1 GROUP BY CPNAM;

VIEW: East Time Zone Merchant Apps

CREATE VIEW N30VAPPM3

AS

SELECT *

FROM N30TAPPM

WHERE CDAST = 6

AND ST IN

CME' , 'NH' , 'VT' , 'NY' , 'PA' , 'WV' , 'VA' , ' OH ' , ' MI ' , 'IN', ' NC ' , ' SC ' , 'GA' , ' FL' , 'NJ' , 'MA' , ' CT ' , ' DE ' , ' RI ' , ' MD ' , ' PR ' , ' ON ' , ' QB ' , ' NB ' , ' NΞ ' ) ;

VIEW: Central Time Zone Merchant Apps

CREATE VIEW N30VAPPM4 AS

SELECT * FROM N30TAPPM WHERE CDAST = 6

AND ST IN

( 'ND' 'SD' 'MN' 'Wl' 'IA' 'NE' 'IL' 'MS' ' KS' 'OK' 'AL' 'MS' 'LA' 'TX' 'AR' )

VIEW: Mountain Time Zone Merchant Apps CREATE VIEW N30VAPPM5 AS

SELECT *

FROM N30TAPPM

WHERE CDAST = 6

AND ST IN C MT ' , ' ID ' , ' WY ' , ' UT ' , ' CO ' , ' AZ ' , ' NM ' ) ;

VIEW: Pacific Time Zone Merchant Apps

CREATE VIEW N30VAPPM6 AS

SELECT * FROM N30TAPPM WHERE CDAST = 6 AND ST IN ( ' BC ' , ' WA' , ' OR ' , ' CA ' , ' NV ' , ' HI ' , ' AK ' ) ;

VIEW: East Time Zone Card Holder Apps

CREATE VIEW N30VAPPCH3

AS

SELECT *

FROM N30TAPPCH

WHERE CDAST = 6

AND ST IN ( ' ME ' , ' NH ' , ' VT ' , 'NY', ' PA ' , ' WV ' , ' VA ' 'OH' , 'MI' , 'IN' 'MC 'ΞC 'GA' ¹ FL' 'NJ' 'MA' CT' DE' , ' RI ' , ' MD ' , ' PR ' , ' ON ' , ' QB ' , ' NB ' , ' NS ' )

VIEW: Central Time Zone Card Holder Apps

CREATE VIEW N30VAPPCH4 AS SELECT *

FROM N30TAPPCH WHERE CDAST = 6

AND ST IN

( ' ND ' , ' SD ' , ' MN ' , ' Wl ' , ' IA ' , ' NE ' , ' IL ' , ' MS ' , ' KS ' , ' OK ' , ' KY ' , ' TN ' , ' AL ' , ' MS ' , ' LA ' , ' TX ' , ' A ' ) ;

VIEW: Mountain Time Zone Cardholder Apps

CREATE VIEW N30VAPPCH5 AS

SELECT * FROM N30TAPPCH WHERE CDAST = 6 AND ST IN ( ' MT ' , ' ID ' , ' WY ' , ' UT ' , ' CO ' , ' AZ ' , ' NM ' ) ;

VIEW: Pacific Time Zone Card Holder Apps

CREATE VIEW N30VAPPCH6 AS SELECT *

FROM N30TAPPCH

WHERE CDAST = 6

AND ST IN (' BC ' , ' WA ' , ' OR ' , ' CA ' , ' NV ' , ' HI ' , ' AK ' ) ;

Table 53: N30TBDGXREF

CREATE TABLE N30TBDGXREF ( ID INTEGER NOT NULL ,

ACCCHCID INTEGER NOT NULL , BDGID CHAR (50) NOT NULL ,

CRTUSRID CHAR (15) NOT NULL , CRTDTTM DATETIME YEAR TO SECOND NOT NULL , CRTSRVR CHAR (15) NOT NULL , CRTCLNT CHAR (15) NOT NULL , CHGUSRID CHAR (15) NOT NULL ,

CHGDTTM DATETIME YEAR TO SECOND NOT NULL , CHGSRVR CHAR (15) NOT NULL , CHGCLNT CHAR (15) NOT NULL ,

UNIQUE (BDGID) CONSTRAINT " INFORMIX" .N30CBDGXREF1 , PRIMARY KEY (ID) CONSTRAINT " INFORMIX" . N30CBDGXREFPK ) LOCK MODE ROW; ALTER TABLE N30TBDGXREF ADD ACCID INTEGER NOT NULL;

ALTER TABLE N30TBDGXREF ADD EXPDT DATE:

Claims

WHAT IS CLAIMED IS:

1. A method of conducting electronic commerce, the method comprising: receiving an electronic authorization request from a vendor for a payment guarantee, wherein the authorization request identifies a transaction amount between the vendor and a buyer; and electronically transmitting to the vendor a guarantee of payment for the transaction amount, wherein the guarantee is conditional to the occurrence of one or more events.

2. The method of Claim 1, wherein one of the events is receipt of an invoice from the vendor.

3. The method of Claim 1, comprising charging the vendor a transaction fee regardless of the occurrence of the conditions.

4. The method of Claim 3, wherein the transaction fee is based at least in part upon either the transaction fee or a payment due date.

5. The method of Claim 1, additionally comprising: receiving an invoice from the seller, wherein the invoice identifies an actual transaction amount of a transaction between the buyer and the seller; and storing the actual transaction amount in a database.

6. The method of Claim 1 , additionally comprising transmitting the invoice to a guarantor.

7. The method of Claim 1 , additionally comprising determining whether to guarantee payment.

8. The method of Claim 1 , wherein determining whether to guarantee payment is based at least in part upon a credit limit of the buyer.

9. The method of Claim 1, additionally comprising: receiving an invoice from the seller, wherein the invoice identifies a payment due date; and determining, based at least in part upon the due date, a fee that is due by the seller.

10. The method of Claim 9, additionally comprising: receiving payment from the buyer; and sending payment to the vendor subsequent to subtracting the determined fee.

1 1. The method of Claim 1 , wherein the guaranteeing payment comprises insuring payment by the seller.

12. The method of Claim 1 , wherein guaranteeing payment comprises purchasing a receivable from the vendor.

13. A system for conducting electronic commerce, the system comprising: means for receiving an electronic authorization request from a vendor for a payment guarantee, wherein the authorization request identifies a transaction amount between the vendor and a buyer; and means for electronically transmitting to the vendor a guarantee of payment for the transaction amount, wherein the guarantee is conditional to the occurrence of one or more events.

14. The system of Claim 13, wherein one of the events is receipt of an invoice from the vendor.

15. The system of Claim 13, comprising means for charging the vendor a transaction fee regardless of the occurrence of the conditions.

16. The system of Claim 15, wherein the transaction fee is based at least in part upon either the transaction fee or a payment due date.

17. The system of Claim 13, additionally comprising: means for receiving an invoice from the seller, wherein the invoice identifies an actual transaction amount of a transaction between the buyer and the seller; and means for storing the actual transaction amount in a database.

18. The system of Claim 13, additionally comprising means for transmitting the invoice to a guarantor.

19. The system of Claim 13, additionally comprising means for determining whether to guarantee payment.

20. The method of Claim 13, wherein the means for determining whether to guarantee payment reads a credit limit of the buyer from a database.

21. The system of Claim 13, additionally comprising: means for receiving an invoice from the seller, wherein the invoice identifies a payment due date; and means for determining, based at least in part upon the due date, a fee that is due by the seller.

22. The system of Claim 21, additionally comprising: means for receiving payment from the buyer; and means for sending payment to the vendor subsequent to subtracting the determined fee.

23. The system of Claim 13, wherein the means for guaranteeing payment issues an insurance policy on the transaction.

24. The system of Claim 13, wherein the means for guaranteeing payment purchases a receivable from the vendor.