HK1065131B

HK1065131B - Use of extensible markup language in a database search system and method

Info

Publication number: HK1065131B
Application number: HK04107733.3A
Authority: HK
Inventors: Cunningham Stephan; Molinaro Anthony; Maritato Frank Jr; Zhao Peng; Conrad Nick
Original assignee: Excalibur Ip, Llc
Priority date: 2002-05-08
Filing date: 2004-10-07
Publication date: 2009-07-03

Description

Use of extensible markup language in database search systems and methods

Technical Field

The present invention relates generally to the field of database searching. More particularly, the present invention relates to the use of an extended markup language in a system and method for influencing the location of a search result list generated by a computer network search engine.

Background

U.S. patent No. 6,269,361 discloses a system and method for influencing the location of a search result list generated by a computer network search engine. In one disclosed embodiment, the disclosed system and method provide an online advertiser account management tool. Search listings associated with advertisers are stored in a database. Each search listing has associated search terms and an advertiser-specific bid amount. In response to a search query entered by a user, search listings having matching search terms are displayed in a search results list. The search listings are sorted from highest to lowest bid amount and the outstanding listings may be listed after the results list. The bid amount is a monetary amount charged to the advertiser's account when the user clicks on a search listing in a search results list.

Still according to embodiments of the patent disclosure, advertisers are provided with online verified login rights to obtain account information and to modify search listings. Examples of advertiser actions include viewing past transactions, selecting a notification option, adding money to an account of an advertiser that selects a matching option, changing a bid amount or other component of a search listing, creating or deleting a search listing, receiving a cost prediction for running a search listing for a particular time, or obtaining an activity report. The ability of advertisers to change bid listings results in dynamic ranking such that the location of search listings in the result list can be changed by increasing or decreasing the associated bid amount, or due to other search listings changing their location. U.S. Pat. No. 6,269,361 has been patented and is incorporated herein by reference in its entirety.

In this way, the disclosed system defines an online marketplace operated by a marketplace operator that provides benefits to advertisers and potential customers of the advertisers. The marketplace serves as a source of information for potential customers and a new source of customers for advertisers. The marketplace is highly competitive in that advertisers compete for potential customers by adjusting the bid amount of their search listings to affect their position in the search result list generated by the search engine in response to a customer search query. An example of such an online marketplace is operated by ovuscule systems (Overture systems) and is accessible at www.

The patented system has been very successful for advertisers searching for new customers and for potential customers trying to learn more about the advertiser's products. In fact, the patented system is so successful that many advertisers have placed large numbers of search listings in the online marketplace, and hired full-time managers to manage their search listings. Third party providers have developed tools that simplify advertiser access to search listings for online marketplaces. The scale of some advertiser participation in the marketplace has created a need for a degree of automation on behalf of advertisers in bid management.

In U.S. patent application serial No. 09/922,028, entitled "System and Method For Providing location and price protection In a Search results List Generated By a Computer network Search Engine," filed on 8/3/2001 and assigned to the assignee of the present application, the patent application serial No. 09/922,028, allows advertisers to set a maximum Cost Per Click (CPC) and/or a desired level In desired Search results. Higher level search listings are displayed to the searcher earlier in a set of search results and are assumed to be more viewed by potential customers and therefore more desirable. If this is possible and does not exceed the bid or maximum CPC, the system adjusts the CPC of the search listing to maintain the search listing at the desired level. If the listing cannot be maintained at the desired level without exceeding the bid, the system will obtain the next highest level allowed by the bid.

Further, In U.S. patent application Ser. No. 09/963,855, the title of which is "Automatic advertisement Notification for a System and Method for providing location and Price Protection In a Search Result List Generated by a Computer Network Search Engine," automated agent is provided that monitors Advertiser-specific conditions on behalf of advertisers, filed on 26.9.2001 and assigned to the assignee of the present application. If any condition is reached or becomes true, a message is sent to the advertiser and some means of correcting the advertiser for the undesirable condition. For example, if the agent determines that the rank of the search listing has fallen below a threshold level, an E-mail message will be sent to the advertiser along with an option to reply to the system with the E-mail message indicating how the rank condition should be corrected.

While these features provide improved convenience to advertisers seeking to manage search listings, they have been limited to success in assisting advertisers who have a large number of search listings to manage, or to third parties who seek to advertise search listings for multiple advertisers. Accordingly, there is a need for improved systems and methods for influencing the location of search result lists generated by computer network search engines.

Disclosure of Invention

By way of introduction only, one present embodiment provides a database search apparatus and method for generating a search result list in response to a client's extensible markup language (XML) request. XML is a flexible way to create common information formats and to share structural models and data over local or distributed networks such as the internet, intranets, and other networks. XML is a formal standard of the world Wide Web consortium (recemmation) and is similar to hypertext markup language (HTML) used in previous web pages. XML is a meta-grammar used to design a syntax that allows data to be constructed. Both XML and HTML are languages that use markup symbols to describe the content of a page or document. However, HTML only describes the content of a web page in terms of how it is displayed and how it interacts with. XML describes content according to what data is displayed and how it relates to other data structures of the model. Both HTML and XML use tags and attributes, where tags are words separated by < >. HTML specifies a limited set of tags and the meaning and use of each tag, i.e. what each tag and attribute means. XML uses tags, but XML is extensible because, unlike HTML, XML's tags are unlimited and custom.

Another current embodiment provides a bid management tool that operates with a client computer to manage search listings and account information for one or more advertisers. The bid management tool is preferably a desktop application that reports and manages paid listings on a server of the online marketplace. The client computer communicates with the server through an XML-based application program interface. The bid management tool provides functionality for reporting account behavior, modifying accounts, manual, timed, or event driven changes to search listings.

The foregoing discussion of the preferred embodiments has been presented for purposes of illustration only. Nothing in this section should be taken as a limitation on the claims. Only the claims define the scope of the invention.

Drawings

FIG. 1 is a block diagram illustrating the relationship between a large network and the systems and methods for generating payment-location search results;

FIG. 2 illustrates functional components of a bid management tool that may operate with a client computer of the system of FIG. 1;

FIG. 3 is a diagram of data for an account record used with one embodiment of the present systems and methods; and

FIG. 4 illustrates an example of a search result list generated by one embodiment of the present systems and methods.

Detailed Description

Referring now to the drawings, FIG. 1 is an example of a distributed system 10 configured as a client/server architecture used in one embodiment of the present invention. A client is a member of a class or group that uses the services of another class or group to which it is not related. In a computer network environment, such as the internet, a client is a process, such as a program or job, that requests a service provided by another process, referred to as a server program. The client process uses the requested service without needing to know any working details about the other server program or the server itself. In network systems, client processes often run on computers that access shared network resources provided by other computers running corresponding server processes. It should be noted, however, that it is possible for the client process and the server process to run on the same computer.

A server is typically a remote computer system that is accessed over a communications medium such as the internet. The client process may be running in a second computer system and communicating with the server process over a communications medium that allows multiple clients to take advantage of the information gathering capabilities of the server. In this way, the server centrally acts as an information provider for the computer network.

Thus, the block diagram of FIG. 1 shows a distributed system 10 that includes a plurality of client computers 12, a plurality of advertiser web servers 14, an account management server 22, and a search engine web server 24, all of which are connected to a network 20. The network 20 will be referred to below generally as the internet. Although the system and method of the present invention is particularly well suited for use with the Internet, it should be understood that client computers 12, advertiser web servers 14, account management server 22, and search engine web server 24 may be connected together via one or more of a variety of different types of networks. Such networks include Local Area Networks (LANs), other Wide Area Networks (WANs), and regional networks accessed over telephone lines, such as commercial information services. The client and server processes may even comprise different programs executing simultaneously on a single computer.

The client computer 12 may be a conventional Personal Computer (PC), a workstation, or any other size computer system. Each client 12 typically includes one or more processors, memory, input/output devices, and a network interface, such as a conventional modem or network interface card. Advertiser web servers 14, account management server 22, and search engine web server 24 may be similarly configured. However, each of advertiser web server 14, account management server 22, and search engine web server 24 may include many computers connected by separate private networks. In practice, the network 20 may include hundreds or thousands of individual computer networks.

The client computer 12 may execute a web browser program 16, such as a Netscape Navigator, Microsoft Internet Explorer, or Mosaic browser program, to locate a web page or record 30 stored on the advertiser server 14. The browser program 16 allows the user to enter the address of the particular web page 30 to be retrieved. These addresses are called universal resource locators, or URLs. In addition, once a page is retrieved, the browser program 16 can provide access to other pages or records when the user clicks on hyperlinks to other web pages. Such hyperlinks are located in the web pages 30 and provide an automated way for the user to enter the URL of another page and retrieve that page. These pages may be data records including full text information content or more complex digitally encoded multimedia content such as software programs, graphics, audio signals, video, and the like.

The client computer 12 of the illustrated embodiment includes a bid management tool 100. The operation of the bid management tool 100 will be described in detail below in conjunction with FIG. 2.

According to one embodiment, each client computer 12 implements an XML interface 15. The XML interface 15 comprises program code for communicating with a complementary XML interface 17 of the account management server 22, which is established under an established XML schema (schema) understandable between the user of the client software and the operator of the online marketplace. Examples of such modes are the appended appendix C and D, but it should be understood that these modes are only examples and are not limiting of the modes available to the invention. The account management server 22 stores information about the account of each advertiser, as described below. The client computer 12 may access and update this information using the XML interface 15 and the XML interface 17 of the account management server 22. The client computer may be operated by an advertiser who manages advertiser search listings. Alternatively, the client computer may be operated by a third party that manages search listings for one or more advertisers. In this embodiment, the client computer 12 interacts with the account management server 22 not using a browser program, but rather using an XML interface 15. The person operating the client computer 12 may activate the browser program, but the actual communication of data is controlled by the XML interface 15.

As shown in FIG. 1, in one embodiment of the present invention, the client computers 12 communicate with various network information providers, including an account management server 22, a search engine server 24, and an advertiser server 14, over a network 20 using functionality provided by the Hypertext transfer protocol (HTTP), although other communication protocols, such as FTP, SNMP, TELNET, and many others known in the art, may also be used. Preferably, the search engine server 24, account management server 22, and advertiser servers 14 are located on or accessible through the Internet.

As noted above, in embodiments of the present system and method, at least two types of servers are contemplated. The first server contemplated is the account management server 22. The server 22 includes a computer storage medium 32 and a processing system 34. The server 22 also includes various software program code including an XML interface 17. These program codes are stored in one or more computer-readable program storage media of server 22, such as storage media 22.

A database 38 is also stored on the storage medium 32 of the account management server 22. The database 38 contains advertiser account information. The account information stored in database 38 includes information regarding the search listings of each advertiser participating in the online marketplace established by distributed system 10. This information includes search terms, bid amount, search listing description and title, and associated URLs and other information, as will be discussed in more detail below. Further, the account information includes information resulting from operation of the marketplace system, such as a current rank and current bid for each search listing, a number of clicks recorded for the search listing, a calculated click-through rate (CTR), and an advertiser's account balance.

As will be appreciated from the description below, the disclosed systems and methods may be implemented in one or more software programs stored as executable instructions on a computer storage medium, such as a memory or mass storage device of the account management server 22. An XML interface 15 or a conventional browser program 16 running on the client computer 12 may be used to access the advertiser account information stored on the account management server 22. Preferably, access to the account management server 22 is accomplished through a firewall (not shown) that protects the account management and search result placement programs and account information from external tampering. Additional security may be provided by enhanced standard communication protocols, such as secure HTTP or a secure sockets layer.

The second server type contemplated is a search engine web server 24. The search engine program allows: upon navigating through their browser program 16 to the search engine web server URLs or sites of other web servers capable of submitting queries to the search engine web server 24, the network user is enabled to type keyword queries to identify pages of interest among the millions of pages available on the internet. In a preferred embodiment of the present invention, the search engine web server 24 generates a search result list that includes, at least in part, the relevant entries obtained from and formatted by the results of the bidding process conducted by the account management server 22. The search engine web server 24 generates a list of hypertext links to documents that include information about the search terms entered by the user at the client computer 12. The search engine web server 24 sends the list in the form of a web page to the network user where it is displayed on the browser 16 running on the client computer 12. An exemplary embodiment of the search engine web server 24 may be found by navigating to a web page located at the URL http:// www.

The search engine web server 24 is connected to the internet 20. In one embodiment, the search engine web server 24 includes a search database 40 that includes search listing records for generating search results in response to user queries. Also, the search engine web server 24 may be connected to the account management server 22. The account management server 22 may also be connected to the internet 20. The search engine web server 24 and account management server 22 of the present invention address the different information needs of the user at the client computer 12.

For example, one class of users located at client computers 12 may be network information providers, such as advertiser web site promoters or owners, having advertiser web pages 30 located at advertiser web servers 14. These advertising web site promoters or advertisers may want to access account information placed in the memory 32 of the account management server 22. An advertising web site promoter may participate in a competitive bidding process with other advertisers through an account placed on the account management server 22. Advertisers can bid on any number of search terms related to the content of the advertiser's web site. In one embodiment of the present invention, the relevance of the bid-upon search term to the advertiser's web site is determined by a manual editing process prior to insertion of the search listing into the database 40, wherein the search listing contains the search term and the advertiser's web site URL.

In an alternative embodiment of the present invention, the relevance of a bidded search term in a search listing to a corresponding web site may be evaluated using a computer program executed at processor 34 of account management server 22, wherein the computer program will evaluate the search term and corresponding web site according to a set of predefined editorial rules.

Higher bids result in more favorable placement on the search result list page generated by the search engine 24 when performing a search bid on a search term by an advertiser. Typically, bids for search terms are given by advertisers in conjunction with the economic value given by the search term based on the occurrence of an agreed upon event. For example, in impression mode payment, an advertiser considers economic value to have been achieved when the advertiser's search listing is presented in search results sent to a searcher, regardless of whether the searcher clicked on the search listing. In another mode, the advertiser considers the economic value to have been achieved when the searcher sees the advertiser's listing, clicks on the listing, and then takes further action, such as registering at the advertiser's web address or providing a credit card number, etc. The economic value may be in any convenient and mutually agreed upon form, such as deducting a monetary amount from an account, adding or subtracting points or other chips from an advertiser's log or account, etc.

In one embodiment, the amount bid by an advertiser includes a monetary amount that is deducted from the account of the advertiser each time the advertiser's web site is accessed or clicked through a hyperlink on a search result list page. The searcher clicks on the hyperlink using a computer input device to initiate a retrieval request to retrieve information associated with the advertiser's hyperlink. Preferably, each access or click on a search result list hyperlink will be redirected to the search engine web server 24 to associate the click to the advertiser's account identifier. This redirection behavior, which is not apparent to the searcher, will access account identification information encoded into the search results page prior to accessing the advertiser's URL using the search results list hyperlink clicked on by the searcher. The account identification information is recorded in the advertiser's account as a search request event along with information from the search request. Since the information obtained by this mechanism ultimately matches the account identifier to the URL in a manner that is not possible using conventional server system logs known in the art, accurate account billing records can be maintained. More preferably, the advertiser's web site description and hyperlink on the search result list page is accompanied by an indication that the advertiser's listing is a paid listing. More preferably, each paid listing displays pricing information to the advertiser in an amount corresponding to the price per click paid by the advertiser for each visit to the advertiser's site through the search result list.

A second category of users of client computers 12 may include searchers searching the web for particular information. These searchers may access a search engine web page 36 located at the web server 24 through their browser 16. Alternatively, the communication may be via an XML interface of the client computer. The search engine web page 36 includes a query box in which a searcher may enter search terms that include one or more keywords. Alternatively, the searcher may query the search engine web server 24 through a query box hyperlinked to the search engine web server 24 and located on a web page stored on a remote web server. When the searcher has finished entering the search term, the searcher may send the query to the search engine web server 24 by clicking on a provided hyperlink. The search engine web server 24 will then generate a search result list page and send the page to the searcher at the client computer.

The searcher may click on the hypertext links associated with each listing on the search results page to access the corresponding web page. The hypertext link may access any web page on the internet and include a paid listing of advertiser web pages 18 located on advertiser web servers 14. In a preferred embodiment of the present invention, the search result list also includes unpaid listings that are not placed as search results for advertiser bids and are generated by conventional Internet search engines, such as the INKTOMI, LYCOS, or YAHOO! A search engine. The outstanding hypertext links may also include links manually indexed by the editorial team to the database 40. More preferably, the unpaid listings are placed after the paid advertiser listings on the search results page.

FIG. 2 illustrates functional components of the bid management tool 100 that may operate with the client computer 12 of the system of FIG. 1. The bid management tool 100 in the illustrated embodiment includes a plurality of menus 102, a setup function 104, a report function 106, a search listing management function 108, and a help function 110.

The bid management tool 100 cooperates with the XML interface 15 (FIG. 1) to report and manage paid search listings in the online marketplace established by the distributed system 10 described above in connection with FIG. 1. The bid management tool 100 is a client application that communicates with servers such as the account management server 22 and the search engine web server 24 (FIG. 1) through the XML interface 15 of the client computer 12. The bid management tool 100 provides functionality to report account activity, modify accounts, manual, timed, or event driven changes to search listings. The bid management tool 100 is capable of managing search listings for an advertiser or multiple advertisers. Although conventional nomenclature is applied herein, the bid management tool 100 may be used to manage all aspects of the accounts of one or more advertisers of the online marketplace.

Using XML communications between the client computer and the server, the bid management tool 100 establishes a downlink from the server to the client and an uplink from the client to the server. The downlink carries information about the current market status and the customer account. The market state includes a set of search listings. In one embodiment, each listing includes the advertiser's current rank, current bid, title, description, and URL for the relevant search term in all search listings. Other information, such as a desired level or maximum cost per click, may also be conveyed. The customer account information includes, for example, the number of clicks recently billed to the advertiser and the account balance. Other customer account information, such as click-through rates (CTRs) for certain specified periods, may also be delivered. The uplink communicates client requests, such as bid change requests or add one or more new search listing requests to the advertiser's account for a particular search term.

The bid management tool 100 may be configured to operate on a regular schedule. For example, the bid management tool 100 can poll the remote account management server periodically, such as once every five minutes. In another example, the tool 100 allows bid updates to be automatically made on a predetermined schedule, such as hourly. The user of the client computer is also able to initiate manual bid updates.

The bid management tool 100 allows a user to define groups of search terms. Such items may be grouped according to any rule that may be established by a user. The set of search terms may relate to a particular product or service, may relate to a particular advertiser if bids for more than one advertiser are being managed, or may relate to any other convenient market parameter. The tool 100 also allows a user to generate reports that define groups and to plan automatic updates of all items in a group. The automatic update may adjust the current bid amount, the current desired level, or any other search listing parameter. A single instance of the tool 100 may allow a user to manage multiple advertisers, accounts, and listings. Each advertiser may have multiple accounts and each account typically supports multiple listings.

The bid management tool 100 may be implemented in any manner suitable for a given client computer. In one embodiment, the bid management tool 100 includes one or more computer readable program codes stored in a storage device, such as a hard disk or memory of the client computer 12. The client computer includes a processor and a communication interface. The processor operates in conjunction with the bid management tool program code to perform the functions described herein. In a preferred embodiment, the bid management tool 100 is an application that may be installed under a personal computer or other processing device operating under one or more versions of the Microsoft Windows operating system. Preferably, tool 100 has an automatic update function that can initiate a communication session with the web site to determine if a new version of the application can be downloaded. If so, the user may be prompted to initiate an autorun download and update process.

In FIG. 2, the bid management tool 100 includes a menu 102 that allows a user to interact with the bid management tool 100. Preferably, in a client computer running under the Windows operating system, the menu 102 conforms to the Windows menu conventions and functions to simplify the user's operation. However, the menu 102 may be customized to a particular application of the bid management tool 100. In another operating system, other menu systems may be substituted.

Menu 102 provides an interface for data entry and option selection to the user. A menu may be accessed to define advertiser accounts or search terms to be managed. Another menu may be accessed to specify the report format. Yet another menu may be accessed to initiate an operation. Other types of menus may also be provided. The menu interacts with other data and applications stored on or accessible from the client computer, such as the XML interface 15 (FIG. 1).

Each menu includes the correct fields or pop-up submenus of the type well known in the art to receive and record the input data provided by the user. Data may be entered or entered into a designated field or selected from options provided in a pop-up sub-menu. In addition, the menu may provide an option that allows the user to simply specify all accounts for a particular advertiser. If the information is not stored locally, the bid management tool 100 may initiate a request to the account management server to obtain account identification information for the specified advertiser. For example, the bid management tool 100 may communicate the advertiser's identification information to an XML interface of the client computer. The XML interface initiates and transmits a properly formatted request to the account management server. Next, the XML interface receives and stores the response and passes the request data to the bid management tool 100.

Setup functions 104 of bid management tool 100 provide functionality to initiate and modify the operation of bid management tool 100. This includes, for example, defining advertisers and their associated accounts to be monitored by receiving a text identifier of the advertiser from a user and determining an account number of the advertiser or receiving and storing a plurality of search terms to be monitored.

The setup function 104 also allows for the definition of search terms and groups of advertisers, which may be associated in any convenient manner. A group is a user-defined set of search listings. A single group can include listings from multiple accounts and advertisers. The list may be displayed in more than one group. In one embodiment, all group definitions are stored locally in the client computer. In another embodiment, the group definition may be stored in whole or in part remotely, such as an account management server of an online marketplace. From the account management server's perspective, a group transaction will include a set of operations to search listings individually. The group content and parameters may be specified using one or more menus 102 or established by importing text files from elsewhere into the bid management tool 100.

Setup function 104 also allows for the specification of polling operations to be implemented in bid management tool 100. Examples include time-based polling according to a predetermined schedule or polling period and event-driven polling in response to the occurrence of certain specific events. One or more menus 104 are typically used to obtain the setting information that is used as an input to the setting function 104. The setting information may also be obtained from the memory of the client computer or by accessing the account management server 24 using the XML interface of the client computer (fig. 1). Preferably, a password or similar information is required to access the account information for each advertiser.

Also, as noted above, the setup function 104 includes an automatic update function. This may be ignored or disabled for the benefit of the customer.

The bid management tool 100 also includes a reporting function 106. The reporting function 106 uses the relevant advertisers, accounts, and listings being managed by the bid management tool 100 to prepare reports. Exemplary report formats include a list format in which raw data is presented and in a graphical format, the raw report data is processed to provide a more clearly understood description of market status and customer account information. The menu 102 may control the appearance and generation of reports.

In one embodiment, the reporting function 106 also allows viewing of data logs maintained by the bid management tool 100. Entries are added to the log file each time a bid change is requested manually by a user or as planned by the bid management tool 100. The log file is stored in the client computer or any other convenient location. The log entry will describe: or an exception, such as a failure to connect to the server or authentication failure; or details of a successful bid change including advertiser, account, term, old bid, old level, new bid, and new level. While other information may be logged. The reporting function 106 allows viewing of log data and interpretation and presentation of reports of log data.

The bid management tool 100 also includes a search listing management function 108. This function 108 implements the primary function of the bid management tool 100, the management of search listings, and in particular, changing bids. In another embodiment, the search listing management function 108 also controls other transactions, such as adding and deleting listings.

The search listing management function 108 performs manual and automatic bid changes. The manual change is specified by the user. Manual changes are requested by specifying listings, accounts, and advertisers, as well as new bid amounts or other search listing parameters to be changed. This information may be entered using menu 102. The search listing management function 108 responds to the manual change by interacting with the XML interface 15 and then initiating a request to the account management server 22. After the change is made, an acknowledgement is communicated from the server to the client. The confirmation is received by the XML interface 15, logged and may provide an indication to the user.

Through the automatic bid change process, the search listing management function 108 updates the specified parameters of the specified search listings for the specified advertiser. Any designation of an automatic bidding process may be established using menu 102. Any of the parameters of the search listing may be changed, including the bid amount, the desired level, the title of the search listing, etc. If group content has already been defined, the search listing to be changed may be specified by specifying a group identifier. A time or event of initiating a bid change operation may be specified to control the automatic bid change process.

Each application of the bid change function includes the following operations:

1. waking up (starting) at a scheduled time (e.g., once an hour).

2. To see if a local copy of the market state information is current.

3. If the local copy is expired, the local copy is updated.

4. The market state will be compared to the specified rules to identify the necessary changes.

5. The changes are sent to the server and success or failure is logged.

Alternatively, the user may specify a time of day and day of week preference, where the advertiser is willing to pay more per click, for example, at a time of day or a day of week. Automatic bid change functionality may be arranged to automatically implement these preferences.

The bid management tool 100 also includes a help function 110. The help function 110 provides convenient available online access to the reference information, which may be desired by the user of the bid management tool 100. Examples of information that may be provided include frequently asked question and answer (FAQ) lists, help topic indexes, search functions for searching for information provided by the help functions, and related routines providing revisions and other information about the bid management tool 100.

In one embodiment, the presently disclosed system is embodied as a computer-readable storage medium, such as a CD-ROM, hard drive, memory, or other storage device. The storage medium includes first program code implementing a bid management tool for managing search listings on an account management server of an online marketplace; and second program code implementing an extensible markup language (XML) interface for communicating with a complementary XML interface of the online marketplace. The program code may be source code, object code, or code in any other format. The bid management tool is preferably as described herein, but various features may be included or omitted and still provide equivalent functionality. The functions on the account management server to manage the search listings include one or more of: retrieving the search listing; retrieving a market state; retrieving a set of account identifiers for one or more advertisers; modifying bid amounts or other parameters of one or more search listings; adding one or more search listings associated with an advertiser; and deleting one or more search listings associated with the advertiser.

As noted, the client computer and the account management server in the illustrated embodiment communicate according to an interface 17 using XML. This interface 17 supports the desktop application of the client computer and automated tools for managing accounts having an online marketplace of the type described herein. Interface 17 provides a common secure external interface at account management server 22 (fig. 1) for interacting with the advertiser systems of server 22. The XML interface 17 of the server 22 and the XML interface 15 of the client computer are complementary to provide reliable two-way communication of requests from the client to the server and responses from the server to the client.

The design and implementation of such an interface 17 relies on some assumptions. The interface 17 is a web page provided by the operator of the online marketplace. A request to interface 17 will be "committed" (post) to interface 17 with the HTTPS protocol. The client and server send commands and replies using XML and UTF-8 character encoding. All communications conform to the XML specification defined by http:// www.w3e.org/XML/for example. All applications should use an XML parser that allows a variable number of blanks, element and attribute names and values. All parties avoid attempting to manually extract data from an XML document by using a schema that requires a particular field name or the like. All requests sent to the server are validated by the formal request mode. All responses from the server are validated by the formal response mode. Any requests to the account management server that do not comply with the request pattern are immediately denied.

The examples provided herein relate to direct Service Center (DirecTraffic Center) advertiser devices offered by the ovuscule services (Overture Service) corporation. Those of ordinary skill in the art can readily modify and extend these examples for application to other systems and other service providers.

Submit to the account management server

The interface 17 defines a number of HTTP headers and parameters that are necessary when a response from the account management server 22 is desired. All POST requests to the server require a title for the content type. In one embodiment, the header has a value of "application/x-www-form-url encoded". And the content length header should be specified and reflect the number of bytes sent to the server. More information is available in the HTTP 1.1 specification at ftp:// ftp. isi. edu/in-nos/rfc2616. txt. Listed below are other parameters for submission to the account management server 22 and profiles for each of them. xml (x ml)

As necessary. The parameter contains an XML document to be sent to the account management server. If the transmitted content type header is "application/x-www-form-URL," the value of this parameter must be URL-encoded.

/go2/xml/XMLRequestHandler.submit

_D:/go2/xml/XMLRequestHandler.submit

As necessary. In this embodiment, the application server uses these parameters internally. The value specified for each parameter should be "" blank.

contentType

And (4) optional. The value of this parameter may be "text/plane" or "text/html" (default).

POST example:

POST/s/dtc/xml/index.jhtml？_DARGS＝％2Fs％2Fdtc％2Fxml％2Findex.jhtml

HTTP/1.0

Content-Length：404

Content-Type：application/x-www-form-urlencoded

xml＝％3c％3fxml+version％3d％221.0％22+encoding％3d％22UTF-

g％22％3f％3e％3cDTCRequest++xmlns％3axsi％3d％22http％3a％2f％2fwww.w3.or

g％2f2001％2fXMLSchema-

instance％22++version％3d％221.0％22++usemame％3d％22gototest％22++password

％3d％22qblahblaht％22％3e++％3cActions％3e++++％3cGetAccountIds％2f％3e++

％3c％2fActions％3e％3c％2fDTCRequest％3e&_D:/go2/xml/XMLRequestHandler.s

ubmit＝+&/go2/xml/XMLRequestHandler.submit＝&contentType＝text％2fplain

sequence of operations

Generally, no particular order is required for commands that need to be submitted to the XML server. The server processes the requests in the order in which they were received. However, the client of the XML server may want to follow a logical order.

The client computer retrieves the set of account identifiers to work before any listings can be retrieved or bid price adjusted. In one embodiment, the server provides a market and account identifier that the account is valid for.

Once the client computer has a list of workable account identifiers, the client computer may retrieve a set of listings for the account. This would provide the important listingId attribute that is necessary for SetListing transactions. The listingId is static (i.e., it does not change), so that the same listingId can be used forever to talk to a particular listing. If the manifest is deleted and its listingId is used, an error is returned. This function also provides the searchTerm attribute, which is necessary to use the market status function.

Once the client computer has the listing and the search terms, the client computer may obtain the current market status for the listing of interest. This function provides a set of search listings in the order in which they will be presented to the searcher to receive the search results in response to a search query to the search engine web server 24 (FIG. 1). The search listings group includes listings that do not belong to the current advertiser. The server specifies the current advertiser owned inventory by providing the listingId.

Based on the market status, the client computer may set a bid price for each listing. One embodiment allows only one-time fixed bid price change requests for listings. Other embodiments allow changes to be made to more than just the attributes and parameters of a search listing.

Authentication

In the illustrated embodiment, the initial bits of information that must be provided for each request are the version string, login username, and password. This information must be provided in the root level dtcrrequest XML tag sent by the client. All commands sent to the server should be contained in this root level tag. If any information in the root tag is lost or incorrect, the request will be denied and all commands contained therein will be ignored.

For example:

<！--queries and commands go here...-->

</DTCRequest>

the version is a string describing the version of the XML interface 17. If it does not conform to the version being used by the account management server 22, an error will be sent and all commands contained in the DTCRequest will be ignored.

The username corresponds to an existing username. The password should be the same password that the user will use to log into the account management server. If the username or password is not provided or is incorrect, the response will be sent immediately and all commands contained in the DTCRequest will be ignored. The response may have the following form:

in embodiments where administrator privileges are given, if the username and password provided belong to an administrator, the administrator has the ability to perform the following actions for any user account.

If the login and version validation process is successful, a success response will be sent and all the included commands will execute:

<！--processed command responses here-->

</DTCResponse>

retrieving account ID groups

It is possible that the user does not know the set of account IDs needed for future commands. This function allows list queries. The administrator will need to provide a username for which to retrieve the account ID.

For example:

</Actions>

normally, a non-administrator user will not provide a username because the server will get it from the DTCRequest tag.

</Actions>

If a non-administrator user specifies dtcUsername, it will be rejected by the error code "PermissionDenified".

The response to the above request appears to be such:

</GetAccountIdsResponse>

</ActionsResponse>

the market field is an enumeration that indicates the market for the account setting.

Search listing

To change the nature of the list, the user must first make a query to retrieve the list. Any requests for manifests are contained in Actions XML tags. Actions tags contain the accountId, which all contained queries and commands apply. The accountId is verified for normal users (normal users) as belonging to an allowed list of accountIds. The administrator may work on any accountId group.

It is possible to grab (gram) a list set based on a specific criteria or, if no criteria are specified, all lists for the specified accountId. If the maxCount attribute is not specified as 40, the maximum number of manifests is returned. If no initial index is specified, the result starts with 1. The function does not return the current level by default for each manifest. To get this information, the attribute withRank is specified as a "true" value.

Example (c):

1. get all lists with accountId 12345 (up to max)

</Actions>

2. Get all lists with the maximum 10 containing "car" in the search term with accountId of 12345

</Actions>

3. Obtaining all the maximum list allowed with current level information and bid price between 0.05 and 0.10

</Actions>

Other search validity criteria include:

Url

title (Title)

Description (Description)

If the supplied string "is contained" is located in this field of the search listing, the search criteria are not matched based on bid price. Search criteria based on bid price will select a listing: "great than or equal to" the price specified in the lowBid attribute; and "less than or equal to" the price specified in the highBid attribute.

Upon successful completion, a response similar to the following will be returned:

</GetListingsResponse>

</ActionsResponse>

when changing the characteristics of listingId to with SetListing request, listingId should be used to refer to a particular line ad (described below).

Obtaining market state

The getmarkstate function is designed to give a snapshot of the current state for a particular search term. This helps in viewing the price difference between the different levels so that people can change their bids accordingly. This function takes the market identifier (required) and the search term identifier (required) and returns the market status as reported by the ovuill (oventune) consumer site. For example,

1. i are shown a current listing of US market grades 1-5 and a search term of "cars".

The response may look as follows:

<Listing rank＝“1”title＝“InvoiceDealers.com-Buy New Cars Direct”

description＝“Quick，easy，painless...It&apos；s new car buying made easy at

InvoiceDealers.com！Get new car pricing before you isit the dealer at

InvoiceDealers.com.”siteHost＝“www.invoicedealers.com”bid＝“0.43”

currency＝“USD”/>

<Listing rank＝“2”title＝“AutoMall Online-Instant Online Prices”

description＝“Since 1994！The smartest way to buy a car.Online instant dealer price

quotes with registration.Guaranteed lowest prices on the Internet.Over5,000quality

dealers.”siteHost＝“www.automallonline.com”bid＝“0.42”currency＝“USD”/>

<Listing rank＝“3”title＝“Extended Warranty for New or Used Cars”

description＝“Get extended car warranty coverage for up to seven years of 150,000

miles.Save up to 60％off dealer prices.Click here for a free quote from the No.1

online provider.”siteHost＝“www.warrantygold.com”bid＝“0.38”currency＝“USD”/>

<Listing rank＝“4”title＝“New Car-Get Lowest Dealer Price Fast”

description＝“Ready to buyGet multiple price quotes on a new car from local and

online dealers fast.Submit simple，no-obligation forms powered by the leading

automobile sites.Compare for best deal.”siteHost＝“www.pricequotes.com”

bid＝“0.37”currency＝“USD”/>

<Listing rank＝“5”title＝“Lexus.com-Official Site”description＝“Explore the

models，build your Lexus，search for a certified pre-owned Lexus，or find a dealer.”

siteHost＝“mojofarm.mediaplex.com”bid＝“0.36”currency＝”USD”/>

</GetMarketStateResponse>

setting bid price for listing

In one embodiment, the XML interface allows only one-time fixed bid price changes for a particular listing. Other embodiments allow for changes to other fields, other bidding behavior, etc.

To change the bid price, the user provides an Actions tag and an account number containing the list to be changed. The accountId attribute verifies the username and password provided in the previous step. In the SetListing tag, listingId provided in the GetListings response is specified. The next required element is a BidBehavior element followed by a "Fixed" element, which requires the bid to be specified as an attribute.

For example,

</BidBehavior>

</SetListing>

</Actions>

in one embodiment, referred to as Bid to Premium, the user can specify that the search listings are always displayed in the first three search listings as the search results are presented. If such a change is desired, a "B2P" element is provided instead of a "Fixed" element. For the "B2P" element, the desired level and maxCap (the maximum amount the advertiser is willing to pay to achieve the desired level) are necessary. For example:

</BidBehvior>

</SetListing>

</Actions>

upon successful completion, a response like the following will be returned:

</ActionsResponse>

if not, the system provides a sentence describing the failure:

<SetListingResponse listingId＝“a123b455”success＝“false”reason＝“Bid

must be in the format#.##”/>

</ActionsResponse>

appendix A, attached hereto, provides an exemplary set of requests that can be registered by a user to an account management server. Similarly, appendix B, which follows, provides an exemplary set of responses that may be returned from the server to the client in response to a request to register. Appendix C provides an exemplary XML schema for requests submitted by clients to the server. Appendix D is an exemplary XML schema for server-to-client responses. Each of these appendices is intended to be illustrative only and not limiting as to the scope of the invention.

FIG. 3 is a chart showing the type of information contained in each advertiser account record 300 in search database 40 (FIG. 1). The database 40 includes search listing records that are used to generate search results in response to user queries. First, advertiser account record 300 contains a username 302 and password 304 for online verification as described above. The account record also contains contact information 310, such as contact name, company name, street address, phone, e-mail address.

Preferably, the contact information 310 is used to direct communications to the advertiser when the advertiser requests notification of a key advertiser event. The account record 300 also contains billing information 320, such as current balance, credit card information. Billing information 320 contains data that is accessible when the advertiser selects an option to add an amount to the advertiser's account. In addition, certain billing information, such as the current balance, may trigger events that need to be notified under the notification option. The audit tail section 325 of the account record 300 contains a list of all events accessed by the account record 300. Each time an account record 300 is accessed or modified by an administrator or advertiser, a brief entry describing the account access and/or modification event will be appended to the audit trail section 330 of the administrator or advertiser account initiating the event. The audit trail information may then be used to help generate a history of transactions made by account owners under the account.

The advertising information section 330 contains information needed to implement the online bidding process for the online marketplace, wherein the location of web site descriptions and hyperlinks in the search result list generated by the search engine are determined. The advertisement data 330 for each user account 300 may be organized into zero or more sub-accounts 340. Each sub-account 340 includes at least one search listing 340. Each search listing corresponds to a bid on a search term. The advertiser may use the sub-account to organize multiple bids on multiple search terms or to organize bids for multiple web sites. The sub-accounts are also particularly useful to advertisers for tracking performance of targeted market segments. The sub-account superstructure is introduced for advertisers to organize their advertising efforts without affecting the method of operation of the disclosed systems and methods. Alternatively, the advertising information portion need not include an increased organizational layer of sub-accounts, but may simply include one or more search listings.

The search listing 344 corresponds to search terms and associated bids and contains key information to implement an online competitive bidding process. In one embodiment, each search listing includes the following information: search term 352, web site description 354, URL 356, bid amount 358, and title 360. The search term 352 includes one or more keywords, which may be common words in English or any other language. Each keyword in turn comprises a string of characters. Search terms are the target of a competitive online bidding process. Advertisers select search terms to bid on the advertiser's web site content. Ideally, an advertiser would select search terms that target what is being input by the searcher to find information on the advertiser's web site, although fewer general search terms may be selected to ensure full coverage of the bid-on related search terms.

The web site description 354 is a short textual description of the content of the advertiser's web site. The description 354 may be displayed as part of an advertiser's entry in a search result list. The search listing 344 may also contain a title 360 of the web site, which may be displayed in the search result list as a hyperlink title to an entry for the advertiser. URL 356 contains the universal resource locator address of the advertiser's web site. When a user clicks on a hyperlink provided in an advertiser's search result list entry, the URL is provided to the browser program. The browser program in turn visits the advertiser's web site by redirecting the browser to the web site specified by the URL. The URL may also be displayed as part of the advertiser's entry in the search results list.

In one embodiment, bid amount 358 is a monetary amount bid by the advertiser for the listing. The monetary amount is deducted or recorded from the advertiser's prepaid account into the advertiser's account, which is credited each time a search is performed by the user for the corresponding search term, and the search result list hyperlink is used to direct the searcher to the advertiser's web site. In another embodiment, the bid amount may be any other type of economic value given by the advertiser or recognized by the operator of the online marketplace.

Finally, the rank values are dynamically generated, preferably by the processing system 34 of the account management server 22 shown in FIG. 1, each time an advertiser places a bid or a searcher enters a search query. The rank value of an advertiser's search listing determines the placement of the advertiser's entry in the search result list that is generated when the search is performed on the corresponding search term. Preferably, the rank value is an ordinal value determined in direct relation to bid amount 58, and the greater the bid amount, the higher the rank value, and the more advantageous the placement on the search result list. More preferably, a rank value of 1 is assigned to the highest bid amount, and successively higher rank values (e.g., 2, 3, 4, … …) are associated with successively lower ranks and assigned to successively lower bid amounts.

An example of a search result list display used in embodiments of the present invention is shown in FIG. 4, where the first few items displayed are from the search term "zip drives". As shown in FIG. 4, an individual entry, such as entry 710a in a search result list, includes a description 720 of a web site, preferably including a title and a brief textual description, and a hyperlink 730, which when clicked by a searcher to hyperlink 730, directs the searcher's browser to the URL at which the described web site is located. The URL 740 may also be displayed in the search result list entry 710a, as shown in fig. 4. Click-throughs of search result items occur when a remote searcher viewing the search result item display 710 of FIG. 4 selects or clicks on a hyperlink 730 of the search result item display 710. To accomplish click-through, the searcher's click should be recorded on the account management server and redirected to the advertiser's URL through the redirection mechanism described above.

The search result listings 710 a-710 h may also display a rank value for the advertiser's search listing. The rank values are ordinal values, preferably numbers, generated and assigned to the search listings by the processing system 34 of FIG. 1. Preferably, the rank value is assigned by a software-implemented process that establishes an association between bid amount, rank and search term of the search listing. The process collects all search listings that match a particular search term, sorts the search listings in order from highest to lowest search term, and assigns a rank value to each search listing in order. The highest bid amount receives the highest level value and the next highest bid amount receives the next highest level value until the lowest bid value of the lowest level values is received. More preferably, the highest level value is 1, with sequentially increasing ordinal values (e.g., 2, 3, 4, … …) assigned to sequentially decreasing levels. The correlation between the rank value and bid amount is shown in FIG. 4, where each paid search listing 710a through 710f displays an advertiser bid amount 750a through 750f for the entry. Preferably, if two search listings having the same search term also have the same bid amount, the earlier received bid will be assigned a higher rank value. The outstanding listings 710g through 710h do not display the bid amount and are displayed after the paid listing at the lowest level. Preferably, if there are not a sufficient number of listings to fill 40 locations on the search results page, the outstanding listings are displayed. The outstanding listings are generated by the search engine using a text search algorithm and a target distributed database as is well known in the art. An example of such a search engine may be operated by Inktomi corporation. The original search query entered by the remote searcher is used to generate unpaid listings by a conventional search engine.

From the foregoing, it can be seen that the presently disclosed embodiments provide improved methods and apparatus for controlling the display of search results in a search result list. The system may be improved by adding an XML interface to the account management server and the client computer. Communications between the server and the client for controlling the search listings of one or more advertisers are consistent with one or more predetermined XML schemas. These patterns define parameters and possible data values for managing advertiser accounts and search listings. In this manner, search listings groups for multiple advertisers may be efficiently managed by a single user. Also, automatic operations may be specified for updating search listings, obtaining market status, receiving account information, and generating reports. The disclosed systems and methods may be used for advertisers to manage their own accounts and search listings and for third parties to manage accounts and search listings for one or more advertisers.

Accordingly, an advantage of the present invention is that reliable two-way communication of requests and responses between an account management bidding tool client and an account management bidding tool server is provided through the use of complementary XML interfaces on both the client and server sides. Another advantage of the present invention is that a universal secure external server interface is provided over a distributed network for advertiser client systems to perform account management functions as well as online advertising marketing, including retrieving search listings, retrieving market status, retrieving a set of account identifiers for one or more advertisers, modifying bid amounts or other parameters for one or more search listings, adding one or more search listings associated with an advertiser, and deleting one or more search listings associated with an advertiser. Yet another advantage of the present invention is that it allows for automation of such account management functions by providing a generic mode for creating requests to the server and another generic mode for understanding responses from the server.

While particular embodiments of the present invention have been shown and described, modifications may be made. It is therefore intended that the following appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.

Appendix A: request example

Get Account Ids(Normal user)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCRequest

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

version＝″1.0″

username＝″testacct″

password＝″fictionalpass″>

</Actions>

</DTCRequest>

Get Account Ids(Admin user)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCRequest

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

version＝″1.0″

username＝″testadminuser″

password＝″fictionalpass″>

</Actions>

</DTCRequest>

Get Listings

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCRequest

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

version＝″1.0″

username＝″testacct″

password＝″fictionalpass″>

<！--get all listings by search term-->

<！--get all listings by url -->

<GetListings maxCount＝″40″

url＝″http://www.goto.com″/>

<！--get all listings by title words with current

rank info-->

<GetListings maxCount＝″40″title＝″zero″

withRank＝″true″/>

</Actions>

</DTCRequest>

Get Market State

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCRequest

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

version＝″1.0″

username＝″testacct″

password＝″fictionalpass″>

</Actions>

</DTCRequest>

Set Listings

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCRequest

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

version＝″1.0″

username＝″testacct″

password＝″fictionalpass″>

<！--Change bid to $1.50-->

</Bidbehavior>

</SetListing>

</BidBehavior>

</SetListing>

</Actions>

</DTCRequest>

Appendix B Server response example

Get Account Ids(Normal user)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCResponse

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″dtc.xsd″

success＝″true″>

</GetAccountIdsResponse>

</ActionsResponse>

</DTCResponse>

Get Account Ids(Admin user)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCResponse

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″dtc.xsd″

success＝″true″>

</GetAccountIdsResponse>

</ActionsResponse>

</DTCResponse>

Get Listings

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCResponse

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″dtc.xsd″

success＝″true″>

<Listing listingID＝″29153391″

url＝″http://mappedtocouponurl.com/″

searchTerm＝″best web site for coupon″

bid＝″0.13″title＝″Title mapped to

′coupon′″

description＝″Desc mapped to′coupon′″

market＝″US″online＝″true″/>

<Listing listingID＝″29153393″

url＝″http://mappedtocouponurl.com/″

searchTerm＝″coupon″bid＝″0.49″

title＝″Title mapped to′coupon′″

description＝″Desc mapped to′coupon′″

market＝″US″online＝″true″/>

</GetListingsResponse>

<Listing listingID＝″26929544″

rank＝″3″

url＝″http://www.goto.com/″

searchTerm＝″gototest123456789″

bid＝″0.05″title＝″test″

description＝″test.″market＝″US″

online＝″true″/>

</GetListingsResponse>

</ActionsResponse>

</DTCResponse>

Get Market State

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCResponse

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″dtc.xsd″

success＝″true″>

<Listing rank＝″1″title＝″print Free Coupons from

Your Computer！″description＝″print free coupons from

your computer at CoolSavings！You&apos；ll save big on

groceries，clothes，baby and kid&apos；s stuff，home

items and much more！Click here to enroll.It&apos；s

free！″siteHost＝″www.coolsavings.com″bid＝″0.39″

currency＝″USD″/>

<Listing rank＝″2″title＝″Get Free Local Coupons

at ClipACoupon！″description＝″It&apos；s totally free！

Enroll now to print free money saving coupons when you

want or need them.print free coupons or receive great

online deals from our local and national merchants.″

siteHost＝″www.clipacoupon.com″bid＝″0.27″

currency＝″USD″/>

<Listing rank＝″3″title＝″The Online Coupon

Resource″description＝click here to visit

100GreatCoupons.com.W can help to save you money on

every online purchase from major online retailers like

Amazon.com，BarnesandNoble.com，and Half.com.″

siteHost＝″www.100greatcoupons.com″bid＝″0.27″

currency＝″USD″/>

</GetMarketStateResponse>

</ActionsResponse>

</DTCResponse>

Set Listings

<？xml version＝″1.0″encoding＝″UTF-8″？>

<DTCResponse

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″dtc.xsd″

success＝″true″>

<SetListingResponse listingId＝″29153393″

success＝″true″/>

<SetListingResponse listingID＝″29153323″

success＝″true″/>

</ActionsResponse>

</DTCResponse>

Appendix C exemplary request schema

<？xml version＝″1.0″encodin9＝″UTF-8″？>

<！--

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊-->

-->

<！--

-->

<！--An XML Schema for bidding tools to programmatically access the

features -->

<！--of DTC.

-->

<！--

＊＊-->

<xsd:schema

xmlns:xsd＝″http://www.w3.org/2001/XMLSchema″

elementFormDefault＝″qualified″>

<xsd:element name＝″DTCRequest″type＝″DTCRequestType″/>

<！--＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊Request Types＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊-->

<xsd:complexType name＝″RequestType″>

</xsd:attribute name＝″aux″type＝″NonEmptyString″use＝″optional″/>

</xsd:complexType>

<xsd:complexType name＝″DTCRequestType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:sequence>

<xsd:element name＝″Actions″

type＝″ActionType″

minOccurs＝′1′

maxOccurs＝′unbounded′/>

</xsd:sequence>

<xsd:attribute name＝″version″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″username″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″password″type＝″NonEmptyString″

use＝″required″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″ActionType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:sequence>

<xsd:element name＝″GetAccountrds″

type＝″AccountIdType″

minOccurs＝′0′

maxoccurs＝′unbounded′/>

<xsd:element name＝″GetMarketState″

type＝″MarketStateType″

minOccurs＝′0′

maxoccurs＝′unbounded′/>

<xsd:element name＝″GetListings″

type＝″GetListingType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

<xsd:element name＝″SetListing″

type＝″SetListingType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

<xsd:element name＝″AddListing″

type＝″AddListingType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

<xsd:element name＝″DeleteListing″

type＝″DeleteListingType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

</xsd:sequence>

<xsd:attribute name＝″accountId″type＝″NonEmptyString″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″AddListingType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:attribute name＝″title″

type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″description″

type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″url″

type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″searchTerm″

type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″bid″

type＝″BidType″

use＝″required″/>

<xsd:attribute name＝″isAdult″

type＝″xsd:boolean″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″DeleteListingType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:attribute name＝″listingId″type＝″NonEmptyString″

use＝″required″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″AccountIdType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<！--The dtcUsername attribute is valid only for

administrative-->

<！--users.Any other time the username is specified，it

-->

<！--will be ignored.

-->

<xsd:attribute name＝″dtcUsername″type＝″NonEmptyString″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″SetListingType″>

<xsd:complexContent>

<xsd:extension base＝″RWListingType″>

<xsd:sequence>

<xsd:element name＝″BidBehavior″

type＝″BidBehaviorType″

minOccurs＝′0′

maxOccurs＝′1′/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″MarketStateType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:attribute name＝″searchTerm″type＝″NonEmptyString ″

use＝″required″/>

<xsd:attribute name＝″market″type＝″MarketType″

use＝″required″/>

<xsd:attribute name＝″startIndex″type＝″xsd:integer″

use＝″optional″/>

<xsd:attribute name＝″maxCount″type＝″xsd:integer″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″GetListingType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:attribute name＝″title″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″description″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″url″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″lowBid″type＝″BidType″

use＝″optional″/>

<xsd:attribute name＝″highBid″type＝″BidType″

use＝″optional″/>

<xsd:attribute name＝″maxCount″type＝″xsd:integer″

use＝″optional″/>

<xsd:attribute name＝″searchTerm″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″market″type＝″MarketType″

use＝″optional″/>

<xsd:attribute name＝″startIndex″type＝″xsd:integer″

use＝″optional″/>

<xsd:attribute name＝″withRank″type＝″xsd:boolean″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″BidBehaviorType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:sequence>

<xsd:choice>

<xsd:element name＝″Fixed″

type＝″FixedType″minOccurs＝′1′maxOccurs＝′1′/>

<xsd:element name＝″B2P″

type＝″B2PType″minOccurs＝′1′maxOccurs＝′1′/>

</xsd:choice>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″FixedType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:attribute name＝″bid″type＝″BidType″use＝″required″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:simpleType name＝″BidType″>

<xsd:restriction base＝″xsd:token″>

<xsd:pattern value＝″[0-9]+\.[0-9][0-9]″/>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name＝″B2PType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<！--The requested rank-->

<xsd:attribute name＝″rank″type＝″xsd:positiveInteger″

use＝″required″/>

<！--Howmuch the advertiser is willing to pay for the rank-

->

<xsd:attribute name＝″maxCap″type＝″xsd:float″

use＝″reguired″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″RwListingType″>

<xsd:complexContent>

<xsd:extension base＝″RequestType″>

<xsd:attribute name＝″listingId″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″title″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″description″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″url″type＝″NonEmptyString″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:simpleType name＝″MarketType″>

<xsd:restriction base＝″xsd:string″>

<xsd:enumeration value＝″US″/>

<xsd:enumeration value＝″UK″/>

<xsd:enumeration value＝″DE″/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name＝″NonEmptyString″>

<xsd:restriction base＝″xsd:string″>

<xsd:minLength value＝′1′/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Appendix D exemplary response modes

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--

＊＊-->

-->

<！--

-->

<！--An XML Schema for bidding tools to programmatically access the

features -->

<！--of DTC.

-->

<！--

＊＊-->

<xsd:schema

xmlns:xsd＝″http://www.w3.org/2001/XMLSchema″

elementFormDefault＝″qualified″>

<xsd:element name＝″DTCResponse″type＝″DTCResponseType″/>

<xsd:complexType name＝″ResponseType″>

<xsd:attribute name＝″aux″type＝″NonEmptyString″

use＝″optional″/>

</xsd:complexType>

<xsd:complexType name＝″StatusResponseType″>

<xsd:complexContent>

<xsd:extension base＝″ResponseType″>

<xsd:attribute name＝″success″type＝″xsd:boolean″

use＝″required″/>

<xsd:attribute name＝″reason″type＝″NonEmptyString″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″DTCResponseType″>

<xsd:complexContent>

<xsd:extension base＝″StatusResponseType″>

<xsd:sequence>

<xsd:element name＝″ActionsResponse″

type＝″ActionsResponseType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″ActionsResponseType″>

<xsd:sequence>

<xsd:element name＝″GetAccountIdsResponse″

type＝″GetAccountIdsResponseType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

<xsd:element name＝″GetMarketStateResponse″

type＝″MarketStateResponseType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

<xsd:element name＝″GetListingsResponse″

type＝″GetListingResponseType″

minOccurs＝′0′maxOccurs＝′unbounded′/>

<xsd:element name＝″SetListingResponse″

type＝″ListingResponseType″

minOccurs＝′0′maxOccurs＝′unbounded′/>

<xsd:element name＝″AddListingResponse″

type＝″ResponseType″

minOccurs＝′0′maxOccurs＝′unbounded′/>

<xsd:element name＝″DeleteListingResponse″

type＝″ListingResponseType″

minOccurs＝′0′maxOccurs＝′unbounded′/>

</xsd:sequence>

<xsd:attribute name＝″accountId″type＝″NonEmptyString″

use＝″optional″/>

</xsd:complexType>

<xsd:complexType name＝″GetAccountIdsResponseType″>

<xsd:complexContent>

<xsd:extension base＝″StatusResponseType″>

<xsd:sequence>

<xsd:element name＝″Account″

type＝″AccountType″

minOccurs＝′0′

maxOccurs＝′unbounded′/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″AccountType″>

<xsd:complexContent>

<xsd:extension base＝″ResponseType″>

<xsd:attribute name＝″id″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″market″type＝″MarketType″

use＝″required″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″MarketStateResponseType″>

<xsd:complexContent>

<xsd:extension base＝″MSListingResponseType″>

<xsd:attribute name＝″market″type＝″MarketType″

use＝″required″/>

<xsd:attribute name＝″searchTerm″type＝″NonEmptyString″

use＝″required″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″MSListingResponseType″>

<xsd:complexContent>

<xsd:extension base＝″StatusResponseType″>

<xsd:sequence>

<xsd:element name＝″Listing″

type＝″MSListingType″

minOccurs＝″0″

maxOccurs＝″100″/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″GetList ingResponseType″>

<xsd:complexContent>

<xsd:extension base＝″StatusResponseType″>

<xsd:sequence>

<xsd:element name＝″Listing″

type＝″GetListingType″

minOccurs＝″0″

maxOccurs＝″100″/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:ccmplexType name＝″ListingResponseType″>

<xsd:complexContent>

<xsd:extensicn base＝″StatusResponseType″>

<xsd:attribute name＝″listingId″

type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″confirmationNumber″

type＝″NonEmptyString″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:ccmplexType>

<xsd:complexType name＝″RequiredListingType″>

<xsd:attribute name＝″title″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″description″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″bid″type＝″BidType″

use＝″required″/>

<xsd:attribute name＝″market″type＝″MarketType″

use＝″required″/>

<xsd:attribute name＝″searchTerm″type＝″NonEmptyString″

use＝″required″/>

</xsd:complexType>

<xsd:complexType name＝″MSListingType″>

<xsd:complexContent>

<xsd:extension base＝″RequiredListingType″>

<xsd:attribute name＝″listingId″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″url″type＝″NonEmptyString″

use＝″optional″/>

<xsd:attribute name＝″currency″type＝″CurrencyType″

use＝″optional″/>

<xsd:attribute name＝″rank″type＝″xsd:integer″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name＝″GetListingType″>

<xsd:complexContent>

<xsd:extension base＝″RequiredListingType″>

<xsd:attribute name＝″listingId″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″url″type＝″NonEmptyString″

use＝″required″/>

<xsd:attribute name＝″online″type＝″xsd:boolean″

use＝″required″/>

<xsd:attribute name＝″currency″type＝″CurrencyType″

use＝″optional″/>

<xsd:attribute name＝″rank″type＝″xsd:integer″

use＝″optional″/>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:simpleType name＝″CurrencyType″>

<xsd:restriction base＝″NonEmptyString″>

<xsd:enumeration value＝″USD″/>

<xsd:enumeration value＝″GBp″/>

<xsd:enumeration value＝″EUR″/>

</xsd:restriction>

</xsd:s impleType>

<xsd:simpleType name＝″BidType″>

<xsd:restriction base＝″xsd:token″>

<xsd:pattern value＝″[0-9]+\.[0-9][0-9]″/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name＝″NonEmptyString″>

<xsd:restriction base＝″xsd:string″>

<xsd:minLength value＝′1′/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name＝″MarketType″>

<xsd:restriction base＝″xsd:string″>

<xsd:enumeration value＝″US″/>

<xsd:enumeration value＝″UK″/>

<xsd:enumeration value＝″DE″/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Claims

1. A system for enabling an advertising web site promoter using a computer network to update information related to search listings in a search result list generated by an internet search engine, the system comprising:

an account management server computer system having stored therein a database having at least one account record for each of a plurality of advertising web site promoters using a computer network, the account record comprising:

at least one search listing comprising:

a search term having at least one keyword;

an alterable bid amount;

a universal resource locator corresponding to an address of a document residing on a network server;

description is given; and

a title;

an account balance;

an extensible markup language device on said computer system comprising an extensible markup language interface for modifying a search listing of an account of an advertising web site promoter upon receipt of a request from said advertising web site promoter;

means for processing a search request from a remote computer, the search request including at least one keyword, the search request received from the remote computer over the computer network via a publicly accessible web site that does not require authentication;

means for generating a search result list in response to the search request, the search result list including search listings from an account of the database, wherein search terms in each search listing in the search result list generate matches to the search request, the search listings in the search result list being arranged in an order determined using bid amounts for the search listings; and

a client computer system operated by an advertising web site promoter for managing search listings stored in a database of the account management server computer system, the client computer system comprising

A bid management tool for interacting with the account management server computer system to modify the advertising web site promoter's account records to enable manual changes to account records specified by the advertising web site promoter and automatic changes to the account records according to preset program code, an

An extensible markup language interface complementary to the extensible markup language interface of the account management server computer system, the complementary extensible markup language interface cooperating with the bid management tool to initiate a request to change the account record to the extensible markup language interface of the account management server computer system, comprising:

communicating a request for an account identifier associated with the advertising web site originator and receiving the account identifier from the account management server computer system,

communicating a request for one or more search listings of the advertising web site promoter to the account management server computer system and receiving the search listings,

communicating a request for a market status for a specified search listing to the account management server computer system and receiving the market status, an

Communicating a request to the account management server computer system to modify a search listing of an account of an advertising web site promoter.

2. The system of claim 1, further comprising:

another extensible markup language device on the account management server computer system for deleting a search listing from an account of an advertising web site promoter upon receiving a request from the advertising web site promoter.

3. The system of claim 1, further comprising:

another extensible markup language means on the account management server computer system for altering a search listing of an advertising web site promoter substantially in real time upon receipt of a request from the advertising web site promoter.

4. The system of claim 1, further comprising:

another extensible markup language means on the account management server computer system for generating activity reports for the advertising web site promoter upon receiving a request from the advertising web site promoter.

5. The system of claim 1, further comprising:

another extensible markup language device on the account management server computer system for providing login rights to the advertising web site promoter in response to authentication, wherein the login rights of the advertising web site promoter grant the advertising web site promoter access to change the account of the advertising web site promoter, the advertising web site promoter not being provided with the right to change other accounts.

6. The system of claim 1, further comprising:

another extensible markup language device on the account management server computer system for adding an amount to an account of an advertising web site promoter in substantially real time upon receiving a request from the advertising web site promoter.

7. The system of claim 6, wherein the database of the account management server computer system further stores:

a search listing history included in an account record of an advertising web site promoter; and

payment processing information, wherein the payment processing information is accessible by a computer system but is isolated from public access over the computer network; and

a history of payments.

8. The system of claim 1, wherein the extensible markup language interface of the client computer system is configured to:

receiving an extensible markup language request from an extensible markup language interface of a client computer system of the advertising web site promoter; and

in response to receiving the extensible markup language request, communicating an extensible markup language response to an extensible markup language interface of the client computer system of the advertising web site promoter.

9. The system of claim 1, further comprising:

an extensible markup language schema.

10. A method for enabling a web site promoter using a computer network to update information related to search listings in a search result list generated by a search engine in response to a search request received from a remote computer over the computer network, the method comprising:

storing at least one account record for each of a plurality of web site promoters of a computer network, the at least one account record comprising:

an account identifier, and

at least one search listing having search terms and an alterable bid amount;

providing the verified login rights to the web site promoter, wherein the login rights of the web site promoter allow the web site promoter to change the account record of the web site promoter;

receiving an extensible markup language request from the web site originator, including an extensible markup language request specifying a username of the web site originator, an extensible markup language request identifying one or more search listings to retrieve, an extensible markup language request for a market status of the one or more search listings to retrieve, and an extensible markup language request specifying a search listing to be modified and a modified extensible markup language request;

modifying a search listing for an account record in response to an extensible markup language request;

receiving information input by a user through input equipment;

searching the stored at least one account record and identifying at least some search listings that represent matches to the user-entered information; and

the search result lists of the identified search listings are sorted in an order corresponding to the bid amount of the search listing.

11. The method of claim 10, further comprising:

receiving an extensible markup language request from a web site promoter; and

the extensible markup language request is parsed against the extensible markup language schema to identify the extensible markup language request.

12. The method of claim 11, further comprising:

the extensible markup language response is provided to the web site promoter confirming modification of the search listing.

13. A method for enabling a web site promoter using a computer network to manage information related to search listings in a search result list generated by a search engine in response to a search request received from a remote computer over the computer network, the method comprising:

a computer database storing at least one account record for each of a plurality of web site promoters comprising a computer network, said at least one account record comprising:

an account identifier, and

at least one search listing having search terms and an alterable bid amount;

storing an extensible markup language schema;

receiving one or more extensible markup language requests from a web site promoter for managing one or more search listings of the web site promoter, the extensible markup language requests including an extensible markup language request to retrieve a set of account identifiers for the web site promoter, an extensible markup language request to retrieve the one or more search listings, and an extensible markup language request to retrieve a current market state for the one or more search listings; and

in response to the extensible markup language request, an operation is performed on at least one account record.

14. The method of claim 13, further comprising:

in response to the extensible markup language request, providing the account identifier, the one or more search listings, and the current market status to a web site promoter.

15. The method of claim 14, wherein providing a market state comprises:

formatting an extensible markup language response including information about a market state; and

an extensible markup language response is communicated to the web site promoter.

16. The method of claim 13, wherein performing an operation on at least one account record comprises:

in response to the one or more extensible markup language requests, a change is made to a modifiable bid amount.

17. A method for managing search listings for an online marketplace using client computers in data communication with an account database server computer of the online marketplace, the method comprising:

formatting, at a client computer, an extensible markup language request to retrieve a search listing from the account database and a market state of the search listing, and communicating the extensible markup language request to the account management server;

formatting, at a client computer, an extensible markup language request to set a bid amount for the search listing stored at an account database server; and

at the client computer, the extensible markup language request is communicated to an account management server of the online marketplace.

18. The method of claim 17, wherein formatting the extensible markup language request comprises:

the extensible markup language request is formatted using an account identifier associated with the search listing, a listing identifier corresponding to the search listing, and a desired bid activity.

19. The method of claim 17, further comprising:

an extensible markup language response is received indicating a successful completion of the request to set a bid amount.

20. A method for managing search listings for an online marketplace using client computers in data communication with an account database server for the online marketplace, the method comprising:

formatting, at a client computer, an extensible markup language request to receive a set of account identifiers corresponding to accounts associated with advertisers and stored at an account database server; and

the extensible markup language request is communicated from the client computer to an account database server computer of the online marketplace.

21. The method of claim 20, wherein formatting the extensible markup language request comprises:

the extensible markup language request is formatted using a username associated with the advertiser and an extensible markup language tag requesting a set of account identifiers associated with the username.

22. The method of claim 21, further comprising:

at a client computer, an extensible markup language response is received that includes an account identifier associated with an advertiser.

23. A method for managing search listings for an online marketplace using client computers in data communication with an account database server for the online marketplace, the method comprising:

formatting, at a client computer, the extensible markup language request to retrieve a market status of the online marketplace; and

24. The method of claim 23, wherein formatting the extensible markup language request comprises:

the extensible markup language request is formatted using the market identifier and the search term.

25. The method of claim 24, further comprising:

at the client computer, an extensible markup language response is received from the account database server computer in the marketplace associated with the identifier, the extensible markup language response including search listing information for one or more search listings associated with the search term.

26. A method for managing search listings for an online marketplace using client computers in data communication with an account database server for the online marketplace, the method comprising:

formatting, at a client computer, an extensible markup language request to receive a set of account identifiers corresponding to accounts associated with advertisers and stored on the account database server, and to communicate the extensible markup language request to an account management server of the online marketplace;

formatting, at a client computer, an extensible markup language request to retrieve search listings associated with advertisers of an online marketplace;

communicating the extensible markup language request to an account management server of the online marketplace;

at a client computer, an extensible markup language request is formatted to retrieve a market state of the online marketplace and communicated to an account management server of the online marketplace.

27. The method of claim 26, wherein formatting the extensible markup language request to retrieve the search listing comprises:

the extensible markup language request is formatted using an account identifier associated with the advertiser.

28. The method of claim 26, wherein formatting the extensible markup language request to retrieve the search listing comprises:

at the client computer, the extensible markup language request is formatted using an account identifier associated with the advertiser and one or more of:

a search term;

a specified bid amount;

a universal resource locator;

a title; and

a description is given.

29. A bid management tool for managing search listings stored on an account management server of an online marketplace from a remote client computer, the bid management tool comprising:

first means, operative on the remote client computer, for data communication with the account management server, the first means forming a menu system; and

a second means, operating on a remote client computer, which forms a search listing management function in cooperation with the menu system, for managing one or more search listings in accordance with user requirements specified through the menu system.

30. The bid management tool of claim 29, further comprising:

third means forming a set function for receiving a user entry specifying an advertiser identifier and an account identifier for management.

31. The bid management tool of claim 29, further comprising:

fourth means forming a reporting function.

32. A client computer operating in conjunction with an account management server of an online marketplace, the account management server storing search listings associated with advertisers, the client computer comprising:

a bid management tool that provides a user interface for receiving account management commands from advertisers to manage search listings of the advertisers and provide information about the search listings to the advertisers, and that provides account management commands based on events or timing; and

an extensible markup language interface in communication with the bid management tool for communicating an extensible markup language request to an account management server, the extensible markup language request including an extensible markup language request to retrieve one or more account identifiers associated with the advertiser, an extensible markup language request to retrieve one or more search listings of the advertiser, and an extensible markup language request to retrieve a market status of the one or more search listings.

33. The client computer of claim 32, wherein the bid management tool comprises:

a menu system; and

a search listing management function in cooperation with the menu system for managing one or more search listings on the account management server in accordance with user requirements specified through the menu system.