WO2001050305A2

WO2001050305A2 - Method and system for supervising on-line purchasing

Info

Publication number: WO2001050305A2
Application number: PCT/US2000/033941
Authority: WO
Inventors: Andrew Stearns Brenneman
Original assignee: Brenneman Andrew Steams
Priority date: 2000-01-06
Filing date: 2000-12-14
Publication date: 2001-07-12
Also published as: WO2001050305A8; WO2001050305A3; AU2101901A

Abstract

A computer system provides an authorizer with the ability to set up and monitor individual accounts for one or more subordinates. Using the subordinate accounts, the subordinates can purchase items over a computer network, without direct access to a credit card, and subject to a combination of forms of purchase approval, purchasing restrictions, and payment options. The system provides feedback and suggestions to subordinates regarding purchases, and maintains a database with information about items previously selected by each subordinate. The database is used to create a personal catalog for each subordinate, with information about items previously selected and ultimately purchased or not by the subordinate and others within the group of subordinates.

Description

METHOD AND SYSTEM FOR SUPERVISING ON-LINE PURCHASING

Field of the Invention

This invention relates to methods and systems for conducting on-line purchases.

Background of the Invention

Electronic commerce has been growing at a rapid pace, and provides opportunities for companies to sell products to customers who are not physically present at a company's store. For many individuals, electronic commerce provides convenience and an ability to obtain better prices. However, the electronic commerce opportunities are considerably more limited for individuals who do not have credit cards or who need to obtain the approval of someone with purchasing authority before completing a purchase. These limitations are particularly evident in the case of minors, who typically do not have credit cards or any other mechanism for purchasing items electronically. These limitations also are evident in various group or team buying situations, in both corporate and family settings.

Recently, a number of systems have been announced to attempt to meet the needs of minors. These systems include those described at www.allowancenet.com, www.cybermoola.com, www.doughboy.com, www.echarge.com, www.icanbuy.com, www.pocketcard.com, and www.rocketcard.com. These systems employ various models, but appear to provide limited flexibility and options. For example, these systems are limited in the variety and combination of purchasing approvals, purchasing restrictions, and payment options that are available to the parents or others with purchasing authority over children or others. These systems also are limited in how they use information about prior purchases and prior attempts to make purchases.

Another limitation with existing electronic commerce systems is the lack of consumer-oriented purchase management systems that allow purchase selections to be managed and reviewed prior to the final purchase transaction. Summary of the Invention

According to the present invention, a supervisor, parent, or other individual, group of individuals, or entity with spending approval authority over others (an "authorizer") establishes a master account and one or more subordinate accounts with an approval system. Each subordinate account typically corresponds to a family member or a member of a buying team (such as the members of a purchasing department) but could correspond to any individual or entity for which the authorizer has spending approval authority. An individual or entity for which an authorizer has such approval authority is identified generally herein as a subordinate. The combination of the master account and associated subordinate accounts is identified herein as a family of accounts.

Through the master account, the authorizer can individually determine how each subordinate will be permitted to make electronic purchases and what limitations will be imposed on the purchases a subordinate may make. For example, a subordinate account may be set up so that the authorizer must approve each purchase before it can be completed. Or, purchases can be pre-approved, provided they meet certain criteria, such as criteria based on the type of item, the cost of the item, or the vendor. Criteria may be inclusive (only those items meeting the criteria may be purchased) or exclusive (items meeting the criteria may not be purchased). Where purchases are pre-approved, a credit card, a bank account, or any other spending mechanism may be used. Like the approval criteria, the spending mechanism may be specified for each subordinate or for a type of transaction. The master account also permits the coordination of group purchases.

Spending criteria and the approval mechanism can be separate. For example, even purchases meeting the criteria can require express approval by the authorizer.

The authorizer also can configure the extent to which each subordinate receives notifications of items that are approved or rejected, and the extent to which each subordinate has access to personal catalog functions.

Once the criteria and approval process are established, a subordinate may purchase any item matching the criteria (and subject to the approval process) that is available over a network or collection of networks, such as the World Wide Web. As long as the vendor recognizes the approval system, the transaction may be conducted. The approval system, in addition to being used to determine whether a purchase takes place, can provide feedback to the subordinate. For example, the approval system can explain the criteria to a subordinate who attempts to make purchases that do not meet the criteria, or can assist the subordinate in revising an order so as to meet the criteria.

Optionally, the approval system maintains a database with information about the prior items examined and selected by each subordinate within a family of accounts, and (where appropriate) whether each item has been approved or not. This permits the creation of a personal catalog, based on items previously viewed or approved by a particular subordinate and/or by others within a family of accounts.

Brief Description of the Drawings

Figure 1 is a block diagram of a computer network for use with an embodiment of the present invention.

Figure 2 is a representation of a structure for a family of accounts according to an embodiment of the present invention.

Figure 3 is a flow diagram of steps performed according to an embodiment of the present invention.

Figure 4 is a flow diagram of steps performed according to an embodiment of the present invention. Figure 5 is a representation of a structure for implementing a system according to an embodiment of the present invention.

Figure 6 is a flow diagram of steps performed according to an embodiment of the present invention.

Figure 7 is a representation of a structure for implementing a system according to an embodiment of the present invention.

Figure 8 is a representation of a structure for implementing a system according to an embodiment of the present invention.

Figure 9 is a flow diagram of steps performed according to an embodiment of the present invention. Figures 10a and 10b are representations of structures for implementing a system according to an embodiment of the present invention. Detailed Description of Preferred Embodiments

Referring to Figure 1, networked system 10 includes user sites 20, approval system 30, and vendor presentations 40, all connected to network 50. In a preferred embodiment, network 50 is the World Wide Web; however, any other network, including a private or dedicated network could be used. User sites 20 include a personal computer configured to interact over network 50. For example, a user site 20 may include a multimedia-capable, Pentium IBM-PC compatible personal computer 22 running Microsoft Windows 95, 98, or NT, with a modem for connecting to the Internet. Personal computer 22 also runs an Internet browser, such as Microsoft Internet Explorer or the Netscape Navigator.

Approval system 30 includes server 32 and database server 34 running an Oracle or other database system 36. Depending on the size of approval system 30, server 32 and database server 34 could be a single physical server or multiple servers, as appropriate to meet the expected system needs.

Vendor presentations 40 may consist of an online store in which products or services are presented for purchase. Such online stores may include a web server 42, an HTTP server 44, and databases 46. A vendor presentation also could consist of a product offer within the context of an online advertisement. Such an online advertisement typically consists of a specific offer for a specific product or service within the context of an advertisement placed in a high-traffic web site. The advertisement may consist of HTML-based content running on an HTTP server. With an advertisement, a purchase may be initiated by interacting with the advertisement.

As shown in Figures 2 and 3, in order to set up a family of accounts, an authorizer at a user site 20 accesses approval system 30 over network 50 (step 210). At step 215, the authorizer provides identifying information 112, such as name, address, and electronic mail address, for a master account 100, and lists each subordinate for which a subordinate account 102 is to be created. Approval system 30 assigns to master account 100 an account ID 104 and password 106, at step 220, to permit items to be approved and parameters to be set or changed, as described below. Similarly, at step 225, authorizer provides identifying information 114 for each subordinate account 102, and approval system 30 assigns an account ID 108 and a password 110 for each subordinate account 102. Optionally, the authorizer and each subordinate may be permitted to change the assigned password. Approval system 30 stores this account information in database system 36. If desired, the master account can have multiple account ID's (and corresponding passwords), so that multiple individuals can serve as authorizers. An authorizer subsequently can add or remove subordinates.

Optionally, at step 230, after establishing each account, the authorizer establishes a default set of parameters 120, which apply to each subordinate account unless overridden for that account. Parameters 120 are stored in database system 36. In a preferred embodiment, parameters 120 include payment information 122, pre-approval status 124, and purchase criteria 126. Approval system 30 can have one or more standard sets of criteria, which can be selected as is or modified, to simplify the establishment of the accounts.

Preferably, payment information 122 includes one or more of the following: credit card information 130 for one or more credit cards, credit card proxies 132 for one or more virtual accounts, and account information 134 for one or more bank accounts (which can be either traditional or on-line banks). Any other payment mechanism, whether prepaid or credit-based, can also be provided. Where all transactions will require the approval of the authorizer, payment information 122 can be omitted, and provided for individual transactions.

Pre-approval status 124 identifies whether the authorizer must approve an individual transaction or whether an individual transaction is pre-approved, subject to meeting the purchase criteria 126. Optionally, multiple levels of approval can be established, so that certain types of purchases (those meeting specified criteria) are pre- approved, others (meeting other specified criteria or not meeting the criteria for pre- approval) require individual approval, and others are automatically rejected. Alternatively, all purchases meeting the specified criteria can be subject to individual approval.

Purchase criteria 126 can be used to determine whether an item is in a pre- approved category, whether it falls within a category of items that must be individually approved, or whether it falls within a category of items that automatically are rejected. Generally, items that automatically are rejected with be items that do not meet the purchase criteria either for pre-approval or to permit individual approval. If the purchase criteria determine only whether an item is pre-approved, items not meeting the purchase criteria may be items that require individual approval or may be items that automatically are rejected. If no items are pre-approved, items meeting the purchase criteria will require individual approval and items not meeting the purchase criteria automatically will be rejected.

The criteria 126 can be inclusive criteria 140 or exclusive criteria 142. Inclusive criteria describe characteristics of items that may be purchased, and exclusive criteria describe characteristics of items that may not be purchased. Inclusive criteria 140 and exclusive criteria 142 can be combined for each category. Criteria 126 are combined in a Boolean fashion to determine the category in which an item falls.

The criteria 126 include absolute criteria, such as the price of an item, the type of item (such as video game, book, clothing, or the rating of a video), the vendor, the day or time, and specified words in the title or description of the item. These criteria can be combined, so that the price cutoff for an item depends on the type of item or the vendor. Criteria 126 also include relative criteria. Relative criteria can include, for example, the total amount selected by the subordinate from the vendor in this transaction, the total amount selected from the vendor within a given time period (such as the past 30 days), the total amount selected from all vendors within a given time period, and the total amount for items of a certain type or group of types (such as the combined amount spent on video games and music in the current month).

Criteria need not be subordinate-specific. They can be cumulative for some or all of the subordinates. For example, in a business purchasing context, the criteria may be cumulative to ensure that two team members do not purchase the same item. The criteria also can include specific items purchased by other subordinates within the applicable time period. For example, the criteria can limit all subordinates to a maximum of ten of the same items (whatever they may be) from an office supplies category.

After establishing the default parameters (if desired), the authorizer establishes, at step 235, the parameters for each subordinate account. If default parameters have been established, then this step may be omitted for any subordinate whose parameters are the same as the default parameters. Similarly, if default parameters have been established, then only those parameters that differ from the defaults need to be established.

The criteria can be established in many different ways. For example, the criteria can be established in the following manner for a subordinate account. First, as shown at step 805 in Figure 9, the authorizer selects the subordinate account of interest. Next, at step 810, the authorizer enters a total budget amount and the time period covered by the budget amount (such as a month). The authorizer then indicates (step 815) whether purchases meeting certain criteria will be pre-approved. If so, the authorizer selects from previously entered financial accounts or enters a new account for making payments on this subordinate's account (step 820). Next, the authorizer identifies (step 825) a first budget segment. For example, a budget segment might be "school supplies." The authorizer then enters a percentage or amount of the budget for this category (step 830). If the budget does not include categories or if certain criteria apply to all segments, the budget segment identifier is "all" and the percentage is 100 percent. The segment budget amount represents the amount of the total budget that is available for the segment.

Although it cannot be greater than the total budget, the combined totals for the budget segments can exceed the total budget amount. For example, a subordinate may be permitted to spend up to 60% of the budget on school suppliers and up to 50% of the budget on clothes, but cannot exceed the total budget in doing so. After selecting a percentage or amount of the budget for the segment, the authorizer (step 835) enters an approval category (pre-approved, requires individual approval, automatically rejected). The authorizer also enters the criteria (step 840) that apply for that category. These could include, for example, approved (or disapproved) vendors for the segment, maximum cost of any one item, the days or times during which an item can be purchased, and description information about the items. The authorizer then has the option (step 845) to select another approval category for that budget segment. If so, the authorizer enters the new approval category (from step 835) and continues as before. When the authorizer has specified all of the approval categories for that budget segment, the authorizer has the option to enter a new budget segment (step 850), in which case the authorizer repeats the steps beginning with step 825. After the authorizer has specified all budget segments, approval system 30 saves the budget segments (step 855) to database system 36. The authorizer then has the option (step 860) to enter criteria for another subordinate or to end this process. The authorizer later can edit any portions of the criteria.

As shown in Figure 4, a subordinate desiring to purchase an item uses the World Wide Web to find one or more items of interest (step 305) from a vendor presentation 40. The vendor presentation may be, for example, a vendor's online store, a vendor advertisement, or any other web site that provides access to the vendor's items. At step 310, the vendor (which could be, for example, the online store, or another web site or an agent able to provide the item) sends a request to approval system 30 for payment. To accomplish this, the subordinate provides an identification of the subordinate's account with the approval system to the vendor. The necessary information regarding the order is sent from vendor site 40 to approval system 30, preferably using an Extensible Markup Language (XML) gateway. The XML data is sent using Hypertext Transfer Protocol (HTTP), using for example the Secure Socket Layer (SSL) for security. Alternatively, an electronic mail message or other communications channels could be used to send the order information from vendor presentation 40 to approval system 30.

Upon receiving the request for payment, approval system 30 accesses database system 36 to compare (step 315) the items to the criteria established for that subordinate and determine the category for each item. Optionally, approval system 30 forwards this information to the subordinate by electronic mail or posts this information (at a site accessible only using the subordinate's password) so that the subordinate can learn the status of each item (step 320). In addition, approval system can explain the purchase criteria to the subordinate or assist the subordinate in revising an order so as to meet the criteria, as explained below.

Items meeting the purchase criteria then are further processed in accordance with whether the purchase is pre-approved. For each item (if any) that is pre-approved, approval system 30 determines the appropriate payment information 122 (step 330), previously entered by the authorizer, then sends the order along with the appropriate payment information 122 to the vendor (step 335). In addition, each of these items is added to database system 36 (step 340). Approval system 30 adds each item (if any) for which individual approval is required to a daily list 150 (Figure 5) for that subordinate (step 350). Preferably, daily list 150 includes entries 152 with the name of the item, its price, the vendor, any available description of the item, and a link 154 to the web page for that item. Alternatively, a single daily list 150 can be used for all subordinates, in which case daily list 150 also includes the name of the subordinate in each entry 152. At the beginning of each day (or other time period), list 150 is empty (step 510 in

Figure 6). During the day, approval system 30 may add items to list 150 as a result of the subordinate seeking to purchase items (step 515). Also, the subordinate may access the list and delete items (step 520). At the end of the day (or other time period), approval system 30 sends all items on list 150 to an electronic mail address for the master account (step 525). The authorizer then determines which items to approve, designates a payment mechanism (which can be a default mechanism), and returns that information to approval system 30 (step 530), using a web-based form, return electronic mail, or any other desired mechanism. The authorizer approves or rejects an item by clicking on the appropriate selection within approval field 156. Optionally, the authorizer provides reasons when rejecting an item. For each item that is approved, approval system 30 sends the order along with the appropriate payment information 122 to the corresponding vendor (step 535). Each item, whether accepted or rejected, is added to database system 36 (step 540). As with the initial list of categories into which each item falls, approval system 30 in a preferred embodiment informs the subordinate of the items that have been approved and rejected (step 545). Alternatively, where appropriate, the subordinate is not informed. Finally (step 550), approval system 30 empties list 150.

The authorizer need not approve or reject all items at one time. For example, the authorizer could approve two items from the list and reject a third item, exit from the approval system's web site, then return later to approve or reject the remaining items. Once items have been approved or rejected in one session, that status is shown in subsequent sessions.

As with items that are pre-approved or that required individual approval, items that were automatically rejected are added to database system 36 (step 360 in Figure 4) as items that were requested but rejected. As shown in Figure 7. items are maintained in database system 36 according to the subordinate, the item name or other identifier (including, where possible, a URL for the web page showing the item), the date the subordinate requested the item, the item's price, the vendor of the item (including a URL for the vendor), the type of item, whether the item was approved or rejected, and the basis for rejecting the item (if applicable). For example, an item might have been rejected because of its cost, because of the other items requested, or because the authorizer rejected it. This information permits the system to keep track of each subordinate's purchase history, which may be used by the authorizer to review the purchase history, and also for determining the approval of subsequent items (as described above) or for establishing a personal catalog. Optionally, database system 36 includes for each item a field indicating the approval category (e.g., pre-approved, requires individual approval, automatically rejected) into which the item fell and a list of the criteria applied in making the categorization. Where the authorizer provides reasons for rejecting an item, those reasons also may be included in database system 36.

Each subordinate has a personal catalog 160, as shown in Figure 8, which shows each item from database system 36 that the subordinate previously selected. Optionally, only items requested within a set time period (such as the past three months) are shown, unless the subordinate requests a different time period. In addition, personal catalog 160 may be purged periodically of old entries.

Each entry 162 in personal catalog 160 includes the name of the item 170, the date the subordinate requested the item 172, the price of the item 174, the vendor for the item 176, the type of item 178, whether the item was approved or rejected 180, and the basis (if applicable) for rejection of the item 182. Alternatively, the basis for rejection 182 or other information can be omitted from personal catalog 160 either automatically or if specified by the authorizer.

The subordinate is able to view the personal catalog by pointing a web browser to the web site of approval system 30 and entering the subordinate's account ID and password. While viewing the personal catalog, the subordinate can click on a vendor 176, which provides a link to the vendor's web site. Similarly, the subordinate can click on an item 174, which provides a link to the location at the vendor's web site where the item is displayed. This provides a simple mechanism for repeat ordering. By clicking on the basis for rejection 182, the subordinate is able to determine whether the subordinate might now be able to purchase the item because conditions have changed. Preferably, personal catalog 160 also provides a link 188 to the purchase criteria 126 applicable to that subordinate. This permits the subordinate to understand the authorization criteria. However, where appropriate, access to this information can be omitted or limited. In a preferred embodiment, personal catalog 160 also includes a link 190 to information from the personal catalogs of other subordinates within the family of accounts. As appropriate, the authorizer can limit the fields from each entry for a subordinate that are visible to other subordinates. Also, each subordinate may be provided the ability to designate certain fields as private (by, for example, clicking on the identifier for the field), subject to override by the authorizer. A private field is not visible to other subordinates. Where information from other personal catalogs is available to a subordinate, the subordinate can click on entries to view the vendor, item, or other information, as with the subordinate's own personal catalog.

Personal catalog also includes table 192 showing the applicable total budget and budget segments, the total amount spent and remaining that period, and the amount spent and remaining for each budget segment.

The information that approval system 30 sends a subordinate as to the categories into which items have been placed (step 320 in Figure 4) is illustrated in Figure 10a. Preferably, information 910 includes entries with the names of the items 912, the date the subordinate requested the items 914, the prices of the items 916, the vendors 918, and the types of the items 920. In addition, if an item or combination of items fails to meet any criteria for pre-approval, approval system 30 provides a description 922 of those criteria. For example, if the subordinate attempted to purchase an item for $200 but the maximum amount for any one item is $100, description 922 would show the maximum amount, but not other criteria (such as permissible vendors) that were not violated. Or, if the subordinate attempted to purchase two items, each costing $75, from a category in which the total budget was $100, description 922 would show the budget category and amount. Approval system 30 also provides a link 924 to the applicable purchase criteria 126. Alternatively, all criteria are displayed, with those criteria that were violated shown in a different manner. If the subordinate clicks on adjust order button 926, approval system 30 provides a table 930 (shown in Figure 10b) that permits the subordinate to try variations on the order, to see how that would affect the results. The top half of table 930 includes financial status 932, which shows the applicable total budget and budget segments, the total amount spent and remaining that period, and the amount spent and remaining for each budget segment. The bottom half of table 930 includes the information from Figure 10a (the names of the items, the date the items were requested, the prices, the vendors, the types of the items, a list of the criteria that were not met, and a link to the applicable purchase criteria). Unlike the information from Figure 10a, the subordinate can change these entries to try different options. For example, the subordinate can delete an item and see how that would affect the results. Table 930 includes a "restore" button 934 that permits the subordinate to return to the original selections and try again.

While there have been shown and described examples of the present invention, it will be readily apparent to those skilled in the art that various changes and modifications may be made therein without departing from the scope of the invention as defined by the appended claims. For example, information from the personal accounts of other subordinates in a family of accounts could be shown along with the information from a subordinate's own personal account, with appropriate designations to indicate whose account it is. Also, the invention can be applied in different contexts. For example, the system can be used as a form of gift registry. After the authorizer establishes criteria, a subordinate can choose the specific items that the subordinate desires to receive as gifts. All items would be subject to individual approval. The authorizer (or authorizers), by "approving" an item, would be purchasing one of the items for the subordinate. In this context, the subordinate generally would not receive a notification when the authorizer approves or rejects an item. Different authorizers could approve different items off the registry, to buy different items for the subordinate.

Accordingly, the invention is limited only by the following claims and equivalents thereto. What is claimed is:

Claims

1. A method for conducting transactions over a network comprising the steps of: receiving from one or more vendors a set of items requested by a first user for purchase over a network; evaluating each item in the set of requested items against one or more purchase criteria; for each item in the set of requested items that meets the purchase criteria: if the purchase of the item also is pre-approved, sending to the vendor of the item information permitting the purchase of the item; if the purchase of the item is not pre-approved: sending to a second user a request for approval of the item; receiving from the second user a response to the request for approval of the item; and if the response includes an approval of the item, sending to the vendor of the item information permitting the purchase of the item, and if the response includes a rejection of the item, providing to the first user a notice that the item was not approved; and for each item in the set of requested items that does not meet the purchase criteria, providing to the first user a notice that the item does not meet the purchase criteria.

2. The method of claim 1, further comprising the step of establishing the purchase criteria with a plurality of sets of purchase criteria, each of the sets of purchase criteria being applicable to a different category of items.

3. A method for conducting transactions over a network comprising the steps ^of: receiving from one or more vendors a set of items requested by a first user for purchase over a network; evaluating each item in the set of requested items against one or more purchase criteria: and for each item in the set of requested items that does not meet the purchase criteria: providing to the first user a notice that the item does not meet the purchase criteria and information relating to why the item did not meet the purchase criteria.

4. The method of claim 3, further comprising the steps of: when at least one item in the set of items does not meet the purchase criteria, providing to the first user a representation of the set of items, receiving from the first user a proposed adjustment to the set of items, and providing to the first user notice of which items in the adjusted set of items would meet the purchase criteria and which items in the adjusted set of items would not meet the purchase criteria.

5. The method of claim 3, further comprising the step of: for at least one item in the set of requested items that meets the purchase criteria: sending to a second user a request for approval of the item; and receiving from the second user a response to the request for approval of the item.

6. The method of claim 3, further comprising the step of: for at least one item in the set of requested items that meets the purchase criteria, sending to the vendor of the item information permitting the purchase of the item.

7. A method for conducting transactions over a network comprising the steps of: establishing one or more purchase criteria for a first user; selecting a pre-approval status for items meeting the purchase criteria; receiving from one or more vendors a set of items requested by the first user for purchase over a network; evaluating each item in the set of requested items against the purchase criteria; and for each item in the set of requested items that meets the purchase criteria, determining the pre-approval status of the item.

8. The method of claim 7, further comprising the step of: for each item in the set of requested items that is determined to be pre-approved, sending to the vendor of the item information permitting the purchase of the item.

9. The method of claim 7, further comprising the step of: for at least one item in the set of requested items that meets the purchase criteria and is determined not to be pre-approved: requesting approval of the item.

10. The method of claim 9, wherein the step of requesting approval of the item includes sending to a second user a request for approval of the item.

11. The method of claim 9, further comprising the step of: for each item in the set of requested items that is determined to be pre-approved, sending to the vendor of the item information permitting the purchase of the item.

12. The method of claim 7, further comprising the step of selecting a rejection notification status for items that are not approved.

13. The method of claim 12, further comprising the step of: for each item that is not approved, if the selected rejection notification status includes providing notification, sending a notification to the first user for items that are not approved.

14. The method of claim 13, wherein the step of sending a notification to the first user for items that are not approved includes providing to the first user a notice that the item does not meet the purchase criteria and information relating to why the item did not meet the purchase criteria.

15. The method of claim 14, further comprising the steps of: when at least one item in the set of items does not meet the purchase criteria, providing to the first user a representation of the set of items, receiving from the first user a proposed adjustment to the set of items, and providing to the first user notice of which items in the adjusted set of items would meet the purchase criteria and which items in the adjusted set of items would not meet the purchase criteria.

16. The method of claim 7, wherein the step of establishing purchase criteria includes establishing the purchase criteria with a plurality of sets of purchase criteria, each of the sets of purchase criteria being applicable to a different category of items.

17. The method of claim 7, wherein the purchase criteria for the first user include criteria based on purchases made by other users.

18. A system for permitting transactions over a network comprising: a server programmed to receive purchase criteria for a user and pre-approval status criteria for items meeting the purchase criteria, programmed to receive over the network from a vendor a set of items requested by a user, programmed to evaluate each item in a set of items received from a vendor against the purchase criteria for the user, and programmed to determine, for each item in a set of requested items that meets the purchase criteria, a pre-approval status of the item from the pre-approval status criteria; and a database system coupled to the server, the database system programmed to maintain the received purchase criteria and pre-approval status, and to maintain for each item received from a vendor whether the item meets the applicable purchase criteria and whether the item has been approved.