The bonded marketplace enables guarantees for individual auctions or transactions and performance bonds to cover multiple transactions involving a bonded seller. Below is an excerpt from the patent specification:
Applying for a Seller Bond or a Purchase Transaction Guaranty
FIG. 5 illustrates a flow diagram documenting the process by which a bond or guaranty is applied for, evaluated, legally bound and deployed. Sub-processes are broken out in more detail in later figures.
Having registered with the Site, the registered user logs in 501, views information about bonds and guaranties, and selects whether she wants to apply for a bond or guaranty 502. If the bond choice is selected, the User selects the desired bond duration 503 and penal sum from a menu and submits information requested in a variety of data fields 504. The requested information includes fields such as: a1. Principal type of merchandise or services sold, which is selected from a menu including computer software, hardware, clothing, music and video media, and other merchandise categories a2. Percentage of sales derived from the category chosen in a1 a3. Secondary type of merchandise (same menu) a4. Percentage of sales derived from the category chosen in a3 b. Expected total revenue from Internet sales b2. Last year’s total revenue from Internet sales c. Average# of transactions d. User’s Social Security# e. User’s bank 1 f. Bank account number at bank 1 g. User’s bank 2 h. Bank account number at bank 2 i. User’s employer j. Employer’s address k. Employer’s city l. Employer’s state m. Employer’s postal code n. Employer’s country o. Employer’s phone p. Employer’s fax q. Employer’s email r. Employer’s web site s. Credit Reference 1 (credit card, other loan institution) t. Account number for Reference 1 u. Credit Ref 2 v. Account number for Credit Ref 2 w. Annual income x. All email accounts used by seller (repeating field) y. All web sites (by URL) used by seller (auction sites, personal sites, etc.) (repeating field) z. Credit card to be charged–type (MC/Visa/AmEx) aa. Card number ab. Card exp. date ac. Name on card ad. Billing zip ae. Answers to various questions such as “Do you sell home-made copies of commercial software?” are also requested af. Previous bond number, if any ag. Password for the previous bond, if any
Typically, the more credit references and dependable identifying information the user provides, the more likely she is to be approved for a bond and/or the less expensive that bond will be, as discussed below in reference to FIG. 6, since such information helps to reduce the Company’s risk. If the seller wishes to take advantage of instant payment from bonded bidders’ deposit accounts per the process described in FIG. 19, routing numbers for wire transfers must also be provided.
When the application is submitted, a new record is created 504 in the Applications Database. The application is evaluated 505 per the Automated Bond Application Review Process depicted in FIG. 6. This sub-process returns a result 509: in the case of rejection, the user’s browser is directed back to the selection page 502. Alternately, (arrow not shown) the user can be sent back to the application page 504 to correct noted defects in the application. In the case of approval, the acceptance page is displayed, including a quoted price for the requested bond 511. If the user agrees to purchase at the quoted price 513, the charge to her credit card charge is finalized 515, a new record is created 515 in the Bonds Database 1301, (FIG. 13) a unique Seal 410 is generated automatically and stored on the Site server 517, and the Provisional Bond Contract becomes legally binding 517. The HTML code for the Bond Seal 410 is displayed 517 to the applicant so that she can copy this code and use it in her offers for sale. The HTML referencing the seller’s Seal can also be retrieved later by the seller visiting her account page on the Site.
Alternately, (not depicted graphically) the Company can require that the bonded seller first submit the URL of each page wherein the Seal will be displayed before the HTML code which renders the Seal is made available. Requiring URL submission of each Web page wherein the Seal is to be displayed may enable greater accuracy in Company policing for pirated Seals.
The Provisional Bond Contract is only valid for a specified period of time and is not renewable. It serves primarily to enable instant binding of a bond, a significant benefit to sellers, while not exposing Company to extended risk. After the Provisional Bond is bound 517, a manual review 520 is conducted by Company staff of the bond application, who pull credit reports and review submitted information. If the seller appears credit-worthy, the Staff authorizes issuance of a Formal Bond 523 by entering the result in the bond application and finalizing the review process. The Formal bond then issues prior to the expiration of the Provisional Bond, thereby rendering the latter null and void. The bonded seller is automatically notified of the issuance of the Formal Bond 523 but is not required to take any further action, since supplanting the Provisional Bond with the contractual rights and obligations of the Formal Bond does not change the appearance of the Bond Seal 410. If Staff decides applicant does not merit the Company’s undertaking the obligations of Formal Bond, Staff enters the result in the appropriate field in the bond application record and finalizes the review process. Thereafter, the Provisional Bond expires, and the seller is automatically notified 522. In this case, the Seal image 411, which resides on the Company’s servers, will be automatically replaced with a new image which indicates that the Provisional Bond has expired.
Returning to the top of FIG. 5, if the registered User chooses to apply for a guaranty, the first time she purchases a guaranty, she will be required to enter much of the same information as is required in the bond application 506. Thereafter, subsequent guaranty applications by the same account holder are much shorter so as to be more convenient. The abbreviated guaranty application requests the following information: a. Auction site where item to be guaranteed is listed b. Auction identification number c. Seller’s email address used in that auction listing (used to access the listing) d. Type of merchandise being sold (select from menu) e. Guaranty amount or estimated closing value f. Check box answers to questions such as: “Is all merchandise authentic and authorized for sale?” g. If credit card is already on file, then the User simply authorizes the charge; if credit card is not on file, then User provides credit card information.
While the above fields pertain to a specific auction, the present invention also contemplates a single submission form containing multiple repetitions of the above fields so that several auction guaranty applications can be submitted at one time, which reduces unnecessary re-entering of data that does not change from auction to auction, such as a credit card number, if such is not already stored.
Upon submission, the application is processed 507 according to the Automated Guaranty Application Review Process detailed in FIG. 7. If the application is approved, then the User is prompted to provide her password for the given auction account 510 and email address if the one being used in the given auction is different from the one already provided. This password is never stored anywhere by the Company and therefore must be entered each time an auction is to be guaranteed. This password is used to gain editing access to the specified auction listing so that the Company’s CGI script technology can automatically append the HTML which produces the Seal 420 to the existing HTML of the specified auction listing. If the User is not accepted, her browser is redirected to the begin page 502 or, alternately, back to the Guaranty Application page 506 (arrow not shown) to correct any defects in her application.
Once the password is submitted 510, which also signifies the applicant’s authorization to charge her credit card, a new record is created 512 in the Guaranty Database, a new, unique Guaranty Seal image 421 is created and stored 512 on the Company server, and the CGI script which appends the Seal HTML to the given auction listing is run 512. If the CGI script successfully adds the Guaranty Seal HTML to the specified auction listing, the credit card transaction is finalized 516, the Guaranty Contract is consummated 518, and the confirmation page is displayed 518 in the applicant’s browser, informing her that the Guaranty is active, and the Seal added to the specified auction. If the CGI script fails, the User is re-prompted for her email address and password 510.
FIG. 6 depicts a flow chart documenting the steps of the Automated Bond Application Review Process. Information in newly submitted applications is input into this software process 601, and a result–acceptance with price quote 615 or rejection 613, with or without reasons–is output. In evaluating the application, the software will produce a rejection result 613 if any significant fields are left blank 602 or if any admissions 603 are made in the application that indicate that the given seller is an intellectual property pirate or other illegitimate seller. Next, the contact information provided in the application is checked against the information contained in all the corresponding fields in all records in the Flagged Individuals Database 1303. If a high certainty correlation exists between the contact information provided in the application and that in a Flagged Individual record, such as an identical email address, then the applicant is consider flagged 604 and is rejected 613.
If the application survives the initial cuts, a Risk Exposure Level is assigned 605. This number is the product of a formula which includes several factors, such as: the coverage value being requested (higher revenue sellers will yield greater risk exposure), the types of merchandise, and the number and verifiability of credit references.
Data is checked to determine whether the applicant has previously been bonded by the Company 606. If so, she will already have an Experience Rating, which is determined per the Experience Rating Process depicted in FIG. 9 below. If the applicant has applied in the past, a manual credit review may have already been conducted on that individual and an in-house Credit Rating assigned to her. The Experience Rating, if any, and Credit Rating are factored in with the information contained in the application itself to assign a Risk Worthiness Level 607 or 610 to each application. The Risk Worthiness Level is compared to the Risk Exposure Level 612, and the application is either accepted or denied. If accepted, a credit card preauthorization is performed 609. Provided that the credit card is valid 614, a price quote for the bond is output 615, the sub-process depicted in FIG. 6 ends, and the main process depicted in FIG. 5 resumes 616. If the application is denied, comparison is made between the applicant’s Risk Worthiness Level and that required for shorter potential bond durations and lower penal sums to see whether the given applicant may qualify for a less risky bond 608. If so, then a new bond duration and rate is selected 611 for use in the price quote. If the applicant is not sufficiently risk-worthy even for a reduced risk bond, then rejection 613 is output 616.
FIG. 7 depicts the Automated Guaranty Application Review Process, which is similar to the bond evaluation sub-process. One difference is that the result is strictly binary; there is no option of reducing the amount of coverage in order to guaranty a non-guaranteeable auction. Also, note that in the preferred embodiment, the prices for guaranties are fixed according to the value of the item; thus, a quote is not necessary, simply the outputting of acceptance and confirmation of price. As an alternative embodiment, prices can be set to vary according to the Risk Worthiness Level of the applicant, in which case a quote would be necessary.
back to financial services