WO2001050402A1 - Sale transactions on a network - Google Patents

Abstract

The invention relates to a method performed on a server of the type used to perform sales transactions over a communication channel. The method includes receiving information on the communication channel, generating a confirmation message directed to the source of the received information that includes identifying information at a set position for associating the confirmation message with the communication message, and receiving a response to the confirmation message containing the identifying information at a set position. The received information includes communication information and addressing information for directing messages to a source of the information.

Description

SALE TRANSACTIONS ON A NETWORK Background of the Invention The invention relates to sale transactions on a network.

Sale transactions (auctions) generally involve a person selling an item (seller) and a person interested in the item (buyer) agreeing on a purchase price. There are different kinds of sale transactions that differ from each other in the way the buyer and the seller reach agreement on a price.

In an English auction, the seller solicits purchase offers ("bids") from multiple potential buyers of a single item. The seller sets the lowest price that he is willing to sell the item at, the reservation price, and the potential buyers make progressively higher bids in an effort to ensure that the seller sells the item to them, and not another buyer. Each successive bid is higher than the previous bid by a minimum bid increment which is set by the seller. The last bidder, who is also the highest bidder, is the winner of the auction provided that his bid is greater than the reservation price. If no bid is greater than the reservation price at the end of the auction, then there is no winner.

In a clock auction, the seller displays the item that is up for sale along with a price. The seller also sets a rule by which the price decreases with time (e.g., 5 dollars every hour). Once the auction is started, the price decreases until a buyer purchases it and terminates the auction. Alternatively, if the price drops to the reservation price before there are any bids, then the auction ends with no winner. An example of a clock auction is the Holland flower and bulb auction.

In a discriminative-price auction, a seller displays the identical items he would like to sell, the total number of such items that is available, a reservation price, and a minimum starting bid price. Multiple bidders enter successively higher bids until there are no more bids on the items. Each new bid is higher than the previous highest bid by a pre-determined minimum bid increment. The items are sold to the top bidders at their bidding price. A uniform price auction sometimes referred to incorrectly as a "Dutch Auction") is similar to a discriminative price auction except all the items are sold at the price of the lowest bid that is high enough to win one of the items for sale at the auction. In both of these auctions types, only those bids that are greater than the reservation price may be winning bids.

In a first-price-sealed-bid auction, there is only one item for sale. Each participant is entitled to one bid, which the user can change before the auction is closed. All bids are secret until the auction is closed. When the auction closes, all bids are made public and the item is sold to the highest bidder at the highest bid price. A second-price-sealed-bid auction, is identical to a first-price-sealed-bid auction, except the winner of the auction pays the second highest auction bid price.

A posted offer auction is similar to a newspaper classified ad. The seller describes the item and specifies a price for it. The first buyer that is willing to purchase the item at the offer price wins the auction. A posted bid auction is similar to a "wanted to buy" newspaper ad. The buyer describes the item he desires and sets his purchase price. The first seller willing to sell at the buyer's price wins the auction.

Auctions are sometimes hosted over the Internet. Users can participate in Internet auctions using a web browser on a computer to access a remote central server where the auction occurs. The central server has a web site containing the auction information. Participants navigate the web site by moving a computer cursor (e.g., a computer mouse) over designated navigational areas (hyperlinks) and actuating the computer cursor (e.g., clicking a mouse). The web site displays auction items by presenting images of the items to the user. When the images cannot be presented (either because the user has opted not have images presented or because of errors in transmitting the images), alternative text (alt text) selected by the auction poster is presented to the user instead. Sellers are often required to pay a fee to post auction items on the auction web server.

Additionally, people can pay to have certain events, and products advertised on an auction site, even though they are not being sold in an auction. The products are often advertised in banners which generally contain images. The banners are hyperlinks that can be clicked on by a user to obtain additional information related to the banner.

Summary of the Invention The invention relates to a method on a server of the type used to perform sales transactions operating over a communication channel. In one general aspect of the invention, the method includes receiving information (including communication information and addressing information for directing messages to a source of the information) over the communication channel, generating and directing to the source of the information a confirmation message that includes identifying information at a set position in the message for associating the confirmation message with the communication message, and receiving a response to the confirmation message containing the identifying information at a set position in the message.

The method allows the auction system to authenticate the auction user using the confirmation message. By locating the identifying information at a set position, the resources and the time needed to extract the identifying information from the confirmation message is reduced.

Embodiments of the invention may include one or more of the following features. The confirmation message is sent as an E-mail message and the set position of the identifying information within the message is within the subject line of the E-mail message. Because the subject line of the message is generally short, this reduces the resources and the time needed to extract the identifying information. The response to the confirmation message is sent as an E-mail message and the set position of the identifying information in the response is within the subject line of the E-mail message. This reduces the processing time and resources required to extract the identifying information.

Prior to sending the confirmation message, the communication information is presented over the communication channel and an acknowledgment is received over the communication channel. This provides a quick verification of the received communication information. Prior to receiving the response, a flag is stored, indicating that a confirmation response has not been received. The flag is altered subsequent to receiving the response, to indicate that a confirmation response has been received. This allows the auction server to determine the status of all posted auctions by examining the flag in the auction file.

The communication information is searched for prohibited information, and is stored only if prohibited information is not found. If prohibited information is detected, the file is moved to a quarantine area for manual inspection. The communication information is stored in a first file within a computer file system. The file system has folders for categorizing information, the first file being categorized with related information, including another file and a folder, in a first folder. The first folder is categorized with additional related information, including a file and a folder, in a second folder. The categories enable easy location of specific item types. The file system is mirrored using a RAID system to provide data redundancy.

The identifying information includes a name for identifying the first file, at least part of the communication information, information about a user.

The communication information includes information about the item which is presented over the communications channel and an offer to purchase the item from a second source is received over the communications channel. The communication information includes advertising information, such as a click-through banner, which is presented over the communications channel. The communication information further can include an image.

Prior to receiving the information over the communications channel, a request for the information is presented over the communications channel. The request includes an HTML form. The communications channel can be the Internet. In another general aspect of the invention, a communications system for performing sales transactions over a communications channel includes a storage element for storing information related to the transactions, a communication element that communicates over the communications channel (including sending and receiving elements, the sending element for sending at least part of the stored information to the channel and a receiving element that receives additional information from the channel), and an interfacing element that interfaces the storage element and the communication element with a variable number of sales modules. The interfacing element is configured such that a sales module can be added without altering the system.

Other embodiments of the invention may include one or more of the following. At least one sales module performs auctions (e.g. English, clock, uniform-price, discriminative- price, first-price-sealed-bid, second-price-sealed-bid, posted-offer, or posted-bid auction) over the communication channel. The communication channel is the Internet and the communication element is a web server. The storage element is a hierarchical file system.

The web server communicates with at least one of the elements by CGI, IS API, or NSAPI. At least one of the elements is implemented in software which runs on a computer. The software is configured such that a second similar system can be implemented in software on the same computer. The communication channel conforms to the IP protocol and the software is configured to communicate either on a different IP address from the second similar system, or on a different IP port from said second similar system. At least one of the elements and modules is configured to remain resident in the virtual memory of the computer. The computer is a UNIX (or UNIX variant such as Linux or AIX) computer and the element resident in virtual memory has its sticky bit (a.k.a. "shared text image bit") set.

Other features and advantages of the invention are described in the description and the claims.

Brief Description of the Drawings Fig. 1 shows the auction web server and its connections to multiple concurrent users.

Fig. 2 shows the home page of an auction web site.

Fig. 3 shows a web page that includes a listing of a category of items for sale at the auction web site of Fig. 1.

Fig. 4 shows a web page that can be used to search through items for sale at the auction web site of Fig. 1.

Fig. 5 shows a web page that includes a registration form that must be filled by a user before he can be granted access to the items for sale at the auction web site of Fig. 1.

Fig. 6a shows a web page that allows a user to submit a bid in an English auction. Fig. 6b shows a web page that allows a user to submit a bid in clock auction. Fig. 6c shows a web page that allows a user to submit a bid in a uniform-price auction.

Fig. 6d shows a web page that allows a user to submit a bid in a discriminative-price auction.

Fig. 6e shows a web page that allows a user to submit a bid in a first-price-sealed-bid auction.

Fig. 6f shows a web page that allows a user to submit a bid in a second-price-sealed- bid auction.

Fig. 6g shows a web page that allows a user to submit a bid in a posted-offer auction. Fig. 6h shows a web page that allows a user to submit a bid in a posted-bid auction. Fig. 7 shows a web page that allows a user to submit an auction to the web site of Fig.

1.

Fig. 8 shows a web page that allows a user to submit an advertisement banner on the web site of Fig. 1.

Fig. 9 shows the computer file system used to store information on the web site of Fig. 1.

Fig. 10 is a flow chart of the process used to generate the web page of Fig. 2. Fig. 11 is a flow chart of the process used to perform the search of Fig. 3. Fig. 12 is a flow chart showing the process of display an auction of Fig. 6A and collecting bids submitted in response.

Fig. 13 is a flow chart showing the processing of the auction submitted in Fig. 7.

Fig. 14 is a flow chart showing the processing of the banner submitted in Fig. 8. Fig. 15 is a flow chart showing the processing of the user registration information submitted in Fig. 5.

Fig. 16 shows the contents of a file used to store the auction information of Fig. 7.

Fig. 17 shows the contents of a file used to store the bidding information of Figs. 6a- 6h. Fig. 18 shows the contents of a file used to store the advertising banner illustrated in

Fig. 7.

Fig. 19 shows the contents of a file used to store the user registration information of Fig. 4.

Fig. 20 shows the different elements of the auction server of Fig. 1. Fig. 21 is a flow chart showing the processing of the E-mail information.

Fig. 22 shows a confirmation E-mail message sent out in step 807 of Fig. 13.

Description of the Preferred Embodiments Referring to Fig. 1, an auction server 3000 is connected to the Internet 4000. Multiple concurrent users 61A-61C are also connected to the Internet 4000. Through the

Internet 4000, the users 61A-61C can access server information 4001 from the auction server 3000. Users 61A-61C can also send user information 4002 to the auction server 3000. The user information 4004 and the server information 4001 are transmitted between a web server that is part of the auction server and a web browser on the users' 61A-61C computers. The connections to the Internet could be dial-up, xDSL, leased line, TI or cable modem connections. A user 71 is connected to the auction server 3000 through an intranet 5000. Intranet 5000 is implemented in this illustrated embodiment, using the TCP/IP protocol over an Ethernet link. Thus, processing sales transactions using a network, as illustrated, allows multiple users to concurrently perform transactions. The operations of the auction server will be described using Figs. 2-22. Figs. 3-8 will be used to describe the web pages that are accessible on the auction server, after which, the hierarchical file system used to store auction information will be described using Fig. 9. The procedure for various processes performed by the auction server will be described using Figs. 10-15 and then Figs. 16-19 will be used to describe the contents of the files used to store information on the auction server. Fig. 10 will be used to describe the various subsystems of the auction server and, finally, Figs. 21 and 22 will be used to describe the automatic electronic mail (auto e-mail) feature of the auction server. Auction Server Web Pages

Referring to Fig. 2, a user 61 A may access information on the auction server 3000 through the home page 2000. The home page 2000 is loaded onto the web browser of the user 61 A (Fig. 1) when the user first loads the web site of the auction server 3000 (Fig. 1) on the user's web browser (not shown). The home page 2000 includes a standard header 1 and a standard footer 2. The auction server 3000 can be configured to automatically display the standard header and footer at the top and bottom of every page. This can implemented using a standard feature of a web server (for example, the Apache web server) or using a complementary program that communicates with the web server using CGI, NSAPI or ISAPI. The information in the header 1 and the footer 2 can be customized to the specific auction site. In Fig. 2, the header 1 identifies the auction hosted on auction server 3000 and the footer 2 contains a copyright notice. Home page 2000 also contains advertising banners 8 and 9. These banners are a source of additional advertising income. The items advertised in the banners do not have to be sold on the auction server 3000. Users can load the web pages associated with a banner by clicking on the banner.

To access other pages on the auction server 3000, user 61 A first registers on the server by clicking on a hyperlink 5. Users that have registered in the past do not have to register again. The registration process collects identity information from user 61A. The identity information is used to prevent other people from impersonating user 61 A. The identity information is also used to prevent user 61 A from performing fraudulent transactions on the auction server.

Once registered, user 61A can navigate the auction server 3000 by clicking on hyperlinks 3, 4, 6 and 7. The items on the auction server are categorized so that user 61 A can easily locate an items of interest. User 61 A can browse the categories by clicking on hyperlink 3. Alternatively, user 61 A can have the auction server 3000 search for items of interest by clicking on hyperlink 4. Additionally, user 61A can post an auction for an item he would like to sell by clicking on hyperlink 6. User 61 A can also post an advertising banner by clicking on hyperlink 7.

Referring to Fig. 3, the web page which is used to browse a category will be described. This web page is displayed after clicking on hyperlink 3 in Fig. 2. It includes a listing of hot items 13, and listings 16 in the category (in this case TVs). It costs a person selling an item (seller) more money to have an item designated as hot. In return for the added cost, the hot items 13 are displayed more prominently above the other listings 16 so that the hot items 13 are more visible to prospective buyers. A seller can also pay more to have an item displayed in bold typeface or in a larger font. The web page of Fig. 3 also has the standard headers and footers 1, 2 and banners 8, 9. User 61 A can get additional information about any one of the posted items 14, 15, 10-

12 by clicking on its hyperlink. The user can also browse subcategories 20 of the current category by clicking on subcategory hyperlinks 17-19. The user can also proceed up a category hierarchy 24 by clicking on hierarchy hyperlinks 20-23.

Referring to Fig. 4, a web page that can be used to search items for sale at the auction web site of Fig. 2 will be described. This web page can be viewed by clicking on hyperlink 4 in Fig. 2. User 61 A can search for an item of interest by providing the search information 38 and clicking on the search button 36. Should the user 61 A make an error in providing the search information 38, the user 61A can undo the provided information by clicking on button 37. The search information 38 that may be entered includes a category 29 that the user would like to search. By selecting a category, the user limits the number of records that have to be checked, thus reducing the time it takes to perform the search. The user may enter keywords 30 that the server should search (for example "34 inch TV"). The user may also select an auction type 31 in which he is interested in participating. The user 61 A can select a minimum price 32 and a maximum price 33 that he would be interested in paying for the item and a location 35 from which he is interested in purchasing. The user starts the search by clicking on the "start search" button 36.

The search engine takes the search information 38 and returns a list containing every auction that matches the selection criteria submitted by the user 61 A. The listing is similar to the web page of Fig. 3. Alternatively, the listing may be presented on multiple pages so that the user only sees a subset of the matching items at any one time.

Referring to Fig. 5, a registration form that is filled by auction users will be described. This form can be accessed by clicking on hyperlink 5 of Fig. 2. The registration form includes identity 43, address 49, telephone 54, and demographic 58 information. After providing the information, the user 61A clicks on button 59 to register. Should the user 61 A make an error in providing the registration information, the user can click on button 60 to reset the form and fill it out again. The identity information includes the user's real name 39, a user ID 40 that will be used to refer to him or her on auctions on the server, and a password

41 for certifying his or her identity. To prevent others from reading the password 41, it is not displayed when entered by the user. The user is required to enter the password a second time

42 to ensure that he or she did not make an error in typing it the first time. The addressing information includes an E-mail address 43, an optional company name 44, a street address

45, a city 46, a state 47, and a postal code 48. The system allows for the entry of a primary telephone number 50, a secondary telephone number 51 , and a fax number 52. The demographic information is used to compile statistics and also to ensure that the postings and banners target a relevant demographic category. Possible categories of demographic information include an age range 55, how the user was referred to the auction server 56, and whether the user is at the auction for business or personal reasons 57.

Upon receiving the registration input, the server checks the input to make sure that it make sense based on a set of rules, such as: the user ID must be greater than 3 characters long; the password must be greater than 6 characters long; numbers can only contain digits, commas, and periods; prices cannot have more than one decimal point or more than two characters after the decimal point; and E-mail addresses cannot have spaces and must have an "@" character at a position other than the first character. If the input is invalid, the server prompts the user to reenter the invalid fields.

Referring to Figs. 6A-6H, web pages 145A-145H that the user 61A can use to submit bids on items 92A-92H that are being auctioned will be described. Each of the items 92A- 92H is being described in a different auction type 133A-133H. The web pages of Figs. 6a-6h can be accessed by clicking on item hyperlinks 10-12, 14, 15 in Fig. 3. The bid web pages include item information 146A-H about the item being auctioned and bid information 69A-H entered by the user to bid for the item. The item information 146 varies by auction type. However, the bid information 69 is, in this embodiment, the same for all auction types.

Bid information 69 includes a user ID 61 and a user password 62 for identifying and authenticating the user 61 A that is submitting a bid for an auction. It also includes a bid price 64 for the item being sold and an optional message 63 to the poster of the auction. The user 61A has the option of submitting the bid with the message by clicking on button 68, submitting only the bid by clicking on button 67, or submitting only the message by clicking on button 66. Should user 61 A make an error in filling the bid form, user 61A can reset the form by clicking on button 65 and fill out the form again.

The bid web pages 145a-145h contain information about the location 76A of the item being sold. This information is useful to the user 61 A in deciding whether to purchase and ship the item from its location 76A or to purchase an item from a location closer to the user 61 A. The web pages 145a-145h also contain information about the payment options 72, and the shipping options 73 that the poster of the auction will accept. For example, the seller in Fig. 6a requires the buyer to pay for shipping and will only accept payments in the form of CODs, cashier's checks, and money orders.

Referring still to Fig. 6A, web page 145a shows a bid web page for an item 92a that is being sold in an English auction 133A. The corresponding item information 146A includes the total number of bids that have been made 83 A, the current highest bid 78A, the minimum bid increment 79A, and the seller's reservation price 82A. The user 61 A uses this information to determine his bid amount 64. The item information 146A also includes the time left 75A before the auction closes.

Referring to Fig. 6B, web page 145b shows a bid web page for an item 92b that is being sold in a clock auction 133B. The corresponding item information 146B includes a pricing rule 85B that specifies how the sale price decreases as time progresses. The current price 84B along with information about whether or not there is a reservation price 82B are also presented.

Referring to Fig. 6C, web page 145c shows a bid web page for an item 92C that is being sold in a uniform-price auction 133C. The corresponding item information 146C includes the number of identical items for sale 86C, the current price per item , the minimum bid increment and the minimum starting price 81C. The seller's reservation price 82C is also presented.

Referring to Fig. 6D, web page 145d shows a bid web page for an item 92D that is being sold in a discriminative-price auction 133D. The corresponding item information 146D includes the number of identical items for sale 86D, the current price for each of the three items 78D. The seller's reservation price 82D is also presented. A history of past bids 86 is also displayed on the web page 145d.

Referring to Fig. 6E, web page 145e shows a bid web page for an item 92E that is being sold in a first-price-sealed auction 133E. The corresponding item information 146E includes the number of bids 83E, the rules of the auction 85E, and whether or not the seller has a reservation price 82E.

Referring to Fig. 6F, web page 145f shows a bid web page for an item 92F that is being sold in a second-price-sealed auction 133F. The corresponding item information 146f includes the number of bids submitted 83F, the auction rule 85F, and whether or not the seller has a reservation price. Referring to Fig. 6G, web page 145G shows a bid web page for an item 92G that is being sold in a posted offer auction 133G (classified ad). The corresponding item information 146G includes the number of identical items for sale 86G, and the price per item 84G.

Referring to Fig. 6H, web page 145H shows a bid web page for an item 92H that a user would like to purchase from a posted-bid auction 133H. The corresponding item information 146H includes the number of identical items to be purchased 86H, and the price per item that the user is willing to pay 84H.

Referring to Fig. 7, the web page 147 used by a user to submit an item for auction will be described. The user identifies the item to be auctioned by providing a short description 92 of the item, a full description 70 of the item, and a category 91 that the item belongs in. The user has the option of including a picture of the item being auctioned by either submitting an HTML link 88 to the image to be displayed or by uploading a GIF or JPEG or other format image to the auction server 89. When applicable, the user specifies the uniform resource location (ORIOLE) of the image of the item in input 90. Additionally, the user discloses the location of the item being purchased 76 and specifies the available shipment options 73 to allow a potential bidder to assess the shipping costs. The user then specifies applicable financial information including the payment options 72, along with a minimum starting bid 80, if any, a reservation price 82, if any, minimum bid increment 79, and the duration of the auction 93. The user may also select additional display options 99 to make the item more noticeable to potential buyers. For example, the user may opt to have the auction displayed in bold typeface or designate an item to be displayed as a "hot" auction item. The user finalizes the posting of the bid by clicking button 95. Should the user make a mistake entering the information, the user can reset the page by clicking button 96.

Referring to Fig. 8, the web page used by a user to submit an advertising banner for display on the auction web site will be described. To submit the banner, the user specifies his user id 61 and his password 62 for authentication. The user then specifies whether he would like the banner image to be uploaded 89 to the auction server or displayed as a link to a separate web page 88. The user specifies the ORIOLE of the image source 90, alternate text to be displayed when the image cannot be displayed 97, and a destination ORIOLE 98 for a destination that is to be loaded when a viewer clicks on the banner. The user may purchase more than one banner display by entering the desired number of banner displays in the "quantity to purchase" input 102.

The user then selects where the banner is to be displayed 99. The user can either have the banner displayed at the top or bottom of a web page. The user must also select the category 100 in which the banner is to be displayed. Finally, the user enters the purchasing information. The user can either pay for the banner by the number of times it is displayed to users (i.e. by thousands of impressions) or by the number of times that a user clicks on the banner (i.e. click-throughs) 101. To commit the banner posting, the user clicks on button 103. Should the user make an error in entering the information, the user can click button 104 to reset the information.

Auction Information Storage

Referring to Fig. 9, the hierarchical computer file system used to store auction information on a computer disk 105 will be described. The file system stores information in files 124-127, 129. Files containing related information are grouped into folders. For example, files 129, which all contain user information, are grouped into folder 128 which is associated with user information. Folders and files containing associated information can be grouped together into parent folders. For example, Toshiba auction folder 121, Toshiba bid folder 122, Toshiba Images folder 123, and a banner file 127 for display on Toshiba TV auctions are all grouped into a single Toshiba folder 119.

Two folders 106-107 on disk 105 are used to store two different auction servers: www.massauction.com 106 and www.newyorkauction.com 107. Two different web servers run on the same computer system to present the two different web sites. The first web server retrieves auction files from the folder www.massauction.com 106 while the second web server retrieves files from the folder www.newyorkauction.com 107. To ensure that users have access to the two servers, the servers are configured so that they respond to two separate IP addresses. Alternatively, the two web server could be configured so that they respond to two separate IP ports. If a multi-hosting web server, such as the apache web server, is used to implement the auction server, one web server could be configured to have two logical servers that host the two different sites.

Alternatively, separate auction servers may be configured such that the same auction data files are used in both auction servers. In this configuration, each server contains its own unique list of users and customized data presentation format. Meanwhile, the sites benefit from a larger number of auctions presented and wider exposure of auction postings to potential buyers.

Folder 107 contains three folders 108-110 which are respectively used to group auction items into three categories: automotive 108, computers 109, and household 110. The household folder 1 10 contains four folders 1 12-115 that further group the items in the household category into four subcategories: dryers 112, microwaves 113, stereos 1 14, and TVs 115. Similarly the TV folder contains four folders 116-119 that group televisions according to their manufacturers. Thus the items are categorized using a hierarchical computer file system. These categories are used by the users to locate items of interest.

Among the information stored in the lowest Toshiba TV subcategory 119 are: auction files 124 stored in an auction folder 121, bid files 125 stored in a bid folder 122, and image files 126 depicting the items on auction stored in image folder 123. A banner file 127 is stored in the subcategory folder 119 for with auction postings for Toshiba TVs.

Additionally, a separate users folder 128 groups user files 129 containing information about the registered users. Each user file corresponds to a separate user.

Auction Server Operations

Referring to Fig. 10, the procedure for displaying the subcategory listing shown in Fig. 3 will be described. The auction server starts by drawing a standard header, at step 500. This can be performed using a standard function of commonly available web servers such as the Apache web server. The auction server then randomly selects a banner from the subcategory folder, at step 501. If no banner is available, the auction server proceeds to step 508. Otherwise if a banner is found at 502, the auction server checks whether the banner is expired, at step 503. If the banner has expired, the auction server sends a summary e-mail at step 504 to the user who posted the banner. The auction server then moves the expired banner to an archive, at step 505, and then reverts to step 501. If the banner has not expired, the auction server proceeds to step 506. The auction server prepares the HTML code required to display the banner at step

506. The HTML code associates the banner image with a hyperlink to a URL such that when a user clicks on the banner, the location is loaded on the user's web browser, and the auction server counts the number of times that the banner has been clicked upon. The location loaded on the browser also redirects the user's web browser to the location URL selected by the banner poster. The number of times that the banner is clicked upon is used to compute charges to banner posters who opt to purchase advertising based upon a per click-through change.

The auction server thus updates the banner file by incrementing the count specifying the number of times that the banner has been viewed, at step 507. The auction server then draws any items within the relevant category that have been designated as "hot", at step 508. By drawing these items higher up on the page than items that are not designated as hot, they are more prominent and therefore draw more user attention. The auction server draws any items that have not been designated as hot, at step 509. It then draws any subcategories within the category at step 510. The auction server then randomly selects a bottom banner from the subcategory folder, at step 511. If no banner is available, the auction server proceeds to step 518. Otherwise if a banner is found at step 512, the auction server checks whether the banner has expired, at step 513. If the banner has expired, the auction server sends a summary e-mail to the user who posted the banner at step 514. The auction server then moves the expired banner to an archive, at step 515, and then reverts to step 51 1. If the banner has not expired, the auction server proceeds to step 516.

The auction server prepares the HTML code required to display the bottom banner at step 516. The HTML code associates the bottom banner image with a hyperlink to a URL such that when the banner is clicked upon, the location is loaded on the user's web browser and the web browser counts the number of times that the banner has been clicked upon. The location loaded on the browser also redirects the user's web browser to a destination URL selected by the banner poster. The number of times that the banner is clicked upon is used to compute charges to banner posters who opt to purchase advertising based on a per click- through charge.

The auction server updates the banner file by incrementing the count of the number of times that the banner has been viewed, at step 517. Finally, the auction server draws a standard trailer, at step 518.

Referring to Fig. 1 1, the procedure for performing the search of Fig. 4 will be described. Upon receipt of a search request from the user interface, at step 600, the auction server examines all auction files and selects the files that meet the user's search criteria, at step 601. The selection is preferably performed using one of the commonly available search engines (e.g. Verity's text including indexing & search product) although the standard UNIX grep utility could be used instead. The auction search then checks whether any matches were found, at step 602. If no matches were found, the server displays a message informing the user that there were no matches and that the user should refine his search, at step 603. Otherwise, if at least one match were found, the auction server displays a table of matching auctions in the display format of items 13, 16 (Fig. 3), at step 604.

Referring to Fig. 12, the procedure for preparing the auction web pages of Figs 6A-H will be described. The auction server reads the file(s) associated with the auction it intends to display, at step 700. Based on the read information, the auction server determines whether or not the auction has expired at step 701. If the auction has expired, the auction server determines whether the auction file has been marked as expired at step 702. If the auction file has not been marked as expired, the auction server sends E-mail messages containing the auction results to the poster and the winner of the auction at step 703. The auction server marks the auction as expired at step 104 and then proceeds to step 705. If the auction at step 702 has already been marked as expired, the auction server proceeds to step 705 without sending mail to either the winner or the poster of the auction.

At step 705, the auction server determines whether the auction expired more than two weeks ago. If the auction expired more than two weeks ago, the auction server moves, at step 707, the auction file to an archive of past auctions, so that it is no longer accessible to users of the auction server and terminates processing of the expired auction. Otherwise, if the auction expired less than two weeks ago, the auction server displays the auction with the price and the results. The auction server then terminates the processing of the expired auction. If the auction has not expired at step 701, the auction server displays at step 708, the auctioned item and its price along with a bid form to be filled by the user. The auction server waits for user input to the bid form at step 709, and proceeds to step 710 upon receipt of the user input. The auction server displays the user input to the user at step 710. The server waits for the user to indicate whether the user would like to further edit the input at step 711. If the user would like to edit the input at step 711, the server reverts to step 708. Otherwise, the server advances to step 712 where it determines whether the user input includes a message to the poster of the auction. If the user input includes a message to the poster of the auction, the server composes an email message at step 713 and sends the message to the poster at step 714. The server then advances to step 715, where it determines whether the user input includes a bid for the displayed auction. If the user input includes a bid for the displayed auction, the server updates the bid file at step 716 and thus completes the processing of the auction item processing.

Referring to Fig. 13, the procedure for processing a new auction posting from the web page of Fig. 7 will be described. Upon receipt of a posted auction request, at step 800, the server validates the user input at step 801. The server checks the input to make sure that it make sense based on a set of rules, such as: the user ID must be greater than 3 characters long; the password must be greater than 6 characters long; numbers can only contain digits, commas, and periods; prices cannot have more than one decimal point or more than more than two characters after the decimal point; and E-mail addresses cannot have spaces and must have an "@" character at a position other than the first character. Additionally, the server checks the input to ensure that it does not contain prohibited categories of information. For example, lewd or sexually explicit information might be considered invalid inputs. If the input is invalid, the server prompts the user to reenter the invalid fields, Otherwise the server proceeds to step 802.

The server checks to see if the user needs to upload an image to the server at step 802. If the user does not need to upload an image, the server proceeds to step 805. Otherwise, the image upload screen is displayed and the file uploaded to the server at step 803. The image file is then encoded to JPEG format, if it is not either JPEF or GIF format at 804. The server then proceeds to step 805.

The server displays, at step 805, a preview of what the auction will look like to the user submitting the auction. If, at step 806, the user would like to edit the auction, the server reverts to step 800 so that the user can change his input to the server. Otherwise, if the user does not need to edit the input, the server writes the input to an auction file and sends out a confirmation E-mail to the user at 807. The server then queries the user to determine if the user would like to submit another auction at 808. If the user would like to submit another auction, the server reverts to step 800, otherwise the server proceeds to step 809.

The server prepares a summary of the payments that the user needs to make at step 809. The summary is displayed to the user in a payment screen at 810. The user enters payment parameters such as credit card numbers and billing codes on the payment screen and then submits it to the server. Upon receiving the user submission, the server checks to see if the payment was successful at step 811. For credit card payments, the payment is verified through a merchant service account approval check. If the payment is unsuccessful, the server reverts to step 809. Otherwise if the payment is successful, the server marks the posted auction as paid at step 812 and then proceeds to step 813.

The server checks, at 813, to see if it has received a confirmation response to its confirmation E-mail of step 807. If it has not then it waits at step 813 until it receives the response. Otherwise, if it has received the confirmation E-mail, the server checks to see if it has received payment for the auction at step 814. This is useful if the user is paying by a check, which may take a while to clear. If the server has not received payment the server waits at step 814 until payment is received. Otherwise the server activates the auction at step 815. The posted auction is now available for display to users. It would be obvious to one of ordinary skill to use event handlers such as interrupts instead of waiting for a response to the confirmation E-mail or polling for a received payment.

Referring to Fig. 14, the procedure for processing a banner posting of Fig. 8 will be described. Upon receipt of a posted banner request, at step 900, the server validates the user input at step 901. The server checks the input to make sure that it make sense based on a set of rules, such as: prices cannot have more than one decimal point or more than more than two characters after the decimal point. If the input is invalid, the server prompts the user to reenter the invalid fields, Otherwise the server proceeds to step 902.

The server checks to see if the user needs to upload a banner image to the server at step 902. If the user does not need to upload an image, the server proceeds to step 905. Otherwise, the image upload screen is displayed and the file uploaded to the server at step 903. The image file is then converted, if necessary, into a common format which is used to store all the images on the server at 904. For example, the image file may be converted into a JPEG file with a resolution of 486X60 pixels, as shown in step 904. The server then proceeds to step 905.

The server displays, at step 905, a preview of what the banner will look like to the user submitting the banner. If, at step 906, the user would like to edit the banner, the server reverts to step 900 so that the user can change his input to the server. Otherwise, if the user does not need to edit the input, the server writes the input to banner file and sends out a confirmation E-mail to the user at 907. The server then queries the user to determine if the user would like to submit another banner at 908. If the user would like to submit another banner, the server reverts to step 900, otherwise the server proceeds to step 909.

The server prepares a summary of the payments that the user needs to make at step 909. The summary is displayed to the user in a payment screen at 910. The user enters payment parameters such as credit card numbers and billing codes on the payment screen and then submits it to the server. Upon receiving the user submission, the server checks to see if the parameters are valid at step 911. For example, for credit card payments, the parameters may be checked against the set of rules used by the issuing authority (e.g., VISA or Mastercard) to assign credit card numbers and expiry dates. If the parameters are invalid, the server reverts to step 909. Otherwise if the parameters are valid, the server starts the processing of the payment and marks the posted banner as paid at 912. For a credit card or electronic check payment, the processing may involve electronically submitting a request for payment to a credit card company. The server then proceeds to step 913.

The server checks, at 913, to see if it has received a confirmation response to its confirmation E-mail of step 907. If it has not then it waits at step 913 until it receives the response. Otherwise, if it has received the confirmation E-mail, the server checks to see if the processing of the payment for the banner is complete at step 914. If the processing of the payment is not complete, the server waits at step 914 until payment is received. Otherwise the server activates the banner at step 915. The posted banner is now available for display to users. It would be obvious to one of ordinary skill to use event handlers such as interrupts instead of waiting for a response to the confirmation E-mail or polling for a received payment.

Referring to Fig. 15, the procedure for processing a user registration request of Fig. 5 will be described. Upon receipt of user registration information at step 1000, the web server validates the information, as previously described, at step 1001. If the information is invalid at step 1001 A, the server prompts the user to re-input the invalid information at step 100 IB. Otherwise the server sends a confirmation E-mail with an encrypted activation key to the user at step 1002. The server then writes the user information in a temporary user file at step 1003 and proceeds to step 1004 where it waits for a confirmation E-mail it previously sent. The server checks whether it has received a confirmation response at step 1004. If it has not received the response, the server checks, at 1005, whether it has been waiting for the response for greater than 2 weeks. If it has not been waiting for greater than 2 weeks, the server reverts to step 1004 and continues to wait for a response. If the server has been waiting for greater than 2 weeks, the server deletes the temporary user file.

Upon receipt of a response at step 1004, the server proceeds to step 1006 where it checks the response to determine if it is acceptable. Specifically, the server checks to determine if the correct encrypted activation key is contained in the response from the registering user. If the response is unacceptable, the server continues to wait for an acceptable response. However, if the response is acceptable, the server makes the temporary user file permanent and activates the user account. The new user now has all the privileges of a registered user.

Contents of Auction Server Files Referring to Fig. 16, an auction file 148 is used to store the information associated with an item. The contents of the auction file include identity information, such as an auction ID 130 for identifying the auctioned item, a poster ID 61 for associating the item with the user who posted it, a flag 132 which indicates whether the item was designated as a "hot" item in the "listing option input" 94 (Fig. 7), and the geographical location of the item 76. The file contains both a short description 92 and a long description 70 of the item on auction. The file also contains such auction details as the type of the auction 133, the starting bid 80, the bid increment 79 and the auction closing time 134. The auction details vary for different auction types. The auction file contains a shipment option 73 and payment options 72. The shipment option specifies whether the buyer or the seller is responsible for the cost of shipping the auctioned item to the buyer. The payment options specify the forms of payment that the buyer will accept. For example, the seller of the item in Fig. 16 will accept COD, money orders, or cashier's checks only. Finally, the auction file contains a confirmation flag 171 and a payment flag 172. These flags are set in steps 813 and 812 of Fig. 13 to indicate respectively that an E-mail confirmation and a payment have been received.

Referring to Fig. 17, the bids associated with the auction of Fig. 16 are stored in a bid file 149. The illustrated bid file contains three bids, although more bids are added to it as they are submitted by users. Each bid contains the ID of the user 61A-61C submitting the bid and the corresponding bid amount 135A-135C.

Referring to Fig. 18, submitted banner information is stored in a banner file 151. The banner file contains the banner image 152. The banner file also contains the "alt" text 156 to be displayed when the user cannot load the banner image file, and the destination URL 153 that the user should be directed to when they click on the banner. Finally, the banner file contains a count of how many times the banner has been viewed 155 and a count of how many items the banner has been clicked on, 154, along with information about which of the two statistics is to be used to determine the user's payment method 157. Finally, the banner file contains a confirmation flag 173 and a payment flag 174, which are set in steps 913 and 91 1 of Fig. 14 to indicate respectively that the banner posting has been confirmed by E-mail and that payment for the posting has been made.

Referring to Fig. 19, only registered users that have been assigned user files are allowed to participate in auctions. File 158 contains registration information for a user 39. The file contains identifying information 43, address information 49, telephone information 54, a comment section 147 and demographic information 58 that have been entered by user 39 in the web page of Fig. 5. The web server could also be configured to collect credit card information 136 for automatically processing payments. The file also contains a flag 175 which is set in step 1007 of Fig. 15 to indicate that the user registration has been confirmed by E-mail. The web server can also be configured to allow other users to comment on their past purchase transactions with user 40. For example, file 158 contains a comment 140 from a second user 139 about user 40. The second user 139 is complaining that user 40 did not deliver an item for which the second user 139 had paid. Users may use these comments to assess the trustworthiness of other users participating in the auction. To allow the auction server to delete old comments as newer comments are received, the comments include a comment date 141. Subsystems of the Auction Server

Referring to Fig. 20, the auction server 3000 is implemented as a set of computer programs written in the C programming language and compiled to produce computer executable files. The auction server is run on a computer system, preferably a UNIX server. The executable files are configured to remain resident in the virtual memory of the computer system. This increases the performance of the server by reducing the number of times the computer system accesses the disk. In a UNIX server, this performed by setting the sticky bit on the executable file.

The auction server 3000 communicates with users over the Internet 4000. The auction server has two modes of communication over the Internet. The first communication mode is performed through the web server 160. It conforms to the HTTP protocol of IP communication. The web server can receive and send information from and to users using receiving element 161 and sending element 162, respectively. Sending element 162 transmits the web pages shown in Figs. 2-8. Receiving element 161 receives responses to the web pages sent by sending element 162.

The second communication mode is performed through the E-mail element 171 and is used to ascertain the authenticity of the communication. In response to information received by the web server 160 from a user 61 A , the E-mail sender component 169 of the E-mail element 171 sends a confirmation E-mail to the E-mail address of the user 61 A and awaits a response from the user. If the user 61 A submits a false E-mail address, he does not receive the confirmation E-mail and therefore cannot respond. The E-mail processor component 169 of the E-mail element 171 processes the received E-mails. Thus the web server 160 and the E-mail element 171 together ascertain the authenticity of communications with users. The authentication of communications can be further enhanced using an encryption process such as the asymmetric key PGP encryption scheme.

The web server 160 communicates with an interfacing element 164 which, in turn, communicates with multiple auction modules 165-166. Each auction module contains the logic needed to perform a different type of auction. For example, English auction module 165 performs English auctions while clock auction module 166 performs clock auctions. The interfacing module is configured such that modules can be added and removed without altering the interfacing element or the rest of the auction server 3000. This may be effected by implementing the modules as separate dynamically linked libraries (DLLs) with the interfacing element defining the application programming interface (API) of the modules. Alternatively, the modules could be implemented as statically linked libraries that require recompiling parts of the auction server 3000 to be added or replaced. However, the C program written to implement the interface element and the rest of the auction server 3000 would not have to be changed to add or remove the auction modules. Each component of the auction server stores its data in storage 168, which is a hierarchical file storage system as shown in Fig. 9. Storage 168 is large enough that multiple auction servers can be hosted in it. Storage 168 is preferably a RAID storage system with data redundancy. The redundancy reduces the likelihood of losing stored information because of disk errors or failures.

Automatic Electronic Mail Feature

The web server 160 communicates with other components of the auction server using either ISAPI, NSAPI, apache API or CGI.

Referring to Fig. 21, the automatic E-mail processor 169 (Fig. 20) starts by moving all received E-mail messages to a staging area at step 1101. The staging area is a location for temporarily handling the E-mail messages that is free from interference by other mail programs running on the computer. The E-mail processor then selects and reads a message at step 1 102. If there is no message available at step 1 102, the E-mail processor stops at step 1 104 and waits to be restarted by the scheduling utility. If a message was successfully read at step 1103, the E-mail processor checks the message to see if the message is a confirmation of an auction posting at step 1105. If the message is a confirmation of a message posting, the E-mail processor checks whether the auction posting has been paid for at step 1 1 13. If the auction posting has been paid for, the E-mail processor activates the auction posting and resets the auction start date to the current date, at 1 114, and reverts to step 1102. If the auction posting at step 11 13 has not been paid for, the E-mail processor advances to step 1112 when the posting is marked as confirmed.

If the message at step 1105 is not a confirmation of an auction posting, the E-mail processor checks to see if the message is a confirmation of a user registration at step 1106. If the message is a confirmation of a user registration, the E-mail processor activates the user ID file and reverts to step 1102. Otherwise, if the message at step 1 106 is not a confirmation of a user registration, the E-mail processor checks whether the message is a confirmation of a banner posting at step 1108. If the message is not a confirmation of a banner posting, the E- mail processor stores the message at 1 109 in a mailbox that will be read by a human supervisor and reverts to step 1002.

If the message at step 1 108 is a confirmation of a banner posting, the E-mail processor checks to see if the posting has been paid for at step 1 110. If the banner posting has been paid for, the E-mail processor activates the banner at step 1 1 11 and reverts to step 1102. Alternatively, if the banner posting has not been paid for, the E-mail processor marks the banner file as confirmed and reverts to step 1102.

Referring to Fig. 22, the E-mail message sent to a user to confirm an auction posting comprises a header 185 and a body 184. The body 184 contains the information submitted by the user. This information is extracted from the auction file shown in Fig. 16. The header 185 contains the E-mail address 183 of the user submitting the auction. This address is used to route the message to the user. Additionally, the message contains a subject line that is used to relate the message to the relevant auction item. The subject line contains an auction file name 180. Because any response to the message will also contain the subject line, the file name and encrypted activation key 180 are used to match the responses with a corresponding auction file. Additionally, the subject line may contain certain information from the auction file. For example, the subject line of Fig. 22 contains a short description of the item 181, and an auction closing date 182. The additional information allows the user to identify the item that is referred to in the E-mail. The different items in the subject line are separated by a delimiter character (";"). This makes it easier for the auction server to extract the different pieces of information in the subject header.

Other features and embodiments are included in the following claims. For example, the auction server 3000 could be executed on multiple computers to improve its performance. For example, the web server could be run on a separate machine from the rest of the auction server elements. Multiple web servers could be used concurrently to improve overall performance.

Other embodiments may use alternate data storage techniques to speed up data access without using a database management system. These data storage techniques are part of the Minimized Data Object storage scheme devised by iSold.com. In a first data storage technique, the name of a file is used to indicate the nature of the information stored in the file. For example, information about an auction item named "19 inch TV" posted by a user named "John Q Public" in the category named "Toshiba" would be stored in a file named "Toshiba_John-Q-Public_19-Inch-TV". This file naming scheme allows the auction server to rapidly determine the contents of auction files from their filenames, instead of searching through the contents of the files.

In a second data storage technique, the auction server may build indices, such as btree or hash indices, in index files for rapidly performing the searches of Fig. 4. The index file is updated, in real time, by the software that makes changes to the data files to ensure that the index is always up to date. The auction server may employ known sorting algorithms to periodically sort the items in the index files. Thus the auction server implements an index without using a database management system. In a third data storage technique, the data files of Figs. 16-19 may be stored in binary form as a flat-file dump of the data structure used to represent the data in the memory of the computer. The data structure contains data elements, which are delimited by a "NULL" character in the flat-file dump. This data file format results in compact information storage files that can be rapidly read and written. Using these data storage techniques, data may be rapidly accessed without using a database management system. The resulting auction server is faster and more reliable than an auction server that uses a database management system for data storage.

Claims

WHAT IS CLAIMED:

1. A method performed on a server of the type used to perform sale transactions over a communication channel, the method comprising: receiving information on the communication channel, said information including addressing information for directing messages to a source of the information, the information further including communication information, generating a confirmation message directed to the source of the information, said confirmation message including identifying information for associating the confirmation message with the communication information, said identifying information being at a set position within said confirmation message, sending the confirmation message, and receiving a response to the confirmation message from the source, the response containing the identifying information at a set position within said response.

2. The method of claim 1 wherein the confirmation message is sent as an E-mail message.

3. The method of claim 2 wherein the set position of the identifying information in the confirmation message is within the subject line of the E-mail message.

4. The method of claim 1 wherein the response is sent as an E-mail message.

5. The method of claim 4 wherein the set position of the identifying information in the response is within the subject line of the E-mail message.

6. The method of claim 1 further comprising: prior to said receiving of the response, storing a flag indicating that a confirmation response has not been received, and subsequent to receiving the response, altering the flag to indicate that a confirmation response has been received.

7. The method of claim 6 further comprising storing said communication information in a first file within a computer file system.

8. The method of claim 7 wherein the file system has folders for categorizing information, the first file being categorized with related information in a first folder.

9. The method of claim 8 wherein the related information includes a file.

10. The method of claim 8 wherein the related information includes a folder.

11. The method of claim 8 wherein the first folder is categorized with additional related information in a second folder.

12. The method of claim 1 1 wherein the additional related information includes a file.

13. The method of claim 11 wherein the additional related information includes a folder.

14. The method of claim 1 further comprising, prior to said sending of the confirmation message: presenting said communication information on said communication channel, and receiving an acknowledgment of the presented communication information on the communication channel.

15. The method of claim 7 wherein the identifying information includes a name and authentication key for identifying said first file.

16. The method of claim 1 wherein the identifying information includes at least part of said communication information.

17. The method of claim 1 wherein the source is a user and the communication information includes information about the user.

18. The method of claim 1 wherein the communication information includes information about an item that is available for sale further comprising: presenting said communication the information about the item over the communication channel, and receiving an offer to purchase the item from a second source over the communication channel.

19. The method of claim 1 wherein the communication information includes advertising information further comprising: presenting the advertising information over the communication channel.

20. The method of claim 19 wherein the advertising information is a banner.

21. The method of claim 20 wherein the banner is a click-through banner.

22. The method of claim 1 wherein the communication information includes an image.

23. The method of claim 1 further comprising, prior to said receiving information on the channel: presenting a request for said information received on said communication channel.

24. The method of claim 23 wherein said request includes an HTML form.

25. The method of claim 1 wherein the communication channel is the Internet.

26. The method of claim 7 wherein said file system is mirrored.

27. The method of claim 7 wherein said mirroring is implemented using a RAID protocol.

28. The method of claim 1 further comprising: . searching through said communication information for prohibited information, and only storing said communication information if said prohibited information is not found in said communication information.

29. A system for performing sales transactions over a communication channel comprising: a storage element for storing information related to said transactions, a communication element that communicates over the communication channel, the communication element including: a sending element for sending at least part of the stored information along the channel, and a receiving element for receiving additional information along the communication channel; an interfacing element that interfaces the storage element and the communication element with a variable number of sales modules, the interfacing element being configured such that a sales module can be added without altering the system.

30. The system of claim 29 further comprising at least one sale module that performs auctions over said communication channels.

31. The system of claim 29 wherein said communication channel is the Internet and said communication element is a web server.

32. The system of claim 29 wherein said storage element is a hierarchical file system.

33. The system of claim 30 wherein the sale module performs English auctions.

34. The system of claim 30 wherein the sale module performs clock auctions.

35. The system of claim 30 wherein the sale module performs uniform-price auctions.

36. The system of claim 30 wherein the sale module performs discriminative- price auctions.

37. The system of claim 30 wherein the sale module performs first-price-sealed- bid auctions.

38. The system of claim 30 wherein the sale module performs second-price- sealed-bid auctions.

39. The system of claim 30 wherein the sale module performs posted-offer auctions.

40. The system of claim 30 wherein the sale module performs posted-bid auctions.

41. The system of claim 29 wherein at least one of the elements is implemented in software running on a computer, the software being configured such that a second similar system can be concurrently running on the computer.

42. The system of claim 41 wherein said communication channel conforms to the IP protocol and said software is configured to communicate on a different IP address from said second similar system.

43. The system of claim 41 wherein said communication channel conforms to the IP protocol and said software is configured to communicate on a different IP port from said second similar system.

44. The system of claim 29 wherein at least one of the elements is implemented in software running on a computer, the element being configured to remain resident in the virtual memory of the computer.

45. The system of claim 44 wherein said computer is a UNIX computer and said at least one of the elements and modules has the sticky bit set.

46. A server of the type used to perform sale transactions over a communication channel, the server comprising: a receiving module for receiving information on the communication channel, said information including addressing information for directing messages to a source of the information, the information further including communication information, a confirming module for generating a confirmation message directed to the source of the information, said confirmation message including identifying information for associating the confirmation message with the communication information, said identifying information being at a set position within said confirmation message, and a sending module for sending the confirmation message, wherein the receiving module is further configured to receive a response to the confirmation message from the source, the response containing the identifying information at a set position within said response.

47. A method for performing sales transactions over a communication channel comprising: storing information related to said transactions in a storage element, communicating over the communication channel, said communicating including: sending at least part of the stored information along the channel, and receiving additional information along the communication channel; interfacing the storage element and the communication channel with a variable number of sales modules, the interfacing being configured such that a sales module can be added without altering the system.