WO2000057337A1 - Systeme et procede de compensation par transaction automatique - Google Patents

Systeme et procede de compensation par transaction automatique Download PDF

Info

Publication number
WO2000057337A1
WO2000057337A1 PCT/US2000/008284 US0008284W WO0057337A1 WO 2000057337 A1 WO2000057337 A1 WO 2000057337A1 US 0008284 W US0008284 W US 0008284W WO 0057337 A1 WO0057337 A1 WO 0057337A1
Authority
WO
WIPO (PCT)
Prior art keywords
automatic
clearing
transaction
funds
parties
Prior art date
Application number
PCT/US2000/008284
Other languages
English (en)
Inventor
Charles S. Stahl, Jr.
Gary P. Bouchard
Herbert R. Lichtman
Michael R. Clark
Original Assignee
Eclearing.Com Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Eclearing.Com Inc. filed Critical Eclearing.Com Inc.
Priority to AU40406/00A priority Critical patent/AU4040600A/en
Publication of WO2000057337A1 publication Critical patent/WO2000057337A1/fr

Links

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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • This invention generally relates to a clearing system and method and more particularly to an interactive automated transaction clearing system and method.
  • patent 5,717,989 issued February 10, 1998 to Tozzoli et al discloses a system in which a funds provider criteria for financial guarantee is compared with a proposed purchase order to determine whether the system can generate a payment guarantee . When appropriate conditions are met, the system issues a funds transfer instruction to transfer payment from buyer to seller.
  • An on-line clearing service is located on the world wide web, or "the internet" at URL address www. iescrow . com targeted to consumer to consumer transactions.
  • the buyer remits the purchase price plus a service fee that is a percentage of the purchase price.
  • the funds are deposited directly with the operator of the web site, and are thereby subject to loss by embezzlement of the operator or due to bankruptcy of the operator.
  • the seller is instructed to ship.
  • the shipment must be insured which adds a mandatory cost to the transaction whether warranted or not.
  • the seller must enable the operator to track the shipment by providing a receipt with the appropriate information or a tracking number of the shipper.
  • the buyer Upon receipt of the goods, the buyer has an agreed upon period within which to accept or reject the goods, and upon formal acceptance, or expiration of a predetermined time period, the operator submits the price to the seller.
  • the system has only limited messaging capability.
  • Another known clearing service is located on the internet at www . tradesafe . com which also does not employ a financial institution to collect, hold and distribute the funds.
  • the parties are enabled to communicate with each other and with the operator only by mail, e-mail or facsimile transmission, and not by interactive web page. This communication limitation disadvantageously impedes the transaction by slowing the communication and increases the operators labor costs for communication.
  • an automatic transaction clearing system having an automatic clearing operation web site application for automatically conveying transaction information through a computer internet with remote buying parties and selling parties n response to receipt of funds clearing information, and an automatic funds controller application distinct and remote from the automatic clearing operation web site application for reporting funds clearing information to the automatic clearing operation web site application, and means associated with the automatic clearing operation web site application for automatically sending notification email to at least the seller of occurrence of at least one of the events of (a) impending automatic release of funds, (b) a check has been returned uncollected of an occurrence, and (c) transaction completion.
  • the object is further achieved by providing an interactive automatic transaction clearing system having an automatic transaction clearing internet server for generating on an internet web page a graphic element for displaying one of a plurality of different visual characteristics respectively representative of different transaction completion status levels and automatically changing the one of the plurality of graphic characteristic m response to receipt of transaction information associated with a completion status level other than the one represented by the changeable graphic characteristic being displayed.
  • the object is still further achieved by providing an interactive automatic transaction clearing system, having an automatic transaction clearing internet application for generating an interactive internet web page that enables parties to interactively enter into agreements to remotely close unfulfilled contracts to buy and sell pursuant to agreed terms and means for enabling the parties to interactively make adjustments to the agreed terms of a transaction after the parties have agreed and the transaction is closed.
  • an interactive automatic transaction clearing system having an internet arbitration application with means for generating an interactive web page for providing interactive arbitration services over a computer internet; and an automatic transaction clearing internet application for generating an interactive internet web page that enables parties to interactively enter into agreements to remotely close unfulfilled contracts, and enabling at least one of the parties to automatically initiate an arbitration at the clearing internet server web page through an automatic link with the arbitration internet server.
  • the object is also achieved by providing a method of interactive automated transaction clearing system, having the steps of, an automatic clearing operation controlled by an automatically clearing operator and including the step of registering parties for a proposed transaction for clearing, and automatically generating automatic payment directions in accordance with the proposed transaction, and an automatic funds controller controlled by a party other than the automatic clearing operator, the automatic funds controller including receiving the funds of the parties, and automatically making payments from the funds in accordance with the automatic payment directions .
  • the object is further achieved by providing an automatic transaction clearing system, including the steps of, automatically conveying transactional information at a web site through a computer internet with remote buying parties and selling parties in response to receipt of funds clearing information, and an automatic funds controller application distinct and remote from the automatic clearing operation web site application for reporting funds clearing information to the automatic clearing operation web site application, and automatically sending notification with the automatic clearing operation web site via email to at least the seller of occurrence of at least one of the events of (a) impending automatic release of funds, (b) a check has been returned uncollected of an occurrence, and (c) transaction completion.
  • an automatic transaction clearing system including the steps of, automatically conveying transactional information at a web site through a computer internet with remote buying parties and selling parties in response to receipt of funds clearing information, and an automatic funds controller application distinct and remote from the automatic clearing operation web site application for reporting funds clearing information to the automatic clearing operation web site application, and automatically sending notification with the automatic clearing operation web site via email to at least the seller of occurrence of at least one of the events of (a) impending
  • the object is further achieved by providing an interactive automatic transaction clearing system including the steps of, generating on an internet web page with an automatic transaction clearing internet server, a graphic element for displaying one of a plurality of different visual characteristics respectively representative of different transaction completion status levels, and automatically changing the one of the plurality of graphic characteristic in response to receipt of transaction information associated with a completion status level other than the one represented by the changeable graphic characteristic being displayed.
  • an interactive automatic transaction clearing system including the steps of, generating an interactive internet web page with an automatic transaction clearing internet application that enables parties to interactively enter into agreements to remotely close unfulfilled contracts to buy and sell pursuant to agreed terms, and enabling the parties to interactively make adjustments to the agreed terms of a transaction after the parties have agreed and the transaction is closed.
  • Still yet another object of the invention is achieved by providing an interactive automatic transaction clearing system having, an internet arbitration application with means for generating an interactive web page, with an interactive automatic transaction clearing system, for providing interactive arbitration services over a computer internet, and generating an interactive internet web page, with an automatic transaction clearing internet application, that enables parties to interactively enter into agreements to remotely close unfulfilled contracts, and including means for enabling at least one of the parties to automatically initiate an arbitration at the clearing internet server web page through an automatic link with the arbitration internet server.
  • Another objective of the invention is achieved by providing an interactive automatic transaction clearing system with means for periodically generating reports of all transactions, means responsive to the transactions with customer account numbers with attached reseller referral code for computing commissions for the resellers with such codes, and means for directing automatic funds controller to pay the reseller the commission.
  • Fig. 1 is a simplified functional block diagram of the interactive automatic clearing system of the invention
  • Fig. 2 is a functional block diagram of the hardware and software required for operation of the system of Fig. l;
  • Figs. 3A, 3B, 3C and 3D form a composite state transition diagram of the interactive automated clearing system and method
  • Fig. 3E is a map illustrating how the individual sheets of Figs. 3A, 3B, 3C and 3C can be arranged to form a single drawing;
  • Fig. 4 is a more detailed state diagram of a section of the portion of the state transition diagram shown in Fig.3B;
  • Fig. 5 is an illustration of an interactive clearing home web page generated by the interactive automatic clearing system of Figs.1-4 for enabling a user to enter into the automatic clearing system;
  • Figs.6A-6B form a composite illustration of an interactive web page generated by the interactive automatic clearing system of Figs.1-4 in response to actuation of the "Sign me up" button of the Clearing Home Page of Fig.5 for enabling creation of a new account by registering contact information, banking information, username, secret password and referral information relating to a referral by a clearing reseller;
  • Fig. 7 is an illustration of an interactive web page generated by the interactive automatic clearing system of Figs. 1-4 in response to actuation of the "Log me in” button on the Home Page of Fig.5 for enabling a previously registered user to login to the system;
  • Fig. 8A is an illustration of a Main Menu page generated by the system when an illustrative buyer named Mast Management logs in using the interactive Enter Login page of Fig. 7;
  • Fig. 8B is an illustration of the "New Transaction" page that is generated by the system in response to the logged in user selecting the "Create a New Transaction" link of the Main Menu web page of Fig. ⁇ A;
  • Fig. 8C is an illustration of the "View All Transactions" page that is generated when the buyer selects "View Active Transactions" link of the main menu of Fig. ⁇ A;
  • Fig. 9A, 9B and 9C form a composite illustration of the Transaction Status window that is generated by the system when the exemplary user Mast Management selects the "Trans#6" link of the web page of Fig. ⁇ C;
  • Figs .9D and 9E form a composite illustration of the transaction Status window that is generated by the system when the exemplary user, Mast Management, selects the "Trans#6" link of the web page of Fig. ⁇ C at a time later than the time of the selection resulting in the view of the Transaction Window" of Figs. 9A-9C, and illustrate how the link for the seller to certify shipment of the purchased goods after the full payment from the buyer has arrived;
  • Figs. 9F, 9g and 9H are illustrations of web pages generated by the system with respect to acceptance of a proposal by an illustrative seller, Mast Management, made by a buyer, Hallmart, with respect to a transaction No.33;
  • Fig. 10 is an illustration of the Main Menu page generated by the system when another exemplary user named Milling Fields, Inc having a user name of "floppymoe” logs onto the system using the "Log on” web page of Fig. 7;
  • Fig. 11A is a Message Center web page generated by the system when the user Milling Fields, Inc. selects the "Go to Message Center" link of the Main Menu of Fig.10;
  • Fig.llB is an exemplary message that is displayed when the user Milling Fields selects the link to "Msg re Trans#6";
  • Figs.11C, 11D and HE illustrate a "Message Viewer" web page that is generated when an illustrative buyer, with the user name, Hallmart and having the password "bettybuyer", selects a link to view transaction twelve involving Mast Management;
  • Fig. 12 is an illustration of the "View All Transactions" page that is generated when the user Milling Fields selects the View Active Transactions" link of the web page of Fig. 10;
  • Figs. 13A, 13B and 13C form a composite illustration of the web page that is generated to display transaction information concerning transaction six when the link "Trans#6" of the web page of Fig.12 is selected by the user "Milling Fields";
  • Figs.l4A, 14B and 14C form a composite illustration of an "Internet Arbitration Services" web page that is generated by the system in response to either of the users selecting the "Demand Binding Arbitration" link of the ⁇ Main Menu" page of Figs . ⁇ A or 10;
  • Figs 14D-14M are a series of illustrative web pages generated by the system during the course of an arbitration initiated by an exemplary seller, Mast Management, against exemplary seller, Filling Fields, with respect to a transaction No.7;
  • Fig.15 is an illustration of the web page that is generated by the system in response to a user selecting the "Edit Your Contact Information" link of the web page of Figs. 6A or 10;
  • Fig.16 is an illustration of the web page that is generated by the system in response to a user selecting the "Edit Your User Name and Password" link of the Main Menu web page of Figs .8A or 10;
  • Fig.17 is an illustration of the web page that is generated by the system in response to a user selecting the "Add New Banking Information" link of the Main Menu web page of Figs .8A or 10;
  • Fig.18 is an illustration of the web page that is generated by the system in response to a user selecting the "Terminate Your Account" link of the Main Menu web page of Figs .8A or 10;
  • Figs.l9A and 19B form a composite illustration of the Administrative Menu that is generated by the system to interface with the operation personnel to administer the automated clearing system of the present invention that is accessed through entry of the appropriate administrative username and password at the log in of the Enter Login page of Fig.7;
  • Fig.20A is an illustration of an Import Data web page that is generated by the system when the "Process Funds Receipt From BA" link is selected from the Administrative Menu of Figs. 19A-B;
  • Fig.20B is an illustration of a Payables Report web page that is generated by the system in response to selection of the "Process Disbursements for BA" link of the Administrative Menu of Figs.l9A-B;
  • Fig.20C is an illustration of a Enter Payments Received web page that the system generates in response to selection of the "Enter Payments Received" link of the Administrative Menu page of Figs.l9A-B;
  • Fig. 20D is an illustration of an Enter Bounced Checks web page that is generated in response to selection of the "Enter Bounced Checks" link of the Administrative Menu of Figs.l9A-B;
  • Fig.21A is an illustration of a Create a Reseller web page that is generated by the system in response to selcetion of the "Create a Reseller link of the Administrative Menu of Figs.l9A-B;
  • Fig.22B is an illustration of a Check Transaction Status web page that is generated by the system in response to selection of the "Lookup Transaction by Transaction Number" link of the Administrative Menu of Figs.l9A-B;
  • Fig.21C is an illustration of a Client Lookup web page that is generated by the system in response to selection of the "Lookup Party by Username or Last Name" link of the Administrative Menu of Figs.l9A-B;
  • Fig.21D is an illustration of a Change Username & Password web page that is generated by the system in response to selection of the "Reset a Username and Password";
  • Fig.22A is an illustration of an Exception & Security Report that is generated in response to selection of the "Exception Report" link of Figs.l9A-B;
  • Fig.22B is an illustration of a Reseller Commission Report web page that is generated by the system in reponse to selection of the "Commission Report" link of Figs.l9A-B;
  • Fig.22C is an illustration of a Revenue Report that is generated by the system in response to selection of the "Revenue Report" link of the Administrative Menu page of Figs.l9A-B;
  • Fig.22D is an illustration of a Trial Balance web page that is generated by the system in response to selection of the "Trial Balance Report" link of the Administrative Menu of Figs.l9A-B;
  • Fig.22E is another illustration of a Trial Balance web page similar to that of Fig.22d.
  • the preferred embodiment of the interactive automatic transaction clearing system 20 is functions to provide interactive automatic clearing between a plurality of buyers 22 and another plurality of sellers.
  • the plurality of buyers are respectively labeled BUYER 1, BUYER 2, ...BUYER N, where "N" represents an indefinite natural number, possibly in the tens or hundreds of thousands, or even in the millions.
  • the plurality of sellers 24 are respectively individually labeled SELLER 1, SELLER 2 ...SELLER M, where M is an indefinite natural number, also possibly in the tens or hundreds of thousands, or even in the millions.
  • the clearing system 20 For each transaction processed by the clearing system 20, there is one buyer and one seller, but the number of buyers N is generally greater than the number of sellers M with each seller selling to multiple buyers. Preliminary transactions between sellers 22 and buyers 24 generally occur via outside buyer/seller communication modes 26 in the general application of the system 20, such as by sellers' internet web page, advertisements, telemarketing, etc. and not initially through the clearing system, itself. Thus, the system is not limited like some of the systems noted above in which all communications between sellers and buyers occur on the system.
  • An interactive automatic clearing operation 28 preferably includes an interactive automatic clearing web site, or clearing web site described in greater detail below.
  • the buyer must access this clearing web site and create a transaction by filling out the template form shown in Fig. ⁇ B and thereby providing amongst other items of information, the seller's username.
  • the buyer must previously been provided with the sellers username, and this is generally provided by the seller during negotiations.
  • the seller must therefore register with the clearing system.
  • the seller must register his username and related information with the system 20 by completing a template form shown in Fig.6A-D. This is the first seller transaction information 32 that the seller must input to the clearing operation 26.
  • the buyer can initiate the clearing process in order to avoid possible confusion if both parties tried to initiate the same transaction simultaneously from opposite sides. All that the buyer need know to do so is the seller's username.
  • the buyer accesses the system home web page such as show in Fig. 5, and selects the log me in button and then logs in using the web page of Fig. 7, the Main Menu page of Fig. ⁇ A is generated.
  • the buyer selects the Create a New Transaction link that causes the system to generate the new transaction web page, such as shown in fig. 8B.
  • the buyer then simply enters certain transaction information 30 to the interactive automatic clearing operation 28 using the form of Fig. ⁇ B, as shown.
  • such information includes the total purchase price and a brief description of the goods or services.
  • the information also includes the proposed time interval between the time that the seller certifies actual shipment of the goods and the time that the transaction funds are to be automatically released if the buyer does not respond after receiving the goods or services. If no time period is entered, the system automatically uses a default time period of six calendar days .
  • the system When the seller next logs in to the web site of the clearing operation 28, the system automatically generates a message. An indication of the message is provided on the Min Menu page, such as shown at Fig.10. The user then selects the "Go to Message Center" link and the system responds by generating the Message Center page as shown in Fig.12.
  • the seller selects the link to the message that is displayed with the message summary, the message is displayed informing the seller of a pending transaction as proposed by the buyer.
  • the seller is asked by the system to accept or reject the proposed transaction.
  • the seller is not allowed to propose modification or changes to the transaction as proposes by the seller.
  • the clearing operation instructs, via buyer transaction information 30, the buyer to remit the total purchase funds directly into a customer dedicated, depository account with a major bank or like financial institution, generally identified as the automatic funds controller 34, such as shown in Fig. 13A.
  • the clearing operator who maintains the clearing operation does actually control the funds held in the automatic funds controller operator. Instead, the funds can only be controlled in accordance with computer generated commands that are created in response to password protected input from the parties themselves. It is the parties, themselves, therefor that control the funds albeit in accordance with the clearing operation protocol. The parties are therefore protected not only from one another but are also protected against loss from the clearing operator.
  • the gross purchase price for the transaction is deposited with the independent automatic funds controller 34 by EFT, wire, by SWIFT transaction or by bank draft or check.
  • EFT EFT
  • SWIFT SWIFT transfer to the dedicated customer account
  • the seller must fill out the appropriate information shown in Fig.8.
  • the check is issued, not to the automatic funds controller, but instead is issued to the clearing operator who owns and operates the clearing operation, but possession of the funds is maintained by the automatic funds controller and controlled by the parties, as explained below, and not by the clearing operator.
  • both parties to the transaction While waiting for the funds to be collected, both parties to the transaction are enabled to initiate and approve price changes, automatic funds release interval changes or to request a cancellation of the transaction.
  • These options are selected through use of a Main Menu page item entitled "View Active Transactions", as shown in Figs.l3C and 13D for the buyer and in Fig.l3C for the seller. Thus, this is done via either buyer transaction information 30 sent to the clearing operation or via seller transaction information 32.
  • a traffic light device appears alongside each listed transaction.
  • This device advantageously enables both the parties to quickly determine clearing status at a glance.
  • the traffic light is caused to display a lit red light.
  • the yellow light of the traffic light device is lit, and the red light is turned off.
  • the green light of the traffic light is lit and the yellow light is turned off. Since there are multiple ways in which payments may be made, the meaning of cleared varies.
  • a received check is "cleared" after a preselected time interval has passed form the time the check is put through the banking system for collection, unless the clearing operation 26 is informed by the automatic funds controller 34 that the check has bounced, i.e. returned uncollected.
  • ACH Automated Clearinghouse
  • SWIFT SWIFT
  • the status of collection of the funds is automatically sent by the automatic funds controller as part of the automatic collection distribution information 3 ⁇ to the automatic clearing operation 26 through a cryptographic encoding system and firewall, or crypo-firewall 40.
  • the automatic clearing operation 26 automatically displays a message on the sellers message center page indicating that the goods can be shipped or the services provided.
  • the seller certifies that the shipment was made or that the services were provided. This is done through use of the Certification link selectable from the Transaction Status web page window, as shown in Fig.9E. This is a very important step because it causes the automatic clearing operation to trigger the countdown of the automatic release of funds time period or interval to which the parties previously agreed.
  • the buyer After the buyer receives the goods or the services, and is satisfied, the buyer is requested to send a message to the automatic clearing operation as part of seller clearing information 42 in order to release the funds before the lapse of the automatic release interval.
  • the automatic clearing operation 28 automatically sends automatic payment directions 44 through a crypo-firewall 46 to the automatic funds controller 34.
  • the automatic funds controller responds to the payment order by distributing the funds.
  • the automatic funds controller 34 In response to the automatic payment directions, the automatic funds controller 34 automatically divides the gross purchase price 36 that has been collected into the sellers price 48, the automatic clearing operators fee 50 and, if applicable, a clearing resellers fee 52.
  • This resellers fee is paid to a reseller, or clearing agent, 54 that has made a referral of the clearing services of the clearing operator that is registered as part of the original transaction and sometimes automatically as will be explained in greater detail below.
  • the automatic clearing operators fee 50 is the fee that the parties agreed to pay the operator, usually a small percentage of the purchase price, an this fee is automatically computed and sent to the clearing operators account 56.
  • the automatic clearing operation 28 provides a message to the buyer on the message center and also by e- mail alerting the buyer of the impending release of funds in the next few days. This gives the buyer an opportunity to intervene before the automatic release of funds occurs. This is part of the buyer clearing information 29 that is sent to the buyer.
  • the buyer has two options if he does not want the funds released.
  • the buyer may place a hold on funds while renegotiating with the seller for price adjustments or product return privileges.
  • the buyer can elect arbitration by selecting "Demand binding Arbitration" link of the Main Menu of Fig. ⁇ A or 10. If the seller is unwilling to negotiate, then the seller may elect arbitration. This is achieved by selecting arbitration and then going to the arbitration window and entering the appropriate information as shown in Fig. 9.
  • the automatic funds controller 34 is controlled by an automatic funds controller application preferably run on a proprietary enterprise level or mainframe computer or equivalent. It interfaces with an automatic, clearing operation, web site application of the automatic clearing operation that will be described with respect to Figs.3A-4 and is preferably run on an enterprise level server computer or equivalent.
  • the automatic arbitration operation web site application 64 is run on an enterprise level server computer or equivalent.
  • the buyers computer 66, the sellers computer 68 and the resellers computer 70 can be personal computers, and all of them are capable of interfacing with a computer network 72 and through the computer internet 72 with the automatic clearing operation web site application.
  • the clearing operation application has a data-link 74 that is generally off line except once per day during data transfer.
  • This data link is preferably implemented using File Transfer Protocol, or FTP, transfer over the public internet, and is protected using the PGP implementation of RSA for encryption and authentication.
  • the sellers computer 68, the buyers computer 66 and the resellers computer 70 all are capable of being linked with their respective financial institutions 76, 78 and 80, respectively. Which in turn are capable of being linked to the automatic funds controller application 60 to enable the exchange of electronic funds transfers, etc.
  • the arbitration application is linked to the automatic clearing application through a data communication link 82.
  • the automatic funds controller 34 When the automatic funds controller 34 receives funds in the customer dedicated lock box account of the clearing operator, the automatic funds operator enters detailed information about the payment into the automatic funds operator computer 60. At the end of a preselected time period, such as at the end of each business day, the automatic funds controller generates a so-called "flat file" to transfer the information to the automatic clearing operation computer.
  • This flat file includes information including the date of receipt, the amount received and the related clearing transaction number that is written on the check or other transfer document that is used to effectuate the payment.
  • the payment information varies depending on the payment method used.
  • the payment information allows a fund transfer to be traced if problems arise later in the transaction.
  • payment information includes the check number.
  • payment information includes the identifying information of the transmitting banking institution.
  • the sequence of fields in the flat file, the delimiter used to separate those fields and the checksum calculations used to verify the file are all predetermined between the automatic funds controller and the automatic clearing operation.
  • the lock-box flat file is then encrypted and signed using PGP encryption method.
  • the encryption prevents an eavesdropper from reading the file if the file is intercepted as it is being transferred from the automatic funds controller and the automatic clearing operation. Authentication, or "signing" the file, enables to ensure that the file has not been modified since leaving the automatic funds controller 34.
  • the file is transferred using FTP, and then the automatic clearing operation uses PGP to decrypt and authenticate the file. After receipt of the file, the automatic clearing operation updates the customer accounts accordingly and posts the appropriate messages and traffic light clearing indications.
  • the automatic clearing operation is ready to direct the automatic funds operator 34 to disperse funds.
  • the automatic funds controller 34 using a proprietary disbursement specification called BAFF, for Bank of America Flat File, of the case of Bank of America, the automatic clearing operation web site application creates a flat file that indicates how much to pay to which parties using which payment methods. This file is then encrypted and signed using PGP, and made available on the automatic clearing operation server for pickup by the automatic funds controller application.
  • the automatic funds controller application picks up the file, decrypts and authenticates, and then makes the disbursements as directed. This is importing of the flat file is done by using the Import Data web page of Fig.20A.
  • Figs. 8A and 10 if either the buyer or the seller are not satisfied with the transaction, then by selecting the "Demand Binding Arbitration", they are automatically connected to the "Internet Arbitration Services" web page of 14A-d and at the portion of the page of Fig.l4D, they may elect arbitration by entering the transaction number and their complaint in the appropriate fields, as indicated, and then select submit to initiate the arbitration.
  • the parties have agreed to binding arbitration as part of their service agreement with the clearing operator as they are reminded at a portion of the arbitration web page shown at Fig.l4B. Procedurally, the arbitration works as described at the portion of the arbitration web page shown at Fig.l4A.
  • the clearing application 62 displays to the other party, the respondent, during the next session of the respondent on the clearing web site.
  • the respondent completes an HTML answer on an HTML answer form shown in Fig.l4D that is generated by the clearing application 62.
  • the answer submitted by the respondent is displayed to the complainant on a web page, as shown in Fig.l4G, and the complainant is invited to submit a written reply on an associated HTML reply form, as shown in Fig.l4H.
  • both parties are given notations of the arbitration proceeding via the chronological log containing the transaction. This is viewed by selecting the appropriate transaction link accessed from the View Active Transactions" link of Fig. ⁇ C.
  • the parties are given actual chronology logs of the complaint, the answer and the reply when they click on the message waiting link upon entering the Main Menu page.
  • the complaint, the answer and the reply and all the other transaction details stored by the clearing application are submitted to the arbitrator.
  • This information includes the entire chronological history of the transaction including the names of the parties, the price the description of the goods or services and the automatic release interval.
  • This information is electronically submitted to a preselected arbitrator for the arbitrator' s review and decision .
  • the arbitrator logs onto the clearing web site, he is presented with a list of pending arbitration matters, as shown in Fig.141. Selecting the links to any of the listed matters automatically displays full details of the matter sufficient to enable the arbitrator to make a decision. The arbitrator then decides the case based on the submissions and the other information that is provided.
  • the arbitrator preferably decides within a few days of the final submission, and conveys his decision to the clearing operation by entering the decision on a HTML form that is then displayed to the parties as shown in Fig.14J.
  • the system then automatically displays a message of the decision to the parties the next time they log onto the system, as shown in Figs.l4K, 14L and 14M.
  • the parties are then expected to take steps within the system to implement the decision. For example, if the arbitrator decides that the funds should be refunded to the buyer, then the seller is expected to approve a release of a refund to the buyer.
  • the complainant fails to remit the arbitration fee in a timely manner, the complainant is warned, and then the Complaint is dismissed by decision of the arbitrator. If the respondent fails to remit the arbitration fee in a timely manner, or fails to submit an answer within a preselected time period after posting of the Complaint on the Message Center for the respondent, then the respondent is warned by means of a message at the Message Center web page. If the respondent fails to respond to the warning by submitting an answer, then a default judgement is entered by decision of the arbitrator. The complainant is not required to submit a reply, and if none is submitted within a preselected time period, the arbitrator decides the case based solely on the other submissions.
  • Another important feature of the present invention is the provision of automatic reseller tracking and reporting. This is a tool of the system that offers referring agents the ability to solicit referral business to the clearing operator and generate incremental revenues for their referral efforts.
  • the clearing operator can form relationships with reseller agents and then enter the relevant data for each reseller into the clearing operation administration page shown in Fig 19.
  • the system records the reseller data, and the system generates a reseller "referral code" for each reseller.
  • the reselling agent can then refer business to the clearing operator by giving the prospective customer his assigned referral code number which the client enters at the last field box on the "Enter Account Information" web page of Fig. 6D.
  • the clearing system then uses this number to automatically capture all transactions, "sign ups", etc. for all clients who transact business under the recorded agent's referral code.
  • the customer is thereby relieved of the chore of entering the agent's code each time the customer engages in a transaction.
  • the referral code is automatically carried by the customer account number whenever the customer engages in a transaction either as a seller or a buyer.
  • a report is generated within the administrative side of the automatic clearing operation 28. Reports of all transactions, and the resultant commissions, are automatically generated for each individual reseller 54.
  • the system provides a copy of the report, and the system automatically directs the automatic funds controller to transfer funds to the reseller via EFT. If reseller recruits another reselling subagent under him, a new number is established which links the original reseller to all transaction of the subagent.
  • the original agent reseller receives a portion of the referral fees of the subagent and all other sub-subagent under the sub-agent etc.
  • Each primary agent that has linked subagents is provided with a breakdown of all subagents and their activities and a master check. The principal agent is responsible to divide commissions according to his own arrangements with the subagents and each agent is expected to do his own accounting.
  • a reseller can have his own web site to promote the services of the clearing operation. For example, a reseller may wish to maintain his own web site extolling his own organization and also to recruit selling subagents. A subagent may encourage a prospect to visit the web site of the of the automatic clearing operation 28. When the reseller's web site is visited and a prospect selects a shot link directly to the home page of the automatic clearing operation 28, transparent to the prospect, the reseller's referral code is then automatically entered into the system on behalf of the reseller. This feature advantageously enhances versatility and some assurances that reselling agents will get credit for introducing business to the automatic clearing operator.
  • Another advantageous feature of the invention enables automatic sales capturing and processing for an online merchant.
  • a few lines of custom code are embedded on an online merchant's s website, or webstore.
  • the buyer is automatically directed by hyperlink to the automatic clearing operation web site.
  • all the sales data and the logo of the merchant are transported to the web site application 62.
  • the buyer is thereby given the impression that they are still connected with the merchant netstore web site.
  • the customer is encouraged to open an account, if none yet exists, and all transaction data is automatically entered for the customer and approved.
  • the customer is then instructed to remit the purchase funds directly to the lock box account, and is then automatically returned to a preselected location of the web site of the merchant, such as a merchant's special "on- sale room".
  • a preselected location of the web site of the merchant such as a merchant's special "on- sale room".
  • the transaction is otherwise handled in the normal course. All the merchant seller need do is enter at his convenience approve all non-preapproved sales (for inventory control purposes) and at a glance review all sales for the day. All sales where funds have cleared the merchant can ship and all transactions pending clearance of funds the merchant can be prepared for shipping.
  • Another important aspect of the invention is the ability of automatically sending e-mail messages to the parties in response to detection of certain events.
  • Email notification to a buyer that the "automated release of funds interval" is about to be triggered unless intervention is done are automatically sent within a few days before the event.
  • Email messages are also sent automatically to both parties in response to a report from the automatic funds controller that a check has bounced and when a transaction has been completed.
  • the system is capable of responding with e-mail messages in response to other triggering event. For instance, when FTP transaction data is sent outside of the clearing operation to a party e-mail messages are automatically created to post a "past due" notice to a buyer' etc.
  • Figs . 3A-4 The State Transition Diagram Referring now to Figs.3A-4, a more detailed description of the operation of the entire system is provided as well as details of the preferred programming employed to implement the system 10.
  • the automatic clearing transactions are constrained to follow the flowchart represented by the state transition diagram of Figs.3A, 3B, 3C and 3D and Fig.4.
  • buyers and sellers are collectively called parties.
  • the current status of a transaction is known as its "state”.
  • the state of transaction 479 could be "waiting to receive funds from buyer".
  • States are represented as circles on the state transition diagram.
  • Event An occurrence that takes a transaction from one state to another state is known as an "event".
  • Typical events include "party requests a price change", or "funds received from buyer”.
  • Events are represented by lines extending from one state to another with an arrow head pointing toward the state that results from the occurrence of the event as arrows on the state transition diagram and away from the state that ends upon occurrence of the event.
  • the state indicates the current situation or status of the system, but not necessarily which of a plurality of events pointing to the state was the last event to result in the state.
  • the state transition diagram is used in many ways to represent and understand the operation of the automatic clearing system.
  • a party's options regarding a particular transaction such as transaction 479
  • all that need be done is to determine the state of the particular transaction.
  • All of the events that leave that particular state constitute all and the only options available. Specifically, these events are the only ones that are offered on the menu to this party.
  • the system by following the state transition diagram, it is able to assemble complete descriptions of the history of a transaction by following the states shown in Figs.3A-3D and Fig .4.
  • the system by operating the system in accordance with the state diagram improves security and reliability by assuring that all possible situations have been enumerated.
  • Event 0A Buyer initiates a transaction.
  • Event 1A Seller approves the transaction.
  • Event IB Seller rejects proposed transaction.
  • E2A Event 2A. Party requests cancellation.
  • E2B Event 2B. Party requests price change.
  • Event 2C Party requests change in interval from shipment-of-goods to release-of-funds .
  • E2D Event 2D. Funds arrive. Amount is correct.
  • E3A Event 3A. Seller certifies that goods have shipped.
  • Event 3B Party requests change in interval from shipment-of-goods to release-of-funds.
  • Event 3C Party requests cancellation.
  • E4A. Event 4A. Predestinated interval from shipment-of- goods has passed. Note that buyer has been warned of imminent release.
  • E4B. Event 4B. Buyer explicitly releases funds.
  • E4C. Event 4C. Buyer invokes a hold.
  • E4D. Event 4D.
  • E4E. Event 4E. buyer rejects the shipment.
  • Event 5A Pay seller in part or in full, and refund to buyer in part if necessary.
  • E7A. Event 7A. "It was an error"
  • Event 7B Event 7B. "We agreed on a price reduction.”
  • E8A Event 6A. Seller approves reduced price; now paid in full.
  • Event 8B. Seller rejects, nullify the transaction.
  • E9A. Event 9A. "My mistake. Please refund the excess payment .
  • E9B. Event 9B . "We agreed on a price increase.”
  • E10A. Event 10A. Counter party accepts cancellation request .
  • Event 10B. Counter party rejects cancellation request .
  • Event HA Counter party requested change in interval; new interval holds.
  • Event 11B Counter party rejects requested change in interval; old interval holds.
  • 12A. Event 12A. Refund payments are made because funds have cleared.
  • E13A. Event 13A.
  • Event 19D. Seller requests buyer to pay a penalty for damaged goods .
  • Event 20B. Seller requests buyer to pay a penalty for damaged goods .
  • Inbounds have cleared so make payments.
  • Event 24A. Inbounds have cleared so make payments.
  • the Data Model party table Each registered user of the clearing system is referred to as a party .
  • a party can act as a buyer in some transactions , and as a seller m other transactions .
  • Parties can be individuals or companies .
  • each reseller is also reated as a party the m the following party table .
  • Even the automatic clearing operation operator, herein referred to as "ECC" is also treated as an operator m this table .
  • Party_ ⁇ d int IDENTITY ( 1 , 1 ) NOT NULL Username varchar ( 15 ) NULL , Password varchar ( 15 ) NULL , Fee_status tinyint NULL , Unread__msg_count smallint NULL , Unread_msg_date smalldatetime NULL , Bus ⁇ ness_flag bit NOT NULL , Ema ⁇ l_Flag bit NOT NULL ,
  • Account_creat ⁇ on_date smalldatetime NULL Account_term_date smalldatetime NULL , Most_recent smalldatetime NULL , Second_most_recent smalldatetime NULL , Th ⁇ rd_most_recent smalldatetime NULL , t ⁇ mestamp_attr ⁇ b timestamp NOT NULL , reseller_name varchar ( 60 ) NULL , reseller_payment_method_ ⁇ d mt NULL , reseller__company varchar ( 60 ) NULL , reseller_pctg_of_annual_fee numeric ( 4 , 2 ) NULL , reseller_pctg_of _trans_f ee numeric ( 4 , 2 ) NULL , reseller_ ⁇ d mt NULL , role char ( 1 ) NOT NULL
  • the party_id is the primary key used to reference this party. This advantageously enables changing the username and password without disrupting references to this party, using the web page of Fig.16.
  • the username is 6 to 15 characters long, and it is not case sensitive.
  • the password is 6 to 15 alphabetic characters, and it is not case sensitive. It is stored in the database in encrypted form.
  • the party's username and the password must each be be unique to be accepted by the system.
  • the fee_status is the last membership year for which this party has paid annual fees. It is initialized to zero. It changes to 1 when the initial annual fee has been assessed. If that fee is not paid because, for example, the transaction is canceled, the fee_status is reset to zero. When the first renewal fee is assessed, it is changed to 2. A party who skips a year is only charged one renewal fee and not for intervening years. The account_creation_date allows the system to determine when the annual renewal fee is due.
  • the unread__msg_count indicates how many messages are waiting in the Message Center for this party. It is updated by triggers in the message_table.
  • the unread_msg_date indicates the date of the oldest unread message in the message center. It is updated by triggers in the message_table . This advantageously enables the system to issue emails to people who have not visited the Message Center, such as shown in Fig.12., but who have unread messages.
  • the business_flag is true for businesses and false for individuals.
  • the email_flag is used to allow sending all messages to a particular party via email, if they so desire.
  • the account_creation_date and the account_termination_date respectively indicate when the account was created and when terminated.
  • the termination date is null for active accounts.
  • the timestamp_attrib is used to implement optimistic concurrency control to prevent interference between two parties that are using the system simultaneously. It is not a date and time, but a unique serial number.
  • the reseller_name is used if and only if the record is for an ECC reseller who will be getting commissions. It is the name of the salesman.
  • Reseller_company is the name of the company for whom the salesman works. Commission is reported at the salesman level, and aggregated at the company level.
  • Reseller_payment_method_ID points to a payment method in the payment_method_table that explains how the commission is to be paid.
  • Reseller_pctg_of_annual_fee is the percentage of annual fees that a reseller would collect from a transaction of a buyer or seller. This applies to the initial fee and all renewal fees, and to all buyers and sellers. Reseller_pctg_of_trans_fee is similar, but only the seller's reseller gets this commission. The format of both values is numeric (4,2), so a reseller getting 5.75% would have 5.75 here.
  • reseller id is the party id of the reseller who brought in the buyer or the seller represented by this record.
  • reseller Ron Robbins signed up buyer Bob Brown their would be two records as follows:
  • the first , middle , and last name refer to either the party, itself ( for an individual ) or to the point of contact at a company ( for a company) .
  • these fields are not used; the name of the individual salesman resides in the reseller_name field of the party_table for historical reasons .
  • the title is the title of the party, such as "manager” or "attorney” .
  • the entry for state_or_province is allowed to exceed two characters for international reasons .
  • the zip field is a variable character, or varchar, to handle the dash in extended zip codes .
  • the city_code field exists for international extensions .
  • the voice , fax, and email fields are varchars to allow for parenthesis and dashes in the phone numbers .
  • transact ⁇ on_table trans_ ⁇ d mt IDENTITY ( 1 , 1 ) NOT NULL , trans_creat ⁇ on_date smalldatetime NOT NULL , buyer_ ⁇ d int NOT NULL , seller_ ⁇ d mt NOT NULL , state_code tinyint NOT NULL , b ⁇ ndmg_pr ⁇ ce numeric ( 9 , 2 ) NOT NULL , b ⁇ nd ⁇ ng_mterval tinyint NOT NULL , descr ⁇ pt ⁇ on_of_goods varchar ( 60 ) NOT NULL , buyer_reference varchar ( 60 ) NULL , ⁇ how_buyer_pays ecc mt NULL , ⁇ how ecc pays buyer int NULL , sell er_reference varchar (60) NULL , how ecc pays seller int NULL , timestamp attrib timestamp NOT NULL , arbitration flag bit NOT NU
  • the trans_id uniquely identifies this transaction.
  • the trans_creation_date indicates when it was created.
  • the buyer_id and seller_id identify the parties to this transaction. They are foreign key references to the party_table, and they are checked by triggers.
  • the state_code corresponds to the state on the state transition of Figs.3A-4. The possible values are:
  • the binding_price is the sale price agreed upon between buyer and seller.
  • the operator ECC will charge buyer this binding price, plus any annual fees owed.
  • ECC will pay seller this binding price, less the transaction fee, less any annual fees owed.
  • the binding_interval is the number of calendar days between certification of shipment of goods by the seller and automatic release of funds to the seller.
  • the system does not require shipping documents or tracking numbers
  • the description_of_goods is a simple text description.
  • the buyer__reference and seller_reference are also simple descriptions with no operational significance .
  • the fields ho _ecc_pays_buyer and how_ecc_pays_seller are foreign key references to the payment_method_table . This indicates whether to disburse funds to these parties via check, wire, or ACH for the particular transaction under consideration.
  • a party can select different methods for different transactions in which it is engaged. This is contrary to the treatment of resellers, which select a payment method associated with their record in the party_table that covers all transactions. Referential integrity is checked by triggers.
  • the field how_buyer_pays_ecc is similar.
  • the timestamp_attrib which is really a serial number and not a time, is used for optimistic concurrency control .
  • the arbitration_flag is true if this transaction is in arbitration, and therefore frozen. even t table
  • event_table ( event id int IDENTITY (1, 1) NOT NULL , trans _id int NOT NULL , event _code char (3) NOT NULL , event date smalldatetime NOT NULL , actor _id int NOT NULL , text attrib varchar (150) NULL , currency attrib numeric (9 , 2) NULL , integer attrib int NULL , date attrib varchar (15) NULL )
  • the event_id is a unique ID for this event, allowing us to reference it elsewhere.
  • the trans_id is a foreign key reference to the transaction in the transaction table to which this event relates. It is checked by a trigger.
  • the event_code is always three characters, is left- justified, and is always in lower case.
  • An event code starts with a number indicating the base state, and ends with a letter indicating which event is taking us out of that base state. Possible event codes, including the way they use the other fields, are:
  • the event_date is the date and time at which this event occurred. This allows the system to sequence the events when we are recreating the chronology.
  • the actor_id is a foreign key referencing a party_id in the party_table. It indicates who initiated this event. Several events have ambiguous actors, such as event 3c, which is a party requesting cancellation.
  • the field actor_id is used to indicate which party requested cancellation.
  • the four fields text_attrib, currency_attrib , integer_attrib, and date_attrib are the parameters of the particular event. Reference should be made to the table of event codes above for details of how these parameters are used with each event. It should also be noted that currency_attrib is actually a numeric (9, 2) , and date_attrib is actually a varchar.
  • a party Whenever a party must be told or asked something, this is done through a message in the Message Center, such as shown if Fig.12. For example, if it is desired to inform the seller that the buyer has remitted funds, a message is created for the seller in the Message Center. If one side proposes a price change, a message is created for the other side asking them to accept or reject the proposal. All messages are stored in the message_table until the recipient logs in. CREATE TABLE dbo.
  • message table ( message id int IDENTITY (1, 1) NOT NULL , intended recipient int NOT NULL , event id int NOT NULL , trans id int NOT NULL , role char (1) NOT NULL , send date sma lldatetime NOT NULL
  • the message_id is a unique identifier for this message, allowing easy deletions, if desired.
  • Informational messages (such as telling the seller that funds have been received) are automatically deleted when they are delivered.
  • Messages that require a response are not deleted until a response to the message is received. Deletions are handled by the ASP code and stored procedure calls and not by triggers.
  • the intended_recipient is the unique party_id of the ECC party who should receive the message. Triggers automatically update the fields unread_msg_count and unread_msg_date in the party_table .
  • the event_id is the unique event_id of the event that led to this message. This event provides the details that will be inserted into the template messages. Note that "pure” messages unrelated to a real event must nonetheless point to an event, and an instance of event "xxx" is used to fill this need.
  • the trans_id is the unique transaction id to which this message relates. It is implicit in the event_id, since each event_id is associated with one and only one transaction_id. However, this improves efficiency.
  • the send_date is the date and time at which the message was sent. It is used to sequence messages, and to determine how old the oldest unread message is.
  • headsup_ table allows the system to schedule events to occur upon the passage of time. It is somewhat complex, but it is crucial to the operation of the payment mechanisms.
  • headsup_table headsup_id int IDENTITY (1, 1) NOT NULL , headsup_code char (3) NOT NULL trans_id int NOT NULL , rqd date smalldatetime NULL , rqd state code tinyint NULL , recipient id int NULL , recipient role char (1) NULL , msg to send varchar (150) NULL event to invoke varchar (3) NULL , pmt to make numeric (9, 2) NULL r reference to make varchar (70) NULL )
  • the headsup_table There are several uses of the headsup_table .
  • the "clearance message" event is automatically scheduled to occur x calendar days later. It should be noted that clearance is not an affirmative event, but is instead the absence of notification of a bounced within a fixed time period. The time period is a constant defined in constantsAndFunctions . inc in the ASP project.
  • the system schedules an automatic release of funds to the seller a preselected time interval x calendar days later.
  • this interval is determined by the buyer and the seller.
  • the system also schedules a warning of imminent release of funds, to be delivered to the buyer three days before the automatic release, itself.
  • the three logical types of headsup records are:
  • the headsup_code is always three characters long. It must be one of uc_, uim, or uid, as specified in the above table.
  • the trans_id identifies the transaction to which this headsup record relates, and it is used in all three headsup templates.
  • the rqd_date is the calendar date that must be reached before this headsup tempate is executed. Headsup records can be executed on or after this minimum date, so that a system shutdown for an entire calendar day would not skip any headsup records. This is used by uponlntervalMessage and uponlntervalDo, but not by UponClearance.
  • the rqd_state_code identifies the state of the transaction that is required for the headsup template to be triggered.
  • a headsup record may define an automatic release of funds to the seller. However, that headsup record would require that the transaction still be in state S4. If the buyer had explicitly released the funds already, the transaction would have moved to state S5 via event E4b, causing the automatic release to be disarmed
  • the recipient_id is the party_id of the party to receive the payment or the message to be delivered by this headsup template.
  • the recipient role indicates the kind of party that is the recipient to enable different processing of payments.
  • the payment methods for buyers and sellers are related to this transaction, while the payment methods for resellers are related to the party. This difference makes it more efficient to record the role here.
  • the values are always in lower case, and can be:
  • the msg_to_send is the actual text of the message to be delivered via the Message Center.
  • the event_to_invoke is the event_code (not the event_id) of the event to invoke when all conditions of this headsup template are met. It should be noted that it can be a real event, or it can be "mp", which is a generic identifier of a set of makePayment events.
  • the pmt_to_make is the amount of the payment to make, if relevant.
  • the reference_to_make is the reference line to be included with any payment. paymen ts_ table
  • the payments table keeps complete information on all money flows related to a particular transaction. It records how much is owed and how much is paid by each party. Changes to prices and fees are recorded as price increases or decreases, and not by changing the original records .
  • the trans_id identifies the transaction to which this payment relates.
  • the party_id identifies the party that now owes ECC more or less money.
  • the description identifies the type of payment. These are case sensitive and must be spelled correctly. The choices are:
  • the amount is technically the change in what the party owes ECC. This allows you to determine the appropriate sign of any record.
  • the maturity is the calendar date on which we can count this payment as being done. It is x days hence for checks, and immediately for all other payments.
  • the value of x is determined by a constant in the file constantsAndFunctions . inc in the ASP project.
  • a single transaction creates two "Purchase price” entries, one showing that the buyer owes ECC money, and the other showing that ECC owes the seller money. 4.
  • a single price reduction creates two "Purchase price” entries, one showing that the buyer owes ECC less money, and the other showing that ECC owes the buyer less money.
  • the transaction fee is also shown as an amount owed to ECC by the seller. It is inserted into the table when the transaction is created. It is changed whenever the price changes. The transaction fee is based on the entire price and not the incremental price. For more information, see the function transFeeOn() in constantsJAndFunctions . inc in the ASP project.
  • Terminal events do not update this table.
  • the official records are kept in reporting_table and not here.
  • the purpose of this table is (1) to allow the system to determine who owes what amounts and to whom the amounts are owed, and (2) to report on payments received, but not to report on payments made.
  • the trans_id holds the unique transaction ID if this exception relates to a transaction, or a zero if it is independent of a transaction. For example, a party who gets locked out of the system due to three missed passwords in 24 hours would hit the exception report, but with no associated transaction ID.
  • the message is a full-text message telling ECC management about a situation that warrants some attention.
  • the priority is a number indicating the importance of the message.
  • the exception_date allows us to show the exceptions in chronological order.
  • the reporting_flag is true if the message has been delivered, and false if it has not been delivered.
  • debarred parties table This table lists parties with whom US-based financial institution may not do business. The list is published periodically by the US Department of State. This table is prepopulated with variations on the names on the list of debarred parties.
  • This table indicates how different parties wish to receive disbursements from ECC.
  • a buyer or seller may create an unlimited number of different payment methods, and may select one of those payment methods for each transaction in which they participate. This selection is stored in the record in transaction_table .
  • a reseller may create only one payment method which is stored in the record in party_table.
  • the method__id is a unique identifier of the selected payment method.
  • the party_id indicates with whom the payment method is associated.
  • the method_code must be in lower case, and takes one of the following values:
  • these definitions leave open the possible values of ic, i , ia and is for the inbound versions of these payment methods.
  • the other fields are self-explanatory.
  • the institution_location should include city, state, and country, for it is intended to be read by a human being in case a SWIFT transfer goes into "repair" due to misrouting.
  • This table is a complete record of disbursements made by ECC. Records are added to this table when the payments are "made”. A payment is "made” after it has been “authorized” and after all inbound checks that have been received have also cleared.
  • the system "makes” a payment by including it m a report; an ECC employee must actually sign checks, initiate transfers, and so on. Alternatively the system uses know check writing and accounting software to perform this function automatically.
  • the payee_id is the party__ ⁇ d of the buyer, seller, reseller, or ECC receiving the payment .
  • the reporting_date is the date of the disbursement .
  • the reference explains the disbursement .
  • the amount is self- explanatory .
  • the reported_flag is set to true when the information is reported .
  • Records in the reporting_table are generally created by processing of records the headsup_table .
  • This information feeds the ECC revenue report , as well as the ECC commission report .
  • the other information is available for other reports such as the exception report and the general accounting reports .
  • This table stores all information related to an arbitration proceeding . While an arbitration is pending, the related transaction is frozen . This happens because the arbitration_flag in the transaction_table is set to true. All arbitration information is exchanged via the Message Center using the message_table and the event table .
  • arbitration_ table ( arb_id int IDENTITY (1, 1) NOT NULL , trans_id int NOT NULL , complainant id int NOT NULL , complaint text NULL , answer text NULL , reply text NULL , decision text NULL )
  • the arb_id is the unique ID of this arbitration.
  • the trans_id is the unique transaction ID of the related transaction.
  • the complainant_id is the unique party_id of the person who initiated this arbitration.
  • the complaint is the full-text arbitration complaint, and the answer is the other response of the opposing party.
  • the reply is the optional response by the complaining party to the answer.
  • the decision is the final decision of the arbitrator. II. Design Overview
  • a transaction can only be created by a buyer. This avoids the ambiguity that would be created if both buyer and seller tried to initiate the same transaction. We would not know if buyer was buying two antique lamps from seller for $40, or if buyer and seller had each initiated a transaction for the same antique lamp.
  • the buyer is selected to initiate the transaction because it is easier to have electronic malls, as sellers under this model.
  • the mall provides a link to the ECC site, and that link fills in the details of the transaction (seller id, price, description, etc.).
  • the buyer selects the Submit function to initiate the transaction, and a clerical person working for the seller later confirms.
  • the sytem When the buyer initiates a new transaction, the sytem creates a record of the new transaction in the transaction_table .
  • This transaction has state SI.
  • a record for the first event, event EOa is created in the event_table. This is the event that takes the system from state SO ("no transaction yet") to state SI ("waiting for response from seller").
  • theseller is notified of the proposed transaction and asked for a response. This is done by creating a record in the message_table.
  • the Main Menu will show that one message has been received in the Message Center.
  • a brief summary of the message will be displayed, such as shown in Fig.12.
  • seller clicks on the brief summary he will see the complete message.
  • the seller is given appropriate choices. This detailed message is presented by the Message Delivery System ASP script.
  • the Message Delivery System first presents a plain- English summary of the message being delivered. It then presents a table of the transactional details (buyer, seller, description, price, etc) , based largely on the transaction_table . It then presents the payment situation, based on the transaction_table and the payment_table . It then presents a chronology of all events that have taken place so far, based on the events in the event_table. Finally, it presents only those options that make sense as responses to this message. These options are determined by examining the state transition diagram. When the seller chooses to accept or reject the message, a script called event xxx processor handles the response. The xxx will vary, depending on which event has been selected. For example, accepting the proposed transaction is event Ela, and rejecting is event Elb.
  • the other workhorse of the site is the State Explanation System ASP script. This script is called whenever the party asks for a summary of a particular transaction.
  • the State Explanation System prepares a plain-English summary, presents transactional details and payment details, and then offers appropriate options based on the state transition diagram of Figs.3A-4. III. Other matters.
  • the database is preferably built using Microsoft SQL Server 6.5 running under Windows NT Server 4.0.
  • the web site is preferably built using Microsoft Visual InterDev 1.0, and, in such case, must be hosted with Microsoft Internet Information Server (IIS). Also, in such case, the IIS must be running the Microsoft FrontPage and Microsoft Active Server Page extensions.
  • IIS Internet Information Server
  • the ASP scripts invoke stored procedure calls, or
  • SPC's that contain a set of database instructions that can be called as a group by using a Connection object, a Command object, a Parameter object, and sometimes a Recordset object. These are part of the ADO that is the Microsoft technology that facilitates database access. Mor information about ADO can be obtained at www.microsoft.com. There are a few problems that are not documented by Microsoft, but that have been confirmed by Microsoft technical support. Here are the problems and the workarounds:
  • a single call to an SPC can return both parameters and a recordset. However, the calling code must use the recordset and close it before accessing the returned parameters. If the calling code needs to use the returned parameters first, then the SPC must be broken into two SPC's.
  • the text datatype is in the SQL Server Version 6.5 that is commercially available database management system, and can be returned to a calling ASP script in a recordset but not in a parameter.
  • a Session object is used to store information like the party_id of the user. This allows the system to distinguish one user from other users who are on the site at the same time. Forcing everyone to the Home Page
  • the response object that enables information to be transferred from a web server to a browser gives the system significant control over the HTML page that is returned to the user.
  • the system uses "response . redirect” to handle errors and other events, redirecting the browser to another page in the web site. Constants
  • constantsAndFunctions. inc This is a good place to check when making changes to things like the initial membership fee, the annual renewal fee, or the default time intervals for various processes.
  • At least one hardware server such as Dell server Model 6300 or any equivalent enterprise server and at least one software server, such as a Microsoft Internet Information Server.
  • the web site address of the preferred embodiment of the present invention is located at www . eclearing . com as of the filing date of this application for invention, which is hereby incorporated by reference and should be referred to for a complete understanding of the invention.
  • DBMS data base management system
  • the automatic funds controller 34 is preferably a triple-A bank, such as the Bank of America.
  • the lock box account avoids the necessity of a true "escrow account" with a financial institution, which would require each of the parties to sign and submit an escrow agreement for each transaction.
  • the present automated clearing system and method does not impose delivery requirements or limitations upon either party or other service tie-in restrictions.
  • the system is completely flexible to the extent that the seller need not wait until payment has cleared once a working relationship with a particular buyer has developed or other wise.
  • the controls provided to the parties are completely within their control and are not dictated by system requirements.
  • the present clearing system can handle both cases of billing.
  • each customer By having each customer initiate a transaction, each customer, in effect, creates their own "billing invoice".
  • the service company performs the services before being paid, even though the transaction is established through the clearing system.
  • a payment notice or a previously agreed payment period is in effect where the client just serviced is expected to remit payment to the clearing operation automatic funds controller lock box account.
  • the automatic funds controller then collects the funds, and the service provider can by observing the traffic light device associated with each of the pending transactions, determine at a glance which customers have paid and which have not.
  • Other customers may be treated differently by having them prepay or by having them consolidate billings from several locations of the customer.
  • other business that would have been turned down because of the fear of collection can now be safely handled, and all of these options can be accomplished from the single system.
  • FTP files containing pertinent data for a specific client is sent into the customers own internal collection/accounting system that will automatically automate the customer' s accounting, e-mailing of billings, past due notices, payment reminders, etc.
  • the system has many other uses.
  • the system can accommodate "lay-away" plans for two parties where a seller secures a buyer and is willing to hold the item purchased after an initial down payment has cleared and then wait an agree time period for a series of payments or a single payment after financing is obtained by the buyer .
  • the system can be used to pre-set bidding limits for auction buyers.
  • a buyer may desire to participate in an international auction that requires a percentage of the bidding limit to be deposited prior to the buyer being allowed to bid, and then after a successful bid the buyer must pay the balance. Both the deposit and the balance can be handled as one transaction by the clearing system.
  • the automated clearing system of the present invention can also be used to segment payments on a value-added project. For example, an artist may require an initial payment prior to beginning a family portrait and then want subsequent payments as different levels of completion are reached, and the system can handle all payments by setting up the transaction accordingly.
  • Other like examples include a construction or manufacturing contract which requires payment as different levels of construction or production are completed or as construction or production raw materials are acquired by the contractor.
  • the present clearing system is capable of facilitating any connectivity platform, any data base, any software application, any operating system, any type of computer or modem, many of which may not be compatible with each other on a stand alone or one to one basis, so long as connectivity to the internet which is now ubiquitous.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système de compensation (10) par transaction automatisée interactive caractérisé en ce qu'il comprend une opération de compensation automatique (28) contrôlée par un opérateur de compensation automatique et présentant des moyens permettant aux parties d'enregistrer une transaction proposée (30, 32) pour une compensation, et générant automatiquement des directives de paiement automatiques (44) conformément à la transaction proposée (30, 32), ainsi qu'un contrôleur de fonds automatique (34) contrôlé par une partie autre que l'opérateur de compensation automatique (28). Le contrôleur de fonds automatique (34) comprend des moyens permettant de recevoir les fonds des parties et d'effectuer automatiquement des paiements à partir des fonds conformément aux directives de paiement automatiques (44).
PCT/US2000/008284 1999-03-25 2000-03-24 Systeme et procede de compensation par transaction automatique WO2000057337A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU40406/00A AU4040600A (en) 1999-03-25 2000-03-24 Automatic transaction clearing system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12620499P 1999-03-25 1999-03-25
US60/126,204 1999-03-25

Publications (1)

Publication Number Publication Date
WO2000057337A1 true WO2000057337A1 (fr) 2000-09-28

Family

ID=22423557

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/008284 WO2000057337A1 (fr) 1999-03-25 2000-03-24 Systeme et procede de compensation par transaction automatique

Country Status (2)

Country Link
AU (1) AU4040600A (fr)
WO (1) WO2000057337A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8930267B1 (en) 2012-08-27 2015-01-06 Jpmorgan Chase Bank, N.A. Automated transactions clearing system and method
US11605045B2 (en) 2012-09-07 2023-03-14 MapMyld, Inc. Address exchange systems and methods

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4799156A (en) * 1986-10-01 1989-01-17 Strategic Processing Corporation Interactive market management system
US4903201A (en) * 1983-11-03 1990-02-20 World Energy Exchange Corporation Automated futures trading exchange
US4980826A (en) * 1983-11-03 1990-12-25 World Energy Exchange Corporation Voice actuated automated futures trading exchange
US5426281A (en) * 1991-08-22 1995-06-20 Abecassis; Max Transaction protection system
US5465206A (en) * 1993-11-01 1995-11-07 Visa International Electronic bill pay system
US5497317A (en) * 1993-12-28 1996-03-05 Thomson Trading Services, Inc. Device and method for improving the speed and reliability of security trade settlements
US5787402A (en) * 1996-05-15 1998-07-28 Crossmar, Inc. Method and system for performing automated financial transactions involving foreign currencies
US6029146A (en) * 1996-08-21 2000-02-22 Crossmar, Inc. Method and apparatus for trading securities electronically

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4903201A (en) * 1983-11-03 1990-02-20 World Energy Exchange Corporation Automated futures trading exchange
US4980826A (en) * 1983-11-03 1990-12-25 World Energy Exchange Corporation Voice actuated automated futures trading exchange
US4799156A (en) * 1986-10-01 1989-01-17 Strategic Processing Corporation Interactive market management system
US5426281A (en) * 1991-08-22 1995-06-20 Abecassis; Max Transaction protection system
US5465206A (en) * 1993-11-01 1995-11-07 Visa International Electronic bill pay system
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5497317A (en) * 1993-12-28 1996-03-05 Thomson Trading Services, Inc. Device and method for improving the speed and reliability of security trade settlements
US5787402A (en) * 1996-05-15 1998-07-28 Crossmar, Inc. Method and system for performing automated financial transactions involving foreign currencies
US6029146A (en) * 1996-08-21 2000-02-22 Crossmar, Inc. Method and apparatus for trading securities electronically

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8930267B1 (en) 2012-08-27 2015-01-06 Jpmorgan Chase Bank, N.A. Automated transactions clearing system and method
US10657530B2 (en) 2012-08-27 2020-05-19 Jpmorgan Chase Bank, N.A. Automated transactions clearing system and method
US11605045B2 (en) 2012-09-07 2023-03-14 MapMyld, Inc. Address exchange systems and methods

Also Published As

Publication number Publication date
AU4040600A (en) 2000-10-09

Similar Documents

Publication Publication Date Title
TW557431B (en) System and method for integrating trading operations including the generation, processing and tracking of and trade documents
US7987117B2 (en) System and method for providing an auction of real estate
US7596511B2 (en) Closing system for closing real-estate transactions between a plurality of parties
US7085735B1 (en) System and method for conducting the closing of a real estate sale over a computerized network
US7958049B2 (en) System and method for obtaining customer bill information and facilitating bill payment at biller websites
US7925586B2 (en) Method and system for multi-currency escrow service for web-based transactions
JP4943154B2 (ja) コンピュータ化されたトランザクション交渉システム及び方法
CA2570897C (fr) Systeme et procede de gestion de paiement de construction d'immeubles
US8533115B2 (en) Payment services for multi-national corporations
JP4234412B2 (ja) 電子商取引に係わる代金の決済サービス方法、決済システム、コンピュータプログラム、プログラム格納媒体
US20160328705A1 (en) Mediated conversion of cryptographic currency and other funding sources to gold
US20020120537A1 (en) Web based system and method for managing business to business online transactions
US20030074273A1 (en) Apparatus and method for facilitating trade
US20050055299A1 (en) System and method for facilitating a request for proposal process
US20030212609A1 (en) Method of facilitating a transaction between a buyer and at least one seller
EP1259924A2 (fr) Procede et systeme de commerce et d'activite electroniques
AU2001250580A1 (en) Electronic activity and business system and method
US20060074802A1 (en) Electronic payment system with rejection option
US20100217711A1 (en) System and method for facilitating a private commodity resource transaction
US20180012203A1 (en) Electronic payment system with option to accept or reject a proffered payment
EP1242941A1 (fr) Systeme et procede d'operations bancaires hypothecaires et services immobiliers associes
WO2000057337A1 (fr) Systeme et procede de compensation par transaction automatique
US10121153B1 (en) Online escrow service
US20170076287A1 (en) Electronic payment system with option to accept or reject a proffered payment
JP2001312624A (ja) コンピュータを用いた物品の取り引き方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP