APPARATUS AND METHOD FOR AUTOMATED
PROCESSING OF PRODUCT PURCHASES
AND PURCHASE TRANSACTION VALIDATIONS
BACKGROUND OF THE INVENTION The present invention is generally directed to electronic commerce and, more particularly, to electronic commerce which advantageously utilizes the existing credit card charging infrastructure to take advantage of the enormous economy of scale, proven technology and reliability of existing electronic commerce networks.
Practically throughout the world, commercial transactions between buyers and sellers are completed via the world-wide and highly-reliable system of credit card charging networks. Thus, merchants, service providers and numerous other organizations such as governments and non-profit entities complete commercial transactions by supplying their products and services and obtaining payments therefor through the network of credit card service providers. These credit card service providers include such famous organizations as Visa, MasterCard, Discover, American Express, etc. Over the years, the vast networks of communication systems have allowed merchants to efficiently and rapidly check the credit
worthiness of and set credit limitations for various individuals, businesses, organizations, etc., validate purchases, and receive payments for merchandise and services in a streamlined, widely applicable and relatively efficient manner.
The services provided by the credit card processors are not inexpensive to merchants. Merchants that accept credit card charges typically pay bank interchange fees which are on the order of from about 1 % to 2%% of the price of the transaction. As a result, for merchants which sell tens or hundreds of millions of dollars of goods, the 1%% to 2 % service charge represents a huge outlay of money which has to be absorbed as the cost of doing business. To avoid credit card service charges, many business such as product manufacturers and the like conduct business directly with their customers, to whom they provide products on a net-30 day payment basis, i.e. customers are expected to pay within 30 days of receipt of invoice. While these businesses bear the risk that some customers might default on their payments, they enjoy the benefit of avoiding the steep 1%% to 2 % credit card bank interchange fees.
With the advent of the Internet, several business organizations have set up Internet accessible
computer systems which provide publicly searchable product databases that describe the particular merchant's products. Such database may describe hundreds, thousands or even tens of thousands of different products. In addition to describing the products, the typical database includes such information as expected delivery dates, prices per unit, volume discounts, etc. To process customer orders placed via such company owned computer systems, absent an automated process these companies would require large staffs to process the computer generated orders, control the company's inventory and delivery of products, generate invoices and communicate with customers .
At present, product and service merchants are left to choose between running their own large, bureaucratic organizations to bypass the credit card establishment, or availing themselves of the credit card services to simplify their internal operations, but at the cost of paying the bank interchange fees.
SUMMARY OF THE INVENTION
Accordingly, it is an object of the present invention to provide an electronic commerce system which utilizes the advantages of credit card charging networks without incurring the typical costs associated therewith.
It is another object of the present invention to provide an electronic commerce system which is simple to use and operate and which also conforms to existing modes of completing electronic commerce transactions from the point of view of the public at large.
It is yet another object of the present invention to provide an electronic commerce system which avoids some of the disadvantages of existing systems. It is yet another object of the present invention to utilize the credit card charging mechanisms that are part of the present crop of commercially available web merchant server systems.
The foregoing and other objects of the invention are realized by a system and method which utilizes the advantages of both existing credit card transaction handling infrastructures and the in-house computer network capabilities of merchant companies to provide to the public Internet accessible databases describing the company's various products and services, all the way through to completing the purchase. The invention allows merchants to enjoy the benefits of the credit card infrastructure without incurring the full bank interchange fees associated with such infrastructures .
The invention achieves its objective by utilizing the existing credit card infrastructure through the creation of a special bureau or agency that creates and uses virtual credit card labels that are then assigned to individual purchasers on a transaction-by- transaction basis or, alternatively, on a purchaser identity basis. While the transaction appears to be a typical credit card transaction, the merchant is not subjected to the usual fees associated with credit card transactions, which are based on the size of the commercial transaction. Rather, a fixed fee is charged which is based primarily on the numbers of transactions being handled on behalf of the merchant, without regard to the dollar amount or size of the transaction. More specifically, the invention comprises the method and system for electronic commerce which implicates first and second subsystems which operate as follows.
The first subsystem includes a merchant-based product database that contains a list of various products of the merchant. The first subsystem also includes a search engine which enables a user to search through the product database to designate products to be purchased and to develop a report defining a "shopping list" of products to be purchased. It is preferred that access to
the various merchant-based databases be controlled through the registration of first time users in a customer database which solicits and records personal data such as the user's business identity, credit history, method of payment and the like. The owner of a database can then authorize businesses and/or individuals to access the product database for the purpose of ordering various products therefrom. The first subsystems further includes an electronic link to the second subsystem typically run and controlled by a single financial institution which regulates and handles commercial transactions received from various merchants.
The second subsystem includes a credit card transaction handling facility which includes means for receiving purchase orders from the various merchants, authorizing and validating purchase orders to proceed and informing the various merchants that shipments of products may proceed. The second subsystem also includes a software facility and credit handling processor that creates the aforementioned virtual credit cards using existing credit card charging technology, solely in order to generate debit statements to purchasers of products, to collect funds and to track and log commercial transactions.
In fact, unlike typical commercial credit card transactions, the financial institution which operates the second subsystem is not meant to operate in the manner of typical credit card processors which supply goods on credit. Instead, the credit risk of the commercial transaction remains with the merchant. This is accomplished by creating a private label credit card account where no physical credit card is used. The credit card transaction is merely a transaction against this virtual credit card which allows the system to utilize existing credit card infrastructures. Purchasers of products are billed by the financial institution and are expected to tender payment within a preset time period, usually thirty days. When customers tender payment, the financial institution credits the received funds to the bank account of the merchant, which account may be a bank account located at the financial institution or at a different financial institution (not involved in operating the second subsystem). Thereby, the present invention enables the use of existing credit card charging systems for executing non-credit card transactions .
Preferably, the system and method of the present invention also provide at the second subsystem the option to process commercial transactions via
conventional credit cards. Thus, purchasers are able to choose to pay for products via conventional credit cards or on a net 30-day basis, when authorized by the merchant to purchase products in that fashion. Still further, the present invention provides a facility for aggregating accounts receivable collected in connection with thousands of commercial transactions into accounts receivable portfolios, which can be then purchased by lenders known as "factors" that are electronically connected to the second subsystem. The invention permits factors to participate in the financing of commercial transactions by selecting portfolios of accounts receivable and tendering discounted payments thereof to the merchants. In this fashion, the transfer of funds to the merchants can be speeded up for merchants that desire to improve their cash flow and reduce their credit risk.
Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings .
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram of an existing system for taking customer orders using the Internet.
Figure 2 is a block diagram of a typical prior art electronic commerce system that uses the credit card billing infrastructure.
Figure 3 is a block diagram of the system of the present invention.
Figure 4 is a block diagram of the system of Figure 3 adapted for use with a plurality of merchants.
Figure 5 is a block diagram of a further embodiment of the system of Figure 4. Figures 6A-6C are flow-charts describing various aspects of the software facilities associated with the system of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Prior art Figure 1 diagrammatically illustrates an Internet-accessible product ordering system 10 of a typical manufacturing company, for example the fictitious Easybuy, Inc. company. To access the product ordering system 10, a typical Easybuy customer 14, running such program as Netscape's Navigator™ Program or the Microsoft Explorer™ Program on its computer network 16 or personal computer 12, accesses the Internet's World Wide Web 18 to establish a connection through a corporate computer network 26 to a product database 22 which lists all (or a portion) of the products of the Easybuy company. The
database 22 may comprise a large memory managed by a database software facility, such as Oracle™ or Sybase™. The hardware and software blocks associated with the database 22 are well known and have been reduced to practice to store a huge number of parts, for example tens of thousands of parts such as nuts and bolts and the like.
The prior art allows the potential customer 14 to examine and search through the parts database 22 by flipping through HTML pages presented by a search engine 24 such as Saqqara™ which is installed on the web server 26 of the Easybuy company. In this manner, the customer is able to narrow the search by selecting different parameters that describe the product (s) he or she is searching for.
When the customer has found the desired products, the customer can click on an "order" icon which causes the computer system 26 to invoke a process running on an order generating facility 28, such as a commerce server that may be implemented, for example, as an IBM Commerce.Net server, OM Transact, MS Merchant Server or Netscape Commerce Server, that places the order in a "shopping basket". Once the customer has assembled a complete order containing all of the parts or products he or she wishes to purchase, the commerce server software
facility formats a digitally encoded shopping list which lists all of the products to be purchased, as well as the accompanying tax and shipping charges, etc. The description below distinguishes between the merchants 15, e.g. Easybuy Inc., and the merchants' buying facility service or system 17, which comprises the elements 22, 24, 26 and 28 in Fig. 1.
Once the digitally encoded order has been logged, the typical company such as Easybuy deploys a large manual labor pool 30 to place the orders, prepare billing statements 32, manage the shipment of products to customers, handle collections 34 and communicate with customers concerning defects, irregularities in billing, complaints, returns and the host of other issues that arise in the normal course of business (as designated generally by the block 36) .
The system described above with reference to Fig. 1 is more typical of manufacturing concerns which deal with a smaller universe of customers who repeatedly buy products or parts for business rather than personal needs. For example, Easybuy Inc. may be an electrical parts manufacturing company or an automobile parts manufacturer which produces parts for the entire gamut of needs presented by an industry. The customers therefore are able to establish closer relationships with the
merchants/sellers of parts, which builds up trust and confidence. Hence, it is not uncommon for the sellers to ship products on a net-30 days payment schedule. It is not necessary for the electrical-connector manufacturing company to sell products through credit card payment methods and to incur the steep 1%% to 2%% charges that are incurred by sellers of consumer products such as department stores and the like.
In contrast — see Figure 2 — department stores and other sellers of consumer oriented products, which do not typically develop close business relationships with a limited number of buyers, almost universally avail themselves of the services of credit card charging networks. In Figure 2, a typical credit card transaction is initiated through an electronic device or service, e.g. a VeriFone™ credit bureau calling device (not shown) , which calls a credit card processing center 40 which thereafter calls one or another of several credit card processors 42a, 42b, 42c, 42d that regulate and control transactions for different credit cards. These credit card processors or facilities may be a Visa credit card processor 42a, a MasterCard processor 42b, a Discover credit card processor 42c or any other such processor. Each of these credit card processors then initiates a call to one or another of different
issuing banks 44a, 44b, 44c or 44d which has issued the particular credit card to check the credit limit or availability of the particular purchaser and to receive an authorization to proceed with the transaction. The issuing banks also prepare and mail billing statements 46 to customers, collect payments and handle customer complaints 48.
Conducting business via the system of Fig. 2 is very efficient and highly streamlined. But as noted previously, the credit card based system of Fig. 2 charges the merchants 15 fees that are calculated as a percentage of each transaction. In a nation such as the United States where commercial trade amounts to hundreds or even thousands of billions of dollars, the cost of the credit card infrastructure to business establishments adds up to billions of dollars.
Reference is now made to Fig. 3, which depicts the layout of a system and method which delivers the benefits of both the system of prior art Fig. 1 and prior art Fig. 2, while avoiding a substantial portion of the expenses associated with the credit card charging system of Fig. 2. Fig. 3 combines the merchant-based, customer interface and products searching system 17 of Fig. 1 with the credit card charging infrastructure 19 of Fig. 2, with some modifications. First, note that the corporate
computer network 26 communicates in this configuration, via the system 28, which handles order generation and external communications, with the credit card infrastructure 19. The system 28 preferably comprises a commercially available, commerce server software and hardware system which communicates via telephone or satellite lines 49 with a special credit card processor, for example the merchant services system 50 of the Chase Manhattan Bank, the assignee of the present invention. The merchant services system 50 electronically receives all orders generated by the corporate network 26 of the merchant 15, in a manner identical to any other credit card transaction processor.
However, in departure from the prior art, the merchant services system 50 communicates with a special private label charging processor 52. This private label charging processor 52 has been especially set up to generate and use what are in effect virtual credit cards, for handling exclusively commercial transactions received from the merchant 15. However, unlike a typical credit card transaction, in which the credit card issuer bears the risk of purchaser default, the risk of non-payment by customers remains with the merchant 15.
The private label charging processor 52 prepares private label credit cards for the customers 14
of merchant 15 based on information which is provided by the merchant. Thus, the corporate computer network provides to the processor 52, such information as the personal data of the various customers, the credit limit for each customer, mode of payment which may, for example, be cash on a net 30-day basis or through a customer's bank and other information which pertains to and defines how funds will be collected in payment for merchandise delivered to the customers 14. With the above information in its database, the private label charging processor 52 proceeds, upon receiving a report of a transaction to be handled, by issuing a customer billing statement via block 46, which block 46 is configured to automatically prepare and mail statements to the customers 14. When the customer remits payments to the statement/collection group 46, receipt of those funds is reported by the private label charging processor 52 to the merchant services system 50, which deposits the funds in the merchant's bank account 54 (which may be a Chase Manhattan Bank account or a bank account at another financial institution) .
Alternatively, the private label charging processor 52 may be set up to communicate the commercial transaction to an electronic funds transfer group 56 which is configured and programmed to communicate with
the customer's bank 58. In this instance, the arrangement contemplates that the customer's bank will pay the billing statement submitted via the private label charging processor 52 in due course, not unlike existing systems in which customer banks are set up to pay their depositors' utility bills, home mortgages and other monthly bills. In this arrangement, the system relies on the customer's bank to prepare and issue billing statements to the customer as indicated by flow-chart line 60.
At such time as the customer's bank 58 transfers funds in payment for the transaction through the electronic fund transfer group 56, receipt of such funds is reported to the private label charging processor 52 which in turn notifies merchant services 50 to credit the received funds to the merchant's bank account 54.
The merchants 15 corporate computer network 26 is also set up to communicate with merchant services 50 via a computer-based communication link that uses standard commercial communication protocols, for example the legacy system 62, through which the financial institution 19 is able to report to the merchant 15 information concerning receipt of funds from customers, the balance in the merchant's bank account 54 and other information that are necessary for administering the
overall system of the present invention. Typically, information pertaining directly to the ordering and paying for products flows over the communication link 49 while financial information concerning balance of merchants' accounts and other more general information is communicated via the link 63.
It should be appreciated that the electronic funds charging and collection system comprising merchant services 50, private label charging processor 52, electronic fund transfer group 56 and the statement/collection group 46 does not entail the costly creation or construction of novel or new elaborate hardware and software systems. Rather, each of the systems such as the system 50, 52, 56, 58 are essentially hardware/software facilities which are known and exist per se and which already serve for and carry out such functions as tracking commercial transactions in a manner similar to the existing infrastructure that serves the needs of the credit processor establishments. In this respect, the setting up of the private label charging processor and the mode of transferring and crediting of funds and controlling commercial transactions between customers and merchants is similar to existing credit card charging systems and does not entail investments in engineering and erecting a new infrastructure.
As a result, a financial institution which implements, runs and supervises the system of Fig. 3 is able to charge merchants 15 a comparatively modest, fixed fee per each commercial transaction, which does not vary with the size of the transaction. The same service fee can be charged to handle a $200 transaction as one involving $1,000,000. The fee can be set purely on the basis of the cost of running the operation, since the financial institution represented by block 19 does not bear any of the risk of non-payment which is left with the merchants 15.
Fig. 4 shows a further enhancement of the system of Fig. 3 which differs only in that it is able to handle a plurality of merchants 15a, 15b... 15N, rather than a single merchant. Thus, in accordance with a broader scope of the invention, customers 14 which may be located throughout the world are able to contact a variety of merchants, and have their orders placed with different merchants to be handled by a single financial institution 19 having the system of the present invention. It is expected that when the system of the financial institution 19 is fully implemented, the private label charging processor 52 will assign different private label credit cards to customers, so that each customer private label card will correspond to and
facilitate commerce with a different one of the merchants 15a, 15b... 15N.
A still more elaborate implementation of the system of Fig. 4 is depicted in Fig. 5. Here, the universe of customers (designated by block 64) is shown communicating with various merchants (whose computerized parts ordering systems are collectively represented by block 66) . The financial institution 19 which operates the private label based system comprises the merchant interface block 68 which corresponds to the merchant services group 50 of Fig. 4 and handles conventional credit card transactions in block 70 and 72 as well as private label transactions in block 74. The customer interface block 76 provides a communication path to the universe of customers 64. Fig. 5 differs from Fig. 4 in that it provides a facility — namely the syndication and factoring interface 78 — that permits the financial institution 19 to speed up and facilitate the delivery of funds to the merchants 66 as explained below. The function of factors in commercial transactions is well known. Factors are financial institutions that study and analyze account receivables portfolios of various merchants for the purpose of purchasing the right to collect these receivables. The merchants receive an immediate cash payment which is
discounted from the face value of the receivables. In this manner, a merchant that is owed for example $1,000,000 from a large group of customers is able to sell to a factor the $1,000,000 worth of accounts receivable at a discounted price, e.g. $900,000 or $950,000 etc. The existence of factors often helps merchants ease their cash flow problems. While the merchant receives less than the full value of the debt, the merchant gains by being freed of any further credit risk.
The system of the present invention allows commercial transactions recorded on the books of the private label charging processor 52 to be lumped and aggregated into various groups of accounts receivable portfolios. Those portfolios are posted on a database or a web page of the system 19 as indicated by the block 78. The different factors such as the factors 80a, 80b... 80N are now able to communicate with the syndication and factoring interface of the financial institution 19 to examine and optionally purchase one or another or several of these portfolios. As soon as those portfolios are purchased, the funds are transferred to the financial institution 19 which then immediately credits those funds to the merchants' bank accounts 54. These portfolios may be grouped on a merchant-by-merchant basis or on the
basis of the character, size or kind of the receivables and, indeed, in any manner agreed to by the merchants 66 and the financial institution 19.
Other features and aspects of the system of the present invention can be discerned from the software and overall system flow-charts of Figs. 6A-6C. Assume that the merchant is company X that manufactures electrical components for the electrical/electronic industry, and that the financial institution 19 is the Chase Manhattan Bank, software flow block 90 shows that an X company customer, running one of the standard browser packages on its PC, is able to access a Connect program resident in the merchant's computer network 26 which enables the customer to run a search engine and set up customer data as indicated in block 92. This enables the customer to search through the product database 22, assemble a shopping list as indicated in block 94 and specify a payment mode as indicated at block 96. The Connect system then establishes an external communication path, as indicated at block 98, with the financial transaction facilitator 100 which in this case represents the Chase Manhattan Bank. Using the computer software system previously described, the Chase Manhattan Bank is able to complete the financial transaction and to communicate
with the Connect system 26 through a protocol that is represented by block 102 of Fig. 6A.
The major software components of the transactions/events taking place at the Chase Manhattan Bank institution are depicted in Fig. 6B. The financial transaction facilitator program 104 includes a software facility 106 which serves to establish communication with merchants and a further facility 108 that receives and processes orders for various products. At decision block 110, the software determines whether payment for the commercial transaction will be via a conventional credit card or on a net 30-day basis.
If the transaction is to be processed in accordance with conventional credit card procedures, the software proceeds to software facility 112 which contacts the card issuer, e.g. Visa, MasterCard, etc., which in turn contacts the issuing bank as indicated in block 114. If the particular customer has sufficient credit available to him/her, decisional block 116 routes the software to block 118 which issues an authorization that allows the commercial transaction to proceed. This authorization is communicated to the merchant's computer network — see Fig. 6A — via the transaction reporting interface 102.
Alternatively, if the customer does not have sufficient credit with the merchant as tracked by the charging processor to cover the commercial transaction, the program issues a rejection as indicated in block 120 and the software program returns to handle other system tasks as indicated at block 122.
If, on the other hand, the Chase Manhattan Bank has received an indication that the particular commercial transaction is to proceed on a net 30-day payment basis, the software proceeds to decisional block 110, i.e. to the private label generating software block 124 which is responsible for handling the creation and the charging of orders to private label cards. Once such a transaction has been received, the decisional block 126 determines, based on inputs received from the merchant, whether the size of the commercial transaction exceeds the credit available to the particular customer as of the time of the transaction. If there is insufficient credit, then a rejection is issued at block 128 and the program continues through the return block 122. On the other hand, if sufficient credit is available, an authorization is returned to block 122 and a charge is registered at block 130 and the software determines whether the funds in payment for the transaction are to come from the customer's bank or from the customer directly. If from
the customer's bank, decision block 132 proceeds to post the necessary ACH debit by interfacing with the customer's bank as indicated at block 134. Alternatively, invoices are issued and funds are collected directly from the X company customers as indicated by block 136.
As a general note, it is assumed herein that the reader understands that the process of transferring funds in the banking industry distinguishes between an "authorization" phase and a "settlement" phase. The authorization phase checks if a purchaser has available the necessary funds to consummate the transaction. If yes, the authorization phase locks up the required amount in the purchaser's account. The "settlement" phase transfers the funds to the receiving party, usually the seller of the merchandise, which in this case is the financial institution which acts as the intermediary between the purchasers and the merchants 15. In the present invention, it is preferred that the financial institution settles with the merchants on a monthly basis. This means that the financial institution actually transfers the funds by accrediting the merchant's account with the moneys that the financial institution had collected during the previous month from customers of the merchant.
Rejection of a commercial transaction can also be based on the size of the transaction. For example, the system may be set up to be used only for transactions that exceed a certain dollar value, for example $50. Or the software may limit certain customers to transactions which must be prepaid, in which case the transaction would be allowed to be completed only by directing the program to the customer's bank for immediate collection of funds. In any case, as soon as the software block of Fig. 6B has determined that the commercial transaction can proceed, appropriate authorization is issued to the merchant, i.e. to the Connect program so that Connect may arrange for the shipping of the purchased merchandise. Other functions performed by the software facility of the financial institution are shown in Fig. 6C. Thus, the financial transaction facilitator program 104 also handles funds received from customers. When such funds are received, decisional block 136 determines whether those funds were received in connection with commercial transactions that were consummated under the private label scheme of the present invention. If so, decisional block 138 proceeds to block 140 and credits the merchant's account with the funds that were received directly from the customers. On the other hand, if such funds were collected from the purchaser's bank, then an
ACH credit report is issued as indicated by block 142 and the program proceeds to credit the received funds to the merchant's credit account 140. In either case, whenever funds are received, a report is issued to the merchant as indicated at block 144 and the program returns at 146.
At decisional block 136 is also determined whether other functions are to be executed. Thus, if decisional block 148 determines that there are no other functions to be performed then the program returns at block 146. Otherwise, the program queries whether it should handle factoring requests from the factors 80a, 80b... 80N as previously described. If so, decisional block 150 directs the program to the software facility 152 which handles the communications with the factors through external communication links. If no factoring is required, the program proceeds from decisional block 150 to query whether any other administrative tasks are to be performed. If the answer is negative, the program returns. However, if such administrative tasks exist then the program turns to handle the tasks as indicated generally by block 154.
Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. It is
preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only by the appended claims.