FIELD OF THE INVENTION The present invention relates to electronic commerce systems for electronic negotiation between buyers and sellers for one or more inventory items, where one or more attributes may be negotiated for each inventory item as well as electronic workflow surrounding such negotiation, and more specifically to such electronic negotiation between buyers and sellers of media advertising time.

BACKGROUND OF THE INVENTION Previous electronic commerce systems have not been able to address the needs of buyers and sellers involved in complex purchase transactions.

In many business situations, purchases of goods and services require significant negotiation between buyers and sellers. These negotiations frequently include many other attributes of the goods or services other than their price, such as the type, quality and quantity of the goods being purchased, each of which may

influence the price of the goods. Negotiations also may require multiple rounds of back-and-forth communication before the parties agree on terms. Purchase prices are also influenced by market supply and demand; negotiations may take into account the presence or absence of alternative suppliers and purchasers.

Furthermore, sellers may explicitly package multiple items together, such that the pricing terms for more popular items are more favorable if purchased with less popular items. Another important aspect of negotiation is the ability for each party to limit the amount of information that is disclosed to the other party or parties. For example, sellers of items may not want to disclose to purchasers that the seller has a large amount of unsold inventory, or that there are few other buyers in the market. The parties'past relationships also factor heavily into negotiations.

A seller may accept a lower price for the same goods from a buyer with whom the seller has a long-standing relationship, and therefore an expectation of continued business, than from a buyer with whom the seller has had limited contact.

These influences are true in many industries, but apply particularly in purchase transactions for media advertising time. For example, advertisers wishing to purchase commercial time on broadcast television will negotiate with television stations in a particular market regarding the number of commercials to be purchased and the program or programs during which each commercial will air.

The advertiser also has specific goals about the size and demographic composition of the viewing audience that the advertiser wants to be exposed to the commercial.

Past audience size and demographic composition are measured by commercial survey firms, such as A. C. Nielsen, that produce ratings for broadcast programs from statistical sampling of the target audience. Ratings are expressed in terms of ratings points, where each rating point for a program represents approximately one

percent of the target demographic audience for the surveyed market viewing that program at a particular time. Because various factors influence the number of viewers that will watch a program and therefore be exposed to a particular commercial, the past ratings for a program serve only as a guide for a future performance and the advertiser and the seller must agree on the projected future ratings for the show as part of their negotiations. Furthermore, unlike many goods, commercial air time is not fungible. Once a particular episode of a program has aired, the advertising time inventory for that episode no longer exists for continued sale. Certain times of the year, such as ratings sweeps periods, are watched by more people than other times and advertising during such periods cost more. The advertiser and seller may therefore negotiate on the date that a certain commercial will air. Certain shows are also more popular than others and receive higher ratings. In order to sell less popular shows, a seller may package a higher-rated show with lower-rated shows and, during negotiations, explicitly link together the rates for the programs in the package.

In order to conduct these negotiations, buyers and sellers currently use various communications methods, such as face-to-face contact, telephone, facsimile, and/or electronic mail to conduct business. Frequently, negotiations are conducted by hand-writing comments on a sheet of paper and faxing the same sheet of paper back and forth between the buyer and seller. These negotiations are made in the context of each party's existing workflow processes, such as order approval processes for sellers, which either use paper records or legacy computer systems. When negotiations occur in paper-based workflow processes, the lack of central record-keeping and organization may lead to miscommunication or lost records. When parties are using legacy computer systems, using these

communications methods often requires that at least one party, and often both parties, manually enter data into a legacy computer system that already exists in the other party's legacy computer system. Every instance in which a buyer or a seller is forced to manually enter data that already existed in electronic form presents an opportunity for costly data entry mistakes to be made. In both cases where non-electronic negotiations have occurred, there is no central, electronic record of the transaction and buyers and sellers may have different understandings about the terms of the transaction. Finally, both buyers and sellers typically wish to monitor their aggregate performance in relation to pricing yields, seasonal demand fluctuations, or sales quota metrics, which becomes very difficult to perform in a non-electronic, non-consolidated data storage system.

Previous attempts to automate the process have involved Electronic Data Interchange ("EDI"), where electronic data is exchanged between the legacy systems of the parties. In order to use this solution, one party must manually enter information into its legacy system. EDI, however, occurs after the negotiation process and does not attempt to automate or track any negotiation details.

Furthermore, EDI still requires manual entry of data into one party's legacy system.

Electronic commerce systems for making unsophisticated purchasing transactions have been known in the art. Previous electronic commerce systems have provided only limited functionality that did not allow sophisticated transactions between buyers and sellers. For example, previous electronic commerce systems utilized a catalog metaphor. Under the catalog metaphor, the seller posted all of its inventory and pricing information on an electronic commerce system, just as mail order catalog vendors display their goods and

prices. Potential buyers browse the displayed inventory, and order the desired amount of goods at the posted prices. Such catalog-driven systems, unlike the present invention, force the seller to disclose all of their available inventory and pricing information to all buyers. Each item is displayed separately, and there is no way to explicitly link the price for one item with other items. These systems do not disclose or suggest flexible, multi-line item, multi-attribute negotiation, and particularly do not work for perishable, non-fungible items such as broadcast media advertising time.

U. S. Patent No. 6,081,789 to Purcell ("Purcell") discloses a catalog electronic commerce system wherein the seller posts its inventory on an e- commerce web site. Purcell further discloses allowing limited access to the system to approved buyers, as well as allowing the buyer to specify search criteria that the system uses to automatically match a subset of the seller's inventory. Purcell does not disclose or suggest, however, electronic multi-line item, multi-attribute negotiation. U. S. Patent No. 6,061,691 to Fox ("Fox") discloses a system for calculating prices for media advertising time inventory based on the available inventory, but does not disclose electronic multi-line item, multi-attribute negotiations relating to that inventory.

Because of the volume of transactions handled by sophisticated buyers and sellers, particularly in the media industry, and based on the above reasons, there is a pressing need for an electronic commerce system to provide a sophisticated electronic negotiation process, including the ability to negotiate multiple attributes of each inventory item, as well as providing centralized record- keeping for historical and audit purposes.

SUMMARY OF THE INVENTION The present invention has been developed to overcome the aforementioned disadvantages. In accordance with the present invention, a system and method have been provided for an electronic commerce system for providing electronic, multi-line item, multi-attribute negotiation between buyers and sellers in purchase transactions, including transactions related to the purchase of media advertising. Initially, a buyer will determine the criteria that the inventory to be purchased must meet, such as the total budget to be spent and the number of ratings points to be purchased. The buyer can then electronically construct a request for proposal and send the request for proposal to one or more sellers through the centralized electronic commerce system. In the media advertising industry, such requests for proposal are known as"avail requests."Each seller will review the request for proposal, electronically prepare a proposal containing proposed inventory with pricing and other attributes, and electronically send the proposal back to the buyer through the electronic commerce system. In order to create a proposal, a media provider can maintain its inventory in the electronic commerce system by electronically importing an inventory list from the station's legacy inventory management system, which is known in the broadcast media industry as a traffic system.

If the proposal is suitable to the buyer, the buyer may electronically submit an order through the electronic commerce system for one or more inventory items from each proposal independently from the other proposed inventory items.

The buyer may also choose to electronically negotiate one or more inventory items through the electronic commerce system. For each inventory item being negotiated, the buyer and seller may negotiate multiple attributes such as price,

quantity, classification, and quality, among others. For example, in the broadcast media advertising industry, each inventory item represents a specific television or radio program or time period in which the buyer's advertisement will be aired.

Purchasers of broadcast media advertising time will negotiate regarding units known as spots, which represent one airing of a commercial. Spots are generally purchased for standard time lengths such as 30 or 60 seconds. Buyers, generally advertising agencies, and sellers, generally television or radio stations, may negotiate about the price of one or more commercial spots during the program, the number of spots to be purchased, the ratings that the spots will provide, and the specific weeks and/or days within those weeks that the spots should be aired. All of these factors affect the price of the spots for a particular program, as well as the number of spots that the seller has available to be sold. Sellers may also package multiple programs together, in which the rate for a spot of one program is explicitly linked to the rate (and amount purchased) of the other programs in the package. Because negotiation occurs electronically, the seller can set a ratio between the programs of the package, such that if the overall rate for the package is changed during negotiation, the system can automatically re-set the individual program rates to maintain the correct overall ratio.

Because the buyer can view proposals from multiple sellers in response to the same request for proposal, the buyer can compare similar inventory items from different sellers and negotiate only those inventory items from each seller that best meet the buyer's criteria. Furthermore, because the proposal was transmitted through the electronic commerce system and the buyer will view the proposal in the same electronic commerce system, the buyer may easily view the seller's proposed values for each possible negotiation attribute, alter those specific

values that the buyer finds unacceptable, and electronically return a counter-offer to the seller. Furthermore, the system can electronically compare the price and ratings values offered by the sellers against the buyer's specified criteria in order to determine which inventory items to negotiate, and the appropriate values to counter-offer.

When the seller receives a counter-offer from the buyer, the seller may accept the counter-offer or continue to negotiate. The seller may negotiate any or all of the original negotiation attributes in response to the counter-offer and send the seller's counter-offer back to the buyer. The buyer and seller may continue this negotiation for several rounds for each inventory item until the buyer and seller have reached mutually agreeable terms and the buyer orders the selected inventory from the seller. When a particular spot is ordered, the order can be electronically submitted to the station's traffic system, avoiding manual data entry errors. An additional benefit of routing negotiations electronically through the electronic commerce system of the present invention is the ability to continue to provide private negotiation channels between a particular buyer and a particular seller, such as electronic mail and instant messaging that is facilitated and managed by our system.

Because the entire negotiation process is performed through the electronic commerce system, the system maintains a record of each exchange between the buyer and seller. Therefore, the parties can easily track the history of the negotiations and the changes that have been made by each party. This is also helpful after the inventory item has been delivered, or in the case of broadcast media, the commercial has aired. The parties can then easily reconcile what was ordered with what was delivered. In the case of broadcast media, after the spots

have aired, the parties can import the ratings data for each spot and determine if the actual ratings for the ordered programs matched the negotiated projected ratings.

Because there is an electronic record of the negotiations, the parties cannot dispute the agreed-upon terms.

Furthermore, because these transactions occur electronically, the electronic commerce system can be used to organize each party's workflow processes and provide for centralized record keeping and historical and audit information. For example, when a station is dealing with a buyer with which it has previously dealt, the station can retrieve the records of past buys and determine the appropriate actions. Additionally, the electronic nature of the system allows sellers to easily include electronic sales collateral when sending proposals, such as video clips of specific programs or other multimedia documents.

It is an object of this invention to provide an electronic commerce system that allows buyers and sellers to electronically negotiate complex purchase transactions involving one or more line items with each line item having one or more attributes that can be negotiated.

It is a further object of this invention to allow multiple line items to be explicitly linked such that the negotiations for one line item automatically and electronically affect the negotiations for one or more other line items.

It is a further object of this invention to incorporate this electronic negotiation into an electronic commerce system that includes workflow for enabling both buyers and sellers to manage the purchasing, approval, and confirmation processes.

It is a further object of this invention to maintain electronic records regarding each transaction for historical, reporting, and audit purposes.

It is a further object of this invention to integrate this electronic commerce system with each party's legacy computer system in order to reduce manual data entry and duplication of data.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1-System diagram of Negotiation/Workflow computers FIG. 2-System diagram of Application Server and Database Server software components FIG. 3-Process flow diagram of buyer's purchase creation/initiation in E- Commerce System FIG. 4-Process flow diagram of seller's response to purchase initiation FIG. 5-Process flow diagram of buyer's review of seller responses FIG. 6-Process flow diagram of buyer's negotiation process FIG. 7-Process flow diagram of seller's negotiation process FIG. 8-Process flow diagram of seller's order approval workflow FIG. 9-Process flow diagram of seller's salesperson order approval workflow FIG. 10-Process flow diagram of seller's management order approval workflow FIG. 11-Process flow diagram of seller's order confirmation process FIG. 12-Process flow diagram of buyer's order confirmation/makegood process FIG. 13-Process flow diagram of order reconciliation process FIG. 14-Process flow diagram of bonus weight request process FIG. 15-Screen shot of buyer's overview page FIG. 16-Screen shot of buyer's proposal view page FIG. 17-Screen shot of buyer's negotiation and analysis worksheet FIG. 18-Screen shot of negotiation window

FIG. 19-Screen shot of seller's order approval page DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT The preferred embodiment of the present invention utilizes an electronic commerce system accessed over a global telecommunications network such as the Internet by buyers and sellers involved in purchase transactions. The buyers and sellers utilize the present invention to conduct electronic negotiations regarding the purchase transactions, as well as performing workflow-related tasks surrounding the purchase, ordering, and order confirmation processes. An exemplary system of the present invention is further disclosed in the provisional patent application with a serial number 60/206,105, which is incorporated by reference in its entirety.

FIG. 1 illustrates a diagram of an electronic commerce system in accordance with the present invention. The preferred embodiment of the present invention utilizes a tiered application architecture to distribute the different application components over different computers. Please note that other embodiments of the present invention may combine certain application components onto the same computer. For example, FIG. 1, blocks 40-50, shows a pair of web servers for receiving client requests. In the preferred embodiment, the application server 60 also serves as the web server.

The client tier, at which buyers and sellers will interface with the system to conduct their negotiations, consists of a client computer 10 located at either a buyer's or seller's location running a web browsing application that retrieves and displays the system's web pages. The client computer 10 retrieves these web pages over the network tier, which is a telecommunications network

such as the Internet 20. Web pages are accessible over the Internet 20 by specifying in the web browser the page's unique identifier, known as a Uniform Resource Locator ("URL"). A URL for a web page consists of the domain name or numeric address of a server computer known as a web server 40,50 on which the web page resides, as well as the name of the specific page to be accessed. When a particular web page is required, the client computer 10 makes a request over the Internet 20 to a web server 40,50 in the web server tier. The illustrated embodiment utilizes a load-balancing router 30 to intercept the requests and route each requests to one of multiple web server computers 40,50 running web server software such as Netscape Enterprise Server which act as proxy servers to the application server 60. Utilizing multiple web servers allows the electronic commerce system to service multiple requests simultaneously and provides for redundancy in case of hardware failure. Other embodiments may use a single web server connected directly to the Internet, or may use different networking hardware between the Internet tier and the web server tier. As noted above, in the preferred embodiment, the application server 60 contains the same functions as the web servers 40,50. The preferred embodiment also utilizes a load-balancing router 30 with multiple application servers 60 to process multiple client requests. The application server 60 contains business logic that is used to determine which web pages are presented to the user and how to respond to the user's actions. This business logic also contains the logic necessary to process the user's transactions and appropriately notify other parties affected by the transaction. In order to construct web pages that reflect the user's current situation, the application server accesses data stored in the database tier on a database server 70 running an Oracle database 80.

When the application server 60 running application serving software such as BEA's WebLogic receives a URL request, a program known as a dispatcher servlet parses the request and initiates another program, known as a command processor, that is specifically designed to respond to the particular request. For example, the dispatcher servlet maintains a list of the web pages used by the electronic commerce system, as well as a list of which command processor program should be initiated when a particular client request is received. The response to each client request is generally a web page contains the graphical presentation of certain system information to the user, in this instance formatted in HyperText Markup Language ("HTML"). However, the response may also contain pure data formatted in the Extensible Markup Language ("XML") and a stylesheet written in Extensible Stylesheet Language ("XSL"), which is used by the web browsing application on the client computer 10 to construct an HTML page to display to the user. As shown in FIG. 12, an example web page in the preferred embodiment shows a list of purchase transactions 1100,1110 on which a particular buyer is currently negotiating or ordering.

Referring again to FIG. 1, because the items that must be displayed to each user are different depending on their current transactions, the application server 60 also contains the program logic that is used by the system to uniquely construct each page for each user and to process the transactions applied by the user. When the appropriate command processor for a particular page is called, the command processor may access a Java Server Page ("JSP") for that page. A JSP contains static HTML that is utilized by any client viewing that page with custom code written in Java that dynamically constructs HTML based on the current user and transaction context. The command processor passes the JSP to a JSP

Processor program, which processes the custom Java code. The Java code utilizes Enterprise Java Beans, which consist of self-contained data objects known as beans, to hold the logic associated with the system and for constructing the particular page. Enterprise Java Bean programming splits the object beans into two types, session beans which contain business logic, and entity beans. For data integrity reasons, the entity beans are the only items allowed to access and modify data in the database 80. Where multiple users will be attempting to access and modify the same data in the database 80, each user will be running different instances of particular session beans, but all database accesses for a particular type of data item are forced to go through the same entity bean. When the JSP processor program has finished running the custom Java code, the resulting HTML page is sent back to the correct client computer 10 through the application server's 60 output stream.

FIG. 2 shows a detailed diagram of the software components associated with an embodiment of the present invention. The Application Server computer 130 running the application server software 135 accesses business logic 170 and other components 160,165,175 which in turn access the database 185 running on the database server 180. FIG. 2 additionally illustrates how a data reporting application 195 can run against the database 185 to create detailed reports of transaction values, times and other metrics. Additionally, FIG. 2 shows the system integrating with legacy computer systems 102 using Specialty Service XML/EDI components 140 on the application server computer 130. The electronic commerce system may access legacy systems 102 either by communicating directly with the legacy system, or a product such as SilverStream, Inc. X- Commerce may be used to emulate a terminal on the legacy system. Data entry

and view screens on the legacy application may be identified on the legacy system, and data inputted or retrieved from the legacy system electronically.

FIGs. 3-10 show process flow diagrams of the method associated with the preferred embodiment of the present invention with regard to purchase transactions of broadcast media advertising time, including workflow surrounding the transactions such as transaction analysis and order approval and confirmation processes.

Broadcast media providers such as television and radio stations distribute programming interspersed with advertisements for various products or services, which are then viewed or heard by consumers. Broadcast advertisements are generally created by or for businesses as a means to communicate a message to potential customers in order to increase awareness of their products and services.

A typical 30 minute television sitcom on a major broadcast network may contain 18 minutes of programming and 12 minutes of advertising, grouped into several "pods"of 30 second commercials.

Referring to FIG. 3 step 200, a buyer of media constructs a specification for a new purchase of advertising in the electronic commerce system.

The specification contains the parameters within which the buyer must operate for the purchase, such as the budget allocated for the purchase, the target demographics, and the. total amount of ratings points (i. e., viewing/listening audience) that the buyer wishes to reach with the specified advertising. Because different people watch television or listen to radio at different times of the day, the buyer may allocate the budget over different time period of the day, known as dayparts in the industry. For example, a radio buyer may allocate a certain portion of the budget to the early morning drive time, known as the"morning

drive"daypart, a certain portion to the daytime daypart, and the rest of the budget to the afternoon rush hour. Because the buy parameters are maintained centrally on the electronic commerce system, the buyer may revise the entries as necessary, step 210. The buyer creates a request for proposal, step 220, known as an avail request, containing some or all of the buyer's purchase parameters. For example, the buyer may not want to disclose its true budget to sellers in order to prevent sellers from offering higher prices, or the buyer may want to disguise its true target demographic for similar reasons. The electronic commerce system maintains a list of all of optional parameters associated with an avail request, and displays a web page to the user allowing the user to select the parameters which will be included on the avail request and displayed to the sellers. Note that although the preferred embodiment describes an electronic commerce system in which the buyer creates an avail request for a single communication medium in a single market, the system could easily be extended to allow buyers to construct buy specifications for multiple media in multiple markets.

The present invention also allows buyers to electronically select which sellers in a particular market will receive the avail request from a stored list of media providers in the market previously entered by the buyer, step 240. If the buyer had entered radio for the particular medium in step 200, the buyer would be presented with a list of radio stations in the market selected in step 200. When the buyer selects the appropriate sellers, step 240, the buyer can add specific comments to be sent to each station, step 250 and finally send the request to those sellers, step 260.

FIG. 4 shows the response of a salesperson at a station upon receipt of an avail request. Because the avail request is sent electronically and the buyer

and the seller are operating off web pages which access the same central database, the seller may be easily notified that it has received a new avail request from the buyer step 300. When a salesperson at the seller station receives the notification, the salesperson may navigate to a web page displaying the parameters included in the avail request by the buyer, step 320. The salesperson may send an immediate comment electronically back to the buyer step 310, or the seller may construct a proposal in response to the avail request, step 340. The proposal contains inventory items that the buyer can order, which in the case of media broadcasting represent programs or time slots during which the buyer can purchase advertising.

When the salesperson is constructing a proposal, the salesperson may access a list of the station's programs that is stored in the central database and select which items to add to the list. The electronic commerce system can also access the station's legacy inventory system to determine the current inventory availability for each program. Additionally, the salesperson can select multiple items and package the items together. The seller can specify multiple attributes for each program, including the price for one or more advertising spots and the number of gross ratings points that the seller projects that the proposed spots will achieve.

The seller may also specify other attributes regarding each line of programming, including the particular days of the week that the advertisement will air, or which weeks during the requested time period during which the advertisements will air.

Because the information is maintained in a central database, the salesperson can save the proposal and either view, revise or delete the proposal Step 350 at a later time. The salesperson also has the ability to attach electronic sales collateral such as multimedia presentations about the programs. When the salesperson has

finished constructing the proposal, the salesperson may send the proposal step 370 to the buyer.

Referring to FIG. 5, the buyer is notified that the seller has returned a proposal in response to the avail request, Step 400. FIG. 15 shows a sample screen shot wherein one of the buyer's overview pages shows an Alert box 1430 which contains a notification 1440 that a proposal has been received. Additionally, the system may notify users through the users'electronic mail systems. Referring again to FIG. 5, the buyer will view the proposal to see which program items the seller has proposed, step 410. Additionally, because the proposals are maintained electronically in the system, the buyer may view other proposals received in response to the same buy specification, step 420.

FIG. 16 shows a screen shot of a sample proposal from a particular television station 1500 being viewed by the buyer. The proposal contains the market 1505, in this case Atlanta, the client 1510 and product 1515 names, the past ratings books used to estimate the future ratings 1520, the target demographics 1525, in this case women 25-54 as well as all adults 25-54. The proposal includes inventory items 1530 representing different television programs. For each program item, the proposal displays the daypart 1535, the days during the week in which the program airs 1540, the time of day that the program airs 1545, the program name 1550, the rating values that the program is projected to receive 1555, the rate for one spot of the program 1560, the average cost for one rating point of the program 1565, which is calculated by the rate of one spot of the program divided by the number of ratings points negotiated for that spot. While ratings points are expressed as percentages, ratings may also be expressed in absolute numbers, in which case the system may calculate the cost per thousand viewers 1570. The

system may also display the length of each spot 1575 and an indicator that the seller has attached electronic sales collateral 1580.

Referring again to FIG. 5, the buyer may decide to evaluate specific inventory items and their current negotiation offers by creating an analysis tool known as a worksheet, step 430,440. If the buyer is interested in a program or package that a seller has proposed, the buyer may add the item to the worksheet for evaluation step 450. Because the worksheet is accessing electronic data stored in a central location, the worksheet allows the buyer to easily view and compare selected items with similar items proposed by other stations, allowing the buyer to more easily negotiate with the sellers. For example, if the buyer wants to purchase advertising in prime time television, the buyer may view in one place the rate, ratings points, and cost per ratings point for the prime time programs proposed by each station in the market.

FIG. 17 shows a sample worksheet showing inventory items 1600, 1605 selected from proposals from multiple stations 1610,1616. Each inventory item represents advertising spots 1620 that can be purchased in a television program. Note that the worksheet displays multiple negotiation attributes for each item, such as the ratings points for a single spot in that television program 1625, the rate for a single spot in the television program 1630, and the average cost per ratings point 1635. The buyer may also indicate the number of spots 1620 that the buyer wants to purchase in each week of the advertising flight that the buyer selected in the specification. The worksheet also indicates the total number of spots 1640 that the buyer has selected for a particular item, which is the sum of the weekly spots 1620, the total ratings points 1645 for a particular item, which is the total number of spots times the ratings points provided by one spot 1625, and the

total cost 1650 for an item, which is the total number of spots 1640 times the rate for one spot 1630. The worksheet also provides an analysis section 1655 that compares the totals for the selected items to the goals 1660 entered by the buyer in the specification, and calculates any deficiency or overage 1665. The buyer may also track the negotiation status of each item 1670, and may use the analysis section to track items in different stages of the purchasing life cycle. For example, the buyer may view totals for items that have been ordered and for which confirmation has been received from the seller 1670, items that are currently in negotiation 1675, and items that have been ordered but not confirmed 1680. For each status, the system will calculate the total worksheet rate 1685, total worksheet ratings points 1690 and total worksheet average cost per point 1695 of all items in that status Additionally, the buyer may also select to temporarily change negotiation attributes for items to determine how those changes would affect the buyer's goals, as shown in the"What If'column 1697.

Referring to FIG. 6, when the buyer is either viewing an initial negotiation offer received from a seller or reviewing a new round of negotiations for a line item 505, if the buyer is interested in an item then the buyer may either decide to accept the seller's offer 525 for that line item, or negotiate one or more of the attributes for that item 535. If the buyer is not interested in the item, the buyer may hide the item 520 so that the item does not show up on the worksheet. If the buyer wishes to negotiate the item, the buyer will create a new offer for the item step 550 containing the negotiation attribute. Because the information is maintained electronically, the buyer may save the negotiation before submitting to the seller for later review, revision or cancellation step 555.

FIG. 18 shows a screen shot of a sample negotiation offer, either by a buyer or a seller. An offer consists of an non-negotiable information identifying the program, such as the program name 1700, days that the program will air 1705, times during the day that the program airs 1710, target demographic 1715, etc.

The non-negotiable fields are displayed in read-only mode, while the negotiable attributes are displayed with editable parameters. Examples of negotiable attributes include the ratings values 1720,1725,1730 that the buyer and seller estimate that a spot of the program will get, the rate 1735 for one spot, and whether the item is part of a package of other items. Additionally, the user may enter negotiation comments 1740 about why an attribute should be different from what was initially offered. For example, the buyer may lower the seller's offered ratings and comment that the seller over-estimated the audience and ratings, noting that the ratings for the program have declined in each of the previous ratings surveys.

When the buyer has finished changing the negotiation attributes for the inventory item, the buyer may cancel the draft negotiation 1745 or submit the negotiation 1750 to the seller as a counter-offer, also FIG. 6., step 565. Additionally, the buyer may review how the changed values affect the buyer's goals before submitting the negotiation. If the buyer was negotiating a package, the negotiation screen could list all of the programs associated with the package and allow the buyer to change the negotiable attributes for each program, such as the ratings points for each program in the package, as well as negotiate on the overall rate for the package. Additionally, the flexible negotiation engine allows the buyer to decide whether quantity is a negotiable attribute. The seller may propose a number of spots for each week of the flight initially, and the buyer and seller may negotiate that order quantity, or the buyer and seller may leave the quantity blank and

negotiate just the rate and ratings for one spot of the program. In that case, the buyer will specify the quantity of spots at order time and the seller will accept or reject the ordered quantities at order approval time. Furthermore, either the buyer or the seller may assign an expiration date to a negotiation offer, such that the offer expires if it has not been accepted by the other side. For example, a seller may provide one price for a popular item if the seller responds by a certain date, or a different price if the buyer responds later when the inventory for the item will be mostly sold.

FIG. 7 shows the salesperson's choices when the salesperson receives a notification 600 of a new negotiation received from a buyer. After the salesperson reviews the negotiation step 610 and evaluates the changed attributes Step 620, the salesperson may either send an acceptance of the buyer's counter- offer 670 for that item, or negotiate the item 640 by changing the negotiation attributes 640 of the inventory item and submitting a counter-offer 690 to the buyer.

The negotiation process between the buyer and seller can continue many times until the buyer and seller have reached mutually agreeable terms.

Because the information is maintained electronically in a central database, the buyer and the seller can view the negotiation history for each item, including the number of negotiation rounds that have occurred, as well as display the list of each offer that was made for the item. The system allows this by storing each of the offers received for an item separately, albeit linked to the item, including the time and date at which each offer is received. In order to save space, the system may store non-negotiable attributes with the item, and only store the negotiable attributes for each new offer. This offer history provides an electronic record of

the transaction in case a dispute arises later about the negotiations. Furthermore, because the system knows when each negotiation offer was received, the system can track and report performance metrics such as how many offers are received per proposal, how many items are negotiated, the average number and length of negotiation trips, etc. This information can be combined with information about the negotiation attributes themselves, such as reports about which cost per ratings points were the most effective in negotiation, and allow the buyer and seller to more fully optimize their operating behavior. Additionally, because the data is maintained electronically and stored centrally, it is simple to define workflow that allows management to oversee the purchasing process by providing electronic notification and allowing management to view documents at any stage in the purchase transaction. For example, sales managers can view the status of any particular proposal. Furthermore, workflow is easily added allowing management approval at any step in the purchase transaction, such as approval of proposals before the salesperson submits to the buyer, or approval of negotiation offers or acceptance of counter-offers before submission to buyers. Similarly, buyer buy specifications, negotiations and orders can be electronically submitted to management for approval before submission to sellers.

Referring again to FIG. 6, once the buyer and seller have reached mutually agreeable terms regarding the rate and ratings for an inventory item, the buyer may order the item step 545 either by keeping the proposed spot quantity, if existing, or adding spot quantities for the weeks that the buyer wishes to advertise.

Because the information is maintained electronically, the buyer may save the order for a later date, and review, revise or cancel the order 540. Once the buyer is satisfied with the order for the item the buyer may submit the order for the item to

the seller. Because each item is maintained independently in the database, each item may be ordered separately, although the system may maintain only one order between a buyer and a seller that contains each of the ordered items for a particular proposal, regardless of order time for each item. Referring to FIG. 8, the buyer may also send order revisions to a station. The buyer may either add new items 720, or cancel a previously ordered item 730, and then submit the revision to the seller 740. All of the information is maintained in the system for audit and reporting purposes.

FIGs. 9-10 show a sample seller's order approval process performed over the electronic commerce system. The order approval process may contain several steps, including review by the responsible sales person and by station management. Additionally, because the information is maintained electronically, the seller may specify the workflow for the order approval process, such as setting the dollar amount that a particular salesperson can approve without further management approval, or routing order approval to other salepeople or managers when the responsible salesperson is on vacation or has left the station. Once the seller receives notification that an order has been received from the buyer FIG. 9, step 800, the salesperson will evaluate the order for approval 810. Even though the buyer and salesperson have negotiated the rates and ratings, the salesperson may completely or partially reject an ordered item either because the ordered spot quantity is too large, or the buyer has responded after the expiration date for the offer and the offer is no longer valid. The salesperson may either reject all items on the order 825, approve all items on the order 830 or review each item individually for approve 840 or rejection 835. Additionally, the salesperson may partially accept or reject spots within a particular item. When the saleperson is

finished approving the order, the salesperson can add comments explaining the approval or rejection 845, and forward the order to station management for further review. FIG. 10 shows a similar order approval process for the station management, after which the approval or rejection is returned to the salesperson 970 for further processing.

FIG. 19 shows a screen shot of an example order approval screen.

Each ordered item 1800 is listed, and for each item, the program information such as name 1810, spot rate 1820, spot rating 1830, total ordered spot quantity 1840. A field is displayed on the web page for indicating whether each line item is approved 1850 or rejected 1860, the ability to add comments 1870, and the ability to cancel the order approval actions 1880 or submit the order approval to station management for further approval 1890. Additionally, the system automatically calculates totals across ordered line items for the seller's convenience 1895.

FIG. 11 shows the Order Confirmation process in the station's legacy inventory system, known as the traffic system or traffic and billing system ("T&B"). Once the order has been approved by station management, the order may be submitted electronically to the traffic system 1010 for order confirmation.

If multiple programs have been linked as a package, an order for each program will be submitted separately to the traffic system. When the traffic system receives the order, it attempts to place the ordered spots in the ordered programs. The electronic commerce system can electronically access the confirmation records to indicate whether the spots for the ordered items were confirmed 1020. When the salesperson reviews the confirmation, the ordered spots will either be confirmed or not available ("NA"). While FIG. 11 indicates the salesperson manually entering the confirmation status of the ordered spots 1050,1070, the order confirmation can

also be retrieved electronically from the legacy system. If an ordered spot is not available, the salesperson can either return the'Not Available"status to the buyer, in which case the buyer is not obligated to pay for the ordered spot, or the salesperson can propose replacement spots from a different program. Such replacement spots are known as makegoods. The salesperson can select the programs for the makegood spots from the stored list of program inventory similar to when the salesperson constructed the initial proposal. For each proposed makegood, the seller may also set the negotiation attributes such as spot rating.

Because the buyer and seller had previously agreed to the ordered items, the buyer must approve the proposed makegoods. Once the salesperson has finished, the salesperson may submit the order confirmation to the buyer 1060, with or without makegoods.

FIG. 12 shows the buyer's processing of the order confirmation. If an item is confirmed 1120, the buy process is finished for that item. If an item has not been confirmed, the buyer may view the item on the worksheet 1140 to determine the effect that the order confirmation (or lack of confirmation) has on the buyer's goals for the overall purchase. The buyer may also add the proposed makegoods to the worksheet 1140 for analysis. If the makegood is acceptable, the buyer may accept the makegood in lieu of the unconfirmed item or spots 1150, in which case the makegood is added to the order as an order revision 1160. If the makegood is not acceptable, the buyer and the seller may negotiate the makegood's attributes 1160 until the makegood is acceptable. Buyers and sellers may also negotiate makegoods if a confirmed item ceases to be confirmed because some or all of the previously confirmed spots either were pre-empted by spots from a different order, or the program in question was cancelled.

Referring to FIGs. 13-14, once the flight dates for a buy have passed, the buyer and seller will reconcile which spots actually aired with what the buyer ordered, as well as comparing the ratings points that the ordered spots actually achieved against the negotiated values. FIG. 13,1200 shows a buyer receiving a ratings report from an outside survey agency. Additionally, this information can be electronically imported into the electronic commerce system for automatic, electronic comparison. Once the information has been entered 1220 or imported, the system will calcuate the difference between the ratings that the buyer and seller negotiated, and the ratings that a particular episode of a program received 1230. Any differences are flagged for the buyer 1240 and a report of whether the buyer did not receive the ordered ratings points is prepared 1250. If there is a discrepancy, the buyer can request additional spots known as bonus weight from the seller 1460.

FIG. 14 shows a bonus weight request submitted to the seller 1330, who then may approve, reject or negotiate the request.

Because all of this information is maintained and negotiated electronically, the system maintains a clear, indisputable record of each transaction in case a dispute arises. Furthermore, both buyers and sellers can analyze their transactional data for reports including how long certain negotiations took, what was the end result, and how many items were ordered, confirmed and eventually aired.

Whereas the invention has been described with respect to specific embodiments thereof, it will be understood that various changes and modifications will be suggested to one skilled in the art and it is intended to encompass such changes and modifications as fall within the scope of the appended claims.

INDUSTRIAL APPLICABILITY The disclosed methods and systems provide for complex electronic negotiations. The methods and systems provide for buyers and sellers involved in purchase transactions to utilize an electronic commerce system to negotiate electronically regarding one or more items to be purchased, where the negotiations for each item may include attributes regarding the item, including cost, classification, quantity and quality. Therefore, the methods and systems disclosed have industrial applicability for the advertisement, commerce, and other industries.