WO2000057337A1 - Automatic transaction clearing system and method - Google Patents

Automatic transaction clearing system and method 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
French (fr)
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/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; 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.

Abstract

An interactive automated transaction clearing system (10) having an automatic clearing operation (28) controlled by an automatic clearing operator (28) and including means for parties to register a proposed transaction (30, 32) for clearing, and automatically generating automatic payment directions (44) in accordance with the proposed transaction (30, 32) and an automatic funds controller (34) controlled by a party other than the automatic clearing operator (28). The automatic funds controller (34) includes means for receiving the funds of the parties, and for automatically making payments from funds in accordance with the automatic payment directions (44).

Description

AUTOMATIC TRANSACTION CLEARING SYSTEM AND METHOD
BACKGROUND OF THE INVENTION
Field of the Invention
This invention generally relates to a clearing system and method and more particularly to an interactive automated transaction clearing system and method.
Discussion of the Prior Art
Automated systems that enable buyers and sellers to interact with respect to contractual transactions of buying and selling goods are known.
In U.S. patent 5,794,207 issued to Walker et al. on August 11, 1998, a commercial transaction system is shown in which computers are used with the public internet to enable automated communications for establishing binding contracts between sellers and buyers. If the parties elect, a central controller establishes an escrow account as an internal temporary holding account by transferring buyer's funds from an internal buyer's account to the escrow account when the seller accepts the offer. In such case, the funds are transferred from the internal escrow account to the seller's internal account only after the goods are received and the buyer transmits a release message to the central controller. Otherwise payments are made by credit card, electronic funds transfer or digital money to the buyers account are transferred to the seller's account without awaiting delivery. In the event of dispute, then the central computer enables the parties to arbitrate and presumably block payments from the escrow account until the arbiters decision or reverses transfers in accordance with the decision.
In U.S. patent 4,799,156 issued January 17,1989, to Shavit et al . , a centralized computer network is shown in which not only industrial buyer and sellers are represented but also represented are shippers, agents, financial institutions, service providers and other ancillaries that service the industry. These ancillaries may become involved in the original buyer-seller transaction, such as a bank providing financing or a shipper providing delivery. Buyer's orders may be modified before they are accepted and a transaction is closed. Users are enabled to have the system convey payment directions to the user's bank and advisories of the payment directions are automatically provided to the payee. The system requires these different types of users to remain in an online condition to enable the on-line processing of the concurrent interactive business transactions between the different types of users in a single industry.
In U.S. patent 5,870,723 issued February 9,1999, relates to a commercial transaction system in which the use of tokens, such a smart cards, are avoided. However, the buyer can only be identified by submission of a biological metric sample that has been previously registered for identification. Once identified, the buyer is enabled to transfer funds need for a transaction.
In U.S. patent 5,465,206, issued November 7, 1995, to Hilt et al., a computerized bill payment system is shown in which a consumer is enabled to authorize payment of a bill via a computer and a modem. This is achieved through the use of electric funds transfer, but no transactions are created, and the billing arrangement must be prearranged.
In U.S, 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.
In U.S. patent 5,433,468 of Abecassis, a transaction approval system is shown for processing transactions in which requires a purchase deposit slip which permits the exclusion of card information on the purchase deposit slip which providing for the inclusion of a delivery by date on the purchase deposit slip. Also, a single transaction number both identifies the deposit transaction and represents an approval number.
In U. S. patent 5,426,281 issued June 20, 1995 to Abecassis, a transaction protection system is disclosed in which delivery of payment occurs upon a future condition being met automatically and acts as a temporary depository control in the flow of monies between the parties, but the system requires an integrated credit/debit system , deposit slips and forms or convention checks combined with either credit card or deposit slips and points of sale terminals, computers or touch tone telephones. An escrow function is performed by the same system that controls the transaction monitoring.
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. In the iescrow system, after the transaction is created the buyer remits the purchase price plus a service fee that is a percentage of the purchase price. Disadvantageously, 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. Also, once the funds have cleared, the seller is instructed to ship. The shipment must be insured which adds a mandatory cost to the transaction whether warranted or not. Also, 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. 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.
At the internet location www . autoescrow . com the service provider holds the funds and title documents, itself, to permit the sale of automobiles over the internet. There is no interactive web page communication and all transactions must be the sale of automobiles.
Other known system named CyberCash and Ecash, referred to as safe payment systems, do not really clear transactions. Instead, they provide credit card information over the public internet to assure payment to the seller, but such assurance must be within the limits of the credit cardholders legal rights to challenge payment. Also, disadvantageously, the system requires the users to purchase software that must be used in their personal computers. This system, being limited to use of credit cards, does not accommodate larger business to business transactions.
The inventors have determined that these systems suffer from various disadvantages that limit their usefulness and also leave the funds of the parties relatively insecure and subject to risk of being included in the service operators estate in the event of bankruptcy. These systems do not appear well suited for use with the world wide web, or public computer internet, but depend upon the use of special terminals, special deposit slips or other special paper forms. They lack flexibility needed for alteration of agreement terms after transaction closing and fail to facilitate payments to agents or brokers of the clearing service, itself. They also fail to provide transactional status information in a clear and concise manner to avoid confusion and are not well adapted for general use by any party without respect to whether they are any particular type of user.
SUMMUARY OF THE INVENTION
It is therefore the principle object of the invention to provide an interactive automated transaction clearing system, having an automatic clearing operation controlled by an automatic clearing operator means for parties to register a proposed transaction for clearing, and for 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, automatic funds controller including for receiving the funds of the parties, and automatically making payments from the funds m accordance with the automatic payment directions.
The object is also achieved by providing 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.
Yet a further 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 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.
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.
The object is still further achieved by providing 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. BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing advantageous features of the interactive automatic clearing system and methods of the present invention will be described in greater detail and other advantageous features will be made apparent from the detailed description of the preferred embodiment that is given with reference to the several figures of the drawing, in which:
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; and
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; and
Fig.22E is another illustration of a Trial Balance web page similar to that of Fig.22d.
DETAILED DESCRIPTION
Referring now to Fig.l, 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. Likewise, 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. 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.
In accordance with the operation of the clearing system 10, after a buyer 22 a seller 24 have completed informally negotiating their deal terms, or the seller solicits an offer. 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. Thus, 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.
However, preferably, only 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. After 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.
As seen, 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 .
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. When 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. At this point in the process, the seller is not allowed to propose modification or changes to the transaction as proposes by the seller.
If the seller accepts the proposal by so indicating in the Message Center window, such as shown in Fig.9H, and submitting the acceptance as part of the buyers transaction information 30. Then 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.
This account has so-called "lock box" services associated with it. Advantageously, 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.
In any event 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. In the case of EFT, wire transfer or SWIFT transfer to the dedicated customer account, the seller must fill out the appropriate information shown in Fig.8. In the case of a bank draft or check, 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.
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.
Advantageously, when a part goes to the View All Transactions page, such as shown in Figs . δC and 11, a traffic light device appears alongside each listed transaction. This device advantageously enables both the parties to quickly determine clearing status at a glance. When the funds have not yet been deposited or only a partial payment has been deposited, the traffic light is caused to display a lit red light. After the funds have been received, but not yet collected, such as in the case of a check, then the yellow light of the traffic light device is lit, and the red light is turned off. When the funds are collected then 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. On the other hand, a federal wire transfer, an Automated Clearinghouse (ACH) transfer and an international SWIFT transfer clear immediately upon being received.
In this way both the seller and the buyer can tell by a quick glance at the display, the status of the funds collection process. 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.
Once full payment has been collected from the buyer into the account of the automatic funds controller 34, 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.
Once the seller has shipped the goods or has provided the services, 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.
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. However, in the absence of intervention by the buyer, when the automatic funds release interval has passed from the time of the seller's certification of shipment, the funds are automatically released to the seller. When the time interval lapses, 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. 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. Alternatively, 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.
Referring to Fig.2, preferably all transactions and communications are achieved automatically via data communication between various software applications that are run on various computers. 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.
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. For a check, payment information includes the check number. For an EFT, wire or SWIFT transfer, 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.
Once all of the conditions of a transaction have been met, meaning that the transaction has progressed to state S6 of the state transition diagram of Figs.3A-D, the automatic clearing operation is ready to direct the automatic funds operator 34 to disperse funds. Periodically, preferably every night, 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.
Referring to 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.
Technically, after the complainant completes the HTML complaint of Fig.l4D and submits it to the automatic clearing operation web site application, 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. During the next session at the clearing site by the complainant, 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. In addition 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.
After the reply is submitted, 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 . When 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.
If 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. Preferably, together with other information provided at time of registration 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. When a customer enters the merchant's webstore and selects an item for purchase, the buyer is automatically directed by hyperlink to the automatic clearing operation web site. In addition, 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". 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. In this diagram and the following description buyers and sellers are collectively called parties. The current status of a transaction is known as its "state". For example, the state of transaction 479 could be "waiting to receive funds from buyer". States are represented as circles on the state transition diagram.
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.
It should be understood that 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. In order to determine a chronology of successive states, it is necessary to examine the succession of events from state zero to the state under consideration. The state transition diagram is used in many ways to represent and understand the operation of the automatic clearing system. First, in order to determine 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. Secondly, in keeping with the invention, 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. Thirdly, by operating the system in accordance with the state diagram improves security and reliability by assuring that all possible situations have been enumerated.
The following is a list of all the states and all of the events that can lead to the states of the state transition diagram of Figs.3A-4 and 4. States
50. State 0. Start
51. State 1. Waiting for approval of the Seller.
52. State 2. Waiting to receive funds from Buyer.
53. State 3. Waiting for Seller to certify shipment of Goods .
54. State 4. Waiting for a payment trigger event.
55. State 5. Payable as soon as inbound funds have cleared.
56. State 6. Done.
57. State 7. Waiting for response from underpaying Buyer.
58. State 8. Wait for approval of price reduction of Seller.
59. State9. Waiting for response from overpaying Buyer. S10. State 10. Waiting for response to cancellation request . SH. State 11. Waiting for response to requested change in interval . 512. State 12. Refund is authorized pending clearance.
513. State 13. Waiting for Buyer to certify return shipment .
51 . State 14. Waiting for Seller's response to proposed price reduction.
515. State 15. Payment frozen.
516. State 16. Waiting for response to interval change request .
517. State 17. Waiting for response to price change request .
518. State 18. Waiting for response to cancellation request .
519. State 19. Waiting for refund trigger event.
520. State 20. Refund payment is frozen by Seller.
521. State 21. Waiting for approval of penalty by Buyer.
522. State 22. Waiting for checks to clear.
523. State 23. Waiting for inbound checks to clear.
524. State 24. Waiting for inbound checks to clear. -Events
EOA. Event 0A. Buyer initiates a transaction.
E1A. Event 1A. Seller approves the transaction.
E1B. Event IB. Seller rejects proposed transaction.
E2A. Event 2A. Party requests cancellation.
E2B. Event 2B. Party requests price change.
E2C. Event 2C. Party requests change in interval from shipment-of-goods to release-of-funds .
E2D. Event 2D. Funds arrive. Amount is correct.
E2E. Event 2E . To much money arrives.
E2F. Event 2F. To little money arrives.
E3A. Event 3A. Seller certifies that goods have shipped.
E3B. Event 3B . Party requests change in interval from shipment-of-goods to release-of-funds.
E3C. 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. Buyer proposes a price reduction. E4E. Event 4E. buyer rejects the shipment. E5A. Event 5A. Pay seller in part or in full, and refund to buyer in part if necessary. E7A. Event 7A. "It was an error"
E7B. Event 7B. "We agreed on a price reduction." E8A. Event 6A. Seller approves reduced price; now paid in full. E6B. 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 . E10B. Event 10B. Counter party rejects cancellation request . E11A. Event HA. Counter party requested change in interval; new interval holds. EllB. 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. Buyer certifies that goods have been shipped. E14A. Event 14A. Seller accepts proposed price reduction. E14B. Event 14B. Seller rejects proposed price reduction. E15A. Event 15A. Buyer releases hold, authorizing immediate payment . E15B. Event 15B. Buyer rejects the shipment. E15C. Event 15C. Buyer maintains hold, proposing a price reduction. E16A. Event 16A. Counter party accepts requested change interval, old interval holds. E16B. Event 16B. Counter party rejects requested change in interval, old interval holds. E17A. Event 17A. Counter party accepts price change, deal at new price. E17B. Event 17B. Counter party rejects price change, deal at old price. E18A. Event 18A. Counter party accepts cancellation request . E18B. Event 18B. Counter party rejects cancellation request so original deal holds. E19A. Event 19A. Predestinated interval has passed. Note that seller has been warned of imminent expiration. E19B. Event 19B. Seller releases refund. E19C. Event 19C. Seller places hold on refund. E19D. Event 19D. Seller requests buyer to pay a penalty for damaged goods . E20A. Event 20A. Seller releases hold authorizing payment of refund. E20B. Event 20B. Seller requests buyer to pay a penalty for damaged goods . E21A. Event 21A. Buyer rejects penalty request. E21B. Event 21B. Buyer accepts penalty request. E22A. Event 22A. Inbounds have cleared so make payments. E23A. Event 23A. Inbounds have cleared so make payments. E24A. 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 . In addition, 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 .
CREATE TABLE dbo . party_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 three fields ost_recent, secondjnost_recent, and third most recent allow us to track failed login attempts. For security purposes, three failed passwords within 24 hours results in a lockout. This lockout only lasts until manually overridden by the operator of the clearing operation.
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.
It is important to note that creation of a reseller requires creation of a record in the party_for the reseller that leaves this field null and to then create the reseller payment method and then to update this record. Otherwise, there will not be compliance with the triggers. (For example, see create reseller .asp. )
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.
It is important to note that the reseller id is the party id of the reseller who brought in the buyer or the seller represented by this record. Thus if reseller Ron Robbins signed up buyer Bob Brown, their would be two records as follows:
Figure imgf000040_0001
The role is one of the following, in in lower case only:
Figure imgf000040_0002
contact_info table
Because there is a limit on the number of characters per record in the party_table, a contact_info_table, as follows :
CREATE TABLE dbo . contact^info_table ( Party_id int NOT NULL , First_name varchar (25) NOT NULL , Middle_initial char (1) NULL , Last_name varchar (40) NOT NULL , Title varchar (40) NULL , Company varchar (40) NULL , Address_line_l varchar (80) NULL , Address_line_2 varchar (80) NULL , Address_line_3 varchar (80) NULL , City varchar (25) NULL , State_or_Province varchar (20) NULL , Zip varchar (10) NULL , Country varchar (20) NULL , City_code varchar (3) NULL , Voice varchar (24) NULL , Fax varchar (24) NULL , Email varchar (40) NOT NULL The party_id is a foreign key reference to the party_table . Most fields are self-explanatory . 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) . For a reseller, 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 . transaction table
Every time a buyer initiates a transaction, a single record for that transaction is created in this table . Every step in that transaction yields a new record in the event_table, but merely updates the fields of the single record in the transaction table .
CREATE TABLE dbo . 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 NULL )
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:
Figure imgf000042_0001
events ;
Distributions have been authorized;
They are payable as soon as all inbound checks have cleared.
All inbound checks have cleared; All distributions have been made; Transaction is complete.
Figure imgf000043_0001
Figure imgf000044_0001
Figure imgf000045_0001
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. Advantageously 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
As noted, the transactions move from one state to another state via events. Those events are recorded in this table. This table allows us to recreate the chronology (the "sequence of events") leading to the current situation by selecting all events related to a particular transaction, and ordering them by their event date. It also provides the detailed information necessary to flesh out a message in the Message Center.
CREATE TABLE dbo . 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:
Figure imgf000046_0001
Figure imgf000047_0001
Figure imgf000048_0001
Figure imgf000049_0001
Figure imgf000050_0001
Figure imgf000051_0001
Figure imgf000052_0001
Figure imgf000053_0001
Figure imgf000054_0001
Figure imgf000055_0001
Figure imgf000056_0001
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.
Every message in message_table points to an event in event_table in order to get the details to present to the message recipient. Therefore, "pure messages" that are not associated with a real event must point to a dummy event for details. These dummy events carry an event_code of "xxx". message_table
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 (such as asking a party to accept or reject a proposed price change) 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.
Since the same party may receive more than one message related to a single event, role is used to select the appropriate message template. If there is only one message template associated with a particular event, then the code ignores this field. The allowed values, which are always upper case are:
Figure imgf000058_0001
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.
It should be noted that triggers check all of the foreign key references on insertions and deletions. headsup_ table The headsup_table 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.
CREATE TABLE dbo . 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 )
There are several uses of the headsup_table . When a check is received, 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 active server pages, or ASP, technology of Microsoft at www.microsoft . com and reference should be made to this cite for further information. Clearance is significant because many sellers will not ship until checks have cleared.
When a seller certifies that goods have been shipped, the system schedules an automatic release of funds to the seller a preselected time interval x calendar days later. Advantageously, 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.
When a transaction has progressed to the point where ECC should disburse funds, we schedule a payment to be made when a "transaction has been cleared". A transaction has "cleared" when all its inbound checks have "cleared".
The three logical types of headsup records are:
Figure imgf000059_0001
Figure imgf000060_0001
"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. For example, 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:
Figure imgf000061_0001
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 .
CREATE TABLE dt o . paymei it s table ( trans id i nt NOT NULL /
Party id int NOT NULL / description varchar (255) NULL , amount numeric (9, 2) NOT NULL , maturity smalldatetime NOT NULL , pmt_date smalldatetime NULL
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:
Figure imgf000062_0001
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.
There are many things to note concerning proper use of this table. First, it should be noted that the initial entry and all changes thereto carry the same description. Thus, if the initial price is $100, and it is later changed to $80, the following records (plus others relating to Initial membership fee, Renewal fee, and Transaction fee) appear:
Figure imgf000063_0001
The following important items should also be noted:
1. The original purchase price and all changes carry the same description line.
2. All amounts owed have an immediate maturity. Only payments by check have deferred maturity.
3. 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.
5. When this transaction is created, the "Initial membership fee" or the "Renewal fee" could be assessed against buyer, seller, or both. These fees only become due on your first transaction in a new membership year, so they are associated with that transaction in the payment table.
6. 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.
7. 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.
8. When a payment of $100 is received from the buyer, it is recorded as -$100 in a buyer-related record in this table. This is because the buyer now owes ECC $100 less. The date of maturity is immediate for wire transfers and ACH transactions, and x days hence for checks .
9. When an outbound transfer of $100 is made to a party, it is recorded as +$100 in the record. This is because the party "owes" ECC $100 more. Note that outbound transfers are recorded in the payment table when they are authorized and not when they are made. Payments are "authorized" when all logical conditions have been satisfied for payments. Payments are "made" when they are "authorized" and all funds received by ECC have cleared. exception_table The exception table is used to keep information that should be reported to ECC management. This is used as a management and a security device. For example, ECC management should know about large transactions, rejections and lockouts.
CREATE TABLE dbo . exception_table ( trans_id int NOT NULL , message varchar (200) NOT NULL , priority tinyint NOT NULL , exception_date smalldatetime NOT NULL , reporting__flag bit NOT NULL )
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.
CREATE TABLE dbo . debarred parties table last name varchar (60) NULL first name varchar (60) NULL company varchar (60) NULL
payment_me thod_ table
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.
For security reasons, no one is allowed to change a payment method record.
CREATE TABLE dbo. payment method table ( method id int IDENTITY (1, 1) NOT NULL ,
Party i d int NOT NULL , method code char (2) NOT NULL , institution name varchar (60) NULL , institution number varchar (40) NULL , institution location varchar (80) NULL, account name varchar (60) NULL , account number varchar (40) NULL )
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:
Figure imgf000067_0001
Advantageously, 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.
reporting_table
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.
CREATE TABLE dbo . reportιng_table (
Figure imgf000068_0001
reportmg_date smal ldatetime NOT NULL , reference varchar ( 150 ) NULL , amount numeric ( 9 , 2 ) NOT NULL , reported flag bit NOT NULL
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 . arbitration_table
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 .
CREATE TABLE dbo . 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. As explained above, 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.
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. In addition, 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"). Finally, theseller is notified of the proposed transaction and asked for a response. This is done by creating a record in the message_table.
When the seller logs in, the Main Menu will show that one message has been received in the Message Center. When he goes to the Message Center, a brief summary of the message will be displayed, such as shown in Fig.12. When 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.
The code, a copy of which is submitted herewith as Appendix A, is heavily commented and is incorporated herein by reference. Each HTML page, Active Server Page (ASP) script, and Stored Procedure Call (SPC) identifies its purpose, identifies which modules call it, and identifies which modules are called by it. Variables are named in understandable ways, and the code is organized consistently. However, several issues warrant additional explanation as follows: Database Issues
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:
• Under normal circumstances, currency data should be stored in a database using a precise data type (such as numeric) and not an imprecise data type (such as single or double) . However, the corresponding value in the Parameter object (adNumeric) has a bug that causes it to round down to the nearest dollar. Therefore, in the implementation of the invention the value adDouble is used in the Parameter object. This is an imprecise data type, so it may round, but it does not suffer from the rounding bug. Although rounding errors are now possible, they would not be observed for values under one billion dollars. This is believed sufficient.
• 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.
Reference should be made to the article "Passing Parameters to and from Microsoft SQL Server Stored Procedures" by Mike Pope and available in the Microsoft Knowledge Base at their web site at www.microsoft . com.
Virtual Sessions
The travels of a user through the system web site are made coherent through a virtual session. 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
Every visitor to any portion of the web site is forced to enter through the home page of Fig.5, even if they have bookmarked or otherwise another page at the site. This is done with a script in the global. asa file using a know technique. Response Object
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 .buffer = true" to make sure that it can build the HTML page in its entirety on the server before transmitting to the browser. This allows the system to handle a special situation or an error by clearing the buffer and redirecting to another web page .
The system uses "response . expires = 0" to indicate to the browser of the user to reload this page every time the user selects it for viewing. Otherwise, some of the dynamic pages would show the user obsolete information.
The system uses "response . redirect" to handle errors and other events, redirecting the browser to another page in the web site. Constants
Many system constants are defined in the include file called 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.
Handling Annual Fees
Annual user registration fees are added into the first transaction processed for a particular party in a particular year. If that transaction does not go to completion, then those fees are never actually paid. Therefore, the fee_status field in the party_table for those parties is reset. The next transaction would reflect the annual fees . However, another transaction that is already in progress, but not yet completed, would not be adjusted to show those fees. It is believed that this would be confusing for the parties.
While the best mode of practicing the invention as presently contemplated has been disclosed in detail with respect to a particular exemplary embodiment that has been disclosed with respect to use of the world wide web or "the internet". However it should be appreciated that the sytem could also be implemented on an "intranet", on an "etranet" and on a virtual private network, or VPN, or on a stand alone computer.
Likewise, although preferably multiple servers, 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. Thus, there is one web application with a data base management system, or DBMS .
Hopefully, all of the advantages of the invention are now appreciated. These advantages include, but are not limited to, the ability of the system to obtain for the benefit, for not only the operator of the automatic clearing operation, but also for the users, of the automatic clearing system of the present invention, protection of the funds in a customer dedicated lock box account. 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.
Unlike other systems, 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.
For example, in a case where a service company provides service on "credit billing" basis and on a prepay basis also, the present clearing system can handle both cases of billing. By having each customer initiate a transaction, each customer, in effect, creates their own "billing invoice". For the customer who has acceptable credit with the service company, the service company performs the services before being paid, even though the transaction is established through the clearing system. After the agreed service cycle is complete, 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. In addition, 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.
In keeping with another advantage of the 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. For example, 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. For example, 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.
Advantageously, 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.
Thus, the invention is not limited to the particular details that have been disclosed here.

Claims

1. An interactive automated transaction clearing system, comprising: an automatic clearing operation controlled by an automatic clearing operator and including means for parties to register a proposed transaction for clearing, and means for 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, said automatic funds controller including means for receiving the funds of the parties, and means for automatically making payments from said funds in accordance with the automatic payment directions .
2. The automatic transaction clearing system of claim 1 in which the automatic funds controller includes means for preventing the automatically making payments means from making payments in response to other than the automatic payment directions.
3. The automatic transaction clearing system of claim 2 in which the preventing means includes means for making payments pursuant to the automatic payment directions only if they are received in correctly encrypted form.
4. The automatic transaction clearing system of claim 3 in which the preventing means include means for receiving payment directions for all of a plurality of transactions only once per preselected time period in a single encrypted data file.
5. The automatic transaction clearing system of claim 2 in which the automatic payment directions generating means includes means for preventing alteration of the automatic payment directions by other than transactional information provided to the transaction register means by the parties.
6. The automatic transaction clearing system of claim 5 in which the alteration preventing means include means for denying access to the parties to alter the transaction unless the parties use a correct password that is unknown to the automatic clearing operator.
7. The automatic transaction clearing system of claim 1 in which at least some of the funds received by the funds controller is in the form of a check payable to a designee of the automatic clearing operator, said check being collectable by the automatic funds controller independently of the automatic clearing operator.
8. The automatic transaction clearing system of claim 7 in which the funds controller is a regulated banking institution and the checks are deposited in a customer dedicated lockbox account of the automatic clearing operator .
9. The automatic transaction clearing system of claim δ in which all the funds of all parties to all transactions are co-mingled in the customer dedicated lockbox account.
10. The automatic transaction clearing system of claim 1 in which the automatic funds controller includes means for providing funds clearing information to the automatic clearing operation.
11. The automatic transaction clearing system of claim 10 in which the automatic clearing operation includes means for selectively providing the funds clearing information of all transactions to the parties to the transaction.
12. The automatic transaction clearing system of claim 11 in which the funds clearing information providing means includes means for displaying a graphic element in association with a display of each transaction, said graphic element and means for changing a visual characteristic of the graphic element in response the clearing information indicating corresponding changes of clearing status as automatically reported to the automatic clearing operation by the automatic funds controller .
13. The automated transaction clearing system of claim 12 in which the graphic element is a representation of a traffic light having a plurality of different colored lights that are respectively lit when the funds are received, when the funds are in the process of being collected and when the funds are collected.
14. The automated transaction clearing system of claim 13 in which the three colors are red, yellow and green for respectively representing when the funds are received, when the funds are being collected and when the funds are collected.
15. The automatic transaction clearing system of claim 10 in which the funds clearing information providing means includes means for automatically sending an encrypted data file containing the funds clearing information to the automatic clearing operation.
16. The automatic transaction clearing system of claim 15 in which the encrypted data file sending means includes means for periodically sending the data file to the automatic clearing operation.
17. An automatic transaction clearing system, comprising: an automatic clearing operation web site application for automatically conveying transaction information through a computer internet with remote buying parties and selling parties in response to receipt of funds clearing information; 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.
lδ. The interactive automatic transaction clearing system of claim 17 in which the notification email is automatically sent to both the buyer and the seller.
19 The interactive automatic transaction clearing system of claim 17 in which automatic email notification is sent in the case of the occurrence of any one of the events (a), (b) and (c) .
20. The interactive automatic transaction clearing system of claim 17 including means for the automatic clearing operation web site application to display at a web site a graphic element with a visual characteristic that changes in accordance with changes in the status of funds clearing for the transaction, in addition to sending the automatic email notification.
21. The interactive automatic transaction clearing system of claim 20 in which the graphic element is a traffic light with different light areas that lighten to indicate an associated status of a transaction.
22. An interactive automatic transaction clearing system, comprising: an automatic transaction clearing internet server with means 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 means for 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.
23. The interactive automatic clearing system of claim 22 in which the element is a traffic light with three different light areas that light to respectively represent the conditions of (a) no funds received, (b) funds received but not yet collected, and (c) funds collected.
24. The interactive automatic clearing system of claim 23 in which the light areas light in the colors of red, yellow and green for the status conditions of (a) , (b) and (c) .
25. An interactive automatic transaction clearing system, comprising: an automatic transaction clearing internet application with means 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.
26. The interactive automatic clearing system of claim 25 in which the enabling means includes an interactive page of the web site at which on of the parties is permitted to make a proposed adjustment to a previously closed transaction and the other party is permitted to accept the proposed adjustment.
27. An interactive automatic transaction clearing system, comprising: 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 with means for generating an interactive internet web page 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.
26. The clearing system of claim 27 including a financial institution with means for collecting funds to be paid by the buyer and means for automatically conveying the status of collection to the automatic transaction automatic transaction clearing internet application, and means for automatically freezing any funds collected and preventing their delivery to the seller immediately in response to initiation of an arbitration at the interactive arbitration web page.
29. The system of claim 27 in which the automatic clearing internet application includes an interactive web page in which the parties must agree to binging arbitration using the interactive arbitration services in order to register a transaction for clearing.
30. The system of claim 27 in which the internet arbitration application includes an interactive web page in at which a complaining party to the transaction may submit a statement of the complaint to an arbitrator over the internet.
31. The system of claim 30 in which the interactive arbitration web page includes means for the enabling access to the answer by the complaining party and means for enabling the complaining party to submit a reply to the answer to the arbitrator over the internet.
32. The system of claim 30 in which the interactive arbitration web page includes means for enabling access to the complaint by the responding party and means for enabling the responding party to submit an answer to the complaint to the arbitrator over the internet.
33. The system of claim 32 in which the interactive arbitration application includes means for detecting whether an answer has been submitted within a preselected time period and, if not, to automatically enter a default judgment in favor of the complainant.
34. The system of claim 27 in which the clearing internet application includes means for maintaining a chronological log of all aspects of the transaction, and means for automatically submitting the chronological log to the arbitrator through transmission to the arbitration application . O 00/57337
35. The system of claim 34 in which the arbitration application includes means for maintaining a log of the submissions made by the parties to the arbitration and means for conveying this information to the clearing application for display to the parties.
36. The system of claim 27 in which the internet arbitration application includes means for the arbitrator to convey an arbitration decision to the parties over the internet, means for the arbitrators decision to be conveyed to the automatic transaction clearing internet application and means associated with the automatic clearing internet application for enabling release of the funds by the financial institution to the seller or refund of the funds to the seller in whole or in part base upon the arbitrators decision.
37. An interactive automated transaction clearing system, comprising: an automatic transaction clearing internet application with means for generating an interactive internet transaction web page that enables parties to interactively enter into agreements to remotely close unfulfilled contract including means for entering a referral code for each customer; means for generating an administration page at which a administrator may enter a referral code for prospective resellers for storage; and means for automatically attaching the code to all transactions by the customer subsequent to the one transaction when the customer first enters the referral code . 00/57337 QJ
38. The system of claim 37 including means for automatically annexing the referral code to a customer account number whenever the referred customer registers either as a seller or as a buyer.
39. The system of claim 37 including 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.
40. The system of claim 39 including means for the storage of electronic funds transfer information for the reseller and in which the automatic funds controller includes means to pay the commission to the reseller via electronic funds transfer based on the stored information .
41. The system of claim 38 including means for establishing a new number for a subagent of a reseller.
42. The system of claim 41 including means for linking the reseller to all transactions in which the subagent has been identified with the transaction.
43. The system of claim 42 including means for periodically generating reports of all transactions, means responsive to the transactions with customer account numbers with attached subagent referral code for computing commissions for the resellers with linked to such subagent codes, and means for directing automatic funds controller to pay the reseller the commission.
44. An interactive, automated method of clearing a transaction, comprising the steps of: controlling an automatic clearing operation by an automatically clearing operator to registering parties for a proposed transaction for clearing, and automatically generating automatic payment directions m accordance with the proposed transaction; and controlling an automatic funds controller by a party other than the automatic clearing operator to receive the funds of the parties, and automatically make payments from said funds m accordance with the automatic payment directions .
45. The method claim 44 includmg the step of preventing the automatically making payments means from making payments response to other than the automatic payment directions .
46. The method of claim 45 including the step of making payments pursuant to the automatic payment directions only if they are received m correctly encrypted form.
47. The method claim 46 including the step of receiving payment directions for all of a plurality of transactions only once per preselected time period m a single encrypted data file.
48. The method claim 45 including the step of preventing alteration of the automatic payment directions by other than transactional information provided to the transaction register means by the parties.
49. The method claim 48 including the step of denying access to the parties to alter the transaction unless the parties use a correct password that is unknown to the automatic clearing operator.
50. The method of claim 45 including the step of receiving at least some of the funds by the funds controller in the form of a check payable to a designee of the automatic clearing operator, said check being collectable by the automatic funds controller independently of the automatic clearing operator.
51. The method of claim 50 which the funds controller is a regulated banking institution and including the step of depositing the checks in a customer dedicated lockbox account of the automatic clearing- operator .
52. The method of claim 51 including the step of co- mingling all the funds of all parties to all transactions in the customer dedicated lockbox account.
53. The method of claim 44 including the step of providing automatic funds controller clearing information to the automatic clearing operation.
54. The method of claim 53 including the step of selectively providing the funds clearing information of all transactions to the parties to the transaction.
55. The method of claim 54 including the steps of displaying a graphic element in association with a display of each transaction, changing a visual characteristic of the graphic element in response the clearing information to indicate corresponding changes of clearing status as automatically reported to the automatic clearing operation by the automatic funds controller .
56. The method of claim 55 in which the graphic element is a representation of a traffic light having a plurality of different colored lights and including the step of respectively lighting the colored lights when the funds are received, when the funds are in the process of being collected and when the funds are collected.
57. The method of claim 56 in which the three colors are red, yellow and green for respectively representing when the funds are received, when the funds are being collected and when the funds are collected.
58. The method claim 53 including the step of automatically sending an encrypted data file containing the funds clearing information to the automatic clearing operation.
59. The method claim 58 including the step of periodically sending the data file to the automatic clearing operation.
60. A method of automatically clearing a transaction transaction clearing system, comprising 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 reporting funds clearing information to the automatic clearing operation web site application; with an automatic funds controller application distinct and remote from the automatic clearing operation web site application for 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 return of a check uncollected, and (c) completion of a transaction.
61. The method of claim 60 including the step of automatically sending notification email to both the buyer and the seller.
62. The method of claim 60 including the step of sending automatic email notification in the case of the occurrence of any one of the events (a) , (b) and (c) .
63. The method of claim 60 including the step of displaying at a web site a graphic element with a visual characteristic that changes in accordance with changes in the status of funds clearing for the transaction, in addition to sending the automatic email notification.
64. The method of claim 63 including the step of lightening different area of a graphic element in the form of a which is a traffic light to indicate an associated status of a transaction.
65. An interactive method of automatically clearing a transaction, comprising 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 one represented by the changeable graphic characteristic being displayed.
66. The method of claim 65 including the step lighting different light areas to respectively represent the conditions of (a) no funds received, (b) funds received but not yet collected, and (c) funds collected.
67. The method 66 in which the light areas light in the colors of red, yellow and green for the status conditions of (a) , (b) and (c) .
68. An interactive automatic method of clearing a transaction, comprising 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.
69. The method of claim 68 including, the step of an interactive page of the web site at which one of the parties is permitted to making one of the parties a proposed adjustment to a previously closed transaction by interacting with an interactive page of the web site and the other party to accepting the proposed adjustment by interacting with the interactive page of the web site.
70. A method of automatically transacting a clearing transaction, comprising the steps of: generating an interactive web page with an internet arbitration application of 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 the step of 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.
71. The method claim 70 including the steps of collecting funds to be paid by the buyer from a financial institution for automatically conveying the status of collection to the automatic transaction automatic transaction clearing internet application, and automatically freezing any funds collected and preventing their delivery to the seller immediately in response to initiation of an arbitration at the interactive arbitration web page.
72. The method of claim 70 including the step of the automatic clearing internet application having an interactive web page in which the parties must agree to bringing arbitration using the interactive arbitration services in order to register a transaction for clearing.
73. The method of claim 70 including the step of internet arbitration application having an interactive web page in at which a complaining party to the transaction may submit a statement of the complaint to an arbitrator over the internet.
74. The method of claim 73 including the step of enabling access to the answer by the complaining party and means for enabling the complaining party to submit a reply to the answer to the arbitrator over the internet.
75. The method of claim 73 including the step of enabling access to the complaint by the responding party and means for enabling the responding party to submit an answer to the complaint to the arbitrator over the internet.
76. The method of claim 75 including the step of detecting whether an answer has been submitted within a preselected time period and, if not, to automatically enter a default judgment in favor of the complainant.
77. The method of claim 70 including the step of maintaining a chronological log of all aspects of the transaction, and means for automatically submitting the chronological log to the arbitrator through transmission to the arbitration application.
78. The method of claim 77 including the step of maintaining a log of the submissions made by the parties to the arbitration and means for conveying this information to the clearing application for display to the parties.
79. The method of claim 70 including the step conveying an arbitration decision by the arbitrator to the parties over the internet, conveying the arbitrators decision to the automatic transaction clearing internet application and enabling release of the funds by the financial institution to the seller or refund of the funds to the seller in whole or in part base upon the arbitrators decision with the automatic clearing internet application.
80. A interactive automated method for clearing a transaction, comprising the steps of: generating an interactive internet transaction web page with an automatic transaction clearing internet page that enables parties to interactively enter into agreements to remotely close unfulfilled contracts including means for entering a referral code for each customer; generating an administration page at which a administrator may enter a referral code for prospective resellers for storage; and automatically attaching the code to all transactions by the customer subsequent to the one transaction when the customer first enters the referral code.
81. The method of claim 80 including the step of automatically annexing the referral code to a customer account number whenever the referred customer registers either as a seller or as a buyer.
82. The method of claim 80 including the step of periodically generating reports of all transactions, responding to the transactions with customer account numbers with attached reseller referral code for computing commissions for the resellers with such codes, and directing automatic funds controller to pay the reseller the commission.
63. The method of claim 82 including the step of storing electronic funds transfer information for the reseller and in which the automatic funds controller includes paying the commission to the reseller via electronic funds transfer based on the stored information.
84. The method of claim 62 including the step of establishing a new number for a subagent of a reseller, and linking the reseller to all transactions in which the subagent has been identified with the transaction.
65. The method of claim 84 including the step of periodically generating reports of all transactions, transacting customer account numbers with attached subagent referral code for computing commissions for the resellers with linked to such subagent codes, and directing automatic funds controller to pay the reseller the commission.
PCT/US2000/008284 1999-03-25 2000-03-24 Automatic transaction clearing system and method WO2000057337A1 (en)

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 (en) 2000-09-28

Family

ID=22423557

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/008284 WO2000057337A1 (en) 1999-03-25 2000-03-24 Automatic transaction clearing system and method

Country Status (2)

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

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 (en) Computerized transaction negotiation system and method
CA2570897C (en) Construction payment management system and method
US8533115B2 (en) Payment services for multi-national corporations
JP4234412B2 (en) Payment service method for electronic commerce, payment system, computer program, program storage medium
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 (en) Electronic activity and business system and method
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
WO2001027832A1 (en) A system and method facilitating mortgage banking and related real estate services
US20180012203A1 (en) Electronic payment system with option to accept or reject a proffered payment
WO2000057337A1 (en) Automatic transaction clearing system and method
US10121153B1 (en) Online escrow service
JP2003076777A (en) Business plan for international electronic settlement, distribution and transaction assurance
US20170076287A1 (en) Electronic payment system with option to accept or reject a proffered payment
JP2001312624A (en) Dealing method for article using computer

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