Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/351—Virtual cards
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

• 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.
• 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.
• bank interchange fees typically pay bank interchange fees which are on the order of from about 1 % to 2%% of the price of the transaction.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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).
• the present invention enables the use of existing credit card charging systems for executing non-credit card transactions .
• the system and method of the present invention also provide at the second subsystem the option to process commercial transactions via conventional credit cards.
• 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.
• 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.
• 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.
• FIG. 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.
• FIG. 1 diagrammatically illustrates an Internet-accessible product ordering system 10 of a typical manufacturing company, for example the fictitious Easybuy, Inc. company.
• a typical Easybuy customer 14 running such program as Netscape's NavigatorTM Program or the Microsoft ExplorerTM 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 OracleTM or SybaseTM.
• 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 SaqqaraTM 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.
• a search engine 24 such as SaqqaraTM which is installed on the web server 26 of the Easybuy company.
• 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".
• 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”.
• 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.
• 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) .
• Fig. 1 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.
• 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.
• the sellers 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.
• a typical credit card transaction is initiated through an electronic device or service, e.g. a VeriFoneTM 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.
• a VeriFoneTM credit bureau calling device not shown
• 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.
• FIG. 3 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the private label charging processor 52 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) .
• the merchant's bank account 54 which may be a Chase Manhattan Bank account or a bank account at another financial institution
• 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.
• 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.
• the system relies on the customer's bank to prepare and issue billing statements to the customer as indicated by flow-chart line 60.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• FIG. 5 A still more elaborate implementation of the system of Fig. 4 is depicted in Fig. 5.
• 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.
• 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.
• FIG. 6A-6C 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.
• the financial transaction facilitator 100 which in this case represents the Chase Manhattan Bank.
• 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 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.
• the software determines whether payment for the commercial transaction will be via a conventional credit card or on a net 30-day basis.
• 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.
• the card issuer e.g. Visa, MasterCard, etc.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the financial transaction facilitator program 104 also handles funds received from customers.
• 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.
• 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.
• 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.

Applications Claiming Priority (3)

Publications (1)

Family

ID=25440169

Family Applications (1)

Country Status (3)

Families Citing this family (11)

Family Cites Families (8)

• 1998
  • 1998-07-13 WO PCT/US1998/014490 patent/WO1999010850A1/en not_active Application Discontinuation
  • 1998-07-13 EP EP98934492A patent/EP1010149A1/de not_active Withdrawn
  • 1998-07-13 AU AU84000/98A patent/AU8400098A/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events