KR20100010037A - Method and system for scheduling transaction listings at a network-based transaction facility - Google Patents

Abstract

In accordance with the present invention, a method is provided that facilitates delivering a plurality of trade lists to a network-based trading facility. An input interface is provided in the merchant application to receive from the user a plurality of transaction lists, each of which includes an associated start time. In addition, a data file is created to contain a list of multiple transactions in the merchant application. In addition, the data file is transferred from the client computer to the network-based trading facility using the merchant application.

Description

METHOD AND SYSTEM FOR SCHEDULING TRANSACTION LISTINGS AT A NETWORK-BASED TRANSACTION FACILITY}

This application claims the benefit of US Provisional Application No. 60 / 387,638, filed June 10, 2002.

Field of technology

The present invention relates primarily to the field of network-based commerce, and more particularly, to a method and system for scheduling a transaction list in a network-based trading facility.

As the Internet, ubiquitous communication, and interaction platforms spread widely, ubiquitous online (or electronic) commerce is commonplace in many business environments. Traditionally, online commerce has been classified into business-to-business (B2B), business-to-consumer (B2C) and even business-to-employee (B2E) commerce. In a B2B environment, several online exchanges or markets (eg, vertical exchanges) have been established to facilitate electronic commerce between parties, for example within a vertical supply chain. Typically, such B2B exchanges provide a number of tools to facilitate commerce, such as aggregate and near real-time inventory information, Request for Quotation (RFQ) capabilities, and auctions.

In B2C and C2C environments, several market exchanges and trading facilities have been found to be widely used. Major electronic trading facilities (or markets) are operated by eBay Corporation. The electronic market is Yahoo! It is also provided by Inc. and Amazon.com. In addition, several online services are available at Yahoo! Yahoo! Provides on-line classification, such as a classified service.

Several on-line markets are used by merchants as important distribution channels, even if they are not the main distribution channel of the product. Typically, these so-called "power users" list many items to sell or auction daily. In addition, several retailers and traders have found Yahoo! Like classification, we use free, low-cost, classified advertising services provided on the Internet. For example, a used car sales operation can generate these various classified advertisements at any time through an on-line classified advertisement service. It would be helpful to provide merchants with a way to generate multiple items and deliver them to the network-based market.

In accordance with the present invention, a method is provided that facilitates delivering a plurality of trade lists to a network-based trading facility. The input interface is displayed in the merchant application such that each of the plurality of transactions from the user receives an associated start time. In addition, a data file is created to contain a list of multiple transactions in the merchant application. In addition, the data file is transferred from the client computer to the network-based trading facility using the merchant application.

Describes a method and system for scheduling a list of transactions in a network-based trading facility. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details.

Terms

The term "user" is treated as referring to any human or automated entity that contributes or participates in a transaction, communication, or process.

The term "transaction" is treated as including any communication or exchange between two or more parties in terms of establishing a business agreement, an exchange of values or a commercial relationship. Thus, the term "transaction" is considered to include, but is not limited to, the purchase and sale established, for example, as a result of an advertisement or as a result of the termination of an auction process performed online or otherwise.

The term "upgrade" is considered to include upgrades and updates. Thus, the term "upgrade" includes but is not limited to variations of existing software modules and data elements.

The term "destination site" means geography (e.g., continent, country, region, etc.), topic (e.g., beanie baby, baseball souvenir, antique car, etc.), purpose (e.g., commercial, non-profit, etc.), It is treated as including a target site (e.g., a website) according to demography (e.g., Spanish, English, etc.). Indeed, any combination of the above or other criteria may be used to describe the "destination site."

The term "website" is taken to mean a related collection of the World Wide Web (WWW) that contains a startup file called a homepage. Thousands of companies and individuals have one or many websites. The company or individual tells you how to access their website by giving you a homepage address. From the home page, you can access all other pages on the site. For example, eBay's website has a homepage address of http://www.eBay.com. EBay's homepage address leads to many different pages. (However, a website may be just a few pages.) A very large website can be spread across several servers in different geographical locations. A company's website consists of thousands of files spread across many servers located around the world. However, perhaps a more common example would be a website residing on a commercial space provider's web server with multiple websites, in which case all websites may or may not be related to each other.

While exemplary embodiments of the invention are described below in the context of "items", it will be appreciated that the invention is not so limited. Accordingly, the term "item" is considered to include, but is not limited to, a list of transactions.

The term "data file" is treated as meaning a collection of transaction lists. Thus, the phrase “data file” is considered to include, but is not limited to, a collection of trade lists that are being delivered to, for example, a network-based trading facility.

Trading equipment

1 is a block diagram illustrating an example network-based trading facility 10. Although an exemplary embodiment of the present invention is described within the context of network-based trading facility 10, the present invention may be applied to many other types of computer-based and network-based facilities (commerce, transactions, or the like).

In an exemplary embodiment, network-based trading facility 10 includes one or more of many types of front-end servers, each including one or more Dynamic Link Library (DLL) providing specific functionality. . Page server 12 delivers a web page (eg, markup language document), picture server 14 dynamically delivers the image to be displayed within the web page, and list server 16 categorizes the categories of lists. The search server 20, which facilitates based browsing, handles search requests to the network based trading facility 10, facilitates keyword based browsing of the list, and the ISAPI server 18 backs up the network based trading facility 10. Provide an intelligent interface to the end. The email server 22 provides in particular automatic email communication to users of the network-based trading facility 10. The management application (s) function 32 facilitates the monitoring, maintenance and management of the network based trading facility 10. API server 13 provides a set of functions for querying network based trading facility 10. APIs are a collection of easy-to-use functions called through the HTTP transport protocol. Information is sent and received using standard XML data formats. Applications used to interact with network-based trading facilities (eg, upload transaction lists, review transaction lists, manage transaction lists, etc.) can be designed to use the API. Such applications may be HTML forms or CGI programs written in C ++, Perl, Pascal, or other programming languages. APIs are described in more detail in US patent application Ser. No. 09 / 999,618, which is incorporated herein by reference.

Page server 12, API server 13, picture server 14, ISAPI server 18, navigation server 20, email server 22 and database engine server 26 are individually or in combination, eg For example, it operates as a communication engine that facilitates communication between the client machine 38 and the network-based transaction facility 10. In addition, the page server 12, API server 13, picture server 14, ISAPI server 18, navigation server 20, email server 22 and database engine server 26 may be individually or in combination. For example, it operates as a transaction engine that facilitates transactions between the client device 38 and the network-based transaction facility 10. In addition, the page server 12, API server 13, picture server 14, ISAPI 18, navigation server 20, email server 22 and database engine server 26, individually or in combination, For example, it operates as a display engine that facilitates the display of items between the client device 38 and the network-based trading facility 10.

The back end server includes a database engine server 26, a search index server 24 and a credit card database server 28, each of which maintains and facilitates access to each database.

The network-based trading facility 10 runs on the client device 38 and accesses the network-based trading facility 10 via a network such as, for example, the Internet 34, for example, the browser 36 (eg For example, it may be accessed by a client program such as Internet Explorer provided by Microsoft of Washington, Redmond. Other examples of networks that clients can use to access network-based trading facility 10 are wide area networks, local area networks, wireless networks (eg, cellular networks) or public. A switched telephone network (PSTN).

Database structure

2 is a database diagram illustrating an example database 30 that is maintained by, and accessed through, a database engine server 26 and that at least partially implements and supports the network-based trading facility 10. In an exemplary embodiment, database engine server 26 maintains two databases 30a and 30b, wherein first database 30a is not included in the virtual "store" in accordance with the present invention (or Maintained for offering information, the second database 30b stores product information for offerings provided through a virtual “store” supported by the network-based trading facility 10. The structures of these databases 30a and 30b are substantially the same, but differ in that the " store " database 30b can include a number of additional fields that facilitate virtual stores. A general description of the basic structure of database 30 is presented below, which can be applied to both database 30a and database 30b.

In one embodiment, database 30 may be implemented as a relational daabse and includes a number of tables having entries or records linked by indexes and keys. In another embodiment, database 30 may be implemented as a collection of objects in an object oriented database.

There is a user table 54 in the center of the database 30, which contains a record for each user of the network-based trading facility 10. When using the network-based trading facility 10, a user may operate as a seller, a buyer, or both. In addition, the database 30 includes an item table 60 that can be linked to the user table 54. The item table 60 may include a seller item table 52 and a bidder item table 58. User records in the user table 54 may be linked to a number of items that are being listed or provided for sale or that have been listed or provided through the network-based trading facility 10. The link indicates whether the user is a seller or a bidder (or buyer) for an item with a record in item table 60.

In addition, database 30 includes one or more category tables 47. Each record in the category table 47 describes a respective category. In one embodiment, specific category table 47 describes a number of hierarchical category data structures, each containing a plurality of category records describing the context of a particular category within one of the plurality of hierarchical category structures. For example, category table 47 describes a number of actual or actual categories to which item records may be linked within item table 60.

In addition, database 30 includes one or more attribute tables 49. Each record in attribute table 49 describes each attribute. In one embodiment, specific attribute table 49 describes a number of hierarchical attribute data structures, each comprising a plurality of attribute records that describe the context of a particular attribute within one of the plurality of hierarchical attribute structures. For example, attribute table 49 may describe a number of actual or actual attributes to which item records may be linked within item table 60. In addition, attribute table 49 may describe a number of actual or actual attributes with which categories may be linked within category table 47.

The database 30 also includes a note table 46 in which note records reside, which may be linked to one or more item records in the item table 60 and / or one or more user records in the user table 54. Each note record in note table 46 may include, among other things, comments, descriptions, history and other information relating to items being provided via network-based trading facility 10 or users of network-based trading facility 10. . The database 30 also includes a destination site table 67 in which a destination site resides that can be linked to one or more item records in the item table 60 and / or one or more user records in the user table 54.

In addition, a number of other tables, namely user past alias table 48, feedback table 50, feedback detail table 53, bid table 55, account table 64, account balance table 62 And the batch item table 40 are shown linked to the user table 54. In addition, to enable one embodiment of the present invention, the database 30 is shown to include a batch table 42, a batch item table 40, and an item waiting table 44. Further details of the database tables 40 to 44 are provided below.

The present invention relates to a method and system for scheduling a transaction list at a network-based trading facility (10). 3 is a block diagram illustrating a network based trading environment 67 including a client side 35 and a server side 71 in accordance with an exemplary embodiment of the present invention. In one embodiment, the transaction list 70 (eg, sales application, auction, fixed price list) is established on the network-based transaction facility 10 via the merchant application 66. Merchant application 66 is used at client device 38 to help communicate multiple transaction listings 70 to network-based trading facility 10. In one embodiment, merchant application 66 may be used offline, or may be used online (eg, connected to network-based trading facility 10). In one embodiment, merchant application 66 is a standalone application running on client device 38. In another embodiment, the communication of multiple transaction lists 70 may be performed using a server-enabled application, such as a web browser or an applet running within the web browser.

In one embodiment, the merchant application 66 is installed and executed on a client computer in terms of assisting the user in delivering multiple transaction lists 70 and their respective start times to the network based trading facility 10. do. Thus, merchant application 66 acts as a client application and provides a number of user interfaces and other functions to assist the user in defining a number of transaction lists 70 in a convenient manner. In addition, the merchant application 66 creates a data file (e.g., batch text 68) and their associated start time, including a plurality of transaction lists 70, and converts the data file as a single transmission into a network based trading facility. To (10). Delivery of such a single data file comprising multiple transaction lists 70 enables to reduce the number of interactions between the client device 38 and the network-based trading facility 10, thereby client device 38. Reduces the amount of time that must be connected to the network (ie, "online").

The associated start time includes different start times for at least a portion of the plurality of trade lists 70 in the data file. The associated start time can include the start date and time of the first transaction listing 70 in the data file 68. In an example embodiment, the start time may be staggered by a user selectable amount of time. For example, December 25, 2002 a.m. The transaction list 70 scheduled at 7:00 becomes as follows:

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

The second list of transactions starts at 7:05 a.m.,

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

The fourth transaction list starts at 7:15 a.m.

Thus, in this example, the start time of the four transaction lists 70 has a time difference of five minutes. In an exemplary embodiment, the user can select the time difference of the start time to several values (eg, 10 minutes, 1 hour, 10 hours, 1 day, etc.). In one embodiment, merchant application 66 prevents a user from specifying an associated start time for transaction list 70 if the associated start time exceeds a maximum advanced scheduling value. In addition, merchant application 66 prevents the user from specifying a time less than the minimum scheduling value. The maximum prior scheduling value and the minimum scheduling value may be defined in units of years, months, days, hours, minutes, or seconds defined by the network-based trading facility 10.

In one example embodiment, when the merchant application 66 is executable on the client side 35 as a standalone application, the merchant application 66 may allow the user to “offline” the way (eg, with the network-based transaction facility 10). Create a plurality of trade lists 70 with no network communication or session), and then convert these multiple trade lists 70 as a single data file transfer as described above into the network-based trading facility 10. It provides a feature that enables transmission to the network.

Another feature of the merchant application 66 executable on the client side 35 is that it can be configured to work with multiple purpose (eg, custom made) sites. Thus, the user can use the merchant application 66 to deliver the same list of transactions 70 to multiple destination sites (eg, geographic destination sites for each of U.S., UK, DE, etc.).

One embodiment of the present invention provides for the viewing, editing and confirmation of a number of transaction lists 70 by a user, facilitated on the server side, and also facilitated by a network based transaction facility 10 This multiple trade list 70 is turned active to initiate the process.

Referring again to FIG. 3, the environment includes a client side 35 and a server side 71. At client side 35, client device 38 (eg, a personal computer, PDA, cellular phone, set-top box, or any other network device) hosts merchant application 66 and browser application 36. Is shown. While merchant application 66 and browser application 36 are shown separately, browser application 36 operates as merchant application 66, for example, via retrieval of an HTML page or execution of an applet from server side 36. It may be configured to. Client device 38 is coupled to a network in the form of an exemplary Internet 34, or within any local area network (LAN) or wide area network (WAN).

In one embodiment, merchant application 66 displays a number of user interfaces to the user for the purpose of obtaining a number of transaction lists 70. In addition, merchant application 66 creates batch text 68 that includes a number of transaction lists 70 entered through a number of interfaces. The merchant application 66 then communicates the placement text 68 to the network based trading facility 10 in accordance with the network based trading facility API. In another embodiment, merchant application 66 interacts with email application 69 to compose an email (email) message that includes placement text 68. The batch text 68 is communicated to the network based trading facility 10 by the email application 69 as an email message. Specifically, the email application 69 uses one of a number of electronic email or message protocols (eg, Simple Mail Transport Protocol (SMTP)) to send email messages over the Internet 34. Of course, in other embodiments, it will be appreciated that any one of a number of other protocols (eg, File Transport Protocol (FTP)) may be used.

Returning to the server side 71, the network-based trading facility 10 may be a communicator module 75, a parser module 76, an upgrade control module 77, a scheduler module 80, and a publisher module 82. Is shown as executing a transaction application 73.

The communicator module 75, including the parser module 76, receives a data file from the merchant application 66 running on the client device 38, which data file includes a plurality of transaction lists 70 and respective associated start times. It includes. Parser module 76 operates to parse a number of trade lists 70 received from batch text 68. In addition, parser module 76 performs various formats, content, and authentication operations. The parser module 76 then resides in the extracted transaction list 70 in the item waiting table 44 maintained by the database engine server 26. Scheduler module 80 schedules the publication of the plurality of transaction lists 70 according to each associated start time. In the manner described below, the transaction list 70 is sent from the item wait table 44 to the live item table 60 according to their scheduled list time. The publisher module 82 publishes each of the plurality of transaction lists 70 at their network-based transaction facility 10 according to their associated time.

In one embodiment, the communicator module 75 authenticates the login information provided by the merchant application 66 with the connection request. This authentication occurs before receiving the batch text 68. When authenticating 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 merchant application 66 requires any update / upgrade. Such updates / upgrades include, but are not limited to, software components (eg, main modules) or data elements (eg, category updates, attribute updates, etc.).

Transaction application 73 also includes a page server 12, which in one example embodiment includes an Internet Server Application Program Interface (ISAPI) 18, which page server 12 is a Washington, DC, Washington, DC. And Internet Information Server, a web server developed by Microsoft Corporation of Redmond. In another embodiment, page server 12 may execute a Common Gateway Interface (CGI) program. The page server 12 generates markup language documents (e.g., web pages) using the content retrieved from the database engine server 26, and generates these markup language documents via the Internet 34 in a browser application ( 36) to dynamically communicate to the merchant application 66 for viewing. In one embodiment, page server 12 serves a plurality of successfully extracted from the list of trade list 70 by parser module 76 to serve reviewer page 72 and display within browser application 36. The list of transactions 70 is specified. This is done to allow the user to view, edit and view this transaction list 70 before this transaction list 70 is communicated from the item waiting table 44 to the effective item table 60.

Primary Architecture of Merchant Applications

In an example embodiment, the merchant application 66 architecture includes three layers. Three layers include a GUI layer, a data object layer, and a communication and database layer. Modules in the GUI layer handle all interactions with users and all management of resource files. The data object hierarchy includes data objects containing destination site data. The data object layer facilitates GUI development by encapsulating XML parsing of destination site data as well as data access. The communication and database layer provides a simplified interface to the rest of the merchant application 66. The upgrade manager (eg, the module described below) is provided to keep the three layers of merchant application 66 up-to-date. This includes managing some types of data elements (eg category data) and components (eg modules). The upgrade manager is further described below.

4 is a diagram illustrating an example merchant application 66. In the example embodiment, the merchant application 66 facilitates delivering the plurality of transaction lists 70 to the network-based transaction facility 10.

Merchant Application Component

In an example embodiment, merchant application 66 is main module 84, resource module 81, data object module 83, transaction list creation / editing module 85, destination site resource module 87, destination Site configuration file (86), communication module (95), data storage module (89), import engine module (91), upgrade manager module (92), helper module (93), user-independent database (94), Merchant application database 97, and configuration and registration module 96. Transaction list creation / editing module 85 includes an interface module 88 and a builder module 90.

Creating a Merchant Application

In the example embodiment, the merchant application 66 is created primarily using Microsoft standard libraries and components. The main executable and graphical user interface (GUI) based components use Microsoft Foundation Classes (MFC). MFC is a large library of C ++ classes developed by Microsoft. MFC is bundled with the C ++ compiler and is also available as part of the Microsoft Developer's Network (MSDN).

In an exemplary embodiment, the communication and database layer uses an OLEDB (OLE Data Base) and a Jet Engine. OLEDB is Microsoft's data connection interface. The application can use OLEDB to access the data source directly, or use OLEDB to access the ODBC database by calling ODBC. The Joint Engine Technology (JET) engine is a database engine used by Microsoft Access and involves Visual Basic and C ++. Typically, jets are used to store data on client devices. Developers using Access and Visual Basic access Jet through the DAO / Jet interface, a COM object.

In an exemplary embodiment, Microsoft components are used because many Microsoft components are already installed on many client devices 28. For example, if a user of merchant application 66 requires that Internet Explorer 5.0 or later be installed, there is a sufficient possibility of using the required version of the jet engine. In an example embodiment, a third tool may be used for the tool to parse STL and XML.

Multiple users and security in merchant applications

In an example embodiment, a multi-user environment is supported by using separate DBs (databases) for each user's preferences. When a user logs on, the database file for that user will be used. Password protection (eg Microsoft Access) is used to secure these user database files. In addition, text fields in the user database can be encrypted in a manner that does not affect performance, but can prevent curious users from hacking tables.

Some user related settings are stored in the merchant application database 97 (eg, site specific data). In the exemplary embodiment, only one merchant application database 97 exists. The merchant application database 97 is always opened by the merchant application 66 regardless of which user logs in. Merchant application database 97 includes a mapping from a network based trading facility user ID to a user related database file name for that user, so that the user dependent database filename does not represent a network based trading facility user ID. This scheme allows the user to change his network based trading facility ID and maintain his existing user related database 94. That way, if the user changes his or her ID and / or password, the stored item is not lost.

Adaptability of Merchant Applications

In an example embodiment, merchant application 66 is adaptable to use at a destination (geographically or otherwise) site. The merchant application string is stored in the resource module 81. Resource module 81 is composed of DLLs. The merchant application string is a string for the merchant application 66 language (eg, the first language) that is distinct from the string appearing in the target site language.

The user may select the first language he wishes to work with and optionally install another merchant application 66 language version. In an exemplary embodiment, switching the first language requires a restart. The first language may be different from the language of the destination site with which the user communicates.

In an exemplary embodiment, the first language used by merchant application 66 is translated into the language of the destination site that the user intends to communicate with. Translation may occur while merchant application 66 is connected to network-based trading facility 10.

Destination site language is the language and locale convention used at a particular destination site. Also, a collection of strings for the destination site language is stored in the destination site resource module 87. Destination site resource module 87 may be comprised of DLLs. In an example embodiment, the destination site data provided by the collection of strings associated with the destination site language may be executed during execution to allow the user to list items on multiple destination sites without restarting the merchant application 66. It may be switched. In order to achieve the conversion of the destination site language, the destination site resource module 87 must include an exact collection of strings for the destination site language.

In addition to the destination site specific translation of the string, this destination resource module 87 may also include a dialog site change specific to the destination site, which is a destination site with a different user interface used in the process of generating the transaction list 70. This makes it possible to be different in appearance. This reduces the amount of site-specific code needed to facilitate the process of generating the transaction list 70, while providing flexibility for users and designers.

In an exemplary embodiment, there is some destination site specific XML configuration data that includes an updatable value (eg, category, attribute, correct format, etc.). If this configuration data is changed for the destination site configured to work with merchant application 66, merchant application 66 must be updated to reflect that change. In the exemplary description, the modifiable destination site specific data may be stored in the destination site resource module 87 or XML file. The latest XML data is stored in the merchant application database 97.

Upgradeability of Merchant Applications

Merchant application 66 is designed to allow upgrades of both data elements and application modules. Upgrade manager module 92 and helper module 93 are used to facilitate such upgrades. Data elements are expected to change frequently. The data element is obtained through an existing API call to the network based trading facility 10. The data element upgrade provides the merchant application 66 with a recent set of categories, attributes, and destination site specific constants (eg, trading limits, publication periods, payment options, fee schedules, etc.). In the exemplary embodiment, destination site configuration file 86 is used to store the destination site data elements.

In the example embodiment, the merchant application 66 module may be upgraded much less frequently than the data elements. The Merchant Application 66 upgrade provides a recent set of Merchant Application 66 and destination site language translations, calculated principles (eg, the principle of associating user data with destination site data), and destination site specific dialog layouts. do.

In the exemplary embodiment, all merchant application 66 modules are upgradeable, even the main module 84. Upgrading the module is performed using the helper module 93. After downloading the new component, an assistant script is generated to instruct the assistant module 93 to replace the merchant application 66 module with the new version of the merchant application 66 module. Each time merchant application 66 is performed, this helper module 93 determines whether there is a possible file replacement to perform before starting main module 84.

In an example embodiment, to support a minimal upgrade, a versioning mechanism is used to install an installed version of the elements and modules of the merchant application 66 and the version available at the network-based trading facility 10. Compare the data elements and seller application 66 modules. The upgrade only attempts to download the modified merchant application 66 module and / or data elements. The downloaded data may be compressed to reduce the transmission time. Allowing code and data to be updated is a property that maximizes the upgradeability of merchant application 66.

In one embodiment, network-based trading facility 10 recognizes that merchant application 66 has been enabled to support a destination site for which support has not yet been downloaded and installed. Recognizing that such support has been downloaded and installed, the network-based trading facility 10 downloads the required support of the destination site (eg, data element, vendor application 66 module update).

Main module

In an example embodiment, the merchant application 66 main module 84 builds an MFC shell for all UI elements displayed using the current application language (eg, menus, toolbars, folders, inventory, and list views). Will provide. Main module 84 is the starting point for merchant application 66. All program flows and actions begin and end in main module 84, whether initiated programmatically or by a user.

At the beginning, main module 84 dynamically loads resource module 81 based on the user's current application language setting. This setting is stored in the user unrelated database 94. In order to change the application language, the user is required to restart the merchant application 66 in order for the change to be recognized. In other embodiments, the application language may be changed without restarting the merchant application 66.

In the exemplary embodiment, the main module 84 is also responsible for controlling the security of the merchant application 66 by requiring the user to enter a password and connecting only to the user related database 94 associated with that user. Merchant application 66 allows only one user dependent database 94 to be used at a time. To use a different user ID, the user must select a different user ID and enter a password for that user ID. Alternatively, you can exit and restart the program to log on as another user.

The user ID and password used to log on to merchant application 66 may be the same user ID and password configured for that user at network-based trading facility 10. If the user changes his ID and / or password at the network-based trading facility 10 without updating the merchant application 66, subsequent attempts to communicate with the network-based trading facility 10 may fail. An error message is provided to the user indicating that the login failed.

In the exemplary embodiment, the main module 84 allows only one instance of the merchant application 66 to run on the user system at a time. When the user attempts to execute a second copy, the first performing instance is activated (eg, the window is restored and called to the top of the desktop). In other embodiments, multiple merchant applications 66 may be run on a user system at the same time.

When creating / editing a new transaction list 70, the main module 84 calls the transaction list generation module 85. In the exemplary embodiment, the main module 84 is a single threaded application, which loads the rest of the required modules on demend.

Merchant Application Language Resource Module

In the example embodiment, the resource module 81 provides the ability to change the merchant application 66 language without any code changes. In addition, the resource module 81 enables the addition of a new merchant application 66 language with minimal installation time and effort. Each resource module 81 includes a complete set of resources for one language. Such resources include dialog templates, menus, icons, and language strings.

As mentioned above, the resource module 81 is loaded by the main module 84 when the merchant application 66 starts. The default merchant application 66 language is set when the merchant application 66 is installed and matches the language of the network-based trading facility 10 destination site (eg, geographic) from which the merchant application 66 was obtained. . Additional languages may be installed from the network-based trading facility 10.

In the exemplary embodiment, each resource module 81 is

String table

Dialog resource

Application icons, bitmaps, etc.

Includes a full set of all resources for the main module, including.

The resource module 81 uses a naming convention in order for the merchant application 66 to know which resource module 81 contains which language; for example, res001.DLL is US English, res002.DLL is German, res003 May ...

Data object module

In the example embodiment, the data object module 83 provides a data model DB that is independent of the merchant application 66 for the category, domain, attribute, item, and site. The data object module 83 may be configured with a dynamic link library (DLL).

The data object included in data object module 83 provides merchant application 66 with data-store independent access to merchant application database 97. A data object can encapsulate XML analysis when the associated data contains an XML string and provide the client with a C ++ accessor function for the data field. If the client requires underlying XML, the data object module 83 may provide it.

There may also be data objects for categories, domains, attributes, and site data. In an exemplary embodiment, the data object is created as a factory function that is exported by a DLL that contains implementation code for the data object. The factory function returns a pointer to the interface supported by the data object. Supported interfaces are defined in header files included by any client code that requires them.

Transaction list creation / editing module

In an example embodiment, merchant application 66 transaction list creation / editing module 85 displays all UI (user interface) elements in the language of the destination site. The transaction list generation / editing module 85 is configured to show the correct set of SYI fields / properties / fees etc. per destination site. One feature provided by the transaction listing generation / editing module 85 is to encapsulate item related knowledge and logic in a single module to minimize the size of future updates. Another feature is to provide a site language independent implementation to allow creation of a transaction list 70 for different destination sites using the merchant application 66 language. Transaction list generation / editing module 85 includes an interface module 88 and a composer module 90. Interface module 88 provides an input interface for a user to receive a plurality of trade lists 70, each of which includes a respective associated start time. The builder module 90 may automatically create a data file that includes a plurality of transaction lists 70 received by the interface module 88. The communication module 95 transfers the data file generated by the builder module 90 from the client computer to the network-based trading facility 10.

Destination Site Resource Module

In an example embodiment, a destination site resource module 87 is provided. Similar to resource module 81, destination site resource module 87 includes resources for only one language. Each time a user creates a new transaction list 70 or edits an existing transaction list 70, the transaction list creation / editing module 85 loads the appropriate destination site resource module 87. Destination site resource module 87 includes a dialog template, an icon, and a language string.

Destination site resource module 87 may also include destination site dependent code. For example, the code is associated with a specific calculation for the destination site currency. During installation of the merchant application 66, one destination site resource module 87 is provided to the merchant application 66. This destination site resource module 87 matches the default language of the installation. The default language is the language of the destination site from which the merchant application 66 is downloaded. If the user wants to list at multiple destination sites, another destination site resource module 87 may be downloaded from the network-based trading facility 10.

The property provided by destination site resource module 87 is to provide language differences at the destination site, as opposed to placing such responsibility on transaction list creation / editing module 85 or main module 84. Another characteristic provided by the destination site resource module 87 is the ability to easily switch between destination sites without restarting the merchant application 66. Another additional feature of the destination site resource module 87 is the ability to configure the merchant application 66 to facilitate operation with the additional destination site (eg, without replacing the transaction listing generation module 85). .

In the exemplary embodiment, each destination site resource module 87 includes a complete set of dialog resources used by the transaction listing generation / editing module 85 for that destination site. Most of the information in the destination site resource module 87 is rarely changed. Thus, data elements that are expected to change frequently are downloaded via different mechanisms (XML files), and the destination site resource module 87 is only downloaded when required because of the changed dialog layout or changed translation.

Communication module

In an exemplary embodiment, the communication module 95 provides a connection to the network based trading facility 10. Some states of the merchant application 66 operation, including version check of site data, software module version check, download of software module, download of site data, and delivery of transaction list 70 to network-based trading facility 10 ( During the phase, the service of the communication module 95 is used.

Communication module 95 encapsulates the format of a standard element in an API request. In addition, communication module 95 may, for example, obtain version information, download software modules, download data elements, download all other data related to the destination site, and list new transactions ( 70) provides a generic request / response function used for common tasks, such as generating

Data storage module

Data storage module 89 manages access to / from user independent datadata 94. The data to be accessed includes a user item list, 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 in two forms: one application database file (e.g., merchant application database 97), and one user database file (e.g., user irrelevant database 94) for each user created. It can be stored in different types of files.

Merchant application database 97 includes a table for merchant application 66 settings, available categories for listings, and category attributes. In the case of category and attribute tables, fields are created only for the important fields and for the fields that need to be indexed. Otherwise the data is stored in an XML blob.

The user unrelated database 94 includes tables for user settings and items. Again, fields are created only for the important fields and fields that need to be indexed. Otherwise, the data is stored in an XML blob.

Import engine module

Import engine module 91 provides the ability to import transaction list 70 from an application other than merchant application 66.

Upgrade Manager Module

The upgrade manager module 92 is used to keep the merchant application 66 up to date, which is associated with several types of data and components, such as:

Application components

EXE, DLL, etc.

Site configuration data

category

property

Options, restrictions, etc.

User configuration data

Storage information

Trading limit

Payment address

Etc.

In an exemplary embodiment, recent data and components can be found in the network based trading facility 10, and performing any necessary updates prior to passing the transaction list 70 to the network based trading facility 10. It is the responsibility of the merchant application 66.

The network-based trading facility 10 has an updated version of data, but no update may be required. In such a situation, the user may be aware of the optional update and may choose not to receive the update.

Further, network based trading facility 10 may have one or more types of data updated for merchant application 66. Some updates may be required and some may not. In an exemplary embodiment, if any available update is required, all available updates are downloaded. In addition, in the exemplary embodiment, if the user chooses to perform a selective upgrade, all available updated data and modules are downloaded and applied. In an example embodiment, compression may also be used to facilitate the transmission of updates from the network-based trading facility 10 to the merchant application 66.

Each upgradeable file has an associated version. The version includes a filename, major version, minor version, and timestamp. Merchant application 66 may be summarized by an array of version objects. In one embodiment, the following is a summary of versionable files.

Merchant Application Component File

seller_application.exe

Helper.exe

CreateTransactionListing.dll

Res001.dll

seller_application data file

Site001.xml (includes category, domain, price, options, etc.)

User003.xml

A "version string" is an XML element with fields for version component major, minor, timestamp, filename, and upgrade requirement. These elements are concatatenate with each other to describe the full system version. The following is an example of an example version string:

In the example embodiment, version comparison of the file at the merchant application 66 and the network-based trading facility 10 is used to determine if an update to the merchant application 66 module and data elements is required. The MINIMUM_VERSION_REQUIRED field is used to version a file at the network based trading facility 10. If the user's merchant application 66 version is lower (or older) than the minimum version required, an update is required. If the user's merchant application 66 version is equal to or larger (or newer) than the minimum version required, upgrading of this file is optional.

In an example embodiment, the user may reject the optional or required update. However, if an update is needed and the user rejects it, that user may be restricted in subsequent communication with the network-based trading facility 10. For example, if the user refuses to receive the necessary updates (e.g., category updates) for the destination site configuration file 86, the user may, for that destination site, add the transaction list 70 to the network-based trading facility 10. ) May not be allowed to deliver.

5 is a flow diagram illustrating a method 100 for configuring (ie, customizing) a merchant application 66 for use with a destination site, in accordance with an exemplary embodiment of the present invention. The example merchant application 66 facilitates communication of the listing to the network based trading facility 10. In one exemplary embodiment, the network-based trading facility 10 supports multiple destination sites (eg, web sites). In another exemplary embodiment, network-based trading facility 10 supports one destination site.

Referring to FIG. 7, a diagram 130 of an example merchant application 66 is provided that communicates with multiple web sites. Merchant application 66 may operate with one website (eg, 132) or multiple websites (eg, 132, 134, 136, 138, and 140). In addition, merchant application 66 may work with websites belonging to one network-based trading facility 10 (eg, 142), or merchant application 66 may all be separate network-based trading facility 10. ) May work with multiple web sites (eg, 132, 134, 140) belonging to 142, 144, and 146. For example, merchant application 66 may work with both the www.facility3.us 142 website and the www.facility2.jp website 138. In an example embodiment, merchant application 66 may work with a wide range of websites (eg, commerce, education, charity, politics, entertainment, etc.). In one embodiment, merchant application 66 may be configured to operate only with a website belonging to a particular network-based trading facility 10.

Returning to FIG. 5, in the example method 100, the merchant application 66 is used by the user at the client device 38 to forward the transaction list 70 to the network-based transaction facility 10. The method 100 begins at a user request to access the network-based trading facility 10 at block 102. In block 104 the identity of the user is verified. In order to access the network-based trading facility 10 through the merchant application 66, the user must have previously obtained login information (eg, user ID and password). In block 106, the user is identified as a first time user.

A user identified as a first time user is asked to enter a billing address, personal address, payment address, and information including, but not limited to, a regional or demographic specific site for which the user wishes to list the item (eg, To pass a list of transactions 70). In block 108, the user selects a destination site from which to list items from a plurality of destination sites provided to the user. In one embodiment, the destination site may represent multiple countries. The user may select the destination site preferences offline. Such offline selection becomes valid when the user is connected to the network-based trading facility 10 and the selection is recognized.

In block 110, the user's merchant application 66 is configured (eg, set up) to be able to communicate with the selected destination site. In an example embodiment, such a configuration includes enabling the merchant application 66 to use the currency of each destination site when working with currency-related fields for each destination site. That is, where appropriate, the call related action is the call type of the selected destination site. Such operations include entering currency values, displaying currency values, and calculating currency values. In addition, the configuration may include preventing the delivery of a particular transaction list 70 (eg, tobacco or alcohol on a commercial website serving a teenager). In an example embodiment, the configuration may also include providing category and attribute options to the merchant application 66 that are available at, or specific to, the selected destination site. In addition, the example embodiments may configure the merchant application to work in the designated corresponding language of the selected destination site. In addition, the configuration of the merchant application 66 may include, but is not limited to, available format types (eg, Auction, Store Items, etc.), reserved price options, payment options, shipping options, checkout options, It may include providing picture service options, and options related to fees for each transaction listing 70.

6 is a flow diagram illustrating a method 120 of scheduling a list via the merchant application 66 in the network-based trading facility 10, in accordance with an exemplary embodiment of the present invention. In the example method 120, the merchant application 66 is used by the user at the client device to communicate the transaction listing 70 and their respective listing times to the network based trading facility 10. Each listing time is the date and time at which the transaction list 70 is published by the network-based trading facility 10 on the website. This includes, but is not limited to, the list of transactions 70 to be sold, auctioned, exchanged, given, or displayed. In block 122, a user interface for receiving a plurality of transaction lists 70 and associated start times in their respective merchant applications is displayed to the user. At block 124, batch text 68 (eg, a data file) is configured in merchant application 66 to include a plurality of transaction listings 70 and their respective start times. In block 126, the batch text generated in block 124 is delivered to the network-based trading facility 10. In an example embodiment, a user may include, within batch text 68, a number of transaction lists 70 including their respective start times. In an example embodiment, the user generates placement text 68 while operating offline. However, in another embodiment, the user may be connected to the network-based trading facility 10 via the merchant application 66 and enter each transaction list 70 directly into the network-based trading facility 10. .

8 shows a method 150 for scheduling a listing of a trade list 70 in a network-based trade list 10 in accordance with the method of the present invention. In the example method 150, the transaction list 70 is provided to the network-based transaction facility 10 from the user via the merchant application 66. The user may provide the transaction listing 70 in a data file that is communicated with the network-based trading facility 10 via the merchant application 66. In block 152, the transaction list 70 and their respective start times are received by the network based trading facility 10. In block 154, the network-based trading facility 10 schedules the publication of each transaction list 70 according to an individual start time associated with each transaction list. At block 156, the transaction list 70 is published according to the schedule devised at block 154.

9 is a flowchart of a method 160 for entering a transaction list 70 description via the transaction list 70 description interface, in accordance with an exemplary embodiment of the present invention. In the exemplary method 160, the merchant application 66 is used by the user at the client device to forward the transaction listing 70 and their respective listing times to the network-based trading facility 10. In block 162, the user indicates a desire to enter a new transaction list 70. In block 164, the user is prompted to enter a description of the transaction list 70 via the transaction list description interface (ie, “WYSIWYG interface”). In addition, the transaction list description interface may be referred to as a custom input screen. In an example embodiment, the WYSIWYG interface includes a first compose user interface, through which text selected and included in the transaction list 70 may be entered. In addition, in the exemplary embodiment, the WYSIWYG interface includes a second preview user interface to provide a preview of the transaction list 70 when provided at the network-based trading facility 10. In one embodiment, the WYSIWYG interface includes a third compose user interface that provides a list of transactions 70 in a descriptor language (eg, HTML) that the user can modify. In block 166, the user completes and stores the transaction list 70.

10 is a flowchart illustrating a method 170 that facilitates update / upgrade of a merchant application 66, in accordance with an exemplary embodiment of the present invention. In the example method 170, at block 172, the network-based trading facility 10 receives a user's connection request. The request is entered through the merchant application 66. In block 174, requestor logon information is received and authenticated. In one embodiment, authentication includes authenticating the user ID and login. In another embodiment, the authentication further comprises authenticating the user status. For example, if a user stops listing the trade list 70 at the network-based trading facility 10, access may be denied. At block 176, upon authentication, network-based trading facility 10 downloads the update / upgrade to merchant application 66. Before the network-based trading facility 10 downloads the update / upgrade to the merchant application 66, in a determination of whether there is an update / upgrade for the merchant application 66, if so, such an existing update / The upgrade is downloaded to the merchant application 66. In an example embodiment, the update / upgrade includes, for example, category update, attribute update, program information update, and version upgrade. In addition, in the example embodiment, the update / upgrade may be downloaded to the merchant application 66 only when automatic update is enabled in the merchant application 66. In block 178, the merchant application 66 update / upgrade is automatically installed at the client device when received.

11 is a flowchart illustrating a method 180 of downloading a merchant application 66 from a network-based transaction facility 10 to a client device 38 in accordance with an exemplary embodiment of the present invention.

In block 182, the network-based trading facility 10 receives a merchant application 66 download request. In one embodiment, this request may be received by a user selection of a hypertext link, or other location identifier, displayed to the user within the context of the markup language document displayed by the browser application 36.

In block 184, the network-based trading facility 10 further receives an identifier of the requesting user. For example, the user identifier is displayed to the user through an interface in the form of a markup language document displayed by the browser application 36.

In decision block 186, the network-based trading facility 10 determines whether the requesting user maintains the credit card details using the network-based trading facility 10. Specifically, if the requesting user is a registered user of the network-based trading facility 10, during the registration process, the network-based trading facility 10 may request that the associated user provide details of a valid credit card.

In decision block 188, the network-based trading facility 10 determines whether the negative feedback rating for the requesting user exceeds a predetermined minimum value. Specifically, in one embodiment, network-based trading facility 10 provides a feedback mechanism through which users can provide feedback for other users with whom they trade. Such a feedback mechanism is useful for establishing trust between users of the network-based trading facility 10 and also provides an indication of the user's credit status and trustworthiness.

In decision block 190, a determination is made as to whether or not the requested user has become a registered user of the network-based transaction facility 10 for a predetermined period of time. For example, if the requesting user was a registered user for only a few hours or less than a week, sufficient time may not elapse to establish the credit, trust and certainty of the requesting user. In addition, a user who intends to commit fraud using the network-based trading facility 10 may be registered under the pseudonym for the special purpose of committing such fraud. The check performed at block 190 allows to reduce access to merchant application 66 by unregistered users for a sufficient period of time, increasing the likelihood of fraudulent registration detection.

After the negative determination in any of decision block 186, 188 or 190, the method 180 rejects the download request at block 194. On the other hand, after affirmative determination in any of decision block 186, 188 or 190, at block 192 the network-based trading facility 10 proceeds to download the merchant application 66 via the Internet 34. do. The method 180 then ends at block 196.

12 is a detailed method of customizing (or configuring) a merchant application used to deliver a trade list 70 and their respective start time to a network based trading facility 10, in accordance with an exemplary embodiment of the present invention. Detailed flowchart showing 200 is shown.

Through the seller application customization, the user may use the merchant application 66 to list the transaction list 70 on multiple destination sites (eg, geographic destination sites for each of US, Germany, UK, etc.). have. The default display language of merchant application 66 may match the local language of the destination site to be downloaded. The user interface provided for creating and editing the transaction list 70 for a particular destination site is presented in a predetermined manner (eg, the local language of the destination site). For example, if the user downloads the merchant application 66 from the German site of the network-based trading facility 10, the user interface may be provided in German. In another example, if the user chooses to create an item to be listed on a Taiwan destination site, the generated transaction list 70 flow (ie, a set of provided user interfaces) will be displayed in Chinese. If the user wants to edit the item later, the edited item panel text will be displayed in Chinese.

If the merchant application 66 needs to display text in a language in which the user does not have the font pack installed, the user is prompted to download or install the font pack from the network-based trading facility 10. In an example embodiment, the font pack is automatically downloaded and installed through the merchant application 66 when the user informs the network-based trading facility 10 that he wishes to list at the destination site where a unique font pack is required. Merchant application 66 allows the addition of additional destination site (s). The ability to use the additional destination site is such that the user selects the additional destination site, the network-based trading facility 10 downloads any necessary software modules and data elements to the user's merchant application, software and data elements. And install the merchant application 66 to use the newly installed software and data elements. The user may select additional destination sites from merchant application 66 while working offline or while connected to network-based trading facility 10.

For example, the content is displayed in a predetermined manner, in the current language configured for the merchant application 66. The content displayed online (eg on the destination site) is currently the local language of the destination site. In the example embodiment, the data displayed in merchant application 66 is presented in a format corresponding to the currently selected destination site. In another embodiment, the data displayed in merchant application 66 is presented in the language selected by the user in merchant application 66.

Merchant application 66 may support site specific transaction variables, such as transaction restrictions. For example, the destination site can cause a trading restriction to be implemented. The transaction limit is a predetermined amount that is varied by the site that a seller can obtain without writing a credit card on file. If the seller places his / her credit card information on file to automatically pay monthly, the network-based transaction facility 10 allows the seller an unlimited listing, assuming the credit card information is valid. Otherwise, when the transaction limit is reached, the seller may not be able to list any new items until a payment is made to account for an account below the transaction limit or a credit card number is placed on the account.

When the user attempts to send the transaction list (s) 70 in the batch text 68 via the merchant application 66, the network-based trading facility 10 performs a transaction restriction check. If the fee corresponding to the list of transactions 70 to be published at the network based trading facility 10 causes the user to exceed their trading limits, the network based trading facility 10 does not allow the list of transactions 70 to be delivered. It may not. In the exemplary embodiment, if the transaction limit is exceeded before all the transaction lists in the batch text 68 are read, the network-based trading facility 10 accepts all the transaction lists 70 read before the transaction limit is exceeded. do.

The transaction restriction check applies registration of the user to the destination site. For example, if the destination site (e.g. a German trading site) has a trading restriction, the trading restriction check is performed each time a user is registered at the German trading site and the target site submitting their list. Regardless, it attempts to send the item to the network based trading facility 10.

If a special destination site is selected, the corresponding currency of that country is used by the merchant application 66. For example, U.S. If the destination site is selected, all rates are displayed in US $. In another embodiment, merchant application 66 uses money from multiple countries. For example, in another embodiment, U.S. If the destination site is selected, all charges are U.S. It is displayed in the currency and Canadian currency. In an example embodiment, merchant application 66 recognizes and applies unique formatting to the particular destination site that the user has selected. As an example, for Germany and Taiwan, the currency field may allow integers. Also, US, AU, CA, UK contain decimal separators (for cents). In addition, France, Spain, Netherlands, Italy, Germany, Belgium (France) and Belgium (Netherlands) have comma separators (for cents). In addition, the Netherlands and Belgium (Netherlands) have comma separators for "Buy it Now" (BIN) and reserve prices, but only allow integers for minimum bidding.

Referring again to FIG. 12, the method 200 begins at block 202 where a user starts a merchant application 66. The method 200 proceeds to block 204, where the merchant application 66 displays a welcome screen 250, an exemplary embodiment of which is shown in FIG. 13A. Welcome screen 250 provides an option to exit 252, open a sample file 254, create a new file 256, or open a sample file 258. In an exemplary embodiment, when selecting one of the options 252-258, a "next" button 260 is selected to begin the option selection. In other embodiments, options 252-258 automatically start when they are selected.

If the opening of the sample file 254 is selected, the method 200 proceeds to block 206 and the user is provided with a sample screen of the transaction list 70. However, if the creation of a new file 256 is selected, the method 200 proceeds to block 210 and the process of entering the transaction list 70 into the collection (eg, batch text 68) begins. do.

On the other hand, if the presence file 258 open is selected, the method 200 proceeds to block 208 and the opening of the presence collection (eg, batch text 68) begins.

In an example embodiment, if creation of a new file 256 is selected at block 210, the method 200 proceeds to block 212, the merchant application 66 displaying the login interface 262, An exemplary embodiment thereof is shown in FIG. 13B. User ID 264 and password 266 are required at login interface 262. The login interface 262 includes a checkbox 268 that informs the network-based trading facility 10 the desire to use the merchant application 66 with multiple destination or custom sites. In an exemplary embodiment, the user ID and password must be obtained before the user creates a new file. In another embodiment, a user may obtain a user ID and password when connecting to the network-based transaction facility 10.

In block 214, the user requests a connection to the network-based trading facility 10. In the exemplary embodiment, for connection with the network-based transaction facility 10, the next button 270 is selected from the login interface 262 after entering the user ID and password. The method 200 then proceeds to block 216, the merchant application 66 provides a connection interface 272, and an example embodiment is shown in FIG. 13C.

In block 216, when selecting the “Connect Now” button 274 in the connection interface 272, the user ID and password are authenticated. If the network-based trading facility 10 is unable to authenticate the user ID and password, the login interface 262 requests the user to reenter the user ID and password.

After authenticating at block 216, the method 200 proceeds to block 218, the merchant application 66 displays the personal information interface 276, and an exemplary embodiment thereof is shown in FIG. 13D. . Such personal information is used to identify users, ensure security, and facilitate the transaction process between users accessing the network-based trading facility 10. User information can be used to reside in user preference fields (eg, location of payment addresses and transaction lists) and to determine a user default destination site. In an example embodiment, merchant application 66 includes a default destination site. In the exemplary embodiment, the default destination site is the site from which users download merchant application 66. However, the user can also edit the primary destination site.

In block 220, determine whether the user wants to use the merchant application 66 on multiple destination sites. After the negative determination at block 220, at block 222 the merchant application 66 is configured to work only with the downloaded destination site (eg, U.S.). In one embodiment, configuring the merchant application 66 includes configuring the merchant application 66 to communicate with the network-based trading facility 10 in accordance with an agreement associated with the selected destination site. In addition, in one embodiment, configuring the merchant application 66 includes configuring the merchant application 66 to provide information to the user in a manner consistent with the convention associated with the selected destination site. On the other hand, after a positive determination at block 220, the method 200 proceeds to block 224, the merchant application 66 provides the destination site interface 280, and an exemplary embodiment thereof is shown in FIG. Shown in 13e.

In block 224, a number of destination sites may be selected to be used by the merchant application 66. In an example embodiment, destination site interface 280 provides a destination site that can be used. It will be appreciated that other destination sites may define more or less than the destination site or other attributes that distinguish it. For example, for destination sites identified by country name, the destination site may define more than one country (e.g., continent), and less than one country (e.g., region, state, Districts, provinces, etc.). The user can select the destination site by selecting the checkbox next to the desired destination site. Multiple destination sites may be selected. In another embodiment, the destination site may be selected by scrolling down the list and highlighting the desired destination site.

In block 226, configuration information corresponding to the destination site selected in block 224 is transmitted from the network-based trading facility 10 to the merchant application 66. At block 228, the merchant application 66 is automatically configured with the information downloaded at block 226. In an example embodiment, the configuration of the merchant application can include providing module updates, category updates, property updates, destination site language updates, main language updates, various software various data elements, and the like. Upon completing the configuration at block 228, merchant application 66 may communicate transaction list 70 and their respective start times for each of the destination sites selected at block 224. The method 200 ends at block 230.

14A and 14B show a detailed flow chart illustrating a method 300 of scheduling a transaction list 70 via a merchant application 66 at a network-based transaction facility 10, in accordance with an exemplary embodiment of the present invention. Shows. In one embodiment, the method 300 is performed at the client side 35 by a standalone executable merchant application 66. In another embodiment, the method 300 may be executed by a client side 35 executable, such as a Java applet or ActiveX control, that executes the context of a browser application. The information may be provided on the client side (eg, to facilitate convenient entry of multiple transaction lists 70 by providing a template that allows a user to define repetitive content for multiple transaction lists 70, for example). 35) and can be implemented. This avoids the need for repetitive entry for each transaction list 70. In addition, the method 300 introduces a client side 35 function of performing an authentication operation on the entered data to check for acceptable content and legality of the content. In addition, the method 300 suggests a presentation list for acceptable content, for example as a drop-down menu, from which the user can select valid content for a particular field of the transaction list 70. In addition, the method 300 provides an option to schedule the transaction list 70.

The method 300, at block 302, displays a merchant application 66 on a client device 70 of a user who wishes to create and deliver a number of trade lists 70 and scheduled start times to the network-based trading facility 10. Start by calling For example, a large user of the network-based trading facility 10 may wish to deliver a number of transaction lists 70, thus bringing up the merchant application 66. In one embodiment, for each transaction list 70 delivered by the merchant application 66 to the network based transaction facility 10, the network based transaction facility 10 may charge a user. In an exemplary embodiment, the fee is based on the user's service level (eg, large user discount).

In block 304, the merchant application 66 executes to display a new item box. The new item box indicated at block 304 includes a new item creation interface 350, an example embodiment being shown in FIG. 15A. The new item box prompts the user to select the type of transaction according to the transaction list 70. In an example embodiment, the types of transactions available in the new item creation interface 350 include, but are not limited to, auction 352, store 364, and Ad format 380. In addition, the new item creation interface 350 provides a drop down site list from which the transaction list 70 (or batch text comprising a number of transaction lists 70) is delivered (e.g., country ) The site is selected. In an exemplary embodiment, if no selection is made in drop-down list 358, the destination site from which merchant application 66 is downloaded is selected.

In block 306, the user reacts with the seller application 66 to prompt the user for information (eg, title, category, etc.) associated with the transaction listing 70, and with the new item creation interface 350. Select the next option displayed as relevant. In one exemplary embodiment, the prompting at block 306 is performed via the new item interface 362, an example including a number of fields that can be filled by a user creating a trade list 70. It is shown in Figure 15b. The individual dialog box is represented as an event in which the user selects either the store format 354 or the ad format 356 in the new item creation interface 350.

In an example embodiment, the new item interface 362 includes multiple input fields for receiving the item title 364, the first item category 366, the second item category 368, and the store category 370. Appears. Each of the three category input fields includes a drop down list that facilitates user selection of the category. The new item interface 362 further includes an attribute 376. An attribute is a category-specific information item that a seller can specify to help buyers find an item and may not be present for all categories. One example would be the category of real estate-housing. For example, when listing items within this category, the user may be prompted to specify the number of bedrooms, number of bathrooms, acreage, air conditioning, pool (drop down: none, in the garden, out of the garden), and the like. Attributes allow buyers to specify that they want to find items based on the attributes available in the real estate category they live in (eg number of beds, number of bathrooms, etc.). Examples of some of the other categories that have attributes include computers (e.g. processor speed, hard drive size), clothes (e.g., type, brand, color), and tickets (e.g., event type, city, state, face value) ) In practice, any category may further be displayed using attribute 376. In order to facilitate convenient navigation between the multiple screens used in the transaction creation list 70, a "previous" button and a "next" button 372 and 374 are also displayed, the user's selection of the buttons being continuously Allows you to advance through multiple screens.

In block 308, in response to the merchant application 66 prompting the user for more detailed information (eg, a transaction list description) associated with the transaction list 70, the user may interact with the new item interface 362. Select the next option shown. In one exemplary embodiment, prompting at block 308 is performed through the transaction listing description interface 450 as shown in FIG. 16A. The transaction list description interface 450 is further described below with reference to FIG. 17.

After the transaction list description is entered at block 308, the method 300 proceeds to block 310, the merchant application 66 displays a format specific interface 378, and an exemplary embodiment thereof It is shown in Figure 15c. Various data items may be included in the format specific interface 378. Exemplary data items are shown to include inventory duration, price, quantity, payment and shipping data items. Also, an “option feature” area with multiple checkboxes to allow users to specify special transactions to be visually or otherwise distinguished or highlighted when displayed by the network-based trading facility 10. Is displayed. For example, transaction list 70 may be bold, displayed with a special background color, or have a graphical image or icon associated therewith.

In block 312, in response to the merchant application 66 performing an authentication check that determines whether the user has entered enough data items to construct a valid transaction list 70 or whether additional information is required, the user Select storage option 380 displayed with format specific interface 378. For example, a user may inadvertently forget to enter a starting price.

After positive authentication, the method 300 proceeds to block 314 as shown in FIG. 14B, where the merchant application 66 displays the inventory item interface 382, an exemplary embodiment of which is shown in FIG. 15D. Is shown. The inventory item interface 382 displays a list of selectable trade lists 70 from the collection 306 related to the destination site selected at block 304. The user may proceed to enter other items to be included in the collection 306 by selecting the create new button 384. In an example embodiment, the user can also delete 386 or edit 388 the transaction listing 70 via the inventory item interface 382.

In an example embodiment, the inventory item interface 382 displays a list summary of all the transaction listings 70 that make up the batch text 68. Specifically, the main window 390 may include a column for displaying the display title, quantity, minimum price, preservation price, and premium list price information to the user in table format. The user may facilitate double-clicking any row of the transaction list 70 displayed in the main window to edit or delete the transaction list 70.

In an example embodiment, a scheduled start date and start time 392 may be selected for which the relevant placement text collection 68 of the transaction listing 70 should be announced by the network-based trading facility 10. If the user does not wish to provide a scheduled start date and time, the scheduled default start time is to start 394 as soon as it is delivered to the network-based trading facility 10. In other embodiments, the start date and time may be specified for each list 70 in the collection 306.

In block 316, the user selects that the collection 306 of the transaction list 70 provides a scheduled start date and start time 392 to be published at the network-based trading facility 10.

At block 318, the user may optionally specify an interval 396 to stagger the number of trade lists 70 when the trade list 70 is published at the network-based trading facility 10. For example, a user may specify that the collection 306 of the transaction list 70 begin at 9 pm July 4, 2002, and also be included between each transaction list 70 in the collection 306. You can also specify an interval of five minutes. Thus, if there are three transaction lists 70 in the collection 306, the first transaction list starts at 9:00 pm, the second list starts at 9:05 pm, and the third list is at 9:10 pm Will start in minutes. The word "beginning" may also be recognized as being published on the selected destination site.

In block 320, the user adds to deliver the displayed option 398 with the inventory item interface 382 in response to the merchant application 66 providing a waiting list for delivering the interface 400. (add), an exemplary embodiment thereof is given in FIG. 15E.

In block 322, the user selects all delivery options 402 that are displayed in association with the interface 400 delivery wait in response to the merchant application 66 prompting the user for a network-based trading facility password. do.

In block 324, when authenticating a user, the collection 306 of the transaction list 70 is passed to the network-based transaction facility 10.

In one embodiment, the batch text 68 described above is communicated from the client device 38 to the network based trading facility 10 via the network based trading facility API. In another embodiment, the placement text 68 may be sent via an email message.

Each transaction list 70 may include a transaction list description. In an example embodiment, the transaction list description may be entered via the transaction list description interface 450, an exemplary embodiment of which is shown in FIG. 16A. Transaction list 70 includes, but is not limited to, text, photos or photos, and formatting (eg, layout, color, font, etc.). In the example embodiment, the transaction list description interface 450 provides three selectable dialog boxes to facilitate entering a transaction list description. Two dialog box options include a design view option 452, an HTML view option 454, and a preview view option 456. If design view option 452 is selected, design view option 452 allows the user to enter descriptive text 458 with the WYSIWYG setting. HTML view option 454 allows the user to enter HTML code for the transaction list description. Preview view option 456 allows the user to preview the transaction list description according to the HTML defined by the WYSIWYG editor or the HTML code entered by the user. An exemplary embodiment of preview view dialog box 478 is shown in FIG. 16C.

Using the design view dialog box 466, a user may enter descriptive text 458 and format it using an editing tool. If the user has enabled multi-site support, a tip is displayed indicating that the transaction list 70 in the local language of each destination site is desirable. The Design View toolbar includes a toolbar item that the user can use to format the description. Each toolbar button may have a tool tip.

In an exemplary embodiment, the font and text controls available for the double-byte character language are displayed appropriately. For example, Chinese fonts are set differently than Western, and do not match bold, italic, or underlined. If the user writes in Chinese, Chinese fonts can be used and only the applicable text controls should be displayed.

Descriptive text 458 entered in Design View dialog box 466 is understood as text that includes descriptor text (eg, HTML code). However, a user may enter descriptor text in the descriptor text view dialog box 470, an exemplary embodiment of which is shown in FIG. 16B. Descriptor text (eg, HTML code) is entered in the descriptor language code window 472. The descriptor language code window 472 is automatically filled with descriptor text (eg, HTML code) according to any text previously entered into the design view dialog box 466.

In the example embodiment, the transaction listing description interface 450 also provides a template 460 that augments the transaction listing 70. The template may include a theme (eg, including a color theme) and a layout 464, respectively, as shown in FIG. 16A. Theme 462 and layout 464 can be selected independently. The user may also add photos to the transaction list 70 via the transaction list description interface 450. Photos may be added via a network-based trading facility 10 or other network facility, through a user's own self-hosted picture service, or a picture service that may be used from a collection of pictures stored on a user's computer. The picture may be added to an image well included in the transaction list description interface 450.

Theme 462 defines the table border color, any border image, background color (description area only), and the like. Layout 464 provides an indication of the location of the explanatory text and the photo. The layout 464 displayed to the users may be specific to the photo hosting preference. Merchant application 66 may also provide an “auto-resize” option. If this option is available, this option resizes your image to the best template image size.

In addition, a set of basic color tables and layouts may be provided by the merchant application 66. May be provided between 5 and 10, respectively (eg, color scheme and layout). The network based trading facility 10 may be updated and may add a template to the merchant application 66 via an update / upgrade. In other embodiments, users may design their own layouts and themes. In yet other embodiments, layouts and themes may be imported.

Additional special features, including supersize 463 and slideshow 465, can be used to augment and / or change the display of the photo. In one exemplary embodiment, the supersize option 463 is included in the left navbar of the transaction listing description interface 450. In an exemplary embodiment, supersize 463 may be applied to all blacked IPIX photos. Also in the exemplary embodiment, the supersize 463 option can only be used for users using the network based trading facility 10 photo service. The supersize 463 option allows the user to enlarge the size of the image to be included in their transaction list 70.

Slideshow 465 features may be selected via a special, slideshow layout. The dialog displayed from this template allows the addition of up to six pictures at a time, not just one picture. Thus, the slideshow 465 feature allows the user to add up to six pictures instead of just one picture to one image well. The pictures added via slideshow 465 are displayed with a list of transactions 70 in the network-based trading facility 10. The slideshow includes a display of a series of photos displayed at one time. The pictures are displayed at the same position on the display. For example, a user looking at a transaction list 70 that includes a slideshow may have each photo (eg, Photo 1 through 1) for a time defined by the network-based trading facility 10 (eg, 5 seconds). 6) is provided. The series of photos of the slide show are continuously rotated until one is selected or until the user closes or exits the window containing the transaction list 70.

17 is a detailed flow chart illustrating a method 500 for entering a transaction list description via the transaction list description interface 450, in accordance with an exemplary embodiment of the present invention. The method 500 begins at block 502, and the merchant application 66 displays the transaction list description interface 450. As discussed above, the transaction list description interface 450 includes a design view option 452, an HTML view option 454, and a preview view option 456.

In block 504, the user selects the design view option 452 in response to the merchant application 66 providing the user with a design view dialog box 466. In an example embodiment, the design view dialog box 466 is a default dialog box and is provided to the user from the transaction list description interface 450 at block 502. In block 506, the user enters descriptive text 458 in the design view dialog box 466. The user may select the preview view option 456 or the HTML view option 454 while in the design view dialog box 466.

At block 508, the user selects the HTML view option 454 in response to the merchant application 66 providing the descriptor language dialog box 470 to the user, the exemplary embodiment of which is illustrated in FIG. 19B. Is shown. Descriptor language dialog box 470 Descriptor language code portion 472 is automatically filled with descriptor language code (eg, HTML code) in accordance with the descriptive text 458 previously entered at block 506. The user may change (eg, add, delete, edit) the descriptor language code in the descriptor language code section.

In block 510, the user selects the preview view option 456 in response to the merchant application 66 providing the user with a preview view dialog box 478, and an exemplary embodiment thereof It is shown in Figure 16c. When published at the network based trading facility 10, the preview view dialog box 478 displays a description of the transaction list as it appears. The content may not be edited in the preview view dialog box 478.

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

At block 514, if a picture is entered, the picture is retrieved and attached to the transaction list 70. By selecting the "Select Photos" button from the Design View dialog box 466, the user can begin the photo selection process. In an example embodiment, a network based trading facility 10 photo hosting service may be used, a user specific hosting service may be used, or a photo may be selected from a collection stored on a user's computer.

At block 516, a layout 464 is selected to be used in the display of the transaction list 70. Layout 464 is a selectable option available in the WYSIWYG interface. If nothing is selected, the default layout is used.

At block 518, a theme 462 is selected to be used in the display of the transaction list 70. Theme 462 is a selectable option in the WYSIWYG interface. If nothing is selected, the default theme is selected. The method 500 ends at block 1210.

18 illustrates a method 550 of scheduling a schedule list entered via the merchant application 66 after a schedule list is received at the network-based trading facility 10, in accordance with an exemplary embodiment of the present invention. Detailed flow chart. In an example embodiment, the transaction list 70 defines variables and content of an online commerce process (eg, online store, online auction). Nevertheless, it will be appreciated that transaction listing 70 may provide any transaction variable (eg, description of a product or service or product service requirement provided for sale by any methodology). Specifically, in another embodiment, transaction listing 70 may describe a product or service that has been or has been offered at a fixed price by separate advertisements, or that is provided within the context of a B2B transaction or electronic market.

The method 550 begins at block 552, where a placement text 68 is received at the network-based trading facility 10.

In block 554, the parser module 76 of the transaction application 311 examines the batch text 68 to extract various transaction lists 70 contained therein, and to each of the extracted transaction lists 70. Various authentication operations are performed.

In block 556, the transaction application 311 communicates a confirmation message to the client device 38 to confirm the extraction of the various transaction lists 70, including successful receipt and scheduled start time. In one embodiment, the confirmation message may include an email message communicated from the email server 22 of the network-based transaction facility 10. Also, in another embodiment, in response to the user request, page server 12 may generate a markup language document (HTML document) that communicates a confirmation message to the user. The confirmation message communicated to the client device 38 at block 556 is a link to a list of the collection of transaction lists 70 extracted from the batch text collection 68 by the parser module 76 at block 656. It may further include a location identifier (eg, Uniform Resource Location (URL)) providing a. In other embodiments, the confirmation message itself may indicate a list of such transactions list 70. For example, the confirmation message communicated to the client device 38 via email may include an HTML document that provides a list of transaction lists 70 included in the batch text 68 that includes the collection 306. have.

At block 558, a number of interfaces are displayed to the user that facilitate viewing and editing of the collection of transaction lists 70 delivered (eg, in the form of placement text 68). As a result, the user can update the transaction list 70 after the transaction list 70 is delivered to the network-based transaction facility 10 via the data file (eg, the batch text 68). The user may update the transaction list 70 while connected to the network-based trading facility 10, or perform an update in the merchant application 66 and forward them to the network-based trading facility 10. In one embodiment, the various interfaces that facilitate viewing and editing of the transaction list 70 are generated by the page server 12 and client over the Internet 34 for viewing within the content of the browser application 36. It may be a markup language document communicated to the device 38. For example, such an interface in the form of a markup language document may be initiated by user selection at the client side 35 of the URL included in the confirmation message communicated at block 556. In another embodiment, the interface indicated at block 558 can be generated by the merchant application 66 using text and data communicated, for example, from the trading application 311. 19A and 19B illustrate example interfaces 600 and 602 displayed to the user by the network-based trading facility 10 to view, edit, preview, and view the collection of transaction lists 70 and the individual transaction lists 70. ).

Merchant application 66 itself includes the ability to automatically update / upgrade any information provided by network-based trading facility 10.

20 is a detailed flow diagram illustrating a method 650 in accordance with an exemplary embodiment of the present invention that facilitates update / upgrade of the merchant application 66. The method 650 begins at block 652 with a connection to the network-based trading facility 10 by the merchant application 66.

In block 654, the network-based trading facility 10 determines if there is an update / upgrade that the merchant application 66 has not received. To support minimal updates / upgrades, a data element (eg, destination site configuration file 86) module for the merchant application 66 in the network-based trading facility 10 (eg, the main module 84 ), A version mechanism is used that compares the available versions of the communication module 95, resource module 81, etc., with the versions of the data elements and modules installed in the merchant application 66. Updates / upgrades are downloaded for changed software modules and data elements. The downloaded data can be compressed to shorten the transfer time. As mentioned above, in an exemplary embodiment, the update / upgrade includes, but is not limited to, category update, attribute update, program information update, and version upgrade. For a category, merchant application 66 determines whether a new / different category structure exists for any merchant application 66 enabled for the destination site. Providing automatic category upgrades to merchant application 66 upon connection with network-based trading facility 10 is advantageous in that categories can change frequently (eg, once a month).

For an attribute, merchant application 66 determines whether there is a new / different attribute structure for any merchant application 66 enabled at the destination site. As noted above, an attribute is a category-specific information item that a seller can specify to help buyers find an item and may not be present in all categories. Take the real estate-housing category as an example. For example, when listing items in this category, you can allow the user to specify the number of rooms, the number of bathrooms, acreage, air conditioning, pool (drop down: none, in the garden, outside the garden), and so on.

The buyer is then displayed a selector tool to use during the search, which enables the specification of certain attribute requests (eg, in the real estate-housing category, item title "New York", 4 rooms, 2 bathrooms). Without the attribute, the seller can specify such information but it is not standardized, so a reliable search mechanism cannot be provided. If there is an attribute, it is guaranteed to the user that the correct information is being retrieved and called.

Other exemplary categories with attributes are computer category (processor speed, hard drive size, etc ..), clothes (clothing) category (type, brand, color, etc ..), and ticket category (event type, city, state, Face value, etc.).

In an example embodiment, the version upgrade includes a change (eg, a software change) that is made to the merchant application 66. This change can also be referred to as a program update. In addition, in the example embodiment, the merchant application 66 update / upgrade may be postponed. However, the network-based trading facility 10 may force an upgrade (eg, a significant change in the program) or an update (eg, a significant change in the category). The user cannot refuse forced updates or upgrades.

In block 656, if the network-based trading facility 10 determines that there is an update / upgrade for the merchant application 66, the update / upgrade is downloaded to the merchant application 66. In one embodiment, the update / upgrade is downloaded only if automatic update of merchant application 66 is enabled. Following affirmative decision at decision block 656, the method 650 proceeds to block 658, where the update / upgrade is automatically installed. In an example embodiment, merchant application 66 includes a routine to automatically install updates / upgrades. In another embodiment, the installation routine is downloaded with each series of updates / upgrades. The installation routine starts automatically upon completion of the download and is configured to install program updates / upgrades. In one embodiment, the installation routine may be configured to autostart only if auto update of merchant application 66 is enabled. The method 650 ends at block 660.

21A-21C provide details of the database structure maintained by database engine server 26 to support the methodology described above.

In FIG. 21A, placement table 42 includes a record as originally described for each collection of transaction listings 70, for example, in placement text received at network-based trading facility 10.

There is a one-to-many relationship between batch table 42 and batch item table 40, where batch item table 40 is a list of transactions extracted by parser module 76 from batch text 68 to database 30. The transaction list 70, including 70, has not yet been validated.

The item waiting table 44 stores the loaded transaction list 70 waiting to be valid as described above. The item table 60 stores a record of the actual transaction list 70 that was validated by the initiation of a transaction process (eg, auction process or sale price offer).

21B and 21C provide details of example fields that may be supported by a batch, batch item, item wait, user, and related tables.

22 illustrates a schematic representation of a device in an exemplary form of computer system 800 in which a group of instructions may be executed to cause a device to perform one of the methodologies described above. In another embodiment, the device may be a network router, a network switch, a network bridge, a personal digital assistant (PDA), a mobile phone, a web device, a set top box (STB), or a series of commands that specify an operation to be performed by the device. It may include any device that can be performed.

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

The disk drive unit 818 includes a machine readable medium 820 that stores a group of instructions (ie, software) 804 that implement some or all of the methodologies described above. The software 840 is also shown as completely or partially present in the main memory 806 and / or in the processor 802. In addition, the software 804 may be transmitted or received via the network interface device 810. For the purposes of this specification, the term "device readable medium" means any medium capable of storing or encoding a series of instructions for execution by a device and causing the device to perform any of the methodologies of the present invention. It is treated as including. Thus, the term “device readable medium” is treated as including, but not limited to, solid-state memory, optical and magnetic disks, and carrier signals. In addition, while the software of FIG. 22 is shown as being within a single device, it will be appreciated that the software 804 may be distributed across multiple devices or storage media that may include device readable media.

In the above, the method and system for scheduling a transaction list in the network-based trading facility through the seller application has been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be appreciated that various modifications and changes may be made to these embodiments without departing from the spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

In the foregoing detailed description, the methods and systems of the present invention have been described with reference to specific exemplary embodiments. However, it will be appreciated that various modifications and changes can be made without departing from the spirit and scope of the invention. In particular, the individual blocks in the various block diagrams represent the functional blocks of the method or apparatus and do not necessarily represent the physical or logical separation or order of operation inherent in the spirit and scope of the invention. For example, the blocks of FIGS. 11A and 11B represent part of the method, which in some embodiments may be organized in parallel rather than in a reordered or linear or stepwise manner. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

The present invention is described by way of example and is not limited to the accompanying drawings in which like reference numerals designate like elements.

1 is a block diagram illustrating an exemplary network-based trading facility in accordance with an embodiment of the present invention.

2 is a database diagram illustrating an example database maintained and accessed by a database engine server of a network-based trading facility.

3 is a block diagram illustrating a network-based trading environment in accordance with an exemplary embodiment of the present invention, including client side and server side.

4 is a block diagram illustrating a merchant application in accordance with an exemplary embodiment of the present invention.

5 is a flow diagram illustrating a method for customizing a merchant application in accordance with an exemplary embodiment of the present invention, wherein the merchant application facilitates delivering a list of transactions to a network-based trading facility.

6 is a flowchart illustrating a method of scheduling a list via a merchant application in a network based trading facility in accordance with an exemplary embodiment of the present invention.

7 is a block diagram illustrating a relationship between a merchant application and multiple network-based trading facilities, in accordance with an exemplary embodiment of the present invention.

8 is a flowchart illustrating a method of scheduling a transaction list at a network-based trading facility, in accordance with an exemplary embodiment of the present invention.

9 is a flow diagram illustrating a method for providing a "what you see is what you get" interface for entering a transaction listing description in a merchant application, in accordance with an exemplary embodiment of the present invention.

10 is a flow diagram illustrating a method of receiving software modules and merchant data updates / upgrades for merchant applications, in accordance with an exemplary embodiment of the present invention.

11 is a flowchart illustrating a method of downloading a merchant application from a network-based transaction facility to a client device, in accordance with an exemplary embodiment of the present invention.

12A and 12B are flow diagrams illustrating a method of customizing a merchant application used to deliver a list of transactions and their respective start time to a network based trading facility, in accordance with an exemplary embodiment of the present invention.

13A-13E are diagrams of interfaces that may be displayed to a user by a network-based trading facility to facilitate ordering of merchant applications.

14A and 14B are flow diagrams illustrating a method of defining batch text that implements a collection of transaction lists, such as, for example, a list to be published in an online store, in accordance with an exemplary embodiment of the present invention.

15A-15E are diagrams of an interface that can be displayed to a user by a network-based trading facility to create, edit, and delete a collection of trade lists and individual trade lists.

16A-16C are diagrams of interfaces that may be displayed to a user by a network-based trading facility to facilitate entry of a transaction list description.

17 is a flow diagram illustrating a method of entering a transaction list description via a transaction list description interface, in accordance with an exemplary embodiment of the present invention.

18 is a flow diagram illustrating a method of scheduling a list via a merchant application in a network-based trading facility, in accordance with an exemplary embodiment of the present invention.

19A and 19B are diagrams of an interface that may be displayed to a user by a network-based trading facility to enable viewing, editing, previewing, and viewing a trade list collection and individual trade lists.

20 is a flow diagram illustrating a method that facilitates updating / upgrading a merchant application, in accordance with an exemplary embodiment of the present invention.

21A-21C are diagrams of a database structure, which may be maintained by a database engine server of a network-based trading facility, in accordance with an exemplary embodiment of the present invention.

FIG. 22 is a diagram of an apparatus in an example form of a computer system in which a group of instructions may be executed to cause the apparatus to perform any of the methodologies described above.

Claims (10)

A method of customizing a merchant application running on a client device that facilitates communication of a list to a network based trading facility, Providing an input interface supported by the network-based transaction facility to receive from the user a selection of one or more destination sites from a plurality of destination sites provided to the user; And Setting a configuration of the merchant application in accordance with the selected one or more destination sites. The method of claim 1, Setting up the configuration comprises configuring the merchant application to communicate with the network-based trading facility in accordance with a convention associated with the selected one or more destination sites. The method of claim 1, Setting up the configuration comprises configuring the merchant application to provide information to the user in a manner consistent with the agreement associated with the selected one or more destination sites. The method of claim 1, Wherein said network-based trading facility provides said plurality of destination sites. The method of claim 1, The merchant application maintains a list of the plurality of destination sites provided to the user. The method of claim 1, Detecting a selection of a primary language for display and entering information in the merchant application, a. The primary language selected may be different from the language of the destination site that the user is communicating with, b. The primary language selected is translated into the language of the destination site to which the user wishes to communicate, c. The merchant application running offline translates the language of the destination site that the user wishes to communicate with, d. The network-based trading facility translates the primary language into a language of the destination site that the user wants to communicate with. The method of claim 1, The setting of the configuration includes setting up the merchant application such that a currency related action is a currency type configured for the selected one or more destination sites. The method of claim 1, Setting the configuration comprises initializing the merchant application to use a transaction listing format available at each of the selected one or more destination sites. The method of claim 1, The setting of the configuration further comprises setting up the merchant application to use a transaction list category available at each selected corresponding country site. A computer readable medium comprising a merchant application, executed on a client device, that can be customized to facilitate communication of a list to a network based trading facility, the application comprising: An interface program module supported by the network-based trading facility and receiving from the user a selection of one or more destination sites from a plurality of destination sites provided to the user; And And a configuration and registration program module for setting a configuration of the merchant application according to the one or more destination sites selected.

Images