WO2001055927A1 - Method closing sales over an open network using an automated haggling system - Google Patents

Abstract

A method of conducting an automated commercial transaction. An item including transaction parameters to be used by a purchaser in deciding to commit to a commercial transaction is presented (201) to a potential purchaser (107). The potential purchaser, after receiving the presented transaction parameters (205), accepts or rejects the commercial transaction. At transaction time a marketplace variable affecting the commercial transaction is obtained (202). In response to the rejection, at least one transaction parameter is modified based on the identified marketplace variable to generate an alternative offer (203). The alternative offer is presented to the potential purchaser at transaction time.

Description

METHOD CLOSING SALES OVER AN OPEN NETWORK USING AN AUTOMATED HAGGLING SYSTEM

BACKGROUND OF THE INVENTION

Related Applications. The present invention claims priority to copending U.S. Provisional

Patent application serial No. 60/178,826 entitled "METHOD AND SYSTEM FOR REMOTELY PROVIDING NETWORK SECURITY AND AVAILABILITY SERVICES" filed January 28, 2000, the specification of which is incorporated herein by reference. The present application is also related to the following U.S. patent applications, all of which are filed concurrently herewith and are incorporated by reference herein: Serial No. 09/651 ,466 entitled SYSTEM AND METHOD FOR PROVIDING DYNAMIC APPLICATION SERVICES; Serial No. 09/650,983 entitled SYSTEM AND METHOD FOR EFFICIENT DISTRIBUTION OF APPLICATION SERVICES; Serial No. 09/651 ,465 entitled SYSTEM AND

METHOD FOR PROVIDING APPLICATION SERVICES WITH CONTROLLED ACCESS INTO PRIVILEGED PROCESSES; Serial No. 09/651 ,467 entitled SYSTEM AND METHOD FOR SECURELY PROVIDING APPLICATION SERVICES; Serial No. 09/649,352 entitled SYSTEM AND METHOD FOR PERSISTENT, EFFICIENT DISTRIBUTION OF APPLICATION SERVICES; and Serial No. 09/650,558 entitled METHOD FOR CLOSING SALES OVER AN OPEN NETWORK USING AN AUTOMATED HAGGLING SYSTEM.

Field of the Invention.

The present invention relates, in general, to electronic commercial transactions, and, more particularly, to software, systems and methods for enabling commercial transactions. Also, the present invention is related to commercial transactions conducted in a manner that permits a seller to haggle with a purchaser based upon criteria known to the seller and relevant to the value of the commercial transaction.

Relevant Background.

Computer systems including business systems, entertainment systems, 5 and personal communication systems are increasingly implemented as distributed software systems. These systems include application code and data that are distributed among a variety of data structures, data processor systems, storage devices and physical locations. Increasingly, computer systems and especially distributed computing environments are used to provide 0 a platform for consumer and business commercial transactions.

Commercial transactions are fundamental events in the interaction of people and the success of a society. Face to face commercial transactions have occurred throughout history and have offered an efficient, mutually satisfying method to exchange goods and services. Each transaction involves 5 an item or product comprising good(s) and/or service(s). The item is a specific set of features of that has an immediate value to the seller, and a potential value to the purchaser. Face-to-face transactions enable the seller and purchaser to interact at transaction time to adjust the set of features (e.g., alter the price, include greater quantity, improve quality and the like) that are the o subject of the transaction. When the perceived value to the seller and purchaser become approximately equal, the both parties can commit to the transaction and an exchange occurs.

Increasingly, commercial transactions are performed in an automated or semi-automated fashion. Examples include electronic commerce transactions 5 performed over the Internet and/or using electronic data interchange (EDI) tools. In particular, situations arise in which the buyer and/or seller lack the information necessary at transaction time to modify their transaction parameters in a manner that efficiently leads to an exchange. To a lesser extent mail order, phone order, and even some face-to-face transactions o exemplify this difficulty. The transaction-time information implicitly used by knowledgeable human participants includes such information as current supply, marginal cost, likelihood of finding another buyer, current need, cost of substitutes, and the like. Moreover, other quantifiable factors are considered such as how close in 5 time the transaction is to an accounting period closing, end of tax year, or other organizationally imposed time period. A salesman may consider, for example, sales quotas and how much of the quota has been achieved as well as proximity to the time at which the sales quotas will be measured. A salesman may be more flexible on price if only a few more units need to be sold to meet a o goal that is only a day or two away. Automated transaction systems fail to account for these variable values at transaction time leading to inefficiency and missed opportunity.

With respect to fact-to-face transactions, many people are intimidated by haggled transactions. This is in part because human participants inherently 5 allow characteristics that are not transaction related to influence and affect the transaction outcome. For example, a strong "salesman" personality may offend some buyers, resulting in no transaction, while encouraging other purchasers to purchase more than desired. Often one party is a more experienced negotiator which can lead to mistrust and difficulty in reaching an efficient transaction o solution. For this reason "one price" type pricing and product packaging is common so that haggling is discouraged. One price type pricing offers both consumers and merchants a high degree of predictability, and is well understood by both merchants and consumers.

However, the one price transaction model often delays purchases until a 5 manufacturer lowers a price over time, for example, to a point where both the purchasers and sellers expectancies are met. This is a slow, inefficient process that leaves the items of exchange in the wrong hands for longer than necessary. Morever, many products have limited "shelf life". This is not just the case with perishable goods (e.g., food) but also with clothing, seasonal o goods, software, and the like. Almost all goods and services experience some loss in value over time. For example, as consumer tastes and needs evolve a once popular clothing style may become difficult to sell. In these cases the product must be discounted or returned to the supplier at a loss to all parties. The difficulties in pricing products using single-price models lead to distribution delays that cause product/service values to waste before a sale is made. Retailers have long sought more efficient distribution solutions that efficiently supply goods to purchasers at prices that will maximize profits and encourage sales in a commercially reasonable time.

U.S. Patent 6,035,288 describes an electronic commerce system in which prices are negotiable. This system encourages haggling as a sole means for conducting a transaction and so cannot realize the many benefits of single price models. Moreover, this system enables only a single transaction parameter to be negotiated-phce. This fails to recognize that any given transaction involves multiple transaction parameters that affect whether a transaction can be completed. One example of online haggling software can be found at http://www.haggle.com/proxy.html. In this system a proxy robot is used to represent one of the participants. Preselected bidding rules are established by the represented participant. This system is adapted to operate is an auction environment with multiple competing bidders and a limited supply of goods and/or services. However, it does not address the needs for haggling in a merchant-to-consumer transaction as it cannot deal with multiple transaction parameters and the final transaction value would always rise to the maximum bid supplied by the represented participant.

What is needed is a transaction environment in which multi-dimensional haggling can be automated on at least one side of the transaction. Moreover, a need exists for a haggle methodology that augments rather than replaces conventional one-price transactions. Further, a need exists for a haggle environment in which a plurality transaction-relevant information can be considered while information non-transactional related variables can be filtered or removed from consideration. SUMMARY OF THE INVENTION

Briefly stated, the present invention involves a method of conducting an automated commercial transaction. An item including transaction parameters to be used by a purchaser in deciding to commit to a commercial transaction is presented to a potential purchaser. The potential purchaser, after receiving the presented transaction parameters, accepts or rejects the commercial transaction. At transaction time a marketplace variable affecting the commercial transaction is obtained. In response to the rejection, at least one transaction parameter is modified based on the identified marketplace variable to generate an alternative offer. The alternative offer is presented to the potential purchaser at transaction time.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 shows a networked computer environment in which the present invention is implemented; Fig. 2 shows an electronic commerce environment in which the present invention is implemented; and

Fig. 3 illustrates a flow diagram indicating logical relations between process steps in an exemplary implementation of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention is related to a merchant-initiated haggle system.

By this it is meant that a merchant initially decides whether a negotiation is appropriate and what transaction parameters are negotiable. Hence, the initial transaction environment may be a conventional "one-price" offer and haggling may or may not occur at the merchant's option. In some embodiments, a party opposite the merchant such as a consumer, purchaser, or automated agent representing a consumer or purchaser, is able to respond to an alternative offer by varying its own transaction parameters. In other embodiments a purchaser may prompt the merchant to haggle, but whether or not a negotiation takes place remains the power of the merchant. The present invention is illustrated and described in terms of a distributed computing environment such as an enterprise computing system using public communication channels such as the Internet. However, an important feature of the present invention is that it is readily scaled upwardly and downwardly to meet the needs of a particular application. Accordingly, unless specified to the contrary the present invention is applicable to significantly larger, more complex network environments as well as small network environments such as conventional LAN systems.

FIG. 1 shows an exemplary computing environment 100 in which the present invention may be implemented. Environment 100 includes a plurality of local networks such as Ethernet network 102, FDDI network 103 and Token ring network 104. Essentially, a number of computing devices and groups of devices are interconnected through a network 101. For example, local networks 102, 103 and 104 are each coupled to network 101 through routers 109. LANs 102, 103 and 104 may be implemented using any available topology and may implement one or more server technologies including, for example a UNIX, Novell, or Windows NT, or peer-to-peer type network. Each network will include distributed storage implemented in each device and typically includes some mass storage device coupled to or managed by a server computer. Network 101 comprises, for example, a public network such as the Internet or another network mechanism such as a fibre channel fabric or conventional WAN technologies.

Local networks 102, 103 and 104 include one or more workstations such as computers 117. One or more computers 117 may be configured as an application and/or file server. Each local network 102, 103 and 104 may include a number of shared devices (not shown) such as printers, file servers, mass storage and the like. Similarly, devices 111 may be shared through network 101 to provide application and file services, directory services, printing, storage, and the like. Routers 109 provide a physical connection between the various devices through network 101. Routers 109 may implement desired access and security protocols to manage access through network 101.

Each of the computing devices shown in FIG. 1 may include memory, mass storage, and a degree of data processing capability sufficient to manage their connection to network 101. The computer program devices in accordance with the present invention are implemented in the memory of the various devices shown in FIG. 1 and enabled by the data processing capability of the devices shown in FIG. 1. In addition to local memory and storage associated with each device, it is often desirable to provide one or more locations of shared storage (not shown) that provides mass storage capacity beyond what an individual device can efficiently use and manage. Selected components of the present invention may be stored in or implemented in shared mass storage.

In addition to shared LAN connections to network 101 , appliances 117 may also connect to network 101 using the public switched telephone network 102 by way of dial-up connections. Dial-up connections are supported by a variety of Internet service providers (ISPs) 107. Dial up connections may be support by landline connections or through wireless interfaces to PSTN 102 such as available in digital and analog cellular systems. ISP 107 supports a connection to network 107. Fig. 2 shows an electronic commerce environment implemented within the computing environment shown in Fig. 1. As shown in Fig. 2 the system in accordance with the present invention enables a transaction between a buyer accessing the environment through appliances 107 using, for example, a web browser program 201. A merchant or seller operates a web site 202 using a Web server. Web site 202 may be implemented using off-the-shelf commercially available web server software or electronic commerce software or custom variations thereof. Web site 202 may be implemented on one or more web servers. Alternatively, a single web server instance may support multiple web sites 202. Web site 202 offers products and/or services for sale by generating text, graphic, and multimedia content presenting the offered goods and/or services for display by browsers 201. Preferably, web site 202 comprises an electronic commerce storefront as opposed to an auction site or haggle-only type 5 commerce site. In other words, a merchant controlling site 202 offers goods and/or services at a predetermined stated price with the intention of selling at the stated price.

At the discretion of the merchant operating web site 202, a haggle component 203 may be activated. Haggle component 203 accesses a 0 transaction-time record 205 within a data store 204 and applies selected business rules to determine whether or not to attempt to haggle with a particular customer over a particular set of goods/services. In the preferred embodiments, a purchaser cannot directly activate haggle component 203, although it is contemplated that a purchaser may be enabled to prompt web site 5 202 to activate haggle component 203. However, the control over whether a haggle component 203 is used in a particular transaction remains within web site 202 and therefore the merchant that controls web site 202 remain in control of when and how haggling becomes involved in the transaction.

The transaction time record 205 includes a number of fields indicating o various state information that represents marketplace variables that are useful in determining whether to haggle a transaction. While the information contained in transaction-time record 205 need not be changed often, it is contemplated that it is maintained frequently enough so that it can be used by haggle component 203 to make reliable decisions at transaction-time. The 5 exemplary information fields shown in Fig. 2 are representative and it is contemplated that other types of marketplace information may be relevant to a particular merchant.

The business rules used to control haggling component 203 may be provided within transaction time record 205 or may be coded into haggle o component 203 itself. Various types of marketplace information such as current product inventory information and related product information (e.g., accessories or up-sell/down-sell products) are examples of information that may be included. Other types of marketplace information include variables that would typically affect a salesman such as sales quotas for the requested 5 product/service as well as other related products and services that are potential up-sell, down-sell and cross-sell candidates.

Considerations also include a measure of how much of the quota(s) has (have) been achieved and how long until the performance-to-quota will be measured. Factory or wholesaler incentive commissions (also called "spiff') o that are available on this product or other product alternatives are also considered. For example, a pending transaction might be "sweetened" for a purchaser by including a free or discounted good/service which is attractive to the retailer who knows that a manufacturer is currently offering an incentive discounted good/service. These types of considerations are only examples of 5 the factors that are considered by human participants in a sales transaction. Any factor that is of value to the merchant may be used to determine or contribute to the determination of whether haggle component will be used in a particular transaction.

In some applications it may be desirable to include customer history o information reflecting historical transactions that may indicate other products/services that have been purchased by the customer and whether particular haggling rules were effective in those prior transactions. Optionally, a calendar of sales events and/or accounting time periods for both the current product and the related products may be included to indicate recent or future 5 sales events such as month end or quarter end discounts that may be applicable to a particular transaction. A counter entry is optionally maintained in the transaction time record or within haggle component 203 to reflect the number of negotiating rounds that have occurred in a current transaction and is used by the business rules to determine progress or termination of current o efforts to negotiate a sale. Transaction-time record 205 is illustrated as a single data structure for ease of illustration and understanding, however, it is contemplated that record 205 may be implemented as a virtual data structure by logical and/or relational combination of data from a variety of sources. For example, current inventory of an item may be pulled from an inventory database whereas sales promotion information may come from a merchant's catalog or marketing database. Competitive pricing information, for example, may be drawn from a competitor's web site or a third-party product review site such as http://www.cnet.com or http://www.pricewatch.com. A transaction-time record 205 may exist per se only at transaction time when haggle component 203 accesses various data stores to obtain the marketplace parameters called for by a particular set of business rules.

One or more appliances 117 may connect to a "buyer agent" module 211 that implements certain functionality on behalf of purchasers. To implement a buyer's agent 211 data packets that are directed to the buyer must be redirected to the agent 211. This can be implemented using conventional proxy technology. The buyer agent 211 implements rules specified by the buyer that is represented. These rules may be static, dynamic, or adaptive to a particular transaction. The rules specified knowledge of negotiation or transaction factors that are significant to be represented principal. In practice these factors can be stored in, for example, a hash table form with a plurality of key:value pairs. Preferably each factor is associated with a user-specified weight. The weight is used to indicate how important this factor is to the represented principal. Unlike prior electronic commerce solutions, the buyers agent 211 in accordance with the present invention use the specified transaction factors to haggle with the opposing party of the transaction. In this manner, a transaction may be consummated by two agents haggling with each other using the factors and weights specified by the business rules.

Fig. 3 shows an exemplary flow diagram of a negotiated transaction using haggle component 203 in accordance with the present invention. For purposes of illustration, the example of Fig. 3 involves a transaction for software application services such as provided by virus scanning software. Such a service is provided in step 301 by scanning a computer's disk and/or memory resources for virus code against a predefined library of known viral agents. The service can be provided at various service levels to meet the needs of a 5 particular customer. For example, the service frequency may be varied, the extensiveness of the scan may be altered (i.e., include/exclude network drives) or a customer may order various numbers of scans of different types.

Web site 202 presents a web page having controls that enable a user to select various levels of service at various specified prices. The prices may 0 include quantity discounts and/or reflect other promotional pricing that currently applies. In step 302 a user selects a level of service and the predetermined price for the selected service is presented in step 303. The user is given control options to accept, decline, or change the level of service in response to the proposal from web site 202. When indicated by the user by selection of a 5 "change" control, the process returns to step 302 by presentation of one or more web pages that enable the user to select the desired level of service and obtain pricing information for the changed level of service.

The present invention allows a conventional transaction to continue upon acceptance of a price for the level of service. Once accepted, transaction o specific processes 305-308 are performed to complete the transaction. In the particular example of providing application services, a registration form is presented to obtain customer-specific information so as to document and memorialize the transaction. Payment is collected in step 306 using any available payment mechanism including online credit card information, deposit 5 account charges, and/or phone authorization. In the case of a software transaction, a software license agreement (SLA) is presented for review in step 307. Upon acceptance of the SLA in step 308 services are provided in 301. Alternatively, if the SLA is declined the process is ended at step 309. It is contemplated that rather than ending the transaction after an SLA declination, a o modified version of haggle component 203 may be activated to negotiate changes to the SLA in a manner akin to negotiation of other transaction parameters.

Returning to process 304, in response to declination of a particular offer (e.g., level of service and price, the present invention determines whether to 5 activate haggle component 203 in process 310. Any number of criteria may be considered in process 310 as specified by the business rules selected by a merchant. By way of example, a haggle may be appropriate for frequent purchases, when a sales event calendar indicates a significant calendar event such as accounting time period (e.g., month-end closing, quarterly closing or 0 the like) that increases the merchants desire to sell product, competitor price information, and the like. For transactions which are not haggled, which may represent a large percentage of total transactions, the process is ended at step 309. The potential customer may or may not be informed that a haggle was considered. 5 One a transaction is deemed "haggleable" in step 310, an alternative offer is generated and presented in step 311. An important feature of the present invention is that the alternative offer preferably takes into consideration any number of transaction parameters and marketplace variables as specified in the business rules. This is in contrast to some haggling solutions that o consider price as the only dynamic transaction parameters. Examples of transaction parameters include price, quantity, frequency of service, bundling with accessory products, as well as alternative goods and services selected to up-sell or down-sell a particular customer. An alternative offer is presented in step 311. 5 Process 304 is then re-entered to enable the customer to accept, change or decline the alternative offer. By changing the alternative offer the customer becomes an active participant in the negotiation process. For example, the alternative offer may provide one-hundred virus scans at a quantity discount over the originally contemplated purchase of ten scans. At o step 304, a customer may propose more or fewer scans to at the proposed price and submit that. At any time, an acceptance of a negotiated offer leads to transaction-specific processing steps 305-308. A decline leads to further consideration of haggling at step 310. Based on the business rules then in force, which may include a limitation on the number of times haggle process 310 may be reentered, the present invention may elected to decline further haggling. Alternatively, new alternative offers may be presented for consideration any number of times by reentehng process 311.

Although the invention has been described and illustrated with a certain degree of particularity, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the combination and arrangement of parts can be resorted to by those skilled in the art without departing from the spirit and scope of the invention, as hereinafter claimed.

Claims

WE CLAIM:

1. A method of conducting an automated commercial transaction comprising the steps of: presenting an item including transaction parameters to be used by a 5 purchaser in deciding to commit to a commercial transaction; identifying a potential purchaser who, after receiving the presented transaction parameters, rejects the commercial transaction; identifying at transaction time a marketplace variable affecting the commercial transaction; 0 in response to the rejection, modifying at least one transaction parameter based on the identified marketplace variable to generate an alternative offer; and presenting the alternative offer to the potential purchaser at transaction time in response to the rejection with an offer for the commercial transaction 5 including the modified transaction parameters.

2. The method of claim 1 wherein the item is a product.

3. The method of claim 1 wherein the item is a service.

4. The method of claim 1 wherein the marketplace variable comprises a value indicating the calendar time relative to an accounting time o period for a seller of the item.

5. The method of claim 1 wherein the marketplace variable comprises a value indicating real-time supply of the item.

6. The method of claim 1 wherein the marketplace variable comprises a value indicating transaction history between a seller of the item 5 and the purchaser.

7. The method of claim 1 further comprising inviting the purchaser to modify one or more of the transaction parameters.

8. The method of claim 7 wherein the transaction parameters comprise price.

9. The method of claim 7 wherein the transaction parameters comprise quantity.

10. The method of claim 7 wherein the transaction parameters comprise a grouping of products that are included in the item.

11. The method of claim 1 wherein the transaction is between a potential purchaser and a merchant and the merchant is represented automatically by a haggle agent operating according to rules specified by the merchant.

12. The method of claim 1 wherein the transaction is between a potential purchaser and a merchant and the potential purchaser is represented by an automated purchaser agent.

13. A commercial transaction system for conducting a transaction between a merchant and a purchaser, the transaction system comprising: a purchaser interface for presenting transaction parameters to the purchaser; a server having an interface communicating transaction parameters with the purchaser interface; a transaction-time data record comprising data representing one or more marketplace variables; controls implemented in the purchaser interface enabling a purchaser to accept and decline currently presented transaction parameters; and a haggle component in communication with the server and the transaction-time data record, the haggle component operable to modify at least one transaction parameter in response to declination of currently presented transaction parameters based on at least one of the marketplace variables, wherein the server is configured to present an alternative offer including the modified transaction parameters to the purchaser using the purchaser interface.

14. The system of claim 13 wherein the server is controlled by the merchant.

15. The system of claim 13 further comprising business rules implemented within the haggle component to vary at least one transaction parameter selected from the group consisting of: price, quantity, product grouping, product type, product accessories, product features, and frequency of service.

16. The system of claim 13 wherein the at least one marketplace variable is selected from the group consisting of: merchant accounting time periods, sales promotions, product inventory, competitor pricing, and customer history.

17. A computer-implemented system for negotiating purchases of goods and/or services, comprising: interface means for enabling a customer to input data relating to the purchase of particular goods and/or services; means responsive to user input data to generate content coupled to the interface means representing a plurality of transaction parameters related to the particular goods and/or services; and means within the server for modifying two or more of the transaction parameters according to merchant-specified business rules and re-generating the content to reflect the modified transaction parameters.

18. The system of claim 17 wherein the means for modifying is responsive to customer-input data reflecting that the customer has declined the currently presented transaction parameters.