WO2001031544A2

WO2001031544A2 - System and method for on-line customer and business transactions using an unattended transfer device

Info

Publication number: WO2001031544A2
Application number: PCT/US2000/029902
Authority: WO
Inventors: Stephen Ezell; Carter Griffin; Timothy Ogilvie; Mark Stein
Original assignee: Brivo Systems, Inc.
Priority date: 1999-10-28
Filing date: 2000-10-30
Publication date: 2001-05-03
Also published as: WO2001031544A8; WO2001031544A9; AU1445701A

Abstract

A method for conducting on-line transactions includes the steps of receiving a selection of one or more items for purchase from a customer and an authorization to partially prepay a merchant for the cost of the purchased item or items, transmitting the customer's selection to a merchant, and generating a transaction code and transmitting the transaction code to a transfer device. A first confirmation of sale of the purchased item or items may be received from the merchant and transmitted to the customer. A prepayment then may be transmitted to the merchant, and a notification of delivery of the purchased item or items may be received from the transfer device, and a final payment may be transmitted to the merchant. After the final payment to the merchant, a charge may be posted against the customer for the cost of the purchased item or items.

Description

SYSTEM AND METHOD FOR ON-LINE CUSTOMER AND BUSINESS TRANSACTIONS USING AN UNATTENDED TRANSFER DEVICE

BACKGROUND OF THE INVENTION

1. Field of the Invention The invention relates generally to the field of on-line customer and business transactions. In particular, the present invention is directed to a system and method for on-line customer and business transactions.

2. Description of Related Art

The on-line shopping experience may be a disparate and confusing one for the customer. The customer may visit several sites a week, and make individual purchases at each of several sites. Information about these purchases is delivered to the purchaser randomly. Order confirmations are received in e-mails that arrive in a random and disorganized manner. The customer may either print or save order details at the time of purchase, but may randomly receive two or three e-mails over the course of a week providing delivery confirmations and order status. Often, these e-mails are confused, lost, or unnoticed.

On over 95% of occasions, on-line customers pay for their on-line purchases with credit cards. See E-Marketer, October 24, 1999. Exposing credit cards on the Internet is a well-documented danger. Stories are rife of credit card numbers captured over the Internet and used maliciously. Fear of credit card theft has been cited in several customer surveys as one of the largest barriers to the adoption of Internet shopping. Theft may occur as credit card information "bounces around" the Internet, or may be caused by unscrupulous individuals, who handle credit card information. The traditional comfort of handing a credit card to an unknown waiter at a restaurant, and yet retaining a knowledge of where that credit card is, and which individuals are handling it, is simply unavailable on the Internet. Internet credit card orders may be processed by individuals thousands of miles away.

Even when fraudulent credit card use is not at play, customers still desire protection and control in their credit card use. Perhaps the merchant charged an incorrect amount to the credit card, or perhaps the merchant charged the right amount, but delivered the wrong item. In most instances on the Internet, a customer must pay for a good immediately, even though the goods will not arrive for several weeks. This procedure is antithetical to real-world practice, where the exchange of money for goods occurs simultaneously.

Customers want to buy on-line but (a) do not want to let their credit card information get out on the Internet and (b) do not want to have to pay until they actually receive their goods.

SUMMARY OF THE INVENTION Therefore, a need has arisen for a system and method for on-line customer transactions. Further a need has arisen for a method for aggregating orders and payment activities and histories in a centralized manner.

In an embodiment, the invention is a method for on-line transactions. The method may comprise the steps of creating a database of customer information, including a payment limit and customer identity verification data and receiving a purchase notification, including a cost for each of at least one purchased item and customer verification data. The cost of the at least one purchased items may be compared with the customer's payment limit and the customer identification data may be compared with the customer verification data. The purchase then may be approved if the cost of the at least one purchased items is less than the customer payment limit and if the customer identification data matches the customer verification data. A transaction code may be generated and transmitted to a transfer device.

The payment limit may be, for example, a customer's credit card limit, or a customer's pre-selected payment limit. In addition, the customer information includes a payment method. Moreover, the payment method is by a debit card and the payment limit is a customer's bank account balance.

The method further may comprise the step of authorizing payment for the purchased items to the merchant. This step also may comprise paying the merchant immediately upon placing the order for an item, paying the merchant after receipt of the delivery notification for the item, paying the merchant after approval of the purchase, or paying the merchant after delivery of the at least one purchased items.

Moreover, the method may comprise the step of notifying the customer of delivery of the purchased items to the transfer device or of the approval of the purchase. To facilitate accomplishing this, the step of generating a transaction code further may comprise transmitting the transaction code to a carrier or to the merchant, or both.

In another embodiment, the invention again is a method for on-line transactions. The method may comprise the steps of receiving a selection of at least one item for purchase from a customer and an authorization to charge the customer for payment for the cost of the at least one purchased items. The customer's selection may be transmitted to a merchant, and a transaction code may be generated and transmitted to a transfer device. A first confirmation of sale of the at least one purchased items may be received from the merchant, and the first confirmation may be transmitted to the customer. A second confirmation of payment then may be transmitted to the merchant, and a charge may be posted against the customer for the cost of the at least one purchased item. A notification of delivery of the at least one purchased item may be received from the transfer device, and the merchant then may be paid for the cost of the at least one purchased item. The method of this embodiment may further comprise the steps of creating a database of customer information, including a payment limit and customer identity verification data and comparing the cost of the at least one purchased item with the customer payment limit and the customer identification data with the customer verification data, in response to receipt of customer's selection. The purchase may be approved, if the cost of the at least one purchased items is less than the customer payment limit and if the customer identification data matches the customer verification data.

In still another embodiment, the invention again is a method for on-line transactions. The method may comprise the steps of receiving a selection of at least one item for purchase from a customer and an authorization to partially prepay a merchant for the cost of the at least one purchased items and transmitting the customer's selection to a merchant and generating a transaction code and transmitting the transaction code to a transfer device. A first confirmation of sale of the at least one purchased items may be received from the merchant and transmitted to the customer. A prepayment ten may be transmitted to the merchant, and a notification of delivery of the at least one purchased item may be received from the transfer device, and a final payment may be transmitted to the merchant. After the final payment to the merchant, a charge may be posted against the customer for the cost of the at least one purchased item.

The method of this embodiment may further comprise the steps of creating a database of customer information, including a payment limit and customer identity verification data and comparing the cost of the at least one purchased item with the customer payment limit and the customer identification data with the customer verification data, in response to receipt of customer's selection. The purchase may be approved, if the cost of the at least one purchased items is less than the customer payment limit and if the customer identification data matches the customer verification data.

In yet another embodiment, the invention again is a method for on-line transactions. The method may comprise the steps of receiving a selection of at least one item for purchase from a customer and an authorization to partially prepay a merchant for the cost of the at least one purchased items and transmitting the customer's selection to a merchant and generating a transaction code and transmitting the transaction code to a transfer device. A first confirmation of sale of the at least one purchased items may be received from the merchant and transmitted to the customer. A prepayment then may be transmitted to the merchant, and a charge immediately posted against the customer for the cost of the at least one purchased item. A notification of delivery of the at least one purchased item then may be received from the transfer device, and a final payment transmitted to the merchant. The method of this embodiment may further comprise the steps of creating a database of customer information, including a payment limit and customer identity verification data and comparing the cost of the at least one purchased item with the customer payment limit and the customer identification data with the customer verification data, in response to receipt of customer's selection. The purchase may be approved, if the cost of the at least one purchased items is less than the customer payment limit and if the customer identification data matches the customer verification data. Other objects, features, and advantages will be apparent to persons of ordinary skill in the art in view of the following detailed description of preferred embodiments and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present invention, the needs satisfied thereby, and the features and advantages thereof, reference now is made to the following descriptions taken in connection with the accompanying drawings in which:

Fig. 1 depicts a flush-mounted unattended transfer device according to one embodiment of the present invention; Fig.2 depicts an unattended transfer device with a one-way mechanism according to one embodiment of the present invention;

Fig. 3 depicts a secure door system according to one embodiment of the present invention;

Fig. 4 depicts secure door system having a full-size door according to one embodiment of the present invention;

Figs. 5a-b depict a subterranean enclosure transfer system according to one embodiment of the present invention;

Figs. 6a-b depict a tether transfer system according to one embodiment of the present invention; Fig. 7a-c depict a peg board transfer system according to one embodiment of the present invention;

Fig. 8a-b depict a sensor transfer system according to one embodiment of the present invention;

Fig.9 is a flow chart depicting a basic purchase methodology using an unattended transfer device according to an embodiment of the present invention;

Figs. 10-1 through 10-3 are flow charts depicting the use of an escrow agent for customer-direct transactions;

Figs. 11-1 and 11-2 are flow charts depicting the use of an aggregated credit card process for customer-direct transactions; Fig. 12 depicts a schematic diagram of a delivery contingent payment process; Fig. 13 depicts a schematic diagram of a delivery contingent/final settlement process;

Fig. 14 depicts a schematic diagram of a package confirmation for settlement (PCS) process.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Preferred embodiments of the present invention and their advantages may be understood by referring to Figs. 1-14, like numerals being used for like corresponding parts in the various drawings. Although the term "transfer" is used throughout this document, as used in this application, this term includes shipping, delivery, and storage of goods.

The present invention is preferably used in conjunction with an unattended delivery or transfer device, such as the device described in U.S. Patent No. 5,774,053 to Porter, entitled "Transfer device for the Delivery and Pickup of Goods," which is incorporated herein by reference. The unattended transfer device preferably is equipped for one way or two way communications, whether they be wireless or landline or the like. In an embodiment, a wireless network may be used. In another embodiment, telephone lines may be used. In yet another embodiment, the radio spectrum may be used.

Other types of unattended transfer devices also may be used. For example, referring to Fig. 1, a flush-mounted unattended transfer device (e.g., a controlled access door) is provided. Device 100 may be mounted in exterior wall 150 of a building, such as a house, a garage, an office building, or the like. Device 100 includes an access portal, such as exterior door 102, access controller 104, interior compartment 106, and interior door 108. Interior compartment 106 may be a solid-walled compartment, as shown in Fig. 1, or it may be a cage.

Access controller 104 controls the access to interior compartment 106 by unlocking or locking exterior door 102. Access controller 104 may include an input device, such as a keypad a bar code reader, a voice recognition device, or the like, that allows a person to enter a code, such as an access code or a vendor or transaction code, into the device. A variety of input devices may function as access controller 104, including, but not limited to, an infrared receiver, a radio antenna, an optical scanner, a magnetic strip reader, a lock and tumbler, and combinations thereof.

Device 100 also may include locking mechanism 1 10 to prevent interior door 108 from being opened from the inside of interior compartment 106. Locking mechanism 110 may be a lock and tumbler device or a similar lock. In other embodiments, locking mechanism 110 may comprise a latch on the outside of interior door 108.

Device 100 may operate in a manner similar to the device disclosed in U.S. Patent No. 5,774,053. Generally, during a delivery, access to interior compartment 106 may be granted by access controller 104, and an item for delivery may be placed within interior compartment 106. Exterior door 102 then is closed. For a shipment, the customer may place an item in interior compartment 106 via either exterior door 102 or interior door 108.

Access controller 104 then transmits information to a remote location. This information may include, inter alia, the access time, the access code, the number of packages, and the like. The information also may include a status of the device, such as device status (e.g., open or closed; battery status; empty, partially filled, or filled; communication signal strength; and the like.)

Referring to Fig. 2, an unattended transfer device with a one-way mechanism according to one embodiment of the present invention is provided. Device 200 includes access controller 104, which is substantially identical to that of flush mounted transfer device 100. One-way mechanism 200 also includes rotating door 202 that is mounted on hinge 204. As shown in the figure, rotating door 202 includes walls 206 and 208, which are mounted at a suitable angle to each other. In an embodiment, walls 206 and 208 may be substantially perpendicular to each other; other appropriate angles may be used.

Rotating door 202 may include at least one handle (not shown) for allowing the customer to rotate rotating door 202 open or closed. During a delivery, when rotating door 202 is unlocked, the customer may extend rotating door 202 outward to accept item 210. Item 210 may be placed on wall 206 of rotating door 202, and rotate rotating door 202 closed. Once rotating door 202 is closed, item 210 shifts to rest on wall place item 210 on wall 208 of rotating door 202. If the customer is on the outside, the process is substantially the same as a delivery.

Referring to Fig. 3, secure door transfer system 300 according to an embodiment of the present invention is disclosed. In this embodiment, the customer may decide to permit access to a limited area a building (e.g.. a garage, a breezeway, a mud room, or the like) and protect the rest of the building through a separate security system. When access is granted by access controller 104, exterior door 302 is unlocked, providing access to the interior of a portion of the building. In an embodiment, external door 302 may open to reveal a tote or a basket (not shown), or simply an open area on the floor, onto which any deliveries may be placed.

Referring to Fig. 4, in another embodiment, external door 402 of secure door system 400 may be a full size door, permitting an authorized person to enter an area of a building (e.g., a garage or a separate building) to make a delivery or a pickup. If necessary, security to the remainder of the building may be achieved by an additional security system, including locking a door to the building, or providing an electronic (e.g., motion detectors) or video surveillance system to prevent or announce entry into unauthorized areas.

In an embodiment, external door 402 may be an interior door of a building. For example, external door 402 may open to reveal a storage area, such as a room, a basement, and the like. Thus, the present invention may be used in both personal and commercial storage areas. In yet another embodiment, external door 402 may be used as a replacement for any conventional door.

In another embodiment, a subterranean enclosure transfer system is disclosed. For example, referring to Figs. 5a and 5b, a customer may use access controller 104 to unlock access door 502 that is adjacent to building 504, which leads to enclosed underground area 506, such as the entrance to a storm cellar. The customer gains access to area 504 through external door, 502, or through an internal door (not shown) similar to those described above. This embodiment may be less obtrusive from an aesthetic standpoint, but may also benefit from temperature control advantages provided by subterranean thermodynamics (e.g., substantially constant year-around temperatures of about 55° F).

Alternatively, a "safe zone" may be provided into which packages may be inserted and from which they may not be removed without triggering an alarm. The safe zone for unattended transfer may be a section of a property, including a porch, a deck, a carport, or other designated area that may be adjacent to or near a building or home. Security may be provided through some non-enclosed means of attachment or sensing, as will be discussed below.

In another embodiment, a tether transfer system may be provided. Referring to Figs. 6a and 6b, tether system 600 may use a small lanyard or plug-in that is attached to the shipping package or container. Upon delivery of a package to the home, tether 602 may be received in connection 604 that is provided in container 606. Container 606 is then protected from theft until tether 602 is released by access controller 104 by a entering a code or providing a key. In an embodiment, tether 604 may be secured to container 606 in such a way that container 606 or its contents may be damaged or destroyed in order to remove container 606 without properly unlocking tether 602. Alternatively, tether 602 may be integral to the locking system on the home, and container 606 may come with either a loop (not shown) through which tether 602 may pass, or female connector 608 to match male end 610 of tether 602. In another embodiment, a tether may be integral with the container, and may be received by a receptacle provided in the secure area. In yet another embodiment, a special container may be provided. The special container may be made of a material, such as plastic, to provide durability, and may be equipped with either a tether or a receptacle for the tether. The special container may be provided with a locking mechanism as well.

In another embodiment, a peg board transfer system may be provided. A peg board system includes one or more hooks attached to a package. In Fig. 7a, pegboard system 700 includes access controller 104 and pegboard 702, which may be divided into a plurality of zones, or regions. Packages 704, such as those shown in Figs. 7b-c, may be delivered with pegs 706 protruding from a portion of the package. Packages 704 may include special containers that have pegs 706 formed integrally therewith, or pegs 706 may simply be attached to packages 704.

Similar to the tether design, pegs 706 are received by holes 710 in pegboard 702. Pegboard 702 may be part of a larger, home or business security system where any inserted pegs then may be secured in place by a locking mechanism. Packages 704 are then secure until they are released by access controller 104 through the actions of someone possessing a key (or codes that serve as a key). Pegs 706 may be secured to package 704 in such a way that package 704 or its contents may be damaged or destroyed in order to remove it without unlocking peg board 702. In yet another embodiment, a sensor transfer system is provided.

Referring to Figs.8a and 8b, sensor system 800 may operate by using electric sensor 802 that emits electromagnetic signal or emission 804 covering a predetermined area. Packages 806 include sensors 808 that may be located on the outside of package 806 or within package 806. Sensor 808 may be a small chip similar in size and function to the shoplifting prevention device attached to clothing in some retail stores, such as U.S. Patent No. 4,123,749 and U.S. Patent No. 5,874,896. In yet another embodiment, a sensor 808 may be integrated with a special container (not shown).

Once package 806 including sensor 808 is recognized, sensor system 800 is switched into "locked" mode and maintains electronic contact with the package 806. If this contact is interrupted, a warning is provided. This may include sounding an alarm, on activating other security measures (e_^g., activating an electronic camera to capture activity in the predetermined area). As with other embodiments, to remove package 806 from the area, an authorized recipient may be required to possess a key or a code to disable the alarm. Regardless of the specific embodiment, the unattended transfer device may be part of a simple physical security mechanism, or part of a device with broader functions and possessing intelligence. For example, such functions and intelligence may include the ability to notify the homeowner of delivery of the package. For deliveries to the system, input codes that identify the package may be used, so that notification may specify the package, the carrier or shipping company, the time of delivery, and the like. Further, the customer may register the unattended transfer device with a service provider. This may include transmitting the individual's name, social security information, home and work address, telephone and other digital/analog communication numbers or electronic mail addresses, as well as information regarding the individual's preferences as a customer of the system, including preferred means of notification, preferred shipping provider, preferred transfer device pick-up times, a "buddy-list" of additional people authorized to use the device, and the like, and combinations thereof. The customer also may register payment information in the central database. A preferred method of payment is a credit card; however, it is possible that payment may be accepted via a debit card, check, electronic-check ("e-check"), or electronic-wallet ("e- wallet") - the latter two examples referencing forms of electronic payment made over the Internet.

In an embodiment of the present invention, a third party may serve as an intermediary between the customer, which may be a customer or business person, and the shipping company. The third party may be referred to as a Network Agent. Referring to Fig.9, the customer may register with a Network Agent (step

902). This may be done be providing personal identification and billing information to the Network Agent and receiving alternative identifying information, such as or including a transfer device identification number, from the Network Agent. When the customer makes a purchase (step 904), the customer will be prompted for identification and payment information (step 906). Instead of providing this information, the customer may provide the alternative information obtained from the Network Agent (step 908), or the merchant may query the Network Agent directly. In step 910, the merchant may then contact the Network Agent to determine whether the customer's purchase is approved or disapproved. If disapproved, the purchase is denied (step 912). However, if the purchase is approved (step 914), the Network Agent pays or arranges for payment to the merchant (step 916). In step 918, the customer is notified of the approval and the payment, and the transaction is entered in the Network Agent's database (step 920).

In step 922, the Network Agent processes the transaction information. This may include arranging for the delivery of the purchased item to the customer's transfer device. In step 924, the selected delivery agent (or the vendor) delivers the purchased item to the transfer device, gaining access by the means described above. The Network Agent is notified of the delivery (step 926) and informs the customer. Alternatively or additionally, the customer may be informed directly by the transfer device Upon receipt of this notification and the Network Agent's invoice, the customer pays the Network Agent for the purchased item.

In another embodiment, a plurality of unattended transfer devices may be co-located in a "post office box" type of arrangement. In this embodiment, the individual bins or boxes may each by owned, or they may be commonly owned by a party, and leased or rented to customers. For example, a customer may rent an individual bin or box in the same manner that a person may rent an apartment, and may have exclusive possession of that individual bin during that time period. A group of customers may rent an individual bin or box in the same manner. Further, a customer may rent an individual bin or box for a single delivery.

An important issue associated with shared resources is their effective utilization. Utilization of a cluster bin or box may be described in classic telecom theory. For example, arrival rates (both inbound and outbound), how often the bin is being used and by how many customers; and average handle times (how long the package is in the bin from insertion to pickup) should be considered.

Package size is an important consideration with such a device. For smaller packages, a common bin may be provided, such that access to remove packages may be limited to the carrier. These would be somewhat similar to the bins that carriers use today to drop off packages for pickup. For larger packages, a common cluster of bins may be used. Nevertheless, a combination of large and small bins may be provided in a common device. The customer may register the unattended transfer device, described above, with a service provider, such as a third party agent (referred to in the figures as "3P"). This may include transmitting the individual's name, social security number, home and work address, telephone and other digital/analog communication numbers or electronic mail addresses, as well as information regarding the individual's preferences as a customer of the system, including preferred means of notification, preferred shipping provider, preferred transfer device pick-up times, a "buddy-list" of additional people authorized to use the device, and so forth. The customer also may register payment information into the central database. A preferred method of payment is a credit card; however, it is possible that payment may be accepted via a debit card, check, electronic- check ("e-check"), or electronic-wallet ("e- wallet") - the latter two examples referencing forms of electronic payment made over the Internet.

The unattended transfer device of the present invention may be used in conjunction with agency software. In an embodiment of the present invention, the customer may install software running on the customer's personal computer, such as a Palm VII™ hand held device, a web-enabled device, or the like. This software may run in the "background" without being noticed by the customer, or it may take a more prominent role. The software may be used to monitor a customer's Internet purchases, and may provide requested information, if desired. The functionality of the software will be discussed as an embodiment of the present invention. However, the present invention does not require the use of such software, nor is it so limited. The software may facilitate the use of the unattended transfer device, facilitate purchases, and provide information to the customer. In an embodiment, the software may assist the customer from their "arrival" at an electronic commerce web-site until the ordered item(s) arrives in their unattended transfer device or home.

The software may be stored on the hard drive or in the memory of a computer, or other web-enabled device, and may interact with an Internet browser and an electronic commerce web-site on the Internet so as to stand between, or more particularly, accompany and stand with the on-line customer during the Internet shopping experience. Alternatively the software could be computer code programmed into the browser Internet. The software manages the on-line shopping experience from the customer' s point of view by storing, collecting, and manipulating information related to the on-line shopping experience.

When a customer directs it to do so, the software may automatically provide the customer's personal data to the web-site the customer is visiting. This obviates the need to reenter personal, contact, and payment information at each new site visited when a purchase is being made. The customer may be able to control anonymity by governing the software's amount of information of disclosure; for example, customers may or may not wish to instruct the software to share their physical address with a merchant.

In another embodiment, the software may be used to determine when an order should leave the merchant's warehouse and enter the delivery channel. This determination may be made based upon the characteristics of the order (weight, size, number of parcels, cost thereof, distance to be transported, and the like.) and historical data about the punctuality and efficiency of various shipping companies. The software may store the results of a customer's previous shipment experiences over time (e.g., how long it took for the package to be delivered, whether or not the delivery was satisfactory and had to be returned, whether or not the package arrived over a weekend) and uses this information in a learned manner to make predictions about future delivery timeframes.

In one embodiment, the software may perform additional services for the customer. For example, the software may "follow up" if an item does not enter the delivery channel. It may follow-up by sending an electronic notification via e-mail to the shipping company, or it may trigger a notice for an individual to contact the shipping company directly. It also may inform the customer of the re-ship date if a reshipment is necessary. In addition, the software may automatically inform the customer if the order will be shipped as a "split" order and provide information concerning the expected arrival of each portion of the split order. Moreover, the software may automatically send complaint messages to all interested parties should the customer files a complaint. The customer may have the ability to file a complaint through the software. It may send a message regarding complaint resolution to all parties if a submitted complaint is resolved.

The software also may complete feedback cards, or forms, on the customer' s behalf (if the customer enables this feature.) Such forms are often generated by the merchant web-site to evaluate the customer's experience.

The software may inform the customer when a delivery option falls outside of the customer's preferences. For example, it may inform the customer that the package delivery option selected meets the customer's preferences, but that, based on historical data, the merchant historically does not timely ship products from its warehouse. Additionally, a customer may only desire a product at a certain cost/time to delivery price point. The software may assess customer preferences/needs and choose for the customer the shipping method best suited to those preferences.

A customer may establish "lock out" preferences that enable on-line shopping only at specified times during the day, so that children, or unauthorized persons, do not access the Internet in the customer's absence and order products from web-sites. The software may necessitate the entry of a password before it shares payment information with a web-site.

The software may store the costs for an item at web-site(s) and compare them as a customer shops around the Internet. The software also may store the shipping costs for various delivery options presented to customers at various web-sites. It may keep a running account in one corner or area of the computer screen displaying accumulated purchase/shipping costs for items the customer has selected for potential purchase at various web-sites.

The software may alert the customer when certain prohibited buying conditions, setup and pre-established by the software customer, are violated. For example, a customer might specify to the software that it is a violation to purchase alcohol on the Internet. If an order for alcohol is placed, the software will compare that order to prohibited entries in its database, and alert the customer as to the violation.

The software may provide usage history reporting. The software may be capable of auditing customer's usage history and provide advice on relevant topics, such as how to reduce buying costs, based on the information it has captured. It may also perform an audit of the usage history in order to offer tips about how to maximize or optimize loyalty program awards. These loyalty program awards may take the form of cash reimbursement, payment in kind, rebates, discounts, or coupons. The software also may maintain a "lookout" for special offers, sales, or discounts that a customer has defined as interesting. Such offers or promotions may apply equally to a particular product, a brand, or the offers of an entire company. The software may contain automated components that enable it to conduct searches of electronic commerce web-sites. For example, a customer may know that a video game will come available shortly over the Internet. The software may search the Internet and inform the customer as soon as the product appears for sale at any web-site. A customer using an unattended transfer device, as described above, may have several methods for payment. For example, in still another embodiment, the third party agent may provide a service for a customer where the customer is not charged for item(s) purchased until the third party agent receives proof of delivery from the customer's unattended transfer device.

Before conducting a transaction, customers preferably will have sufficient credit available with a customer operations center to cover the costs of the transaction.

Referring to Figs. 10-1 through 10-3, a process 1000 for customer direct transactions, using an escrow agent, is described. Merchants participating in the service may not need any prior relationship with the customer operations center (COC) of a Network Agent.

In steps 1002-1018, customers may elect to use the services of the COC to coordinate any transaction they make either on-line or via catalog. Customers provide personal information (step 1006), which may be used to verify their identities; address information (step 1008) for use in delivering or picking up goods; and payment information (e.g.. credit card, debit card, e-check, or e-wallet (steps 1010 and 1012).

After they indicate their preferred method of payment to the merchant (step 1012) , they provide a transfer device identification number assigned in step 1014.

A new customer must receive a transfer device identification number (step 1014); receive and install a transfer device step (1016); and opt to participate in an escrow agent purchase process (step 1018). When the customer goes shopping on the Internet and decides to make a purchase (steps 1020-1024), the site will prompt the customer for personal payment information (see steps 1006-1010 above). As indicated in steps 1026 and 1030, this information may be entered manually or automatically. In either event, however, agency software will monitor the transmission of the information (step 1028).

In step 1032, the merchant, whether a catalog merchant or on-line merchant, then may request credit card information from the customer. In steps 1034- 1036, the customer may respond by instructing the web-site or the merchant to contact the Network Agent's COC, by entering the transfer device identification number at the web-site or providing it to the merchant, and by activating the transfer device (if not already activated). The agency software opens a channel to the COC (step 1040), and, in step 1042, the COC checks the customer's credit account to ensure there is available credit. If so, then the COC approves the purchase (step 1044) and the COC makes payment to the merchant (step 1052) or pays the merchant using its own credit (step 1050) and further defers actual disbursement. Once payment has been made, the transaction may be logged into the

COC database (step 1054) and the purchase appears in the customer's account in the agency software (step 1062). The customer may be e-mailed or otherwise notified of the payment (step 1056). There are several options available in terms of charging the customer's credit card. When a package gets delivered to a transfer device, the entry of the transaction code(s) (generated in step 1060) used to open the unit informs the COC that the customer's specific package has arrived. The communication devices used to transmit vendor codes, the methodologies of the transfer device customer or deliverer to enter codes into the transfer device, and the methods for opening and closing the transfer device, are described below. Once the COC knows that a customer has received his package, the COC may instantly charge his or her credit card for the goods. However, the COC also may hold the purchases and aggregate them into a monthly billing statement, at the customer's preference (see steps 1064-1076).

Whether or not the customer chooses to be billed in a monthly fashion, the customer has the option to receive monthly use statements (step 1066 and 1068), showing the dates, times, contents, and the like, of each transfer device delivery use and a summary statement of purchase activity made in conjunction with the transfer device (step 1070). If the customer is using the agency software, described below, the monthly statements will summarize and generalize all on-line purchasing activity, whether or not the customer routed the purchase for delivery to the transfer device. Likewise, the COC might establish deferred to weekly billing cycles with electronic commerce or catalog merchants. For example, the COC may aggregate all customers' purchases of goods at a particular web-site and make a lump-sum payment to the merchant on a weekly or perhaps daily basis.

One of the benefits of this escrow functionality is to expand the use of non-credit card payment options on the Internet. For example, the COC might set up electronic-wallets, on-line electronic debit accounts for each of the COC's customers, that will debit from their accounts for their on-line purchases. The preferred method is still credit card payments, but it does introduce the option to viably use other forms of electronic payment.

Referring to Figs. 11-1 and 11-2, when subscribing to the unattended transfer device system 1100 , the customer is issued agency software that will contain the functionality to enable credit card monitoring and protection by the Network Agent. Once again the customer must enable and activate the agency software (step 1102) and enter payment information into the database (1 104). When a customer makes a purchase from an e-commerce web-site (or from a retail catalog) in steps 1106-1112, the customer provides the merchant with a transfer device identification number, instead of standard (e.g., credit card number) payment information. When the customer is prepared to make a purchase from a web-site (step 1106), the customer clicks the order button (step 1 108). The process is analogous to the agency software/browser interface/interaction discussed above. At the time of order, agency software also generates unique transaction codes, which are communicated to the merchant and the carrier/deliverer and to the transfer device (step 1114), and which are used by the carrier/deliverer to attain access to and open the transfer device for package insertion (step 1118).

The Network Agent develops transaction (or vendor) codes for the transfer device and the carrier/deliverer (step 1116). When the carrier/deliverer closes the transfer device after inserting the relevant package inside, the closing of the transfer device (step 1 120) signals the control device operating the transfer device to generate several communications simultaneously. The customer and the COC are notified (step 1124), by his or her preferred method, that a parcel awaits in the transfer device (step 1122). The transfer device also signals the COC that a specific transaction has occurred, referencing, inter alia, the transaction codes used, time, name of carrier/deliverer and the like that successful delivery has occurred (step 1126). Only at this point will the COC pay the on-line merchant for the product and record a debit in the account of the customer (step 1128). The COC preferably will not advance the money for the purchase unless there is sufficient available credit in the customer's credit card account. Further, the agency software preferably will not advance money for purchases over the amounts pre- specified by the COC. Thus, the customer will have the product sent without needing to pay for it at the point of purchase. Further, the customer only is charged when the product arrives at the transfer device. The customer is secure knowing that his or her money is not at risk until the product is in-hand, replicating the traditional and real-world experience of buying from a store.

To effect payment, the COC has at least two options. First, the COC may pay the merchant on a weekly, monthly, or quarterly basis (step 1138 and 1140), aggregating all charges against it (step 1132) and providing customer statements and a lump-sum invoice at these various time points (step 1142). Alternatively, the COC could post a charge against the customer at the time of receipt of each individual package (step 1130). Similarly, the COC may bill a customer for the on-line purchase at the exact time of receipt, or may defer an invoice to be combined with a time-specified billing/customer statement delivered to the customer at specified timeframes, weekly, monthly, or even quarterly. For this service, the customer will have to forgo promotions or benefits provided with their credit card; but the COC might provide some additional credit or enticement to make up to the customer. If there is a disputed claim, the COC will mediate the dispute between the electronic merchant and the customer. The customer's credit card information is not released or otherwise made known (step 1 134). Agency software assists customers from the moment of their arrival at an electronic commerce web-site on the Internet until the package arrives at their home. The agency software will assist on-line customers as they browse amongst various web-sites, attempt to calculate and compare purchase costs and shipping costs both separately and concurrently, place orders, pay for orders, and evaluate their purchases. Functionally, the software may be stored on the hard drive of a personal computer and interact with an Internet browser and an electronic commerce web-site on the Internet so as to stand between, or more particularly, accompany and stand with the on-line customer during their Internet shopping experience. The software will manage the on-line shopping experience from the customer's point of view by storing, collecting, and manipulating information related to the on-line shopping experience. The software may be a thin client application that sits atop the customer' s desktop. However, the software itself may reside on almost any open systems platform, which includes laptop computers, network or commerce servers, PalmPilota electronic organizers, universal portable devices, or the like. The agency software monitors on-line buying activities by linking to an transfer device. This unit may feature an enclosure with an included communications device designed for the inbound delivery and outbound sending of packages, such as that described in U.S. Patent No. 5,774,053. The agency software and the services it provides are a central piece of the transfer device, and may be used in conjunction with the other systems, described above. When a customer directs it to do so, the agency software automatically provides the customer's personal data to the web-site the customer is visiting. This obviates the need to reenter personal, contact, and payment information at each new site visited when a purchase is ready to be made. The customer may control anonymity by governing the software's amount of information of disclosure; for example, customers may or may not wish to instruct the software to share their physical address with a merchant.

The agency software determines when customer's order is expected to leave the merchant's warehouse and enter the delivery channel. This determination is made based upon the characteristics of the order (weight, size, number of parcels, cost thereof, distance to be transported, and the like.) and historical data about the punctuality and efficiency of various shipping companies. The software stores the results of a customer's previous shipment experiences over time - how long it took the package to be delivered, whether or not the delivery was satisfactory and had to be returned, whether or not the package arrived over a weekend - and uses this information in a learned manner to make predictions about future delivery timeframes. The agency software then: a) Follows up if the package does not enter the delivery channel. It may follow-up by sending an electronic notification via e-mail to the shipper, or it may trigger a notice for an individual to contact the shipper personally. b) Informs the customer of the re-ship date if a reshipment is necessary. c) Automatically sends complaint messages to all interested parties if the customer files a complaint. The customer is able to file a complaint through the agency software. d) Sends a message regarding complaint resolution to all parties if a submitted complaint is resolved. e) Evaluates split order contingency.

The agency software may fill out feedback cards or forms on the customer's behalf (if the customer enables this feature.) Such forms are often generated by the merchant web-site to evaluate the customer's experience. The software additionally informs the customer when a delivery option falls outside of the customer's preferences. For example, it might inform the customer that the package delivery option selected meets the customer's preferences, but that the COC's method for determining when the package is expected to leave the warehouse exceeds the customer's delivery options, based on historical data demonstrating that the merchant historically does not timely ship products from their warehouse. Additionally, a customer might only desire a product at a certain cost/time to delivery price point. The agency software could assess customer preferences/needs and choose for the customer the shipping method best suited to those preferences.

A customer might establish preferences that enable on-line shopping only at specified times during the day, so that children do not get onto the Internet overnight and start ordering products from web-sites. The software may necessitate the entry of a password before it would share payment information with a web-site.

The software may store the costs for an individual product at web-site(s) and compare them as a customer shops around the Internet. The software also may store the shipping costs for various delivery options presented to customers at various websites. It may keep a running tab in one corner of the computer screen displaying accumulated purchase/shipping costs for items the customer has selected for potential purchase at various web-sites.

The agency monitoring software may alert the customer when certain prohibited buying conditions, setup and pre-established by the software customer, are violated. For example, a customer might specify to the software that it is a violation to purchase alcohol on the Internet. If an order for alcohol is placed, the software compares that order to prohibited entries in its database, and alert the customer as to the violation.

The software allows for usage history reporting. The software may audit customer's usage history and provide advice on relevant topics, such as how to reduce buying costs, based on the information it has captured. It may also perform an audit of the usage history in order to offer tips about how to maximize or optimize usage benefits, such as loyalty program awards. Such benefits may take the form of cash reimbursement, payment in kind, rebates, discounts, or coupons.

The software may maintain a lookout for special offers, sales, or discounts that a customer has defined as interesting; such offers or promotions may apply equally to a particular product, a brand, or the offers of an entire company. The software may contain automated components that enable it to conduct searches of electronic commerce web-sites. For example, a customer may know that a video game will come available shortly over the Internet. The software will search the Internet and inform the customer as soon as the product appears for sale at any web-site.

The customer may carry a credit card through an issuing bank. The customer has deployed an unattended transfer device, such as that described above. The third party that deploys the unattended home delivery device, also may act in a third party agency capacity to facilitate payment for goods purchased on-line. Referring to Fig. 12, a delivery contingent payment process is shown.

Initially, the customer makes a selection for an item to purchase from an on-line merchant. The customer authorizes the third party agent to charge the purchase against a credit card. The customer presents his credit card to the on-line merchant, either by manually keying it into forms on the merchant's web-site, by directing an electronic wallet to communicate the credit card information, or by verbally reading to an agent of the on-line merchant. The merchant communicates the purchaser's credit card information electronically (although the information might be read verbally) to the merchant's financial institution. The merchant's financial institution makes an electronic inquiry, an "Authorization Request" to the bank that issued the credit card to the customer, seeking authorization for the expense. The bank's computer system accepts the electronic request and queries its databases whether the customer has available credit for the purchase and is currently authorized to make charges against this credit card. The customer's bank formulates a decision to this "Authorization Request," which is communicated electronically back to the merchant' s financial institution, which in turn forwards the yes/no decision to the merchant. This constitutes the exchange of data between the merchant and the third party agent. If the card is not approved, then the transaction ceases. If the card is accepted, then the on-line merchant has effectively received from the third party agent a promise to pay for the relevant purchase.

The on-line merchant then ships the purchase, consisting of a package(s), to a third party agent provided or approved receptacle having a delivery confirmation device. Such a receptacle might consist of an unattended transfer device, such as that described above. When the package(s) have been successfully deposited into the device by the agent of a carrier/deliverer, the unit provides confirmation that the package(s) have been safely and fully received, communicating that information via electronic signal to the third party agent's COC. The confirmation alerts the COC that the package(s) has been received.

With that knowledge, the third party agent will pay the on-line merchant via an electronic fund transfer after (e.g.. on the day after) the package safely arrives at the unattended transfer device. Finally, the third party agent will record a charge against the customer's credit card the moment the package is received in the receptacle. Thus, the customer is charged and required to make payment only once the product is received. The merchant is short the float for the days the package is in transit.

The customer may carry a credit card through an issuing bank. The customer has deployed an unattended transfer device, such as that described above. The third party is linked to the unattended transfer device also acts in a third party agency capacity to facilitate payment for goods purchased on-line. The third party agent has the customer's credit card information on file.

Referring to Fig. 13, a delivery contingent/ final settlement process is shown. Initially, the customer makes a selection for an item to purchase from an on-line merchant. The customer authorizes the third party agent to make payment for goods purchased in conjunction with this transaction. The third party agent immediately pays the on-line merchant for the purchase. This is accomplished through an electronic funds transfer.

Next, the on-line merchant ships the purchase, consisting of a package(s), to a third party agent provided or approved receptacle. Such a receptacle might consist of an unattended transfer device, such as that described above. The unattended transfer device generates a signal when the package(s) has been received in the unattended transfer device, informing the third party agent's COC that the package has arrived safely in the unattended transfer device.

Once the third party agent receives confirmation that the package(s) has been delivered to the unattended transfer device, the agent charges the customer. Ideally, the third party agent will immediately place a charge onto the customer^'s credit card, which information the agent retains on file. Alternatively, the third party agent might deduct the purchase amount from a debit account managed by the third party agent. This process implies that the third party agent will float cash for the duration of the time it takes the shipment to reach the receptacle; as the third party agent will have paid the online merchant for the purchase, but not yet received payment for the purchase from the customer. The merchant gets paid instantly and carries no float.

The customer may carry a credit card through an issuing bank. The customer has deployed an unattended transfer device, such as that described above. The company that deploys the unattended transfer device also acts in a third party agency capacity to facilitate payment for goods purchased on-line. The third party agent has the customer's credit card information on file.

The customer makes a selection for an item to purchase from an on-line merchant. The customer authorizes the third party agent to make payment in conjunction with this transaction. The third party agent immediately pays the on-line merchant for the purchase. This is accomplished through an electronic funds transfer.

Next, the on-line merchant ships the purchase, consisting of the package(s), to a third party agent provided or approved receptacle. Such a receptacle might consist of an unattended transfer device, such as that described previously. The unattended transfer device generates a signal when the package(s) has been received in the unattended home transfer device, informing the COC of the third party agent that the package has arrived safely in the unattended transfer device.

Once the third party agent receives confirmation that the package(s) have been delivered to the unattended transfer device, the third party agent will record in a payment history log the amount of the purchase. All of the customer' s on-line purchases for a given month is recorded and aggregated. Finally, at the end of the month, the third party agent sends the customer an invoice (bill) for the customer's aggregate on-line purchases that month. Thus, merchant is paid immediately, but customers have one month, plus the time it took the delivery itself to arrive, before they will be payment- liable for their on-line purchases.

The third party agent effectively carries a float consisting of: a) the number of days it took before the package(s) to arrive in the device; b) the thirty-day billing cycle for the monthly statements; c) the time between the receipt of invoice data and the payment due date; d) the number of days it might take (after the date due has passed) for the customer to remit payment to the third party agent; and e) duration of any system outages.

In this model, the third party agent acts somewhat like a credit card issuing bank. The third party agent will have the ability to charge interest for late payments. The third party agent will not accept credit card payment of the invoice, but instead requires payment by check or debit account.

The customer may carry a credit card through an issuing bank as described above. The customer has an unattended transfer device. The company that deploys the unattended transfer device also acts in a third party agency capacity to facilitate payment for goods purchased on-line. The third party agent has the customer's credit card information on file.

Referring to Fig. 14, a package confirmation for settlement (PCS) process is shown. Initially, a customer goes to a web-site on the Internet and decides to purchase a product from an on-line merchant. When prompted to enter his or her payment information, the customer enters and sends his or her unattended transfer device identification number to the merchant. The third party agent, in this case, is the same company providing the unattended transfer device to the customer. The third party agent then pays the merchant, immediately after the customer has made his or her selection, via an electronic funds transfer, so that the merchant gets paid at the point of purchase. Just after the third party agent pays the merchant, the third party agent charges the customer for his purchase. Ideally, this charge entails the automatic addition of a debit to the customer's credit card account. Alternatively, the customer might have a debit account on file with the company, and the cost of the purchase might be subtracted from the debit account.

The on-line merchant then ships the purchase, consisting of the package(s), to a third party agent provided or approved receptacle. Such a receptacle might consist of an unattended transfer device, such as that described above. The transfer device generates a signal when the package(s) has been received in the transfer device, informing the COC that the package has arrived safely in the unattended transfer device. The confirmation closes out the transaction.

There is no float involved to the on-line merchant at the time of purchase because the third party agent immediately sends payment to the merchant; likewise, there is no float with regard to the third party agent because it receives payment from the customer immediately.

EXAMPLES:

The invention will be further clarified by a consideration of the following examples, which are intended to be purely exemplary of the use of the invention.

In a first example relating to situations involving temporarily assigned storage bins or boxes, the customer grants access to a bin or box by means of a delivery access code (DAC). Customers may themselves access a bin or box with an owners access code (OAC). In such situations, a customer enters the assigned customer DAC. This customer DAC may be made valid to access any bin or box or may be made good for any linked storage bin or box. Alternatively, the DAC may be limited to providing access only to empty bins or boxes. The DAC also may provide only single use access or may remain valid indefinitely for access to empty bins or boxes. The customer then may request a pick-up access code (PAC). Bin or box messages may be generated in response to the entry of the PAC and may be displayed at the bin or box. In an embodiment, customers may generate their own PACs at the storage bin or box, at a website, or by interacting with a COC.

If PACs are generated by the bin or box, the PACs must be uploaded to the COC. The COC associates each PAC with a bin or box and a customer. The customer uses the DAC to open the bin or box and the customer then may deposit a package. The COC then notifies a commercial carrier of the pick-up by identifying the bin or box number.

When the carrier's representative arrives at the bin(s) or box(es), he or she enters the PAC. The bin or box then opens to permit the carrier to retrieve the deposited package. The status of the pick-up (and of the bin or box) is then transmitted to the customer operations center, ant the customer is notified of the pick-up.

In a second example, a delivery of some ordered good (e.g., laundry) may be anticipated or scheduled by a customer. The customer may establish a temporary DAC through the customer operations center and provide it via a computer network (e.g.. the Internet) to a vendor. The DAC may also be sent by direct or wireless link to a tether (Figs. 6a-6b) or pegboard (Figs. 7a-7c) or sensor control system (Figs. 8a-8b). When the vendor (or its representative) arrives with the goods, the vendor enters the DAC into the transfer device and the device may unlock or indicate the preferred location for positioning the goods (e.g., where to hang the laundry on the pegboard). For example, with a tether, the vendor may insert a male-end into the female-end of a tether connector, or, in a sensor system, the vendor may position the goods in view of the sensor.

Whatever control system is utilized, the control system will sense the physical presence of the delivered goods. The security components of the control system will engage or surround the goods and will prevent unauthorized removal. The customer then will be notified of the completed delivery.

While the invention has been described in connection with preferred embodiments and examples, it will be understood by those skilled in the art that other variations and modifications of the preferred embodiments described above may be made without departing from the scope of the invention. Other embodiments will be apparent to those skilled in the art from a consideration of the specification or practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

Claims

1. A method for on-line transactions, comprising the steps of: creating a database of customer information, including a payment limit and customer identity verification data; receiving a purchase notification, including a cost for each of at least one purchased item and customer verification data; comparing the cost of the at least one purchased item with the customer's payment limit and the customer identification data with the customer verification data; approving the purchase, if the cost of the at least one purchased item is less than the customer payment limit and if the customer identification data matches the customer verification data; and generating a transaction code and transmitting the transaction code to a transfer device.

2. The method of claim 1, further comprising the step of authorizing payment for the purchased items to the merchant.

3. The method of claim 2, wherein the step of authorizing payment for the at least one purchased items further comprises paying the merchant.

4. The method of claim 2, further comprising the step of paying the merchant after receipt of the delivery notification.

5. The method of claim 2, further comprising the step of paying the merchant after approval of the purchase.

6. The method of claim 2, further comprising the step of paying the merchant after delivery of the at least one purchased item.

7. The method of claim 1 , further comprising the step of notifying the customer of delivery of the purchased items to the transfer device.

8. The method of claim 1 , wherein the step of generating a transaction code further comprises transmitting the transaction code to a carrier.

9. The method of claim 1, further comprising the step of notifying the customer of the approval of the purchase.

10. The method of claim 1, further comprising the step of transmitting the transaction code to the merchant.

1 1. The method of claim 1, wherein the payment limit is a customer's credit card limit.

12. The method of claim 1, wherein the payment limit is a customer's pre-selected payment limit.

13. The method of claim 1 , wherein the customer information includes a payment method.

14. The method of claim 13, wherein the payment method is by a debit card and the payment limit is a customer's bank account balance.

15. A method for on-line transactions, comprising the steps of: receiving a selection of at least one item for purchase from a customer and an authorization to charge the customer for payment for the cost of the at least one purchased item; transmitting the customer's selection to a merchant and generating a transaction code and transmitting the transaction code to a transfer device; receiving a first confirmation of sale of the at least one purchased item from the merchant and transmitting the first confirmation to the customer; transmitting a second confirmation of payment to the merchant and posting a charge against the customer for the cost of the at least one purchased item; receiving a notification of delivery of the at least one purchased item from the transfer device; and paying the merchant for the cost of the at least one purchased item.

16. The method of claim 15, further comprising the steps of: creating a database of customer information, including a payment limit and customer identity verification data; and comparing the cost of the at least one purchased item with the customer payment limit and the customer identification data with the customer verification data, in response to receipt of customer's selection.

17. The method of claim 16, further comprising the step of approving the purchase, if the cost of the at least one purchased item is less than the customer payment limit and if the customer identification data matches the customer verification data.

18. A method for on-line transactions, comprising the steps of: receiving a selection of at least one item for purchase from a customer and an authorization to partially prepay a merchant for the cost of the at least one purchased items; transmitting the customer's selection to a merchant and generating a transaction code and transmitting the transaction code to a transfer device; receiving a first confirmation of sale of the at least one purchased item from the merchant and transmitting the first confirmation to the customer; transmitting a prepayment to the merchant; receiving a notification of delivery of the at least one purchased item from the transfer device and transmitting a final payment to the merchant; and posting a charge against the customer for the cost of the at least one purchased item.

19. The method of claim 18, further comprising the steps of: creating a database of customer information, including a payment limit and customer identity verification data; and comparing the cost of the at least one purchased item with the customer payment limit and the customer identification data with the customer verification data, in response to receipt of customer's selection.

20. The method of claim 19, further comprising the step of approving the purchase, if the cost of the at least one purchased item is less than the customer payment limit and if the customer identification data matches the customer verification data.

21. A method for on-line transactions, comprising the steps of: receiving a selection of at least one item for purchase from a customer and an authorization to partially prepay a merchant for the cost of the at least one purchased item; transmitting the customer's selection to a merchant and generating a transaction code and transmitting the transaction code to a transfer device; receiving a first confirmation of sale of the at least one purchased item from the merchant and transmitting the first confirmation to the customer; transmitting a prepayment to the merchant and posting a charge against the customer for the cost of the at least one purchased item; receiving a notification of delivery of the at least one purchased item from the transfer device; and transmitting a final payment to the merchant.

22. The method of claim 21, further comprising the steps of: creating a database of customer information, including a payment limit and customer identity verification data; and comparing the cost of the at least one purchased item with the customer payment limit and the customer identification data with the customer verification data, in response to receipt of customer's selection.

23. The method of claim 22, further comprising the step of approving the purchase, if the cost of the at least one purchased item is less than the customer payment limit and if the customer identification data matches the customer verification data.