WO2001018712A1 - Web-based system to facilitate purchase, pick-up, and delivery of, and escrow and payment for, merchandise - Google Patents

Abstract

A Web-based purchasing method using a networked computer system (100) to facilitate the purchase of merchandise by a purchaser (130) from a seller (140). The system receives a purchase offer from the purchaser to purchase a merchandise at an established purchase price. The system (100) then transmits a request to a shipper to pick the merchandise from the seller (140) and an amount at least equal to the established purchase price is transferred from the purchaser's financial account into an escrow account (120). The escrow account (120) is being controlled by a transaction computer (110) based on information contained in the transaction database (116). After the merchandise is delivered to the purchaser (130) at the purchaser's address, and following an inspection period, at least a portion of the gross purchase price is transferred from the escrow account to the seller's financial account as well as to other participants of the web-based purchasing system.

Description

WEB-BASED SYSTEM TO FACILITATE PURCHASE, PICK-UP, AND DELIVERY OF, AND ESCROW AND PAYMENT FOR, MERCHANDISE

Cross Reference to Related Application This application is a continuation-in-part of U.S. application serial number 09/393,730, filed September 10, 1999.

Field of the Invention The present invention relates generally to electronic commerce, and, more particularly, to a method and system for enabling commerce over a large public network that includes capabilities for electronically integrating pick-up and delivery of, and escrow and payment for merchandise.

Background of the Invention Increasingly, individuals and businesses are desirous of selling their products and services in an automated fashion using a large, networked computer system such as the Internet. As the number of people worldwide who have access to the Internet (and particularly the World Wide Web portion of the Internet) increases, the Internet is expected to grow and become one of the world's most significant new marketplaces. Currently, the vast majority of electronic commerce, that is the buying and selling of information, products and services over computer networks, is business-to-business. However, one particular e-commerce market segment that is growing almost exponentially each year is individual-to-individual, or so-called peer-to-peer, transactions. Individual-to-individual commerce can take many forms including, for example, the various auction websites available on the Internet. Others who may participate in the individual-to-individual commerce market include merchants for antiques and collectibles, memorabilia enthusiasts, home crafters, sporting and entertainment season ticket holders, family households, and the like. There exists, however, several barriers to this market segment's ability to effectively conduct commerce over the Internet. One drawback to the increased use of the Internet in this individual-to-individual market segment is that the participants often have no means of electronically transferring payments from the buyer to the seller. While conventional businesses typically use credit cards, debit cards, or other forms of payment, sellers, particularly individuals and small businesses, have limited means to establish relationships with credit card companies and other similar financial institutions. The need for a conventional merchant account in order to accept payment with a credit card impedes commerce on the Internet because an average individual Internet user may have a difficult time qualifying for such a merchant account. Additionally, the parties to an individual-to-individual transaction often do not have a relationship with a pick-up and delivery service. Because many potential participants in the individual-to-individual market segment typically ship a small amount of packages on an annual basis, they lack the power and ability to negotiate preferred rates with such delivery services. Furthermore, commercial pickup and delivery services require individuals to pay for shipping with cash only. Individuals may pay for shipping services with check or credit card (noncash payment) through a third party facilitator. However, facilitators currently require that the packages be delivered from the facilitator's location; thus requiring individuals to transport their packages to the facilitator's location for shipping. Currently, independent third parties cannot arrange for delivery of a package from a first party to a second party. One significant problem with e-commerce in general is the instance of fraud. This is particularly problematic in the individual-to-individual market because often there is no established trust relationship between the parties to such a transaction. One possible solution to the fraud problem is the use of a third party escrow service that holds the payment until the purchaser is satisfied in exchange for a fee. While escrow services are generally available for electronic commerce transactions over the Internet, the available services are not seamlessly integrated into the entire purchasing process and, in particular, are not tied directly into the pick- up and delivery of the merchandise. None of these existing online escrow services provide more than the escrow function and all require telephone or other authorization from the buyer before the escrowed funds are distributed. In each instance, pick-up and delivery must be separately arranged and paid for by the parties to the transaction. Also, even if an individual were capable of accepting payment by a credit card, presently most credit card companies do not allow the settlement of funds from a buyer's account until actual shipment of the goods ordered is complete. This puts the merchant or seller at risk that the purchaser will not have sufficient funds or credit availability to complete the transaction. Accordingly, there is a need for a system that facilitates the purchase of merchandise over a networked computer system that fully automates the negotiation, fulfillment and payment aspects of electronic commerce. A preferred system would link and automate the entire commerce process, permitting buyer and seller to arrange and complete the agreed-upon transaction without ever leaving their computer terminals.

Summary of the Invention A system having these features and satisfying these needs has now been developed. The present invention is a fully electronically integrated web-based purchasing system that links and automates every stage of a transaction in the e-commerce cycle. The system facilitates an e- commerce transaction between a seller and a purchaser by providing the means to allow the purchaser to use his or her credit card, debit card, electronic check, or financial account as a payment vehicle, electronically schedules pick-up and delivery of the purchased merchandise, virtually escrowing the seller's goods during the transaction, escrows the purchaser's money during the fulfillment and inspection period, and electronically distributes funds to the entitled parties after the purchaser has received, inspected and accepted the merchandise. In one embodiment of this invention, a web-based purchasing method using a networked computer system to facilitate the purchase of merchandise by a purchaser from a seller is established. Preferably, the seller and the purchaser each have an associated financial account such as a credit card, check card, electronic check with bank routing and checking account numbers, and/or other financial accounts to facilitate the purchase of merchandise using the invention. The networked computer system includes a merchandise database having stored therein a product profile table for the merchandise. The networked computer system may receive a purchase offer initiated from the purchaser to the seller for merchandise offered for sale by the seller at an established purchase price. Also, the networked computer system may receive an offer to sell initiated from the seller to the purchaser for merchandise wanted for purchase by the purchaser. The offer to sell may or may not include a sales price desired by the seller. Additionally, the purchaser may initiate a purchase offer without stipulating a purchase price. The established purchase price may have been previously negotiated between the parties by using the networked computer system for offer/counter offer, or it may have been predetermined in advance by the seller and accepted by the purchaser. The purchase offer can be associated with the purchaser's financial account and the purchaser's registered delivery address. The networked computer system recognizes acceptance of the offer/counter offer, by the seller or the purchaser, and a transaction identification number (TID) may be created, thus establishing an associated purchase and transaction account between the seller and the purchaser. A request for authorization for credit against the purchaser's financial account is generated and transmitted to a financial institution associated with the purchaser's financial account to verify that the purchaser has the gross purchase price in the purchaser's financial account to make the purchase. The gross purchase price generally includes the purchase price established between the seller and the purchaser, as well as all appropriate transaction fees. The financial institution then generates an authorization indicator in response to the request for authorization, which is then reviewed by the system to verify that the purchaser is authorized to make the purchase using the purchaser's financial account. At this point, the purchaser's funds or credit may be reserved. The seller may be notified by the system that an authorized purchaser desires to purchase the merchandise offered for sale; alternatively, the seller may be notified by the system of an unauthorized purchase offer (i.e. prior to the system requesting an authorization for credit). The seller may be specifically requested to acknowledge the purchase offer by the purchaser, to confirm that the merchandise is still available for purchase, to accept the purchase offer and to establish the date the merchandise may be ready for shipment. The system may generate a query to the seller prior to the established shipment date requesting confirmation that the merchandise is packaged and ready for pick-up and delivery. The system then transmits a request to the delivery system which automatically contacts a carrier associated with the delivery system to pick up the merchandise from the pick-up address specified by the seller. The carrier then picks up the merchandise, as confirmed by the carrier to the delivery system, and an amount equal to the established gross purchase price is transferred from the purchaser's financial account into an escrow account. After the merchandise is delivered to the address specified by the purchaser, as confirmed by the carrier to the delivery system, at least a portion of the established purchase price is transferred from the escrow account to the seller's associated financial account, as well as to other participants of the web-based purchasing system. This transfer from the escrow account may be delayed for a predetermined amount of time pending the purchaser's acceptance of the merchandise. The foregoing and other objects are intended to be illustrative of the invention and are not meant in a limiting sense. Many possible embodiments of the invention may be made and will be readily evident upon a study of the following specification and accompanying drawings comprising a part thereof. Various features and subcombinations of the invention may be employed without reference to other features and subcombinations. For instance, a person may deliver a package utilizing the delivery system of the present invention without using the escrow services. The delivery system of the present invention allows users to pay for shipping using noncash methods such as checks and credit cards, and allows users to arrange for packages to be picked up from any location. The current invention overcomes the deficiencies of previous delivery systems which required either cash payment, or transportation of packages to a third party facilitator's location.

Brief Description of the Drawings These and other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings wherein: Figure 1 is a schematic block diagram of a networked computer system to facilitate the purchase, pick-up and delivery of, escrow, as well as payment for merchandise in accordance with one embodiment of the present invention; and Figures 2 through 5 are flow charts showing the functions of a method to facilitate web- based purchase of merchandise using a networked computer system as shown in Figure 1. Figure 6 is a flow chart showing the options for a person using the system of the present invention to access the delivery system of Figure 1. Figure 7 is a flow chart showing the user registration process shown of Figure 6. Figure 8 is a flow chart showing the user logon process shown of Figure 6. Figure 9 is a flow chart detailing the user menu shown of Figure 6. Figure 10 is a flow chart showing the shipping detail process of Figure 9. Figure 11 is a flow chart showing the payment detail process of Figure 9. Figures 12 through 14 are flow charts showing of the display transaction process of Figure 9.

These drawings are provided for illustrative purposes only and should not be used to unduly limit the scope of the present invention. Detailed Description of the Invention The present invention transforms the online buying process by linking and automating every stage of the transaction including: (i) purchase offer, negotiation, and offer acceptance; (ii) credit verification and billing authorization; (iii) verification of product manufacture and shipping status; (iv) order fulfillment (i.e., pick-up and delivery) virtually escrowing the merchandise; (v) credit settlement and purchase funds escrow; and (vi) escrow settlement and merchant payment. Referring now to Figure 1 , therein is shown one preferred web-based purchasing system 100 to facilitate the purchase of merchandise by a purchaser from a seller. The system 100 includes, and is controlled by, a transaction computer 110 that is connected to a publicly available network, such as the Internet global computer network. The transaction computer 110 controls the overall operation of the web-based purchasing system 100 of the present invention. For example, the transaction computer 110 may provide a website 170 organized in a variety of ways providing functions such as enabling users to become registered sellers and/or purchasers, allowing sellers to advertise their products, allowing potential purchasers to review and select merchandise, allowing the users to negotiate a transaction, and allowing the users to complete a transaction, including the functions of payment and delivery. The website 170 may allow participants of the web-based purchasing system 100 to communicate and interact with the system 100 and other participants. The website 170 may be linked to other websites, allowing users who have negotiated a transaction and agreed upon a purchase price and possible other conditions using other means, such as an auction website, to complete their transaction using the system of the present invention. These other websites may be termed net venue transaction participants. The website 170 may include other functions, such as allowing the merchandise available for purchase through the system to be advertised and accessed in a variety of ways, such as through a conventionally-implemented search engine. In addition to the traditional computer components, such as a processor, random access memory (RAM), read only memory (ROM), an operating system, and various communication devices and ports, the transaction computer 110 incorporates a number of databases. For example, the transaction computer 110 may have a merchandise database 112, which stores information related to a plurality of products offered for sale through the web-based purchasing system 100. This information may be arranged into product profiles and includes, for example, the product identity; the seller's identifying information, and the established purchase price for the product. The product profile may also include various types of other product information, i.e., further details on the product and its availability. The product profiles may include digital advertisements in a variety of multimedia formats, including audio, photographs, video, and text. Additionally, the advertisement may direct the potential purchaser to the seller's own website by, for example, a hypertext link. The product profiles stored in the merchandise database 112 may be generated from information obtained from the seller, or may be linked to databases from other websites. Thus, a net venue transaction participant may host its own website containing a database of product profiles that may be accessed via the purchasing system 100. The transaction computer 110 organizes and uses the information stored in the merchandise database 112 to create the website 170 that digitally advertises and/or provides information about the products for sale. The transaction computer 110 preferably also includes a registered user database 114, which maintains a list of registered buyers and purchasers as well as information required of the users to allow them to access and use the features of the web-based purchasing system 100. Each record of the registered user database 114 may include information relating to the user, such as name, e-mail address, delivery and/or pick-up address, telephone number, and financial account information. Financial account information for registered purchasers includes a viable and approved credit card or checking account information. Sellers must generally provide a checking account routing and account number to allow direct electronic deposit of funds upon the completion of a transaction. This information is obtained when a seller or purchaser first registers to use the web-based purchasing system 100 using, for example, website 170, and may preferably be updated or revised anytime a seller or purchaser connects to the system 100. The transaction computer 110 may assign an account number and/or a password to each registered user. The use of a password ensures that only the registered user, or someone under his or her control, has access to view and/or modify information relating to his or her account or any transaction that he or she may be participating in through the system. The transaction computer 110 also houses a settlement database 118, which stores information related to the communications between the transaction computer 110 and a transaction settlement network 150 as described below. The settlement database 118 also controls the automated re-authorization process as described below. The transaction computer 110 also preferably includes a transaction database 116, which tracks all transactions performed through the system 110 with fields such as delivery status, pick-up status, buyer acceptance of transaction, seller acceptance of transaction, ship date, package delivery, etc. The transaction database 116 thus stores information relating to "active" transactions, i.e., those transactions that are not yet complete, to enable the system 100 to appropriately monitor and process such on- going transactions. Additionally, the transaction database 116 stores information related to completed transactions, to enable the operators of the system 100 to review any past transactions in response to, for example, user complaints. As those skilled in the art will appreciate, portions of the transaction database 116, particularly the portion related to completed transactions, may be archived and removed from the memory of the transaction computer 110 and stored on other conventional off-line memory devices, such as tape drive or mass storage disks. The transaction computer 110 also includes an escrow account 120, which temporarily holds the purchaser's funds pending approval of the merchandise by the purchaser. The escrow account 120 is controlled by the transaction computer 110 based on information contained in the transaction database 116. The escrow account may be organized by all parties involved in the purchasing system 100. The transaction computer 110 is connected to a publicly available network, such as the Internet, by an Internet Service Provider through a conventional telephone network, or through commercial on-line services, such as America OnLine, Yahoo!, or Uunet, allowing purchasers and sellers a wide range of connection alternatives through which users may access the system of the present invention. Typically, a buyer or seller may access the system by, for example, a purchaser computer 130 and/or a seller computer 140. Although Figure 1 shows only one purchaser computer 130 and a single seller computer 140, the system 100 is understood to extend to include multiple buyers and sellers, each having their own computers to network to, and communicate with, the transaction computer 110. In another embodiment, multiple users (sellers and purchasers) can access the system 100 through a third party's computer system, which may be located at, for example, an auction site, a traditional brick and mortar retail store, at a collectibles show, or another's residence. Thus, a user of the system 100 need not even own a personal computer to take advantages of the benefits of the present invention. Also, a seller or a purchaser may be an individual, a group of people, a company, or an institution. A delivery system 160 is also connected through the network to the transaction computer 110. The delivery system 160 includes a carrier capable of picking up and delivering merchandise, such as United Parcel Service, Federal Express Corp., the United States Postal Service, or bulk item transportation providers, such as Mark VII. The delivery system 160 also preferably includes a computer system incoφorating conventional tracking capabilities to allow the transaction computer 110 to monitor the status of packages picked up and delivered in connection with the system 100, which may be accessed directly by the purchaser and seller to review the delivery status. The delivery system 160 communicates with the transaction computer 110 via the network to schedule pick-ups and delivery of merchandise and to provide the status of such deliveries. The timely communication between the delivery system 160 and the transaction computer 110 ensures that the escrowing of both the purchaser's money and the seller's merchandise is achieved. The transaction computer 110 is also networked to certain financial services, such as a transaction settlement network 150. The transaction settlement network 150 represents presently-available commercial institutions that process credit and other financial transactions. For example, the transaction settlement network 150 may represent commercially available credit card processing institutions (e.g., VISA, Master Card, Discover, etc.). The transaction settlement network 150 also includes banks or other institutions that provide merchant accounts for entities that want to receive payment for the sale of goods or services. In this invention, the operators of the system 100 act as a merchant, thus allowing sellers to sell their merchandise to purchasers without having to qualify as credit card merchants. Thus, the operators of the system 100 have a merchant account that is similar or identical to the conventional merchant accounts that are provided to businesses. The transaction computer 110 interfaces with the transaction settlement network 150 to collect and distribute payments to the various parties involved in the system, including purchasers, sellers, delivery systems, escrow services, banks, billboards, and referral sources. For example, a purchaser's transactions that are initiated using the system 100 would show up on the purchaser's credit card statements as a charge from operators of the web- based purchasing system 100. Processing of credit card transactions by the transaction computer 110 through the transaction settlement network 150 may be supported by various commercially available software packages, such as WebCash Manager by Pulitzer & Haney or WebAuthorize by Tellan. In one embodiment of the present invention, the transaction computer 110 operates as a web server, both receiving and transmitting e-mail messages related to merchandise available for purchase through the system and on active transactions processed by the system. The transaction computer 110 thus must be capable of high volume transaction processing, performing a significant number of mathematical calculations, processing communications as rapidly as possible, and performing database searches. A processor such as a Pentium 686 may be used as the transaction computer 110, or any equivalent processor or multiple processors networked together. The transaction computer 110 includes software capable of performing all system operations as described below in further detail. Also, while the embodiment described herein describes a single computer performing the functions attributed to the transaction computer 110, those skilled in the art will appreciate that such functions may be distributed across a larger number of computers, including those connected across a network. Generally, users of the presently preferred web-based purchasing system communicate with the system using e-mail messages. Certain information may also be posted or accessible through website 170. Alternatively, purchasers and sellers may access the transaction computer 110, albeit in certain instances with human involvement, telephone, voice-mail, facsimile, or postal mail transmissions. Figures 2 through 5 are schematic flow charts showing the functions of a method to facilitate the purchase of merchandise using a web-based purchasing system as shown in Figure 1, in accordance with one embodiment of the present invention. Except for the interaction between the system and the purchaser and seller, the entire process of the present invention may be fully automated. The networked transaction computer 110 waits until a user connects to and logs on the system (function 202), and selects the type of transaction to process. A user generally connects to the system by accessing website 170 coupled to and controlled by the transaction computer 110. However, participants may use the system via another's website via a hyperlink to connect to the system through a dedicated home page or by reference from any licensed net venue transaction participant permitted to connect to the website 170. A net venue transaction participant is one who participates in the web-based purchasing system by providing an entry point into the system. Thus, a net venue transaction participant may host its own website containing a database of product profiles that may be accessed via the purchasing system 100. Typically, a net venue transaction participant provides a means for its customers to negotiate a transaction, but does not offer services to allow its customers to complete the transaction. For example, the net venue transaction participant may be an auction website that allows its customers to "negotiate" or otherwise arrive at an agreed upon price for the merchandise. Upon completion of the auction process, the auction website may then suggest to its customers that they connect to the present web-based purchasing system 100 to complete the transaction, i.e., to arrange for pick-up and delivery of and payment for the merchandise. Because the net venue's customers "complete" their transactions separate from the net venue's website (e.g., pick-up and delivery of, and payment for merchandise purchased), the net venue participant is left to collect its own receivables by conventional means (e.g., billing the merchant/debtor and then receiving payment by mail or phone.) However, the present invention enables net venue participants to collect and receive payment for their receivables at the same time their customers complete their transactions using the web-based purchasing system 100. In order to use the web-based purchasing system 100 for transactions, the purchaser and the seller both need to have registered as users of the system 100. As registered users, such purchasers and sellers of the system 100 may conduct commercial transactions with each other, such as selling products using the features of the present invention. The user may logon to the system via an electronic network, with the transaction computer 110 acting as a web server. For example, a person may initially register as a new seller by providing the transaction computer with the seller's registration information or modify the registered seller's existing information (function 204). This seller's information may include, for example, the seller's name, e-mail address, pick-up address, telephone number, and financial account information. Another person may elect to register as a new purchaser or modify the registered purchaser's information (function 206). A new seller or pre-registered seller may choose to add or modify merchandise to the merchandise database (function 208). Similarly, a purchaser may advertise that he/she desires to purchase certain merchandise at an established offer price. Each of these actions results in the system updating the appropriate registered user and/or merchandise databases to reflect the new or modified information. Additionally, the transaction computer 110 may assign a password and/or account number to each new registered user. While the preferred method for a user to register with the web-based purchasing system 100 would be to access the system's website, alternative forms of registration may be used, including e-mail, facsimile transmission, postal mail, etc. In addition to establishing an account with the web-based purchasing system, a purchaser may elect to issue a purchase offer for particular selected merchandise (function 210) at an established purchase price. The purchase price may be established as an advertised price as shown in the on-line advertisement for the merchandise, or may be a negotiated price, negotiated through the present invention or off-line methods, such as face-to-face negotiation, auction (including web-based auction sites), newspapers, telephonic or written communications, or other advertising mediums. The established purchase price may also be defined as a counteroffer issued by the purchaser to a seller's advertised price, or a counter offer issued by the seller in response to a purchaser's counteroffer. The purchaser may identify the particular merchandise by searching through the products available for sale in the merchandise database 112 using, for example, a search engine located in the transaction computer 110 and accessed by the purchaser computer 130. Importantly, a purchaser and a seller may meet and negotiate a sale independently of the system 100 and then use the system 100 to complete the transaction by simply logging onto the system and using its features to arrange for pick-up and delivery of, and payment for the sold merchandise. After the purchaser logs-on with the system (function 202), and then selects the merchandise offered for sale (function 212), the system requests the purchaser's preferred payment method and delivery address (function 214). The system then requests the purchaser to validate his or her preferred payment method (function 216). If the purchaser desires to alter either the payment method or the delivery address for this particular transaction, the purchaser then provides the system with his or her financial account information and/or delivery address (function 218). Payment methods may include conventional credit cards, personal checks, electronic funds transfer, digital money, E-cash, etc. Using the purchaser's selected or provided financial account information, the system then requests authorization for credit approval for an amount equal to at least the established purchase price, plus possibly an additional estimated amount to cover delivery and transaction fees, from the transaction settlement network (function 220). The delivery and transaction fees can be paid entirely by the purchaser, paid entirely by the seller, or paid partially by the purchaser and partially by the seller. The transaction fees may include payments to net venue participants, other referral sources, fees for escrow services, fees for the operator of the web-based purchasing system 100, and applicable taxes. If the transaction settlement network 150 indicates that the purchaser has sufficient funds or credit available to purchase the selected merchandise (function 222), the system then reserves the funds (function 224) and control is then transferred to function 226. This function serves to "lock-up" a portion of the available credit on the purchaser's credit card or other payment vehicle while the transaction is "active." At function 222, the transaction settlement network responds to the pre- authorization request, indicating whether sufficient credit is available. When the purchaser selects merchandise the transaction settlement network 150 will provide a Transaction Identification number (TID), which the transaction computer 110 stores in its transaction database 116 along with other information related to this "active" transaction, for later reference. The other information stored in the transaction database 116 may include the product selected, the seller, the buyer, and the stage of the transaction. If the transaction settlement network 150 responds that the purchaser has insufficient funds or credit available, the system terminates the authorization request and so notifies the purchaser (function 225). At this point, the purchaser may supply another financial account to make the purchase or terminate the transaction completely. If the purchaser supplies another financial account, the system repeats starting at function 220. If the purchaser has sufficient funds or credit, the system then notifies the seller and provides the seller with a purchase offer specifying the transaction details, such as the selected merchandise and the purchase amount (function 226). This notification is preferably by way of an e-mail message delivered by the system. Upon receipt of the notification, and after reviewing the transaction details (which may be provided in the e-mail message or through website 170), the seller can then either (function 230): (i) accept the purchase offer; (ii) reject the purchase offer and terminate the transaction process (function 228); or (iii) reject the purchase offer and attempt to re-negotiate the offer by supplying the purchaser with a counteroffer (function 234). If the seller elects to attempt to re-negotiate the offer, the seller provides a counteroffer to the purchaser for consideration (function 232), through the web-based purchasing system, which is tracked by the system in the transaction database 116. The purchaser can then terminate the transaction or initiate another purchase order, using the seller's offered price, or another offer from the purchaser (function 234). The process then repeats starting at function 226. The system may also include a provision that, in the event that the purchaser or seller does not respond to a purchase offer or a counteroffer within a predetermined period of time, the system will terminate the active transaction. Additionally, if the authorization to charge the purchaser's credit card account is about to expire, the system can automatically suspend the transaction until the purchaser's credit is re-authorized by repeating functions 220 through 224. Once the seller has accepted the purchaser's offer, or the purchaser has accepted the seller's counteroffer, the seller then provides pick-up instructions, such as, for example, the pick- up address, the estimated pick-up date, the number of packages, and the approximate weight of the packages (function 233). Certain of this information may be retrieved from the registered user database 114 and/or the merchandise database 112. This information is then transferred to the delivery system 160 (function 236), which awaits further instruction from the seller as to when the packages are available for pick-up. Once the package(s) is available for pick-up (function 238), which may be delayed pending product manufacture by the seller, the seller notifies the delivery system 160 through the system. Again, the system can incorporate a number of checks and balances to ensure that all pending transactions are completed within a given period of time. As another example, the system could notify the seller if he or she has not notified the delivery system that the package is available for pick-up within a predetermined amount of time. The delivery system 160 is then provided the transaction information (TID) and is automatically dispatched to pick up the packages (function 240). The information on the transaction sent to the delivery system 160 is preferably sufficient to allow the delivery system to print out a delivery label, which the carrier can then carry out to the seller's address and readily attach on the package(s). An e-mail message may be sent from the delivery system (possibly through the transaction computer) to the seller to remind him or her of the pick-up date and to request more specific information regarding the merchandise (e.g., number and weight of packages) (function 242). The delivery system may not actually dispatch a carrier to the seller's address unless the seller acknowledges this confirmation. Upon confirmation that the packages have been picked up from the seller, the monies previously reserved against the purchaser's financial account are transferred into the system escrow account 120 (function 244). Thus, the escrow account allows payment to the seller to be delayed until the delivery of the merchandise to the purchaser is confirmed and until the purchaser has had a sufficient amount of time to inspect the merchandise, while, at the same time, ensuring that the purchaser will in fact make payment. Thus, during this period of time, both the money and the merchandise are escrowed by the system. Another e-mail message may then be sent to both the purchaser and seller to notify them of the progress of the transaction (function 246). The merchandise is then delivered to the purchaser's specified delivery address (function 248). The purchaser's funds are held in the escrow account until the purchaser has an opportunity to inspect the purchased merchandise. After delivery of the merchandise is electronically verified by the delivery system and the buyer has inspected and accepted them, or has failed to reject the merchandise within a predetermined amount of time, the escrowed funds are released to the entitled parties using, for example, automated NACHA electronic fund transfer files through the transaction settlement network 150 (functions 250 through 256). The interested parties receiving payment may include, in addition to the seller, the operator of the web-based purchasing system 100, the escrow service, the transaction settlement network 150, and the delivery system 160. An additional payment may be made to a third party net revenue transaction participant, such as an auction site, from which the parties initiated their transaction, and/or other referral sources. Details of the transaction may be recorded in the transaction database 116 (function 258). The present invention also provides for automated resolution of disputes. For example, in the event the purchaser desires to reject the merchandise (function 250), the purchaser contacts the web-based purchasing system (function 260) and provides a reason for the rejection, which may include a defective or broken product, that the product is not as advertised, or that the purchaser simply no longer desires the product. The web-based purchasing system may then notify the delivery system to pick-up the merchandise from the purchaser and return it to the seller (function 262) and release the escrowed money back to the purchaser's account, minus any appropriate transaction fees (function 264). While those skilled in the art may establish many different approaches for handling each of the various types of rejections, set forth below is one set of approaches. In the event the purchaser rejects the merchandise because it is defective, the purchaser notifies the web-based purchasing system, which then automatically contacts the delivery system 160, and the carrier associated with the delivery system is notified to return to the purchaser to pick-up the defective merchandise and return it to the seller. The system will send the seller a message via e-mail notifying him or her to expect return of the merchandise. If the seller can repair or replace the defective merchandise, the purchaser can notify the system and arrange for re-delivery. Generally, the seller will incur the charges for this extra shipping charge. In the event the purchaser rejects the merchandise because he or she simply no longer desires the merchandise, the purchaser notifies the web-based purchasing system, which then automatically contacts the delivery system 160, and the carrier associated with the delivery system is notified to return to the purchaser to pick-up the merchandise and return it to the seller. Upon verified return of the package(s) to the seller, the purchaser's funds are returned via the transaction settlement network 150, possibly after subtracting any appropriate shipping charges and appropriate transaction fees. In the event the purchaser rejects the merchandise because it is broken or damaged, the purchaser notifies the web-based purchasing system, which then automatically contacts the delivery system 160 for resolution, and the carrier associated with the delivery system is notified to return to the purchaser to pick-up the merchandise for inspection. If the delivery system, and/or carrier, is determined to be at fault, the escrowed funds will be held pending resolution by the delivery system with the purchaser and seller. Upon resolution, the escrowed funds will be released to the appropriate parties. In the event the carrier associated with the delivery system is determined not at fault, the merchandise is returned to the seller for resolution in a manner as a defective product. In the event the purchaser rejects the merchandise because it is not as advertised or represented, the purchaser notifies the web-based purchasing system and the carrier associated with the delivery system is notified to pick up the merchandise and return it to a location associated with the operator of the system 100 for resolution. Such resolution may, in appropriate circumstances, involve contacting authorities if it is determined that commercial fraud may be involved. The present invention also incorporates a means to keep the authorization issued by the transaction settlement network 150 "live" during the pendency of an active transaction. As is known, most credit card issuers automatically drop an authorization if the authorization has not been settled within a certain period of time (e.g., between 7 and 31 days). The present invention includes the ability to re-time a credit card or electronic funds authorization that allows the original credit authorization issued by the settlement transaction network 150 to retain its original authorization number and amount authorized until the authorization is settled, or until a specific predetermined fulfillment date has passed. The re-timing of the authorization must occur before the drop date of the authorization, which varies for each credit issuer. The system's i transaction computer 110 references the purchaser's original credit authorization and

2 authorization date for each transaction. The transaction computer 110 then communicates with

3 the settlement network 150 providing the settlement network's computer with a specific re-

4 authorization period of time (e.g., between 3 days and 7 days) which then automatically, and

5 continuously, "re-times" the original credit authorization until a specific predetermined

6 fulfillment date has passed.

7 Additionally, the purchasing system 100 of the present invention can include a means to

8 cancel a credit authorization prior to the credit issuer's drop date, enabling the system to free up

9 the purchaser's credit account in the event a transaction is canceled. Such a feature is useful if 10 the product offered for sale is no longer in the seller's inventory. This function generally n involves the seller notifying the web-based purchasing system 100 that the merchandise offered

12 for sale is not longer in inventory, or the purchaser's offer to purchase merchandise is ignored by

13 the seller and a predetermined "offer acknowledgment" date (e.g., between 1 and 5 days) has

14 passed. The transaction computer 110 then communicates with the settlement network 150

15 providing the settlement network's computer with a specific re-authorization period of time of 6 "0" days. The settlement network 150 then automatically drops the purchaser's original credit

17 authorization. 8 While Figures 2 through 5 show one embodiment of the present invention, those skilled 9 in the art will readily recognize that many variations exist and fall within the spirit and scope of 0 the present invention. For example, a seller may, when adding a particular product to the 1 merchandise database 112, establish that he or she will automatically accept any purchase offer 2 above a given strike price. This will eliminate the function of having the seller "accept" the 3 purchaser's purchase offer and further streamline the process. The seller may also indicate a 4 quantity of products that are available, which can be stored in the appropriate product profile of 5 the merchandise database. The transaction computer 110 may then keep track of how many 6 products are sold and delivered and continue to advertise such product until all are sold. Thus, 7 using these two features, a seller could connect to the web-based purchasing system 110 once, 8 add a product to the merchandise database 112 , and then "sell" all such products while having 9 the system ensure delivery and acceptance of all such products without further involvement from 0 the seller. A seller's indication that any or all products have indeed sold, may be as simple as a 1 noticeable increase in the seller's deposit account. As previously indicated, the web-based purchasing system 100 of the present invention may be implemented through a web server and the various sellers and purchasers may access the system 100 by logging onto the web server, for example, through the World Wide Web portion of the Internet. The present invention thus includes a system to fully automate the entire commercial transaction process using a network computer system such as the Internet. The system and method preferably includes the escrowing of both funds and merchandise until the parties are satisfied with the transaction, automated dispatch of third party shippers, electronic confirmation of order pick-up and delivery, and built-in fraud protection. The system allows individuals and small businesses around the world to conveniently become importers and exporters of goods at a relatively low cost. The present invention may be implemented through a website that allows small businesses, merchants for antiques and collectibles, memorabilia enthusiasts, home crafters, sporting and entertainment season ticket holders, family households, and the like, to advertise their goods for sale, or the goods they desire to purchase, free of charge, until the sale is consummated. Figure 6 shows an embodiment of the system 100 in which a user accesses only the delivery system 160 without utilizing the negotiation and/or payment aspects of the system 100. Figure 6 is a flow chart depicting the various options for a person using the system 100 to access the delivery system 160 of Figure 1 to arrange for delivery of a package. The user can be the person possessing the package prior to pickup, the person to which final delivery is intended, or a separate third party. In function 602 a user connects to the system 100 by accessing website 170 and function 604 displays a default menu. The user may access the web site 170 via another's website, via a hyperlink or by reference from a net venue transaction participant. The default menu of function 604 gives the user various options such as: registering for the site (function 606), logging on (function 610), reading privacy information (function 616), reading frequently asked questions (FAQ) (function 622), reading information about the website (function 626), and reading the user agreement for the site (function 630). If the user decides to register (function 606), a registration process is initiated (function 608) (see Figure 7 for registration process), after which a delivery user menu (function 614) is accessed (see Figure 9). If the user is already registered, the user may initiate (function 610) a logon process (function 612)(see Figure 8) to the system 100. Once the logon is complete the delivery user menu (function 614) is displayed (see Figure 9). If the user selects the privacy option (function 616), the privacy page is displayed (function 618), and the default menu is retained (function 620). If the user chooses to read the FAQ (function 622), the FAQ page is displayed (function 624), and the default menu is retained (function 620). If the user selects About the website (function 626), the About the website page is displayed (function 628), and the default menu is retained (function 620). If the user selects the user agreement (function 630), the user agreement page is displayed (function 632), and the default menu is retained (function 620). If the user does not select any action, function 634 times out the session. Figure 7 shows the user registration process (function 608) shown in Figure 6. Function 702 begins the registration process. The new user is prompted to enter a user I.D. and a password for the site (function 704). If the new user I.D. is not unique, the system prompts the user to enter a different user I.D. (function 706). Once the user has entered a unique user I.D., the system determines whether or not the password is valid. If the password is not valid, the system will prompt the user to enter a new password (function 708). Once a valid password is acquired, the user is prompted to enter basic registration information such as address, phone number, billing information, etc. (function 710). The user is then logged into (function 712) the system 100, and the delivery user menu is displayed (function 714, 614). Figure 8 shows the user logon process (function 612) shown in Figure 6. The user requests to logon (function 802) to the system 100, and a logon page is displayed (function 804). The user is prompted to enter his/her user I.D. and password (function 806). The system determines whether or not the user I.D. is valid (function 808). If the user I.D. is valid, the system determines whether or not the password is valid (function 810). If the user I.D. and password are valid, the delivery user menu is displayed (function 814, 614). If either the user I.D. or the password is invalid, the logon is failed (function 812) and the user is prompted to attempt to logon again (function 816). If the user decides to attempt to logon again, the logon page is displayed (function 804), and the functions already described repeat from that point. If the user decides not to attempt logon again, the user is prompted to register (function 818). If the user decides not to register, the user exits the system 100 (function 820). If the user decides to register, function 822 sends the user to function the user registration (function 702) (see Figure 7). Figure 9 shows the delivery user menu shown (function 614) in Figure 6. Function 902 displays the delivery user menu. The delivery user menu allows the user to edit registration information (function 904). If the user selects to edit registration information, the system sends the user to a registration edit function (function 906). The delivery user menu allows the user to begin a transaction (function 908); alternatively (not shown), a user may choose to cancel an existing transaction, initiate a trace of a shipment, or file a claim for damaged or missing items. If the user begins a transaction, the user is prompted to enter shipping details (function 910) (see Figure 10). After entering shipping details, the user is prompted to enter payment details (function 912) (see Figure 11). The delivery menu also allows a user to monitor existing transactions (function 914). If the user chooses to monitor the status of an existing transaction, a transaction list is displayed (function 916) (see Figure 12). The delivery menu allows the user to log out (function 918) of the system 100. While the user is logged on, the system while wait a predetermined amount of time for a user action (function 420). If there is no user action the system times out the session (function 922). If the session times out, or if the user logs out, the system ends the session and returns the user to the delivery homepage (function 924) displaying the Default Menu (function 604) (see Figure 6). Figure 10 shows the shipping detail process (function 910) of Figure 9. The system 100 displays the shipping details page (function 1002). The user enters a pick-up address (function 1004) and the system 100 filters out carrier options based on the pick-up address (function 1006). The user then enters the delivery address (function 1008) and the system 100 filters out carrier options based on the pick-up and delivery addresses (function 1010). The user then selects a pick-up date (function 1012) and the system 100 filters out carrier options based on the pick-up address, delivery address, and pick-up date (function 1014). The user can select a delivery date (function 1016) and the system 100 filters out carrier options based on the pick-up address, delivery address, pick-up date, and delivery date (function 1018). The pick-up and delivery dates can designate an earliest available date, a latest possible date, or a date range for pick-up/delivery by the carrier. The user can select a price limit (function 1020) and the system 100 filters out carrier options by pick-up and delivery addresses, pick-up and delivery dates, and price limit (function 1022). The user can enter package details (i.e. weight, description, type of contents of each package, etc.) (function 1024) and the system 100 filters out carrier options based on pick-up and delivery addresses, pick-up and delivery dates, price limit, and package details (function 1026). The system 100 allows the user to cancel the shipping transaction, or to select a carrier from the filtered carrier options (function 1028). If the user has selected a carrier, the system requests the user to enter payment details (function 1030) (see Figure 11). If the user does not select a carrier within a predetermined time or chooses to cancel the transaction, the system 100 will return the user to the user menu of Figure 9 (function 1032). Figure 11 shows the payment detail process (function 912) of Figure 9. The system 100 allows the user to specify funding source information (i.e. amount, type, and source of funding) (function 1102). The system 100 then determines whether the funding source information is complete (function 1104). If the funding source information is incomplete the system 100 allows the user to re-enter the funding source information (function 1106), and the system 100 again determines whether the funding source information is complete (function 1104). Once the funding source information is complete, the system 100 determines whether funds can be validated (function 1108) by the funding source. If the funds cannot be validated, the system 100 indicates that funds could not be verified with the current source (function 1110) and the system 100 then determines whether or not there is another funding source available (function 1112). If another funding source exists, the system 100 retrieves information about the alternative funding source (function 1114) and requests the user to enter any additional funding source information (function 1106). If an alternative funding source is unavailable, the system 100 determines that funds could not be validated (function 1122), fails the transaction (function 1126) and displays the delivery user menu (function 1128) (see Figure 9). If the system 100 can validate funding (see function 1108) the system then creates a final total itemization of charges (function 1116). The system then requests the user to either accept or decline the total (function 1118). If the user accepts the total, the system 100 displays a confirmation screen (function 1120), and determines whether the validation of funds remains viable (validation may become inactive if a predetermined time period has elapsed) (function 1122). If the validation is viable, the system completes the transaction/shipping request (function 1124) and returns the user to the delivery user menu (function 1128) (see Figure 9). If the system 100 cannot validate funding (i.e. the user does not accept the total charges, the original validation is no longer viable, or validation was never achieved), the system 100 will fail the transaction (function 1126) and display the delivery user menu (function 1128). Figures 12 through 14 show the display transaction process (function 1202, 916) of Figure 9. If the user selects to display the transaction list the system 100 determines whether the user has any pending transactions with the system (function 1204). If the user does not have any transactions, the system 100 determines whether a prior transaction has been cancelled (function 1205). If a previous transaction has been cancelled, the system displays a message indicating that the transaction has been cancelled (function 1207). If a transaction has not been cancelled, the system 100 displays a message indicating the absence of any transactions (function 1206). If the user has one or more pending transactions, the system 100 determines whether shipping data has been entered (function 1208). If the transaction has the system 110 displays a message indicating that a transaction has been initiated, for which the shipping data is incomplete (function 1210). If the shipping data has been entered, the system 100 determines whether the payment data for shipping has been completed (function 1212). If the payment data is incomplete, the system 100 displays a message indicating that the shipping data is completed, and the payment data is pending (function 1214). If the payment data is complete, the system 100 determines whether a package level detail (PLD) file (i.e. pick-up information, size/number of packages, etc.) has been created for the transaction (function 1216), and whether the PDL has been forwarded to the carrier (function 1222). If the PDL has not been created, or not been forwarded to the carrier, the system 100 will display a message indicating that payment data is complete and carrier pick-up is pending (function 1218, 1224); and cancellation of the transaction is prohibited (function 1220, 1226). If the PLD file has been forwarded to the carrier, the system 100 determines whether the package has been picked up (function 1228). If the package has not been picked up, the system 100 displays a message indicating that payment data is complete and carrier pickup is pending (function 1230). If the package has been picked up, the system determines whether the package is still in transit to the delivery address (function 1232). If the package is in transit, the system displays a message indicating that the shipment has been picked up by the carrier and is in transit to the delivery address (function 1234). If the shipment is no longer in transit, the system determines whether the package has been delivered (function 1236). If the package has not been delivered, the system 100 determines whether a trace is pending on the package (function 1240). If a trace is pending, the system 100 displays a message indicating that a trace is in progress (function 1242). If no trace is pending, the system 100 displays a message indicating that the shipment has been picked up by the carrier and is still in transit (function 1238). If the package has been delivered, the system 100 determines whether a damage claim is pending on the package (function 1244). If a damage claim is pending, the system displays a message indicating that a damage claim is pending (function 1246). If no damage claim is pending, the system 100 determines whether the transaction is complete (function 1252). If the transaction is complete, the system displays a message indicating that the transaction is complete (function 1254). If the transaction is not complete, the system displays the delivery user menu (function 1256) (see Figure 9). Although the present invention has been described in considerable detail with reference to certain presently preferred versions thereof, other versions are possible without departing from the spirit and scope of the present invention. Therefore the appended claims should not be limited to the description of the preferred versions contained herein.

Claims

Claims

What is claimed is: 1. A method of sending an item comprising the steps of: receiving by a facilitator pick-up information for an item from a first party, combining facilitator acquired delivery information with the pick-up information to form a transit information for the item, communicating the transit information from the facilitator to a commercial carrier, and transmitting a request from the facilitator to the commercial carrier to pick up the item at a first location other than the facilitator's location and to deliver the item to a second location other than the facilitator's location.

2. A method as claimed in claim 1 , wherein the first location is part of the pick-up information, the second location is part of the delivery information, and the delivery information is provided by a second party.

3. A method as claimed in claim 1 , wherein the first location is a part of the pick-up information.

4. A method as claimed in claim 1, wherein the second location is a part of the delivery information.

5. A method as claimed in claim 1, wherein the carrier is selected from a plurality of delivery services.

6. A method as claimed in claim 1 , further comprising the step of: receiving credit information to be used for payment to the carrier.

7. A method as claimed in claim 1 , further comprising the step of: picking up the item by the carrier at the first location and delivering the item to the second location.

1 8. A method as claimed in claim 1, further comprising the steps of:

2 preparing a label, and

3 delivering the label to the first location.

i

9. A method as claimed in claim 1, further comprising the step of:

2 notifying the carrier by the facilitator upon recipient rejection of the item.

l

10. A method as claimed in claim 9, wherein the item is rejected for being damaged.

1 11. A method as claimed in claim 9, wherein the item is rejected for failing to meet the recipient's expectations.

1 12. A method as claimed in claim 1, wherein the first location represents an address provided by a seller and the second location represents an address provided by a purchaser, and claim 1, further comprising the step of: receiving by the facilitator information regarding a sales transaction between the purchaser and the seller of the item.

13. A method as claimed in claim 12, further comprising the step of: providing for a transfer of funds from the purchaser to the seller.

14. A method as claimed in claim 12, wherein the information regarding the sales transaction includes a purchase price that is predetermined by the seller and stored within a product profile table.

15. A method as claimed in claim 12, further comprising the step of: negotiating a purchase price for the item.

16. A method as claimed in claim 12, wherein the address provided by the seller is stored in a product profile table and the carrier is requested to pick up the item from the stored address.

17. A method as claimed in claim 12, further comprising the step of: notifying the seller that a pick-up is scheduled, and receiving verification from the seller that the item is available for pick-up prior to the carrier picking up the item from the seller.

18. A method as claimed in claim 12, further comprising the step of: receiving a rejection of the item from the purchaser and arranging for re-delivery of the item to the first location.

19. A method as claimed in claim 12, wherein the sales transaction is negotiated using a net venue transaction participant, the participant directing the sales transaction information to the facilitator, and claim 12, further comprising the steps of: collecting payments on behalf of the participant, and transferring the collected payments to the participant.

20. A method as claimed in claim 12, wherein the information regarding a sales transaction includes a purchase price, and claim 12, further comprising the step of: transferring an amount at least equal to the purchase price from a purchaser's financial account into an escrow account.

21. A method as claimed in claim 20, further comprising the step of: transferring at least a portion of the purchase price from the escrow account to a seller's financial account.

22. A method as claimed in claim 21, further comprising the step of: receiving an acceptance of the item from the purchaser prior to the step of transferring at least a portion of the purchase price from the escrow account to the seller's financial account.

1 23. A method as claimed in claim 22, further comprising the step of:

2 waiting a predetermined amount of time to receive a notice of rejection from the

3 purchaser, and

4 transferring at least a portion of the purchase price from the escrow account to the

5 seller's financial account upon passage of the predetermined amount of time

6 without receiving notice of rejection.

1 24. A method as claimed in claim 12, wherein the information regarding the sales transaction

2 includes a purchase offer.

l

25. A method as claimed in claim 24, wherein the purchase offer includes a purchase price.

1 26. A method as claimed in claim 12, wherein the information regarding the sales transaction

2 includes a sales offer.

l

27. A method as claimed in claim 26, wherein the sales offer includes a sales price.

1 28. A method as claimed in claim 12, further comprising the step of: creating a transaction identification number associated with the sales transaction.

1 29. A method as claimed in claim 25, further comprising the step of: transmitting a request for authorization for credit of a transaction amount against a purchaser's financial account.

30. A method as claimed in claim 29, wherein the purchaser's financial account is selected from the group consisting of credit card account, check card, and electronic check.

31. A method as claimed in claim 29, wherein the request for authorization is transmitted prior to notifying the seller of the purchase offer.

32. A method as claimed in claim 29, wherein the transaction amount comprises the purchase price, a calculated shipping charge and transaction fees.

33. A method as claimed in claim 29, further comprising the steps of: receiving an approved request for authorization, and notifying the seller that the purchaser is authorized to purchase the item.

34. A method as claimed in claim 29, further comprising the step of: receiving an approved request for authorization.

35. A method as claimed in claim 34, further comprising the step of: reserving funds in the amount of the transaction amount from the purchaser's financial account without withdrawing the funds from the purchaser's financial account.

36. A method as claimed in claim 34, further comprising the step of: transferring an amount at least equal to the purchase price from the purchaser's financial account into an escrow account.

37. A method as claimed in claim 36, further comprising the step of: transferring at least a portion of the purchase price from the escrow account to a seller's associated financial account.

38. A method as claimed in claim 29, wherein the approved request for authorization is for a period of time, and claim 29, further comprising the step of: extending the authorization period of time for a re-time period prior to expiration of the authorization period of time.

39. A method as claimed in claim 38, further comprising the step of: canceling an authorization request by providing a re-time period of zero days.

1 40. A method of facilitating a transaction comprising the steps of:

2 transmitting a request for authorization for credit of a transaction amount against a

3 purchaser's financial account,

4 receiving an approved request for authorization for a period of time, and

5 extending the authorization period of time for a re-time period prior to

6 expiration of the authorization period of time.

1 41. A method as claimed in claim 40, wherein the authorization has an associated

2 authorization number.

1 42. A method as claimed in claim 40, wherein the authorization is retained during the

2 extended period of time.

1 43. A method as claimed in claim 40, wherein the step of extending the authorization period

2 of time is repeated until an occurrence.

1 44. A method as claimed in claim 43, wherein the occurrence is a cancellation of the

2 transaction.

l

45. A method as claimed in claim 43, wherein the occurrence is a completed transaction.

1 46. A method as claimed in claim 43, wherein the occurrence is a predetermined fulfillment

2 date.

1 47. A method as claimed in claim 40, further comprising the step of:

2 canceling an authorization request by providing a re-time period of zero days.

l

48. A method as claimed in claim 40, wherein the transaction involves the sale of a good.

l

49. A method as claimed in claim 40, wherein the transaction involves the sale of a service.

1 50. A method as claimed in claim 40, wherein the transaction amount comprises a purchase

2 price and transaction fees.

1 51. A method of providing escrow services for a transaction comprising the steps of:

2 transferring a transaction amount at least equal to a purchase price from a purchaser's

3 financial account into an escrow account,

4 sending at least a portion of the purchase price from the escrow account to a seller's

5 associated financial account, and

6 integrating the transferring and sending steps into a purchasing process.

1 52. A method as claimed in claim 51, wherein the purchasing process comprises negotiation

2 between a seller and a purchaser using a net venue transaction participant.

1 53. A method as claimed in claim 51, wherein the sending step is performed without

2 authorization of the purchaser.

1 54. A method as claimed in claim 53, wherein the transferring step is performed after a

2 predesignated time period.

l

55. A method as claimed in claim 51, wherein the transaction involves the sale of a good.

l

56. A method as claimed in claim 51, wherein the transaction involves the sale of a service.

1 57. A method as claimed in claim 51, wherein the transaction amount comprises the purchase price and transaction fees.

58. A method of sending an item comprising the steps of: receiving by a facilitator pick-up information for an item from a first party, combining facilitator acquired delivery information with the pick-up information to form a transit information for the item, communicating the transit information from the facilitator to a commercial carrier, and transmitting a request from the facilitator to the commercial carrier to pick up the item at a first location other than the facilitator's location and to deliver the item to a second location other than the facilitator's location, wherein the delivery information is provided by the first party.

59. A method as claimed in claim 58, wherein the first location is a location of the first party.

60. A method as claimed in claim 58, wherein the second location is a location of the first party.

61. A method as claimed in claim 58, wherein a location of the first party is a location other than the first location and the second location.

62. A web-based purchasing method using a networked computer system to facilitate the purchase of merchandise by a purchaser from a seller, the seller and the purchaser each having an associated financial account, the computer system comprising a merchandise database having stored therein a product profile table for the merchandise, the method comprising the steps of: (a) receiving over the network a purchase offer from the purchaser to purchase the merchandise at a purchase price, the purchase offer associated with the purchaser's financial account; (b) generating and transmitting a request for authorization for credit against the purchaser's financial account to a financial institution associated with the purchaser's financial account to verify that the purchaser has at least the purchase price in the purchaser's financial account to make the purchase; (c) generating an authorization indicator in response to the request for authorization; (d) reviewing the authorization indicator to verify that the purchaser is authorized to make the purchase using the purchaser's financial account; (e) transmitting a request to a carrier to pick up the merchandise from an address specified by the seller; (f) picking up the merchandise from the seller; (g) transferring an amount at least equal to the purchase price from the purchaser's financial account into an escrow account; (h) delivering the merchandise to the purchaser; and (i) transferring at least a portion of the purchase price from the escrow account to the seller's associated financial account.