CN1659564A - Method and system for arranging trade listings at a web-based trading establishment - Google Patents

Abstract

In accordance with the present invention, a method is provided for facilitating the propagation of multiple transaction listings to a network-based transaction facility. An input interface is provided at the seller application for receiving from a user a plurality of transaction listings, each transaction listing including an associated start time. Additionally, a data file is constructed at the seller application to contain the plurality of transaction listings. Further, the data file is propagated from the client computer to the network-based transaction facility using the seller application.

Description

Method and system for arranging trade listings at a web-based trading establishment

This application claims priority to US Provisional Application No. 60/387,638, filed June 10,2002.

technical field

The present invention relates generally to the field of web-based commerce, and more particularly to methods and systems for scheduling transaction listings at web-based transaction establishments.

Background technique

On-line (or electronic) commerce via the Internet has become increasingly common in a variety of business environments as the Internet has gained wide acceptance as a pervasive interactive communication and interaction platform. Online commerce has traditionally been divided into business-to-business (B2B), business-to-consumer (B2C), customer-to-customer (C2C) and even business-to-employee (B2E) commerce. In a B2B environment, many online exchanges or marketplaces (eg, vertical exchanges) have been established to facilitate e-commerce between parties in, for example, vertical supply chains. Such B2B exchanges generally provide a variety of tools to assist in the conduct of commerce, such as aggregated and near real-time inventory information, Requests for Quotation (RFQ) capabilities, and auctions.

In the B2C and C2C environment, many market exchanges and trading institutions have become popular. A leading electronic exchange (or marketplace) is operated by eBay Corporation. Yahoo! The company, as well as Amazon.com, also offer electronic marketplaces. Moreover, many online services provide on-line classified (on-line classified), such as Yahoo! Provided by Yahoo! Classifieds service.

Various online marketplaces are used by wholesalers as an important, if not essential, channel for product distribution. These so-called "big users" typically list large numbers of items for sale or auction every day. Moreover, various retailers and wholesalers also take advantage of free or low-cost classified advertising services available on the Internet, such as Yahoo! Classifieds. For example, a used car sales department can place a large number of such classified services at any time through online classified advertising services. It would be helpful if there was a way for wholesalers to create multiple offers and distribute them to a web-based marketplace.

Contents of the invention

In accordance with the present invention, a method is provided for facilitating the propagation of a plurality of trade listings to a web-based trading establishment. An input interface is provided at the seller application to receive a plurality of transaction listings from the user, each transaction listing including an associated start time. Additionally, a data file is constructed at the seller application to contain the plurality of transaction listings. Also, the data file is propagated from the client computer to the web-based exchange using the seller application.

Description of drawings

The present invention is described by way of example and not limitation in the accompanying drawings, in which like numerals refer to like elements:

Figure 1 is a block diagram illustrating an exemplary web-based transaction mechanism, according to one embodiment of the present invention.

Figure 2 is a database diagram illustrating an exemplary database maintained and accessed by a database engine server of a web-based transactional institution.

Figure 3 is a block diagram illustrating a web-based transaction environment including a client side and a server side, according to an exemplary embodiment of the present invention.

Figure 4 is a block diagram illustrating a seller application according to an exemplary embodiment of the present invention.

5 is a flowchart illustrating a method for customizing a seller application that facilitates the propagation of trade listings to a web-based exchange, according to an exemplary embodiment of the present invention.

6 is a flowchart illustrating a method for arranging listings through a seller application at a web-based exchange, according to an exemplary embodiment of the present invention.

Figure 7 is a block diagram illustrating the relationship between a seller application and a plurality of web-based exchanges, according to an exemplary embodiment of the present invention.

8 is a flowchart illustrating a method for arranging trade listings at a web-based trade establishment, according to an exemplary embodiment of the present invention.

9 is a flowchart illustrating a method for providing a "what you see is what you get" (WYSIWYG) interface for entering a transaction listing description in a seller application, according to an exemplary embodiment of the present invention.

Figure 10 is a flowchart illustrating a method for receiving software module and configuration data updates/upgrades for vendor applications, according to an exemplary embodiment of the present invention.

11 is a flowchart illustrating a method for downloading a seller application from a web-based exchange to a client machine, according to an exemplary embodiment of the present invention.

Figures 12A and 12B are flow diagrams illustrating a method for customizing a seller application for disseminating transaction listing items and their respective start times to a web-based transaction institution, according to an exemplary embodiment of the present invention .

The interfaces shown in Figures 13A-13E may be provided to users by a web-based exchange to facilitate customization of seller applications.

14A and 14B are flowcharts illustrating a method for defining a batch of text containing a set of transactional listings, such as listings to be published on an online store, according to an exemplary embodiment of the present invention.

The interfaces shown in Figures 15A-15E may be provided to users by a web-based exchange to allow creation, editing, and deletion of trade listing groups and individual trade listings.

The interfaces shown in Figures 16A-16C may be provided to users by a web-based transaction institution to facilitate entry of transaction listing item descriptions.

17 is a flowchart illustrating a method for entering a deal listing description through a deal listing description interface, according to an exemplary embodiment of the present invention.

18 is a flowchart illustrating a method for scheduling listings through a seller application at a web-based exchange, according to an exemplary embodiment of the invention.

The interface shown in Figures 19A and 19B may be provided to a user by a web-based exchange to allow viewing, editing, previewing, and validation of groups of listings and individual listings.

FIG. 20 is a flow diagram illustrating a method for assisting updates/upgrades of seller applications, according to an exemplary embodiment of the present invention.

21A-21C provide schematic representations of database structures that may be maintained by a database engine server of a web-based transaction institution in accordance with an exemplary embodiment of the present invention.

Figure 22 shows a schematic representation of a machine in the exemplary form of a computer system, within which a set of instructions may be executed to cause the machine to perform any one of the methods described above.

Detailed ways

A method and system are described herein for arranging trade listings at a web-based trading establishment. In the following description, for the purposes of explanation, numerous specific details are given in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details.

the term

The term "user" should be understood to mean any entity (human or automated) that contributes to or participates in a transaction, communication or process.

The term "transaction" shall be understood to include any communication or exchange between two or more parties to establish a commercial agreement, exchange of value or commercial relationship. Accordingly, the word "transaction" shall be deemed to cover, but not be limited to, purchase and sale transactions established as a result of, for example, the placement of an advertisement, or the completion of an auction process in which The process is conducted online, or otherwise.

The term "upgrade" should be understood to include upgrades and updates. Accordingly, the word "upgrade" shall be deemed to cover, but not be limited to, modifications to existing software modules and data elements.

The term "targeted site" should be understood to include sites based on geography (e.g., continent, country, region, etc.), subject (e.g., Beanie dolls, baseball memorabilia, antique cars, etc.), purpose (e.g., commercial, non-profit) sex, etc.), demographics (e.g. Spanish, English, etc.), etc. Virtually any combination of these and other criteria (such as geography, use, and population) can be used to describe a "target site".

The term "web site" should be understood as a set of related World Wide Web (WWW) files, which includes a start file called a home page. Thousands of companies or individuals have one or more websites. A company or individual tells you how to get to their website by giving you the address of their home page. From the home page, you can reach all other pages on the site. For example, eBay's website has a homepage address http://www.eBay.com. eBay's home page address leads to many other pages. (However, a website can also have only a few pages.) Very large websites may be spread across multiple servers in different geographical locations. Some companies' Web sites consist of thousands of files, spread across many servers in multiple locations around the world. But a more typical example might be a website that resides on a commercial space provider's web server that hosts multiple other websites, all of which may or may not be related to each other.

While exemplary embodiments of the invention are described below with reference to "items," it should be appreciated that the invention is not limited thereto. Accordingly, the word "Item" shall be deemed to cover, but not be limited to, Transaction Listing Items.

The term "data file" shall be understood as a set of transaction list items. Accordingly, the phrase "data file" should be considered to cover, but not be limited to, a set of transaction listings, such as transaction listings being propagated to a web-based exchange.

trading organization

The block diagram of FIG. 1 shows an exemplary web-based transaction institution 10 . Although the exemplary embodiment of the present invention is described in the context of a web-based transactional establishment 10, the present invention is also applicable to many different types of computer-based and web-based establishments (commercial, trading or otherwise).

In an exemplary embodiment, web-based exchange 10 includes one or more of several types of front-end servers, each of which includes at least a dynamic link library (DLL) to provide certain functionality. The page server 12 delivers web pages (e.g., markup language documents), the image server 14 dynamically delivers images to be displayed within the web page, the listing server 16 facilitates category-based listing browsing, and the search server 20 handles requests to web-based exchanges 10. The ISAPI server 18 provides an intelligent interface to the backend of the web-based exchange 10 for search requests, and to facilitate keyword-based listing browsing. One of the functions of the email server 22 is to provide automated email communications to users of the web-based transaction institution 10 . Administrative application functions 32 assist in the monitoring, maintenance and management of the network-based transaction institution 10 . The API server 13 provides a set of functions to query the web-based exchange 10 . The API is a set of easy-to-use functions called through the HTTP transport protocol. Information is sent and received using the standard XML data format. Applications used to interact with the web-based trading establishment (eg, upload trade listings, view trade listings, manage trade listings, etc.) can be designed to use the API. These applications can be CGI programs or HTML forms written in C++, Perl, Pascal or any other programming language. The API is more fully described in US Patent Application Serial No. 09/999,618, which is hereby incorporated by reference.

Page server 12, API server 13, image server 14, ISAPI server 18, search server 20, e-mail server 22, and database engine server 26 may be used individually or in combination as communication engines to facilitate, for example, client 38 and web-based transactions Communication between organizations 10 . In addition, page server 12, API server 13, image server 14, ISAPI server 18, search server 20, email server 22, and database engine server 26 may be used individually or in combination as transaction engines to facilitate, for example, client 38 and web-based transactions between 10 trading institutions. In addition, page server 12, API server 13, image server 14, ISAPI server 18, search server 20, email server 22, and database engine server 26 may be used individually or in combination as display engines to facilitate, for example, client 38 and web-based Items between 10 trade bodies are displayed.

Back-end servers include database engine server 26, search index server 24, and credit card database server 28, each of which maintains and facilitates access to various databases.

The web-based trading institution 10 is accessible by a client program such as a browser 36 (e.g., Internet Explorer issued by Microsoft Corporation of Redmond, Wash.), which executes on a client machine 38 and accesses the web-based trading facility over a network such as the Internet 34. Agency10. Other examples of networks that a client may use to access a web-based transaction institution 10 include a Wide Area Network (WAN), a Local Area Network (LAN), a wireless network (such as a cellular network), or a Public Switched Telephone Network (PSTN) network.

data structure

The database diagram of FIG. 2 illustrates an exemplary database 30 maintained by and accessed by database engine server 26 , which at least partially implements and supports web-based transaction institution 10 . In this exemplary embodiment, database engine server 26 maintains two databases _30a and _30b , with the first database _30a being maintained for listings (or goods) information, while the second database _30b stores availability information for offerings that may be offered through the virtual "store" supported by the network-based exchange 10. The structures of these databases _30a and _30b are basically the same, with the difference that the tables of the "store" database _30b may include a number of additional fields to assist the virtual store. A general discussion of the basic structure of database 30, applicable to both databases _30a and _30b , will be provided below.

In one embodiment, database 30 may be implemented as a relational database, comprising a plurality of tables with entries (or records) that are related to each other by indexes or keys. In an alternative embodiment, database 30 may be implemented as a set of objects in an object-oriented database.

Centrally located in the database 30 is a user table 54 that contains a record for each user of the web-based exchange 10 . Users utilizing the web-based exchange 10 may act as sales groups, buyers, or both. Database 30 also includes a project table 60 , which may be related to user table 54 . Item tables 60 may include seller item table 52 and bidder item table 58 . A user record in user table 54 may be associated with a number of items that are or have been listed or offered for sale through web-based exchange 10 . For those items for which a record exists in the item table 60, an association indicates whether the user is a seller or a bidder (buyer).

Database 30 also includes one or more category tables 47 . Each record in the category table 47 describes a category. In one embodiment, the specific category table 47 describes a plurality of hierarchical category data structures, and includes multiple category records, and each record describes a specific category in one of the multiple hierarchical category structures. The context of the category. For example, category table 47 may describe a number of real or actual categories that may be associated to item records within item table 60 .

Database 30 also includes one or more attribute tables 49 . Each record in the attribute table 49 describes an attribute. In one embodiment, the specific attribute table 49 describes a plurality of hierarchical attribute data structures and includes a plurality of attribute records, each record describing the context of a specific attribute in one of the plurality of hierarchical attribute structures . For example, attribute table 49 may describe a number of real or actual attributes that may be associated to item records within item table 60 . Additionally, attribute table 49 may describe a number of real or actual attributes that may be associated to categories within category table 47 .

Database 30 also includes a notes table 46 populated with note records that may be associated to one or more project records in project table 60 and/or to one or more user records in user table 54 . Each note record within notes table 46 may include comments, descriptions, history, or other information pertaining to an item being sold through network-based exchange 10 , or to a user of network-based exchange 10 . In addition, database 30 also includes a target site table 67 populated with target site records that may be associated to one or more project records in project table 60 and/or to one or more user records in user table 54 .

Also shown are a number of other tables associated with user table 54 , namely user previous name table 48 , feedback table 50 , feedback details table 53 , bid table 55 , account table 64 , account balance table 62 , and batch item table 40 . The database 30 is also shown to contain a batch table 42 , a batch item table 40 and an item waiting table 44 for purposes of implementing one embodiment of the invention. Further details regarding database tables 40-44 are provided below.

The present invention relates to a method and system for arranging trade listings at a web-based trading establishment 10 . Figure 3 is a block diagram illustrating a web-based transaction environment 67 including a client side 35 and a server side 71, according to an exemplary embodiment of the present invention. In one embodiment, a transaction listing 70 (eg, for sale, auction, fixed price listing) is created on a web-based exchange 10 by a seller application 66 . The seller application 66 is used at the client 38 to facilitate the transfer of the plurality of transaction listings 70 to the web-based exchange 10 . In one embodiment, the seller application 66 can be used offline or online (eg, connected to a web-based exchange 10). In one embodiment, the seller application 66 is a separate application running on the client machine 38 . In an alternative embodiment, the transfer of the plurality of transaction listings 70 may be performed using a server-enabled application, such as a web browser or an applet executing within a web browser.

In one embodiment, a seller application 66 is installed and executed on the client computer to assist the user in propagating the plurality of transaction listings 70 and their respective start times to the web-based exchange 10 . The seller application 66 thus operates as a client application and provides a number of user interfaces and other functionality to assist the user in defining the number of transaction listings 70 in a convenient manner. Seller application 66 is also operable to construct a data file (e.g., bulk text 68) that includes multiple transaction listing items 70 and their associated start times, and propagates this data file as a single transmission to a web-based trading institutions10. This propagation of a single data file comprising multiple transaction listing items 70 is such a feature that reduces the number of interactions between the client 38 and the network-based transaction institution 10, thereby reducing the number of times the client 38 has to connect to the network. (i.e. "online") amount of time.

The associated start times include different start times for at least a portion of the plurality of transaction listings 70 in the data file. The association start time may include the start date and time of the first transaction listing 70 in the data file 68 . In an exemplary embodiment, the start time may be staggered by a user-selectable amount of time. For example, for the transaction list item 70 scheduled to start at 7:00 a.m. on December 25, 2002, if the user's selected user stagger time is 5 minutes, the following results will be obtained:

The first transaction list entry starts at 7:00a.m.;

The second transaction list item starts at 7:05a.m.;

The third transaction list item starts at 7:10a.m.;

The fourth trade list item begins at 7:15 a.m.

In this way, the start times of the four transaction listings 70 in this embodiment are staggered by 5 minutes. In this exemplary embodiment, the user may select a number of values to stagger the start times (eg, 10 minutes, 1 hour, 10 hours, 1 day, etc.). In one embodiment, the seller application 66 prevents the user from specifying an association start time for the transaction listing 70 that exceeds the maximum pre-scheduled value. Additionally, the seller application 66 may prevent the user from specifying an association start time below the minimum scheduled value. The maximum pre-scheduled value and the minimum scheduled value may be defined in terms of years, months, days, hours, minutes or seconds as defined by the web-based transaction institution 10 .

In an exemplary embodiment, the seller application 66, while executable as a stand-alone application on the client side 35, provides a feature that allows the user to build multiple transaction lists in an "offline" manner Items 70 (eg, without establishing any network communication or session with the web-based exchange 10), and then propagate these transaction listing items 70 to the web-based exchange 10 in the single data file transfer described above.

Another feature of the client side 35 executable seller application 66 is that it is configurable to work with multiple target (eg custom) sites. Thus, a user may use the seller application 66 to propagate the same deal listing 70 to multiple targeted sites (eg, geographically targeted sites for each country in the US, UK, Germany, etc.).

One embodiment of the present invention provides server-side assisted browsing, editing and confirmation of a plurality of transaction listing items 70, and also provides for submitting (commit) the plurality of transaction listing items 70 as an active state to start the transaction process by Multiple transaction processes facilitated by the web-based transaction institution 10 .

Referring again to FIG. 3 , the environment includes a client side 35 and a server side 71 . On the client side 35 , a client machine 38 , such as a personal computer, personal digital assistant (PDA), cell phone, set-top box, or any other networked device, is shown housing a seller application 66 and a browser application 36 . Although the seller application 66 and the browser application 36 are illustrated as being separate, the browser application 36 may be configured to function as the seller application 66, for example by fetching HTML pages from the server side 71 or by executing an applet. Client 38 is coupled to a network, such as the Internet 34 for example, which may also be a local area network (LAN) or a wide area network (WAN).

In one embodiment, the seller application 66 provides a user with various user interfaces for harvesting a plurality of transaction listings 70 . The seller application 66 also builds a batch of text 68 containing a plurality of transaction listings 70 entered through the plurality of interfaces. The seller application 66 then transmits the bulk text 68 to the web-based exchange 10 according to the web-based exchange API. In an alternative embodiment, seller application 66 interacts with email application 69 to construct an electronic mail (e-mail) containing bulk text 68 . Bulk text 68 is transmitted by email application 69 to web-based exchange 10 as an email message. Specifically, email application 69 utilizes any of a variety of email or messaging protocols, such as Simple Mail Transfer Protocol (SMTP), to transmit email messages over Internet 34 . It will of course be appreciated that in other implementations, any of a variety of other protocols may be utilized (eg, File Transfer Protocol (FTP)).

Focusing on the server side 71, the web-based transaction institution 10 is shown executing a transaction application 73 comprising a communicator module 75, a parser module 76, an upgrade control module 77, a scheduler module 80 and a publisher Module 82.

A communicator module 75 including an analyzer module 76 is used to receive a data file 68 from the seller application 66 executing at the client machine 38, the data file 68 including a plurality of transaction listings 70 and their respective associated start times. Analyzer module 76 operates to analyze a plurality of transaction listings 70 received from bulk text 68 . The analyzer module 76 may also perform various format, content and validation operations. The analyzer module 76 then populates the item waiting table 44 maintained by the database engine server 26 with the extracted transaction listing items 70 . The scheduler module 80 schedules the publication of the plurality of transaction listings 70 according to their respective associated start times. Transaction listings 70 are transferred from the Item Waiting list 44 to the Active Items list 60 in accordance with the respective scheduled listing times in a manner to be described below. The publisher module 82 publishes each of the plurality of transaction listings 70 at the network-based transaction institution 10 according to a respective associated start time.

In one embodiment, the communicator module 75 authenticates the user login information provided by the seller application 66 with the connect request. The verification occurs prior to receipt of the bulk text 68 . After verifying the user login information, the communicator module 75 provides the received user information to the upgrade control module 77 . The upgrade control module 77 determines whether the seller application 66 requires any updates/upgrades. The updates/upgrades may include, but are not limited to, software components (eg, main modules) or data elements (eg, classification updates, attribute updates, etc.).

The transaction application 73 also includes a page server 12, which in one embodiment includes an Internet Server Application Programming Interface (ISAPI) 18, wherein the page server 12 includes an Internet Information Server, which is a web server developed by Microsoft Corporation of Redmond, Washington. server. In an alternative embodiment, the page server 12 may execute a Common Gateway Interface (CGI) program. The page server 12 operates dynamically to generate markup language documents (e.g., web pages) using content retrieved from the database engine server 26, and transmits these markup language documents over the Internet 34 to the vendor application 66 for viewing using the browser application 36. browse. In one embodiment, the page server 12 provides a viewer page 72 containing a list of transaction listings 70 successfully extracted by the analyzer module 76 from the list of transaction listings 70 for display in a browser application. 36 in. This is so that the user can view, edit and confirm the transaction listings 70 before transferring them from the project waiting table 44 to the active project table 60 .

The basic architecture of the seller application

In an exemplary embodiment, the vendor application 66 architecture includes three tiers. These three layers include GUI layer, data object layer and communication and database layer. Modules at the GUI layer handle all interaction with the user and all management of resource files. The data object layer includes data objects containing target site data. The data object layer encapsulates the XML analysis of target site data and database access to facilitate GUI development. The communication and database layer provides a simplified interface to the rest of the seller application 66. An upgrade manager (such as the upgrade module explained below) is provided to keep the three layers of vendor applications 66 up-to-date. This involves managing several types of data elements (such as class data) and components (such as modules). The upgrade manager is explained further below.

FIG. 4 illustrates an exemplary seller application 66 . In this exemplary embodiment, the seller application 66 assists in propagating the plurality of transaction listings 70 to the web-based exchange 10 .

Seller Application Components

In an exemplary embodiment, the seller application 66 includes a main module 84, a resource module 81, a data object module 83, a create/edit transaction listing module 85, a target site resource module 87, a target site configuration file 86, a communication module 95 , data storage module 89 , import engine module 91 , upgrade manager module 92 , assistant module 93 , user independent database 94 , vendor application database 97 and configuration and registration module 96 . The create/edit transaction listing module 85 includes an interface module 88 and a builder module 90 .

Seller Application Construction

In an exemplary embodiment, the vendor application 66 is essentially built using Microsoft standard libraries and components. The main executable file and GUI (Graphical User Interface) based components use MFC (Microsoft Foundation Classes). MFC is a large C++ class library developed by Microsoft Corporation. MFC comes bundled with several C++ compilers and is available as part of the Microsoft Developer Network (MSDN).

In an exemplary embodiment, the communication and database layers use OLEDB (OLE DataBase) and Jet Engine. OLEDB is Microsoft's programming interface for database access. Applications can use OLEDB to directly access data sources, or they can use OLEDB to call ODBC to access an ODBC database. The Jet (Joint Engine Technology) engine is a database engine used in Microsoft Access, which is related to Visual Basic and C++. Jet is generally used to store data in the client. Developers using Access and Visual Basic access Jet through the DAO/Jet interface (which is a COM object).

In the exemplary embodiment, Microsoft components are utilized because many components are already installed on many client machines 38 . For example, users who require Vendor Application 66 to install Internet Explorer 5.0 or higher are likely to get the required version of Jet Engine. In an exemplary embodiment, third-party tools can be used for STL and XML analysis.

Multiple Users and Security in Vendor Applications

In an exemplary embodiment, a multi-user environment is supported by using a different DB (database) for each user's preferences. When a user logs in, the user's database file is used. Use password protection (such as Microsoft Access) to ensure the security of these user database files. The text fields of the user database can also be encrypted in the following manner, which does not affect performance but prevents curious users from "hacking" the table.

Some user-independent settings are stored in the vendor application database 97 (eg site-specific data). In the exemplary embodiment, there is only one vendor application database 97 . The seller application database 97 is always opened by the seller application 66 regardless of which user is logged in. The seller application database 97 contains a mapping from a web-based exchange user ID to a user-independent database file name for that user, so that the user-independent database file name does not indicate a web-based exchange user ID. This scheme allows users to change their web-based exchange ID and continue to use their existing user-independent database 94 . This way, if a user changes their ID and/or password, they will not lose their saved items.

Adaptability for seller applications

In an exemplary embodiment, the seller application 66 may be adapted for use with targeted (eg, geographically or otherwise targeted) sites. The vendor application string is stored in the resource module 81 . The resource module 81 is constituted by a DLL (Dynamic Link Library). The seller application string is a string for the seller application 66 language (eg, base language) that is distinct from the string that appears in the target site language.

The user can select the base language they want to use and optionally install additional seller application 66 language versions. In an exemplary embodiment, switching base languages requires a reboot. The base language may be different from the language of the target site with which the user is communicating.

In an exemplary embodiment, the base language utilized by the seller application 66 is translated into the language of the target site with which the user wishes to communicate. The translation may occur offline at the seller application 66 or at the web-based exchange 10 when the seller application 66 is connected to the web-based exchange 10 .

Target site language is the language and site convention used at a particular target site. The set of strings for the target site language is also stored in the target site resource module 87. The target site resource module 87 may be constituted by a DLL (Dynamic Link Library). In an exemplary embodiment, the target site data provided by the set of strings associated with the target site language can be switched during execution so that a user can list items on multiple target sites without restarting the seller application 66 . In order to realize the switching of the target site language, the target site resource module 87 should contain the correct string set of the target site language.

In addition to target site-specific string translations, these target site resource modules 87 may also contain target site-specific dialog layout variants that will make the user interface used in the process of creating transaction list items 70 look different in appearance. different target sites. This provides flexibility to users and designers while minimizing the amount of site-specific code needed to assist in the process of creating transaction listing items 70 .

In an exemplary embodiment, there is some target site-specific XML configuration data containing updatable values (eg, categories, attributes, valid formats, etc.). If this configuration data is modified for a target site that is configured to work with the vendor application 66, the vendor application 66 should be updated to reflect this modification. In an exemplary embodiment, modifiable target site specific data may be stored in target site resource modules 87 or XML files. The most current XML data is stored in the vendor application database 97 .

Upgradability of Vendor Applications

The vendor application 66 is designed to upgrade data elements and application modules at the same time. An upgrade manager module 92 and a helper module 93 are used to assist in assisting this upgrade. Data elements are expected to change frequently. Data elements are obtained through existing API calls to the web-based exchange 10 . The update data element provides the seller application 66 with an up-to-date set of categories, attributes, and target site-specific constants (eg, transaction limits, posting periods, payment options, fee schedules, etc.). In an exemplary embodiment, a target site configuration file 86 is used to store target site data elements.

In an exemplary embodiment, vendor application 66 modules are updated much less frequently than data elements. The Upgrade Seller Application 66 module provides an up-to-date set of Seller Application 66 and target site language translations, calculation rules (ie rules that correlate user data with target site data) and target site specific dialog layouts.

In an exemplary embodiment, all of the vendor application 66 modules are upgradeable, even the main module 84 . Upgrading the modules is done using the helper module 93 . After downloading the new components, a helper script is generated which instructs the helper module 93 to replace these modules with new versions of the vendor application 66 modules. Whenever the vendor application 66 is executed, this helper module 93 determines whether there is a possible file replacement before starting the main module 84 .

In the exemplary embodiment, to support minimal upgrades, a versioning mechanism is used to compare the vendor application 66 modules at the web-based exchange 10 for versions of installed elements and vendor application 66 modules and the available versions of the data elements. The upgrade simply attempts to download the changed Vendor Application 66 modules and/or data elements. Downloaded data can be compressed to reduce transfer time. This feature allows both code and data to be updated to maximize the scalability of vendor applications 66 .

In one embodiment, the web-based exchange 10 recognizes that the seller application 66 has been enabled to support a target site for which support has not been downloaded and installed. Upon identifying that this support has not been downloaded and installed, the web-based transaction 10 downloads the support required by the target site (eg, data elements, vendor application 66 module updates).

main module

In an exemplary embodiment, the seller application 66 main module 84 will provide an MFC shell for all UI elements that are displayed using the current application language (e.g. menus, toolbars, inventory and list item views) etc. of. The main module 84 is the starting point for the seller application 66 . All program flow and actions begin and end at the main module 84, whether they are program-initiated or user-initiated.

At startup, the main module 84 dynamically loads the resource module 81 based on the user's current application language setting. This setting is stored in the user independent database 94 . In order to change the application language, the user needs to restart the vendor application 66 for the change to be recognized. In an alternate implementation, the application language can be changed without restarting the vendor application 66 .

In the exemplary embodiment, the main module 84 is also responsible for controlling the security of the vendor application 66 by requiring the user to enter a password and only connecting to the user-independent database 94 associated with that user. The vendor application 66 is only allowed to use one user-independent database 94 at a time. To use a different user ID, the user must select another user ID and enter the password for that user ID. Alternatively, a user can log out and run the program again to log in as another user.

The user ID and password used to log into the seller application 66 may be the same as the user ID and password configured for that user at the web-based exchange 10 . If the user changes his ID and/or password on the web-based exchange 10 without updating the seller application 66, future attempts to communicate with the web-based exchange 10 may fail. An error message indicating a failed login will be provided to the user.

In an exemplary embodiment, the main module 84 allows only one instance of the vendor application 66 to execute on the user's system at a time. If the user tries to run another copy, the first executing instance is activated (eg a window is restored and brought to the top of the desktop). In an alternative embodiment, multiple vendor applications 66 may be running on the user's system at the same time.

The main module 84 calls the create/edit transaction listing module 85 when creating/editing a new transaction listing 70 . In an exemplary embodiment, the main module 84 is a single-threaded application and dynamically loads the remaining modules as needed.

Seller Application Language Resource Module

In an exemplary embodiment, the resource module 81 provides the ability to change the language of the vendor application 66 without changing any code. Additionally, the resource module 81 allows new vendor application 66 languages to be added with minimal installation time and effort. Each resource module 81 contains a set of resources for a language. These resources include dialog templates, menus, icons, and language strings.

As mentioned above, the main module 84 loads the resource module 81 when the seller application 66 starts up. A default seller application 66 language is set when the seller application 66 is installed and it matches the language of the web-based exchange 10 target site (e.g., geographically) from which the seller application 66 was originally obtained of. Other languages may be installed from the web-based transaction institution 10.

In an exemplary embodiment, each resource module 81 contains a complete set of all resources of the main module, including:

string table

dialog resource

App icons, bitmaps and more.

Resource modules 81 may follow a naming convention so that vendor application 66 knows which resource module 81 contains which language (eg res001.DLL is American English, res002.DLL is German, res003 is . . . etc.).

data object module

In an exemplary embodiment, the data object module 83 provides a DB independent data model to the seller application 66 for categories, domains, attributes, items and sites. The data object module 83 may be constituted by a DLL (Dynamic Link Library).

The data objects contained in the data object module 83 provide the seller application 66 with data store independent access to data in the seller application database 97 . When the data involved contains an XML string, the data object can encapsulate the XML analysis, providing the client with C++ accessor functions for the data fields. If the client requires the underlying XML, the data object module 83 can provide it.

There can be data objects for categories, domains, attributes, and site data. In an exemplary embodiment, a data object is created using a factory function exported by a DLL that contains the data object's implementation code. The factory function returns a pointer to the interface supported by the data object. The supported interfaces are defined in a header file that is included by any client code that requires it.

Create/Edit Transaction List Item Module

In an exemplary embodiment, the create/edit transaction listing module 85 of the seller application 66 displays all UI (user interface) elements in the language of the target site. Create/Edit Transaction Listing Module 85 is configurable to display the correct set of SYI fields/attributes/fees etc. for each target site. It is a feature of the create/edit transaction list item module 85 to encapsulate item related knowledge and logic in a single module to minimize the size of future updates. Another feature provides a site language independent implementation to allow the creation of transaction listings 70 for different target sites using the language of the seller application 66 . The create/edit transaction listing module 85 includes an interface module 88 and a builder module 90 . The interface module 88 provides an input interface for the user to receive a plurality of transaction listings 70, each of which includes a respective associated start time. The builder module 90 can automatically build a data file containing the plurality of transaction listing items 70 received by the interface module 88 . The communication module 95 disseminates the data files created by the builder module 90 from the client computer to the web-based exchange 10 .

target site resource module

In an exemplary embodiment, a target site resource module 87 is provided. Similar to resource module 81, target site resource module 87 contains resources for only one language. The create/edit transaction listing module 85 loads the appropriate target site resource module 87 each time a user creates a new transaction listing 70 or edits an existing transaction listing 70 . Target site resource module 87 contains dialog templates, icons and language strings.

The target site resource module 87 may also include target site related code. For example, code related to calculations specific to the currency of the target site. A target site resource module 87 is provided to the seller application 66 during installation of the seller application 66 . This target site resource module 87 matches the installed default language. The default language is the language of the target site from which the seller application 66 was downloaded. Additional destination site resource modules 87 may be downloaded from the web-based exchange 10 if the user wishes to be listed on multiple destination sites.

One feature provided by the target site resource module 87 is to provide for language differences in the target site without imposing this responsibility on the create/edit transaction listing module 85 or the main module 84 . Another feature provided by the target site resource module 87 is the ability to easily switch target sites without restarting the vendor application 66 . Another additional feature of the target site resource module 87 is the ability to configure the seller application 66 to easily work with other target sites (ie without changing the create/edit transaction listing module 85).

In an exemplary embodiment, each target site resource module 87 contains a set of dialog resources used by the create/edit transaction listing module 85 for that target site. Most of the information in the target site resource module 87 changes infrequently. Therefore, data elements that are expected to change frequently are downloaded through another mechanism (XML files), while the target site resource module 87 is downloaded only when required due to dialog layout changes or translation changes.

communication module

In the exemplary embodiment, the communication module 95 provides a connection to the web-based exchange 10 . Its services are used during several stages of operation of the seller application 66, including when checking site data versions, checking software module versions, downloading software modules, downloading site data, and propagating trade listing items 70 to web-based trading institutions 10 .

Communication module 95 encapsulates the formatting of standard elements in API requests. The communication module 95 also provides generic request/response functions for some common tasks such as obtaining version information, downloading software modules, downloading data elements, downloading all other miscellaneous data related to the target site, and creating new transaction lists Item 70.

data storage module

Data storage module 89 manages access to and from user-independent database 94 . The data that will be accessed includes user project list items, user settings, and application-wide data.

Data storage module 89 manages database access to local on-disk storage for both user files and application-wide data. This data can be stored as two types of files: an application database file (eg, vendor application database 97) and a user database file for each user created (eg, user-independent database 94).

The seller application database 97 contains tables for seller application 66 settings, available listing categories, and category attributes. For category and attribute tables, only create fields for important fields and fields that must be indexed. Other data is stored as XML big data type (blob).

The user independent database 94 contains tables for user settings as well as for projects. Again, only create fields for important fields and fields that must be indexed. Other data is stored as XML big data type.

import engine module

Import engine module 91 provides the ability to import transaction listings 70 from applications other than seller application 66 .

update manager module

The update manager module 92 is used to keep the vendor application 66 up-to-date, which involves managing several types of data and components:

application components

EXE, DLL, etc.

site configuration data

category

Attributes

options, constraints, etc.

user configuration data

Shop information

trading limit

payment address

etc.

In an exemplary embodiment, the most current data and components are available at the web-based exchange 10, and it is the responsibility of the seller application 66 to perform any necessary update.

The web-based exchange 10 may have an updated version of the data, but may not need to be updated. In this case, the user is made aware of the optional update and given the option not to receive the update.

Additionally, the web-based exchange 10 may have updated versions of more than one type of data for the seller application 66 . Some of these updates are required and some may not be. In an exemplary embodiment, if any available updates are required, all available updates are downloaded. Additionally, in the exemplary embodiment, if the user chooses to perform any optional updates, all available update data and modules are downloaded and applied. Additionally, in the exemplary embodiment, compression may be utilized to speed up the transfer of updates from the web-based exchange 10 to the seller application 66 .

Every upgradeable file has an associated version. This version includes the file name, major version, minor version, and timestamp. The vendor application 66 may be summarized by a list of version objects. In one implementation, the following is a summary of versionable files:

Seller Application Component File

seller_application.exe

Helper.exe

CreateTransactionListing.dll

Res001.dll

seller_application data file

Site001.XML (contains categories, domains, fees, options, etc.)

User003.xml

A "version string" is an XML element that has fields for major version component, minor version component, timestamp, filename, and upgrade requirement. These elements can be chained together to describe the entire system version. The following is an example of an exemplary version string:

<SELLERAPP_FILE_VERSION>

<FILENAME>RES001.DLL</FILENAME>

<MAJOR>1</MAJOR>

<MINOR>8</MINOR>

<TIMESTAMP>030802:22:01:01</TIMESTAMP>

<MINIMUM_VERSION_REQUIRED>

<MAJOR>1</MAJOR>

<MINOR>7</MINOR>

</MINIMUM_VERSION_REQUIRED>

// optional

<FILE_URL>http://www.ebay.com/files/sellerapp/res001.dll.gzip

</FILE_URL>

<INSTALLED/>

</SELLERAPP_FILE_VERSION>

In an exemplary embodiment, the vendor application 66 and the file versions at the web-based exchange 10 are compared and this comparison is used to determine whether the vendor application 66 or data elements need to be updated. The MINIMUM_VERSION_REQUIRED field is used to version files at the web-based transaction institution 10 . If the user's Vendor Application 66 version is below (or older than) the minimum required version, an update is required. Updates to this file are optional if the user's Vendor Application 66 version is equal to or higher (or newer) than the minimum required version.

In an exemplary embodiment, a user may decline optional or required updates. However, if updates are required and the user declines to accept them, the user may be limited in future communications with the web-based transaction institution 10 in the future. For example, if a user declines to accept a required update to a target site configuration file 86 (eg, a category update), the user may not be able to propagate the transaction listing 70 to the web-based exchange 10 for that target site.

The flowchart of FIG. 5 illustrates a method 100 for changing (ie, customizing) a seller application 66 for use with a target site, according to an exemplary embodiment of the present invention. The exemplary seller application 66 assists in facilitating the transfer of listings to the web-based exchange 10 . In an exemplary embodiment, the web-based exchange 10 supports multiple target sites (eg, websites). In another exemplary embodiment, the web-based exchange 10 supports a destination site.

Referring to FIG. 7 , a diagram 130 is provided illustrating an exemplary seller application 66 communicating with multiple websites. Seller application 66 may work with one website (eg, 132 ) or multiple websites (eg, 132 , 134 , 136 , 138 , and 140 ). Also, the seller application 66 can work with websites belonging to one web-based exchange 10, or the seller application 66 can work with a plurality of websites ( eg 132, 134 and 140) work together. For example, the seller application 66 can work with the website www.facility3.us 142 and the www.facility2.jp website 138 at the same time. In an exemplary embodiment, the seller application 66 may work with multiple websites (eg, business, education, charity, political, entertainment oriented, etc.). In one embodiment, the seller application 66 may be configured to only work with websites belonging to a particular web-based exchange 10 .

Returning to FIG. 5 , in the exemplary method 100 , the seller application 66 is used by the user at the client 38 to propagate the transaction listing 70 to the web-based exchange 10 . Method 100 begins at block 102 with accessing web-based exchange 10 at the request of a user. At block 104, the identity of the user is verified. In order to access the web-based exchange 10 through the seller application 66, the user must have previously obtained login information (eg, user ID and password). At block 106, the user is identified as a first-time logged-in user.

Users identified as logging in for the first time are asked to enter a variety of information including, but not limited to, billing address, personal address, payment address, and site specific for the region or population at which they wish to list the item (e.g., for Propagate transaction list item 70). At block 108, the user selects a destination site at which the item is desired to be listed from among a plurality of destination sites offered to the user. In one embodiment, one target site may represent multiple countries. Users can select target site preferences offline. This off-line selection becomes active and recognized when the user connects to the web-based exchange 10 .

At block 110, the user's seller application 66 is configured (eg, installed) so that it can communicate with the selected target site. In an exemplary embodiment, this configuration includes enabling the seller application 66 to utilize the currency of each target site when working with the currency-related fields for each target site. That is, when necessary, operations involving currency are performed in the currency type of the selected target site. These operations include entering currency values, displaying currency values, and calculating currency values. Configuration may also include preventing the dissemination of certain transaction listings 70 (eg prohibiting the dissemination of alcohol or tobacco on a commercial website serving teens). In an exemplary embodiment, configuring may also include providing the seller application 66 with category and attribute options available at the selected target site, or providing category and attribute options available specific to the target site. Additionally, the exemplary embodiment configures the seller application 66 to work in the corresponding language specified by the selected target site. Configuration of the seller application 66 may also include, but is not limited to, providing available format types (e.g., auction, store item (fixed price), etc.), reserve price options, payment options, shipping options, inspection options, image service options and options related to the cost of each transaction listing 70.

The flowchart of FIG. 6 illustrates a method 120 for arranging listings at a web-based exchange 10 via a seller application 66, according to an exemplary embodiment of the present invention. In the exemplary method 120 , a user utilizes the seller application 66 at the client to propagate the transaction listings 70 and their respective start times to the web-based exchange 10 . Each listing start time is the date and time that the web-based exchange 10 publishes the exchange listing 70 on the website. This may include, but is not limited to, transaction listings 70 that are about to be sold, auctioned, bartered, given away, or displayed. At block 122, a user interface is provided to the user for receiving at the seller application 66 a plurality of transaction listings 70 and their respective associated start times. At block 124, a batch of text 68 (eg, a data file) is constructed at the seller application 66 to include a plurality of transaction listings 70 and their respective start times. At block 126 , the batch of text created in block 124 is propagated to the web-based exchange 10 . In an exemplary embodiment, a user may include a plurality of transaction listings 70 in the bulk text 68, each transaction listing 70 including their respective start times. In an exemplary embodiment, bulk text 68 is created while the user is working offline. However, in an alternative embodiment, the user may connect to the web-based exchange 10 and enter the transaction listing 70 directly into the web-based exchange 10 through the seller application 66 .

The flowchart of FIG. 8 illustrates a method 150 for arranging a trade listing 70 at a web-based trade establishment 10, according to an exemplary embodiment of the present invention. In the exemplary method 150 , the transaction listing(s) 70 are provided from the user to the web-based exchange 10 via the seller application 66 . A user may provide transaction listing(s) 70 within a data file transmitted to web-based transaction establishment 10 via seller application 66 . At block 152 , the transaction listings 70 and their respective start times are received by the web-based transaction institution 10 . At block 154, the web-based exchange 10 schedules the publication of each deal listing 70 based on each deal listing's respective associated start time. At block 156 , the transaction listing 70 is posted according to the schedule devised in block 154 .

9 is a flowchart illustrating a method 160 for entering a deal listing description via the deal listing 70 description interface, according to an exemplary embodiment of the present invention. In the exemplary method 160 , the user utilizes the seller application 66 at the client to propagate the transaction listings 70 and their respective listing times to the web-based exchange 10 . At block 162 the user indicates that he wishes to enter a new transaction listing 70 . At block 164, the user is prompted to enter a description of the transaction listing 70 through the transaction listing description interface (ie, the "WYSIWYG interface"). The trade list item description screen is also known as the custom entry screen. In the exemplary embodiment, the WYSIWYG interface includes a first build user interface through which text can be entered and graphics can be selected to be included in the transaction listing item 70 . Additionally, in the exemplary embodiment, the WYSIWYG interface includes a second preview user interface for providing a preview of the transaction listing 70 as it is offered at the web-based exchange 10 . In one embodiment, the WYSIWYG interface includes a third build user interface for presenting transaction listing items 70 in a user-modifiable descriptor language (eg, HTML). At block 166, the transaction listing 70 is completed and saved.

The flowchart of FIG. 10 illustrates a method 170 for facilitating updates/upgrades of seller applications 66, according to an exemplary embodiment of the present invention. In the exemplary method 170, at block 172, the web-based exchange 10 receives a connection request from a user. The request is entered through the seller application 66 . At block 174, requestor login information is received and verified. In one embodiment, the verification includes verifying a user ID and login. In an alternative embodiment, the verification further includes verifying user status. For example, if the user is suspended from listing transaction listings 70 at the web-based transaction establishment 10, access may be denied. At block 176 , the web-based exchange 10 downloads the update/upgrade to the seller application 66 after verification. Before the web-based exchange 10 downloads the update/upgrade to the seller application 66, it is determined whether there is an update/upgrade of the seller application 66, and if so, the existing update/upgrade is downloaded to the seller application 66. In an exemplary embodiment, updating/upgrading includes category updating, attribute updating, program information updating and version upgrading, for example. Additionally, in the exemplary embodiment, updates/upgrades are only downloaded to the seller application 66 if automatic updates are enabled at the seller application 66 . At block 178, the update/upgrade of the vendor application 66 is automatically installed on the client machine after being received.

The flowchart of FIG. 11 illustrates a method 180 for downloading a seller application 66 from a web-based exchange 10 to a client machine 38, according to an exemplary embodiment of the present invention.

At block 182 , the web-based exchange 10 receives a request to download the seller application 66 . In one embodiment, this request may be received through user selection of a hypertext link (or other location identifier) that is displayed in the browser application 36 provided to the user within the context of the markup language document.

At block 184, the web-based exchange 10 also receives an identifier of the requesting user. The user provides the user identifier through an interface provided to the user in the form of a markup language document displayed by the browser application 36 .

At decision block 186 , the web-based transaction institution 10 determines whether the requesting user maintains credit card details associated with the web-based transaction institution 10 . Specifically, if the requesting user is a registered user of the web-based transaction institution 10, the web-based transaction institution 10 may require the relevant user to provide valid credit card details during the registration process.

At decision block 188, the network-based exchange 10 determines whether the negative feedback rating for the requesting user exceeds a predetermined minimum. Specifically, in one embodiment, the web-based exchange 10 provides a feedback mechanism whereby users can provide feedback from other users with whom they have conducted transactions. This feedback mechanism is useful for building trust among users of the network-based transaction institution 10, and also provides an indication of the trustworthiness and reliability of the users.

At decision block 190, it is determined whether the requesting user has been a registered user of the network-based transaction institution 10 for a predetermined period of time. For example, if the requesting user has only been a registered user for a few hours or less than a week, there may not be enough time to establish the requesting user's credibility, credibility, and reliability. Additionally, a user attempting to cheat with the web-based exchange 10 may have registered an alias to be used exclusively for such cheating. The checks performed at block 190 are intended to reduce access to the vendor application 66 for users who have not registered enough time to increase the likelihood of false registrations being detected.

If a negative decision is made in any of blocks 186 , 188 or 190 , the method 180 denies the download request at block 194 . On the other hand, if an affirmative decision is made in each of decision blocks 186, 188, 190, then at block 192, the network-based transaction institution 10 begins downloading the seller's application 66 to the client computer via the Internet 34 38. Method 180 then terminates at block 196 .

The detailed flowchart of FIG. 12 shows a detailed method 200 for customizing a seller application for disseminating transaction listing items 70 and their respective start times to a web-based trading institutions10.

By customizing the seller application 66, a user can utilize the seller application 66 to list deal listings 70 at multiple targeted sites (e.g., geographically targeted for each of the United States, Germany, United Kingdom, etc. site). The default display language of the seller application 66 may match the local language of the target site from which the application was downloaded. The user interface provided for creating and editing transaction listings 70 for a particular target site is displayed in a customized manner (eg, in the target site's native language). For example, if the user downloads the seller application 66 from the German site of the web-based exchange 10, the user interface may be provided in German. In another embodiment, if the user decides to create an item to be listed at the Taiwan target site, the process of creating a transaction listing 70 (ie, the series of user interfaces provided) will be displayed in Chinese. If the user wants to edit the item later, the edit item panel text will be displayed in Chinese.

If the seller application 66 needs to display text in a language for which the user has not installed the front-end toolkit, the user is prompted to download or install the front-end toolkit from the web-based exchange 10 . In an exemplary embodiment, when a user notifies the web-based exchange 10 through the seller application 66 that he wishes to be listed at a target site that requires a particular toolkit, the front-end toolkit is automatically downloaded and installed. The seller application 66 allows for the addition of additional target site(s). The ability to utilize additional target sites requires the user to select additional target sites, the web-based exchange 10 to download any necessary software modules and data elements to the user's seller application, install the software and data elements, And configure the seller application 66 to take advantage of the newly installed software and data elements. The user may select additional destination sites from the seller application 66 while offline or while connected to the web-based exchange 10 .

The content is displayed to the user in a customized manner, for example in the current language configured for the seller application 66 . Content displayed online (eg, at the target site) is in the local language of the current target site. In an exemplary embodiment, the date displayed at the seller application 66 has a format corresponding to the selected current target site. In an alternative embodiment, the date displayed at the seller application 66 is in the language selected by the user at the seller application 66 .

The seller application 66 may support site-specific transaction parameters, such as transaction limits. For example, a target site may have transaction limits enforced. The transaction limit is a preset amount of charges that a user can incur without a credit card on file, which varies from site to site. If the user has registered his/her credit card information for automatic monthly billing, the web-based exchange 10 allows the user to list without limitation, assuming the credit card information is valid. Otherwise, when the transaction limit is reached, the user may not be able to list any new items until a payment is made to bring the account balance below the transaction limit, or the credit card number is registered.

When a user attempts to send a transaction listing(s) 70 in bulk text 68 via the seller application 66, the web-based exchange 10 performs a transaction limit check. The network-based exchange 10 may not allow the transaction listing(s) 70 to be propagated if the fee corresponding to the transaction listing 70 to be issued at the network-based exchange 10 would cause the user to exceed their transaction limit . In an exemplary embodiment, if the transaction limit is exceeded before all transaction listings 70 in the batch text 68 are read, the network-based exchange 10 accepts all transaction listings 70 read prior to exceeding the transaction limit.

Transaction limit checking applies to the user's destination site registration. For example, if a target site (e.g., a German trading site) has transaction limits, a transaction limit check will be performed every time users registered with the German site attempt to send an item to a web-based transaction institution 10, regardless of whether the users are sending to The target sites submit their listings.

When selecting a particular target site, the seller application 66 utilizes the corresponding currency for that country. For example, when selecting a US destination site, all charges are displayed in US dollars. In an alternative implementation, the seller application 66 utilizes multiple national currencies. For example, in another embodiment, when a US destination site is selected, all charges are displayed in both US and Canadian currencies. In an exemplary embodiment, the seller application 66 recognizes and applies a format unique to the particular target site that the user has selected. As an example, for Germany and Taiwan, the currency field might only allow all numbers. Additionally, US, AU, CAN, UK include decimal separators (for cents). Also, France, Spain, Netherlands, Italy, Germany, Belgium (French) and Belgium (Dutch) have a comma separator (for minutes). Also, the Netherlands and Belgium (Dutch) have a comma separator for Buy Now (BIN) and Reserve Price, but only allow full numbers for minimum bids.

Referring again to FIG. 12 , the method 200 begins at block 202 where the user launches the seller application 66 . The method 200 proceeds to block 204, where the seller application 66 provides a welcome screen 250, an exemplary implementation of which is shown in FIG. 13A. Welcome screen 250 provides options to exit 252 , open sample file 254 , create new file 256 or open existing file 258 . In an exemplary embodiment, upon selection of one of the options 252-258, the "Next" button 260 is selected to initiate option selection. In an alternate embodiment, options 252-258 are automatically activated upon selection.

If Open Sample File 254 is selected, method 200 proceeds to block 206 where a sample screen of transaction listing 70 is provided to the user. However, if Create New File 256 is selected, then method 200 proceeds to block 210 where the process of entering transaction listings 70 into a collection (eg, batch text 68) is initiated.

On the other hand, if Open Existing File 258 is selected, method 200 proceeds to block 208 where the process of opening an existing collection (eg, bulk text 68) is initiated.

In an exemplary embodiment, if Create New File 256 is selected at block 210, method 200 proceeds to block 212 where vendor application 66 provides login interface 262, an exemplary implementation. Login interface 262 requires user ID 264 and password 266 . Login interface 262 includes a selection box 268 for notifying web-based exchange 10 of an intent to use seller application 66 for multiple target or custom sites. In an exemplary embodiment, a user ID and password must be obtained before a user can create a new file. In an alternative embodiment, a user may obtain a user ID and password upon connecting to the web-based exchange 10 .

At block 214 , the user issues a request to connect with the web-based transaction institution 10 . In the exemplary embodiment, after entering the user ID and password, the next button 270 is selected from the login interface 262 to connect to the web-based transaction institution 10 . The method 200 then proceeds to block 216, where the seller application 66 provides a connection interface 272, an exemplary implementation being shown in FIG. 13C.

At block 216, the user ID and password are verified upon selection of the "Connect Now" button 274 in the connection interface 272. If the network-based transaction institution 10 cannot verify the user ID and password, the user is requested to re-enter the user ID and password at the login interface 262 .

After verification at block 216, the method 200 proceeds to block 218, where the seller application 66 provides a personal information interface 276, an exemplary embodiment of which is shown in FIG. 13D. This personal information is used to identify users, ensure security, and facilitate the transaction process between users accessing the web-based transaction institution 10 . User information may be used to populate user preference fields such as payment address and location of transaction listings, and to determine the user's default destination site. In an exemplary embodiment, the seller application 66 includes a default target site. In this embodiment, the default target site is the site where the user downloaded the vendor application 66 . However, users can edit the default target site.

At block 220, it is determined whether the user wishes to use the seller application 66 at multiple target sites. If block 220 is a negative decision, then at block 222 the vendor application 66 is configured to work only with the target site (eg, the US site) from which it was downloaded. In one embodiment, configuring the seller application 66 includes configuring the seller application 66 to communicate with the web-based exchange 10 according to the agreement associated with the selected target site. Additionally, in one embodiment, configuring the seller application 66 includes configuring the seller application 66 to provide information to the user in a manner consistent with an agreement associated with the selected target site. On the other hand, if block 220 is affirmatively determined, method 200 proceeds to block 224 where seller application 66 provides target site interface 280, an exemplary embodiment being shown in FIG. 13E.

At block 224, a number of target sites to be used by the seller application 66 may be selected. In an exemplary embodiment, the destination sites interface 280 provides available destination sites. It will be appreciated that other target sites may define more or fewer target sites, or any other attribute that may distinguish one target site. For example, for a target site distinguished by a country name, the target site may define information above a country (such as a continent) and information below a country (such as a region, state, territory, province, etc. of a country). A user may select a target site by selecting a selection box adjacent to the intended target site. Multiple target sites can be selected. In an alternate implementation, the user may select a target site by scrolling through the list and highlighting the desired target site.

At block 226 , configuration information corresponding to the target site selected at block 224 is sent from the web-based exchange 10 to the seller application 66 . At block 228 , the seller application 66 is automatically configured with the information downloaded at block 226 . In an exemplary embodiment, configuration of the seller application may include providing software module updates, category updates, attribute updates, target site language updates, base language updates, various software miscellaneous data elements, and the like. After completing the configuration at block 228 , the seller application 66 may be used to propagate the deal listings 70 and their respective start times to the respective target sites selected at block 224 . Method 200 ends at block 230 .

The detailed flow diagrams of FIGS. 14A and 14B illustrate a method 300 of arranging a trade listing 70 at a web-based exchange 10 via a seller application 66, according to an exemplary embodiment of the present invention. In one embodiment, the method 300 is performed on the client side 35 by a separately executable vendor application 66 . In an alternative embodiment, the method 300 may be performed by a client-side 35 executable, such as a Java applet or ActiveX control, that executes within the context of a browser application. Some intelligence resides and executes on the client side 35 to assist in the easy entry of transaction listings 70 , for example by providing templates that allow users to define repetitive content shared by multiple transaction listings 70 . This avoids repeated entry for each transaction listing 70 . Furthermore, the method 300 directs the functions of the client side 35 to perform verification operations on the input data to check the allowable content and the legality of the content. Additionally, the method 300 suggests providing a list of allowable content, such as through a drop-down menu, from which the user can select legal content for a particular field of the transaction listing 70 . Furthermore, the method 300 provides the option of scheduling transaction listings 70 .

The method 300 begins at block 302 by invoking the seller application 66 on the client 38 of a user who wishes to construct a plurality of transaction listings 70 and propagate the transaction listings 70 and their scheduled start times to the Network of trading institutions10. For example, a high-volume user of a web-based exchange 10 may wish to propagate multiple deal listings 70, thus invoking the seller application 66. In one embodiment, the web-based exchange 10 may charge the user for each item trade listing 70 that the seller application 66 propagates to the web-based exchange 10 . In an exemplary embodiment, the fee is dependent on the user's level of service (eg, high-volume user discounts).

At block 304, the seller application 66 executes to provide a new item box. The new project box provided at block 304 includes a create new project interface 350, an exemplary implementation of which is shown in FIG. 15A. The new item box prompts the user to select a type of transaction corresponding to transaction list item 70 . In an exemplary embodiment, the types of deals available at create new item interface 350 include, but are not limited to, auctions 352 , stores 364 , and ad formats 380 . Also, the create new item interface 350 provides a drop-down list of sites 358 from which the transaction listing 70 (or bulk text 68 comprising a plurality of transaction listings 70) will be propagated to the target (eg country) sites from the list. In an exemplary embodiment, if the drop-down list 358 is not selected, the target site from which the seller application 66 is downloaded is selected.

At block 306, the user selects the "Next Step" option provided in association with the create new item interface 350, in response to which the seller application 66 prompts the user to obtain information (e.g., name, category) associated with the transaction listing item 70 etc). In an exemplary embodiment, prompting at block 306 is performed through a new item interface 362, one example of which is shown in FIG. List item 70. If the user selects a store format 354 or an ad format 356 in the create new item interface 350, a different dialog box is provided.

In the exemplary embodiment, the illustrated new item interface 362 includes a plurality of input fields to receive an item name 364 , a first item category 366 , a second item category 368 , and a store category 370 . Each of the three category input fields includes drop-down lists to facilitate user selection of categories. New item interface 362 also includes properties 376 . Attributes are category-specific information items that sellers can specify to help buyers find an item, and may not be available in all categories. An example is the property-residence category. For example, when listing an item in this category, the user could be prompted to specify number of bedrooms, number of bathrooms, square footage, air conditioning, pool (dropdown: none, ground, non-ground), and more. These attributes allow buyers to indicate that they are looking for properties based on available attributes (eg, number of bedrooms, number of bathrooms), etc. - items in the residence category. Some other examples of classes with attributes include computers (eg, processor speed, hard drive size), clothing (eg, model, brand, color), and ticketing (eg, event type, city, state, denomination, etc.). Almost any category can be further described using attributes 376 . To assist in navigating between the multiple screens used when creating the transaction listing 70, a "Back" button 372 and a "Next" button 374 are also shown, selection of which allows the user to advance through multiple screens at once .

At block 308, the user selects the "Next Step" option provided in association with the new item interface 362, in response to which the seller application 66 prompts the user to obtain more detailed descriptive information associated with the transaction listing item 70 ( e.g. transaction list item details). In an exemplary embodiment, the prompting at block 308 is performed through a transaction listing description interface 450, such as shown in FIG. 16A. The transaction listing item description interface 450 will be further described below with reference to FIG. 17 .

After entering the transaction listing description at block 308, the method 300 proceeds to block 310, where the seller application 66 provides a format details interface 378, an exemplary embodiment of which is shown in FIG. 15C. Various data items may be included in the format details interface 378 . Exemplary data items shown include listing period, pricing, quantity, payment, and shipping data items. An "Optional Features" area with multiple selection boxes is also provided so that the user may specify that particular transaction listing items should be distinguished or highlighted, visually or otherwise, when displayed by the web-based transaction institution 10 . For example, transaction listing item 70 may be bolded, displayed with a particular background color, or have a graphical image or icon associated therewith.

At block 312, the user selects the save option 380 provided in association with the format details interface 378, in response to which the seller application 66 performs a validation check to determine whether the user has entered sufficient information to form a valid transaction listing 70, or if further information is required. For example, a user may inadvertently forget to enter a starting price.

After affirmative verification, the method 300 proceeds to block 314, as shown in FIG. 14B, where the seller application 66 provides an inventory interface 382, an exemplary implementation being shown in FIG. 15D. The item inventory interface 382 provides a selectable list of transaction listing items 70 in a collection 306 associated with the target site selected at block 304 . The user may begin entering another item that should be included in collection 306 by selecting “New” button 384 . In an exemplary embodiment, the user may also delete 386 or edit 388 transaction listing items 70 via the item inventory interface 382 .

In an exemplary embodiment, inventory interface 382 provides a listing summary of all transaction listings 70 that make up bulk text 68 . Specifically, the main window 390 may include multiple columns that display name, quantity, lowest price, reserved price, and priority list item price information to the user in a tabular form. The user can double-click on any row of the transaction listings 70 provided in the main window to facilitate editing or deletion of the transaction listings 70 .

In the exemplary embodiment, a scheduled start date and start time 392 may be selected at which the web-based exchange 10 should post the associated bulk text collection 68 of the trade listing 70 . If the user does not wish to provide a scheduled start date and time, the default scheduled date and time is "Start Immediately" 394 after propagation to the web-based trading institution 10 . In an alternative embodiment, each listing 70 in collection 306 may be individually assigned a start date and time.

At block 316 , the user decides to provide a scheduled start date and time 392 at which the collection 306 of trade listings 70 will be posted at the web-based exchange 10 .

At block 318 , the user optionally specifies an interval 396 for staggering when the plurality of trade listings 70 in the set 306 are posted at the web-based exchange 10 . For example, a user may specify that the set 306 of transaction listings 70 begin at 9:00 PM on July 4, 2002, and then specify that a 5-minute interval should be included between each transaction listing 70 in the set 306 . Thus, if there are 3 transaction list items 70 in the collection 306, the first will start at 9:00PM, the second at 9:05PM, and the third at 9:10PM. The word "start" can also be understood as publishing at the selected target site.

At block 320, the user selects the "Add to Propagate" option 392 provided in association with the item inventory interface 382, in response to which the seller application 66 provides a list item interface 400 waiting to be propagated, shown in Figure 15E. An exemplary implementation.

At block 322, the user selects the "spread all" option 402 provided in association with the wait to propagate interface 400, in response to which the seller application 66 prompts the user for a web-based exchange password.

At block 324, the set 306 of transaction listings 70 is propagated to the web-based exchange 10 after user authentication.

In one embodiment, bulk text 68 as described above is propagated from client 38 to web-based exchange 10 via a web-based exchange API. In an alternate embodiment, bulk text 68 may be transmitted via email messages.

Each deal listing 70 may include a deal listing description. In an exemplary embodiment, the transaction listing description may be entered through the transaction listing description interface 450, an exemplary embodiment is shown in FIG. 16A. Transaction listings 70 include, but are not limited to, text, one or more pictures, and formatting (eg, layout, color, font, etc.). In an exemplary embodiment, the transaction listing description interface 450 provides three optional dialog boxes to assist in entering a transaction listing description. The three dialog options include design view option 452 , HTML view option 454 and preview view option 456 . The design view option 452 when selected will allow the user to enter descriptive text 458 in the WYSIWYG settings. HTML view option 454 allows users to enter HTML code for their transaction listing item descriptions. A preview view option 456 allows the user to preview the transaction listing item description based on the HTML defined by the WYSIWYT editor or the HTML code entered by the user. An exemplary implementation of the preview view dialog box 478 is shown in FIG. 16C.

Using the design view dialog 466, the user can enter descriptive text 458 and format it using editing tools. If the user has enabled multi-site support, a prompt is displayed indicating that the transaction listing 70 should preferably be in the local language of each target site. The Design View toolbar includes toolbar items that users can use to format their presentations. Each toolbar button has a tooltip.

In an exemplary embodiment, for double-byte character languages, the available font and text controls are displayed appropriately. For example, Chinese font sets are different from Western ones, and thus are not compatible with bold, italic, or underlined. If the user is writing in Chinese, Chinese fonts can be used and only applicable text controls should be displayed.

Descriptive text 458 entered in design view dialog 466 is interpreted as text, including descriptor text (eg, HTML code). However, the user may enter descriptor text in the descriptor text view dialog box 470, an exemplary implementation of which is shown in FIG. 16B. Descriptor text (eg, HTML code) is entered in the Descriptor Language Code window 472 . Descriptor language code window 472 is automatically populated with descriptor text (eg, HTML code) based on any text previously entered in design view dialog box 466 .

In an exemplary embodiment, the deal listing description interface 450 also provides a template 460 for improving the deal listing 70 . Each of the templates may include a theme (eg, including a color scheme) 462 and a layout 464, as shown in FIG. 16A. Themes 462 and layouts 464 are independently selectable. In addition, the user may add a picture to the transaction listing 70 through the transaction listing description interface 450 . The pictures may be added through a picture service, which may be available through the web-based exchange 10 or another network establishment, or the picture may be added through a picture service supported by the user himself, or from a picture service stored on the user's computer set of images on . The picture may be added to an image field included in the transaction listing description interface 450 .

Themes 462 may define table border colors, any border images, background colors (only used to describe areas), etc. Layout 464 may provide a display location for descriptive text and pictures. The layout 464 displayed to the user may be specific to their picture support preferences. The seller application 66 may also provide an "auto-size" option. This option, when enabled, resizes the user's image to the optimized template image size.

The seller application 66 may also provide a default set of color schemes and layouts. 5 to 10 are available (e.g. color schemes and layouts). The web-based exchange 10 may update and add templates through updates/upgrades to the seller application 66 . In an alternate embodiment, users can design their own layouts and themes. In another alternative implementation, layouts and themes can be imported.

Other special functions include "supersize" 463 and slideshow 465, which can be used to improve and/or change the display of pictures. In an exemplary implementation, the extra large option 463 is included in the left navigation bar of the transaction list item description interface 450 . In an exemplary embodiment, supersize 463 may be applied to all IPIX pictures where appropriate. Additionally, in the exemplary embodiment, the oversize 463 is only available to users who are utilizing the web-based exchange 10 image service. An oversized 463 option allows users to enlarge the size of images contained in their transaction listings 70 .

Slideshow 465 features are selectable through dedicated slideshow layouts. The dialog shown from this template allows adding up to 6 images at a time instead of just one. Therefore, the Slideshow 465 feature allows users to add up to 6 pictures in one image area instead of just one. The pictures added by the slideshow 465 function are displayed at the web-based trading establishment 10 along with the transaction listing items 70 . A slideshow consists of presenting a series of pictures, one at a time. These pictures are displayed in the same position on the monitor. For example, each picture (eg, pictures 1-6) is provided to a user viewing a trade listing 70 containing a slideshow presentation for a period of time (eg, 5 seconds) defined by the web-based transaction institution 10 . The series of pictures in the slideshow loops continuously until one is selected, or the user closes or exits the window containing the transaction list item 70 .

The detailed flowchart of FIG. 17 illustrates a method 500 for entering a deal listing description through the deal listing description interface 450, according to an exemplary embodiment of the present invention. Method 500 begins at block 502 where seller application 66 provides transaction listing description interface 450 . As noted above, the transaction listing item description interface 450 includes a design view option 452 , an HTML view option 454 , and a preview view option 456 .

At block 504 , the user selects the design view option 452 , in response to which the seller application 66 provides the user with a design view dialog 466 . In the exemplary embodiment, the design view dialog 466 is the default dialog and is provided to the user in the transaction list item description interface 450 at block 502 . At block 506 , the user enters descriptive text 458 in design view dialog 466 . While in the design view dialog 466 the user may select the preview view option 456 or the HTML view option 454 .

At block 508, the user selects the HTML view option 454, in response to which the seller application 66 provides the user with a descriptor language dialog box 470, an exemplary embodiment of which is shown in FIG. 19B. Based on the descriptive language 458 previously entered at block 506, the descriptor language code portion 472 of the descriptor language dialog box 470 is automatically populated with descriptor language codes (eg, HTML codes). A user can modify (eg add, delete, edit) the descriptor language codes in the descriptor language codes section.

At block 510, the user selects the preview view option 456, in response to which the seller application 66 provides the user with a preview view dialog box 478, an exemplary implementation of which is shown in FIG. 16C. The preview view dialog box 478 displays the description of the transaction listing item as it would appear when posted at the web-based transaction institution 10 . Content cannot be edited in the preview view dialog 478 .

At decision block 512 , it is determined whether the user wishes to enter a picture corresponding to transaction listing 70 .

At block 514, if an image is to be entered, the image is retrieved and attached to the transaction listing item 70. The user initiates the picture selection process by selecting the “Select Picture” button from the design view dialog 466 . In an exemplary embodiment, the image support service of the web-based exchange 10 or a user-specified image support service may be utilized, or the image may be selected from a collection stored on the user's computer.

At block 516 , the layout 464 to be utilized in the display of the transaction listing 70 is selected. Layout 464 is an optional option available on the WYSIWYG interface. Utilizes the default layout if not selected.

At block 518 , the theme 462 to be utilized in the display of the transaction listing 70 is selected. Theme 462 is an optional option available on the WYSIWYG interface. Utilizes the default theme if not selected. Method 500 ends at block 1210 .

The detailed flow chart of FIG. 18 illustrates a method 550 for arranging for receipt of listings entered through a seller application 66 at a web-based exchange 10, according to an exemplary embodiment of the present invention. In an exemplary embodiment, transaction listings 70 define the parameters and content of an online business process (eg, online store, online auction). It will be appreciated, however, that the transaction listing 70 may provide any transaction parameters (eg, the product or service to be sold by any means, or a description of the product service requirements). Specifically, in an alternative embodiment, the transaction listing 70 may describe a product or service that is offered for a fixed price through a classified advertisement, or that is offered and desired in the context of a B2B transaction or electronic marketplace .

Method 550 begins at block 552 with receipt of bulk text 68 at web-based exchange 10 .

At block 554 , the analyzer module 76 of the transaction application 311 analyzes the batch of text 68 to extract the individual transaction listings 70 contained therein, and performs various validation operations associated with each extracted transaction listing 70 .

At block 556, the transaction application 311 transmits a confirmation message to the client 38 confirming the successful receipt and extraction of the various transaction listings 70, including their respective scheduled start times. In one embodiment, the confirmation message may comprise an email message transmitted from the email server 22 of the web-based transaction institution 10 . In an alternative embodiment, the page server 12 may generate a markup language document (eg, HTML document) in response to the user's request, which transmits the confirmation message to the user. The acknowledgment message sent to client 38 at block 556 may also include a location identifier (e.g., a Uniform Resource Locator (URL)) that provides a link to the text that parser module 76 extracted from bulk text collection 68 at block 554. A list item for a collection of transaction list items 70 . In an alternative embodiment, the confirmation message itself may provide a list of such transaction listings 70 . For example, a confirmation message emailed to client 38 may include an HTML document providing a list of transaction listings 70 contained in bulk text 68 containing said collection 306 .

At block 558, the user is provided with interfaces to facilitate browsing and editing of the propagated collection of transaction listings 70 (eg, in the form of bulk text 68). Thus, the user may update the transaction listing 70 after the transaction listing 70 has been propagated to the web-based exchange 10 via a data file (eg, bulk text 68). The user may update the transaction listing 70 online while connected to the web-based exchange 10 , or the update may be made at the seller application 66 and propagated to the web-based exchange 10 . In one embodiment, the various interfaces that facilitate browsing and editing of transaction listings 70 may be markup language documents generated by page server 12 and transmitted to client 38 over Internet 34, wherein transmission to client 38 is For browsing in the context of the browser application 36 . For example, these interfaces in the form of markup language documents may be invoked by a user's selection on the client side 35 of the URL contained in the confirmation message transmitted at block 556 . In an alternative embodiment, the interface provided at block 558 may be generated by the seller application 66 using text and data passed from the transaction application 311, for example. 19A and 19B illustrate exemplary interfaces 600 and 602 that may be provided to users by the web-based exchange 10 to allow browsing, editing, previewing, and confirmation of collections of trade listings 70 as well as individual trade listings 70.

The seller application 66 includes the ability to automatically update/upgrade itself with specific information provided by the web-based exchange 10 .

The detailed flowchart of FIG. 20 illustrates a method 650 for assisting in the updating/upgrading of seller applications 66, according to an exemplary embodiment of the present invention. Method 650 begins at 652 where seller application 66 connects to web-based exchange 10 .

At block 654 , the web-based exchange 10 determines whether there are updates/upgrades that the seller application 66 has not received. To support minimal updates/upgrades, data elements (e.g., target site configuration file 86) and modules (e.g., main module 84, communication module 95, resource module 81, etc.) available versions are compared with the versions of data elements and modules installed at the vendor application 66. Download updates/upgrades for changed software modules and data elements. Downloaded data can be compressed to reduce transfer time. As mentioned above, in an exemplary embodiment, updating/upgrading includes, but is not limited to, category updating, attribute updating, program information updating, and version updating. For categories, the seller application 66 determines whether there is a new/different category structure for any target sites for which the seller application 66 is enabled. It is beneficial to provide automatic category updates to the seller application 66 when connected to a web-based exchange 10, since categories may change frequently (eg, once a month).

For attributes, the seller application 66 determines whether there is a new/different attribute structure for any target sites for which the seller application 66 is enabled. As mentioned above, attributes are category-specific items of information that sellers can specify to help buyers find items, and may not be available for all categories. An example could be the property-residence category. For example, when listing an item in this category, the user may be prompted to specify number of bedrooms, number of bathrooms, square footage, air conditioning, sink (dropdown menu: none, above ground, off ground), etc.

Buyers are then provided with a selector tool to use when searching, which allows specific property requirements to be specified (eg in the Property-Residence category, "New York", 4 bedrooms and 2 bathrooms could be in the project title). Without attributes, sellers can specify this information, but it is not standardized and thus cannot provide a reliable search mechanism. With attributes, you can assure users that they are searching for and getting the correct information.

Some other example categories with attributes include computer categories (processor speed, hard drive size, etc.), clothing (or apparel) categories (model, brand, color, etc.), and ticketing categories (event type, city, state, denomination, etc. wait).

In an exemplary embodiment, a version upgrade includes modifications (eg, software changes) made to the vendor application 66 . These modifications may also be referred to as program updates. In an exemplary embodiment, updates/upgrades of the seller application 66 may also be postponed. However, the web-based exchange 10 may force upgrades (eg, major program changes) or updates (eg, major class changes). Users do not have the ability to exclude mandatory updates or upgrades.

At block 656 , if the network-based exchange 10 determines that there is an update/upgrade to the seller application 66 , the update/upgrade is downloaded to the seller application 66 . In one embodiment, updates/upgrades are only downloaded if automatic updates of the seller application 66 are enabled. Following an affirmative decision in decision block 656, method 650 proceeds to block 658 where the update/upgrade is automatically installed. In an exemplary embodiment, the seller application 66 includes routines for automatically installing updates/upgrades. In an alternative embodiment, an installation routine is downloaded with each update/upgrade series. The installation routine is configured to automatically start and install the program update/upgrade when the download is complete. In one embodiment, the installation routine is configured to be automatically launched only if automatic updating of the vendor application 66 is enabled. Method 650 ends at block 660 .

21A-21C provide further details of the database structure that may be maintained by the database engine server 26 to support the methods described above.

In FIG. 21A , the batch table 42 includes a record for each set of transaction listings 70 as initially described, such as within the batch text 68 received at the web-based exchange 10. .

There is a one-to-many relationship between the batch table 42 and the batch item table 40. The batch item table 40 includes the transaction listing items 70 extracted from the batch text 68 into the database 30 by the analyzer module 76, but these transaction listing items 70 have not yet been to the scene.

The item waiting table 44 stores loaded transaction listing items 70 that are waiting on site as described above. The item table 60 stores a record of the actual trade listings 70 that have come to the scene by the web-based exchange 10 initiating a trade process (such as an auction process or a sale price).

21B and 21C show entity relationship diagrams that provide further details of exemplary fields that may be supported by bulk tables, bulk item tables, item wait tables, item tables, user tables, and related tables.

Fig. 22 shows a schematic representation of a machine in the exemplary form of a computer system 800, within which a set of instructions may be executed to cause the machine to perform any of the methods described above. In other embodiments, the machine may include a network router, network switch, bridge, personal digital assistant (PDA), mobile phone, web appliance, set-top box (STB), or any other device capable of executing a sequence of instructions specifying the actions to be taken. machine.

Computer system 800 includes processor 802 , main memory 806 , and static memory 808 , which communicate with each other via bus 824 . Computer system 800 may also include a video display unit 812 (eg, a liquid crystal display (LCD) or a cathode ray tube (CRT)). Computer system 800 also includes alphanumeric input device 814 (eg, keyboard), cursor control device 816 (eg, mouse), disk drive unit 818 , signal generating device 822 (eg, speaker), and network interface device 810 .

Disk drive unit 818 includes a machine-readable medium 820 on which is stored a set of instructions (ie, software) 804 embodying any or all of the methods described above. Software 804 is also shown as residing, wholly or at least partially, within main memory 806 and/or processor 802 . Software 804 can also send/receive via network interface device 810 . For this specification, the term "machine-readable medium" should be understood to include any medium as long as it can store or encode a sequence of instructions to be executed by a machine and cause the machine to perform any method of the present invention. The term "machine-readable medium" should accordingly be understood to include, but not be limited to, solid-state memories, optical and magnetic disks, and carrier signals. Also, while the software shown in FIG. 22 resides within a single device, it should be appreciated that the software 804 may be distributed across multiple machines or storage media, which may include the machine-readable media.

Thus, a method and system have been described for arranging deal listings at a web-based exchange through a seller application. Although the invention has been described with reference to specific exemplary embodiments, it will be apparent that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

In the foregoing detailed description, the method and system of the present invention have been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. In particular, the different blocks of the various block diagrams represent functional blocks of the various methods and apparatuses, and do not imply physical or logical divisions or order of operations inherent in the spirit and scope of the invention. For example, the blocks of Figures 11a and 11b represent parts of a method which, in some embodiments, may be reordered or organized in parallel rather than linearly or stepwise. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims (52)

1. A method of facilitating the propagation of a plurality of trade listings to a web-based trading institution, the method comprising: providing an input interface at the seller application for receiving a plurality of transaction listings from the user, each transaction listing including an associated start time; constructing a data file at the seller application to include the plurality of transaction listings; and The data file is propagated from the client computer to the web-based exchange using the seller application. 2. The method of claim 1, comprising executing the seller application to provide a plurality of input interfaces for receiving respective ones of the plurality of transaction listings. 3. The method of claim 2, comprising: executing the seller application to provide the plurality of input interfaces for further receiving an associated start time of each transaction listing in the plurality of transaction listings. 4. The method of claim 1, wherein the associated start time is a future start time. 5. The method of claim 1, wherein, for at least a portion of the plurality of transaction listings in the data file, the associated start times include different start times. 6. The method of claim 5, wherein the association start time comprises a start date and time of a first transaction listing in the data file. 7. The method of claim 6, wherein transaction listings subsequent to the first transaction listing have staggered association start times. 8. The method of claim 7, wherein the association start times are staggered by a user-selectable amount of time. 9. The method of claim 1, comprising executing the seller application to update the transaction listing after disseminating the data file to the web-based exchange. 10. The method of claim 9, wherein said updating comprises establishing a connection with said web-based transaction institution and using the established connection to update said transaction listing online. 11. The method of claim 9, wherein said updating comprises generating an update of said transaction listing offline at said seller application and then propagating said update to said web-based transaction establishment. 12. The method of claim 1, comprising executing the seller application to prevent the user from specifying an association start time that exceeds a maximum pre-scheduled value. 13. The method of claim 12, wherein the maximum prescheduling value includes a number of days that a transaction listing can be prescheduled. 14. The method of claim 1, comprising executing the seller application to prevent the user from specifying an association start time below a minimum scheduled value. 15. The method of claim 14, wherein the minimum scheduling time value includes a minimum amount of time that a transaction listing can be scheduled. 16. The method of claim 1 including charging a fee for each transaction. 17. The method of claim 16, wherein the fee is dependent on a user's level of service. 18. A method for receiving and arranging a plurality of transaction listings sent by a seller application at a web-based transaction establishment, the method comprising: At the network-based exchange, a data file is received from the seller application running on a client machine, the data file including a plurality of transaction listings, each of the plurality of transaction listings including Association start time; scheduling publication of each of the plurality of deal listings at the web-based exchange based on the associated start time; and Each of the plurality of trade listings is posted at the network-based exchange based on a respective associated start time. 19. The method of claim 18, wherein "receiving said data file at said web-based exchange" comprises said web-based exchange authenticating said seller prior to receiving said data file User login information provided by the application. 20. The method of claim 18, wherein each associated start time of each of the plurality of transaction listings in the data file is specific to the respective transaction listing. 21. The method of claim 20, wherein each of the association start times includes a start date and time. 22. The method of claim 18, wherein each association start time for each of the plurality of transaction listings in the data file is different. 23. The method of claim 18, wherein the associated start times of the plurality of deal listings define a staggered posting schedule for the plurality of deal listings. 24. The method of claim 23, wherein the staggered time is a user-selectable amount of time contained in the data file. 25. The method of claim 23, wherein the start times are staggered by a user-selectable amount of time. 26. The method of claim 18, comprising updating said transaction listing items and their respective associated start times upon receipt of said data file at said web-based transaction institution. 27. A seller application for facilitating the propagation of a plurality of trade listings to a web-based exchange, the application comprising: an interface module, configured to provide an input interface to receive a plurality of transaction listing items, each transaction listing item in the plurality of transaction listing items includes a respective associated start time; a builder module for automatically constructing a data file comprising said plurality of transaction listing items; and a communication module for disseminating said data file from a client computer to said web-based transaction institution. 28. The seller application of claim 27, wherein the interface module provides a plurality of input interfaces for receiving respective transaction listings of the plurality of transaction listings. 29. The seller application of claim 28, wherein the plurality of input interfaces further receives a respective associated start time for each transaction listing of the plurality of transaction listings. 30. The seller application of claim 27, wherein the association start time is a future start time. 31. The seller application of claim 27, wherein, for at least a portion of the plurality of transaction listings in the data file, the associated start times include different start times. 32. The seller application of claim 31 , wherein the association start time comprises a start date and time of a first transaction listing in the data file. 33. The seller application of claim 32, wherein transaction listings subsequent to the first transaction listing have staggered association start times. 34. The seller application of claim 33, wherein the association start time is staggered by a user-selectable amount of time. 35. The seller application of claim 27, wherein the seller application executes to update the transaction listing after disseminating the data file to the web-based exchange. 36. The seller application of claim 35, wherein said updating comprises establishing a connection with said web-based exchange and using the established connection to update said transaction listing online. 37. The seller application of claim 35, wherein said updating comprises: generating an update of said transaction listing offline at said seller application, and then propagating said update to said web-based exchange . 38. The seller application of claim 27, including executing to prevent the user from specifying an association start time that exceeds a maximum pre-scheduled value. 39. The seller application of claim 38, wherein the maximum prescheduling value includes a number of days that a deal listing can be prescheduled. 40. The seller application of claim 27, including executing to prevent the user from specifying an association start time below a minimum scheduled value. 41. The seller application of claim 40, wherein the minimum schedule time value includes a minimum amount of time a deal listing can be scheduled. 42. The seller application of claim 27 including charging a fee per transaction. 43. The seller application of claim 27, wherein the fee is dependent on a user's level of service. 44. A system for receiving and scheduling a plurality of trade listings sent by a seller application at a web-based trade establishment, comprising: a communicator module including an analyzer for receiving a data file from a seller application running at a client, the data file including a plurality of transaction listing items and respective associated start times; a scheduler module that schedules publication of the plurality of deal listings based on their respective associated start times; and A publisher module that publishes each of the plurality of transaction listings at the network-based exchange based on an associated start time of the plurality of transaction listings. 45. The system of claim 44 including a communicator module for verifying user login information provided by the seller application prior to receiving the data file. 46. The system of claim 44, wherein the associated start times include different start times for at least a portion of the plurality of transaction listings in the data file. 47. The system of claim 46, the association start time comprising a start date and time of a first transaction listing in the data file. 48. The system of claim 44, wherein transaction listings subsequent to the first transaction listing have staggered association start times. 49. The system of claim 48, wherein the association start times are staggered by a user-selectable amount of time. 50. A web-based exchange establishment application for receiving and scheduling a plurality of trade listings at a web-based exchange, comprising: a communicator module including an analyzer for receiving a data file from a seller application running at a client, the data file including a plurality of transaction listing items and respective associated start times; a scheduler module that schedules publication of the plurality of deal listings based on their respective associated start times; and A publisher module that publishes each of the plurality of transaction listings at the network-based exchange based on an associated start time of the plurality of transaction listings. 51. A computer readable medium storing a sequence of instructions which, when executed by a machine, cause the machine to: providing an input interface at the seller application for receiving a plurality of transaction listings from the user, each transaction listing including an associated start time; constructing a data file at the seller application to include the plurality of transaction listings; and The data file is propagated from the client computer to the web-based exchange using the seller application. 52. A computer readable medium storing a sequence of instructions which, when executed by a machine, cause the machine to: At the network-based exchange, a data file is received from the seller application running on a client machine, the data file including a plurality of transaction listings, each of the plurality of transaction listings including Association start time; scheduling publication of each of the plurality of deal listings at the web-based exchange based on the associated start time; and Each of the plurality of trade listings is posted at the network-based exchange based on a respective associated start time.

Images