Patent Publication Number: US-2003229554-A1

Title: Method and system for composing transaction listing descriptions for use in a network-based transaction facility

Description:
[0001] This application claims the benefit of U.S. Provisional Application No. 60/387,638, filed Jun. 10, 2002. 
    
    
     
       FIELD OF THE INVENTION  
       [0002] The present invention relates generally to the field of network-based commerce and, more specifically, to a method and system for composing transaction listing descriptions for use in a network-based transaction facility.  
       BACKGROUND OF THE INVENTION  
       [0003] With the wide spread acceptance of the Internet as an ubiquitous, interactive communication and interaction platform, on-line (or electronic) commerce conducted over the Internet has become commonplace in a variety of business environments. On-line commerce is traditionally categorized as business-to-business (B2B), business-to-consumer (B2C), consumer-to-consumer (C2C) and even business-to-employee (B2E) commerce. In the B2B environment, a number of online exchanges or marketplaces (e.g., vertical exchanges) have been established with a view to facilitating electronic commerce between parties, for example, within a vertical supply chain. Such B2B exchanges typically provide a number of tools for facilitating commerce, such as aggregated and near real-time inventory information, Requests for Quotation (RFQ) capabilities and auctions.  
       [0004] In the B2C and C2C environments, a number of marketplace exchanges and transaction facilities have proved popular. A leading electronic transaction facility (or market place) is operated by eBay, Incorporated. Electronic marketplaces are also provided by Yahoo! Incorporated and Amazon.com. Further, a number of on-line services offer on-line classifieds, such as the Yahoo! Classifieds service offered by Yahoo! Incorporated.  
       [0005] A number of the on-line marketplaces are utilized by merchants as an important, if not a primary, distribution channel for products. Such so-called “power users” typically list a large number of items to be sold or auctioned each day. Further, various retailers and merchants also utilize free, or low-cost, classified advertisement services offered on the Internet, such as Yahoo! Classifieds. For example, a used-car sales operation may, at any time, place a number of such classified advertisements via an on-line classified advertisement service. It would be helpful to provide merchants with a way to create and propagate multiple items to a network-based marketplace.  
       SUMMARY OF THE INVENTION  
       [0006] According to the present invention, there is provided a method to compose transaction listings for use in a network-based transaction facility. The method includes presenting a first compose user interface via which text can be input and graphics selected to be included in a transaction listing. The method further includes presenting a second preview user interface to present a preview of the transaction listing as it will be presented at the network-based transaction facility.  
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0007] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:  
     [0008]FIG. 1 is a block diagram illustrating an exemplary network-based transaction facility, according to one embodiment of the present invention.  
     [0009]FIG. 2 is a database diagram illustrating an exemplary database maintained and accessed by a database engine server of the network-based transaction facility.  
     [0010]FIG. 3 is a block diagram illustrating a network-based transaction environment, according to an exemplary embodiment of the present invention including a client-side and a server-side.  
     [0011]FIG. 4 is a block diagram illustrating the seller application, according to an exemplary embodiment of the present invention.  
     [0012]FIG. 5 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of customizing the seller application, where the seller application facilitates propagating transaction listings to a network-based transaction facility.  
     [0013]FIG. 6 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of scheduling listings, via the seller application, at the network-based transaction facility.  
     [0014]FIG. 7 is a block diagram illustrating the relationship between the seller application and multiple network-based transaction facilities, according to an exemplary embodiment of the present invention.  
     [0015]FIG. 8 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of scheduling the listing of transaction listings at a network-based transaction facility.  
     [0016]FIG. 9 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of providing a “what you see is what you get” (WYSIWYG) interface for entering transaction listing descriptions in the seller application.  
     [0017]FIG. 10 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of receiving software modules and configuration data updates/upgrades for the seller application.  
     [0018]FIG. 11 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of downloading the seller application from the network-based transaction facility to a client machine.  
     [0019]FIG. 12 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of customizing the seller application utilized to propagate transaction listings and their respective start times to a network-based transaction facility.  
     [0020] FIGS.  13 A- 13 E illustrates interfaces that may be presented to a user by a network-based transaction facility so as to facilitate customization of the seller application.  
     [0021]FIG. 14 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of defining batch text that embodies a collection of transaction listings, such as for example, listings to be published at an online store.  
     [0022] FIGS.  15 A- 15 E illustrate interfaces that may be presented to a user by a network-based transaction facility so as to allow creating, editing, and deleting collections of transaction listings and of individual transaction listings.  
     [0023] FIGS.  16 A- 16 C illustrate interfaces that may be presented to a user by a network-based transaction facility so as to facilitate the entry of a transaction listing description.  
     [0024]FIG. 17 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of entering a transaction listing description via a transaction listing description interface.  
     [0025]FIG. 18 is a flow chart illustrating a method, according to an exemplary embodiment of the present invention, of scheduling listings, via the seller application, at a network-based transaction facility.  
     [0026]FIGS. 19 a  and  19   b  illustrate interfaces that may be presented to a user by a network-based transaction facility so as to allow the viewing, editing, previewing and confirmation of collections of transaction listings and of individual transaction listings.  
     [0027]FIG. 20 is a flow chart illustrating a method, according to an exemplary embodiment of the invention, of facilitating the updating/upgrading of the seller application.  
     [0028] FIGS.  21 A- 21 C provide a diagrammatic representation of a database structure, as may be maintained by the database engine server of a network-based transaction facility, according to an exemplary embodiment of the present invention.  
     [0029]FIG. 22 shows a diagrammatic representation of machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed.  
    
    
     DETAILED DESCRIPTION  
     [0030] A method and system for scheduling transaction listings at a network-based transaction facility are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.  
     [0031] Terminology  
     [0032] The term “user” shall be taken to refer to any entity, human or automated, that contributes to, or participates in, a transaction, communication or process.  
     [0033] The term “transaction” shall be taken to include any communication or exchange between two or more parties with a view to establishing a business agreement, exchange of value or a commercial relationship. Accordingly, the word “transaction” shall be deemed to cover, but not be limited to, a purchase-and-sale transaction established as a result, for example, of the placement of an advertisement or as a result of the conclusion of an auction process, the auction process being conducted on-line or otherwise.  
     [0034] The term “upgrade” shall be taken to include upgrades and updates. Accordingly, the word “upgrade” shall be deemed to cover, but not be limited to, modifications to existing software modules and data elements.  
     [0035] The term “targeted site” shall be taken to include a site (e.g., website) targeted according to geography (e.g., continent, country, region, etc.), subject matter (e.g., Beanie Babies, baseball memorabilia, antique cars, etc.), purpose (e.g., commercial, non-profit, etc.), demographics (e.g., Spanish language, English language, etc.), etc. In fact, any combination (e.g., geography, purpose, and demographics) of the above or other criteria may be used in describing a “targeted site.” 
     [0036] The term “web site” shall be taken to mean a related collection of World Wide Web (WWW) files that include a beginning file called a home page. Thousands of companies and individuals have one or multiple websites. A company or an individual tells you how to get to their web site(s) by giving you a home page address. From the home page, you can get to all the other pages on the site. For example, the web site for eBay has the home page address of http://www.eBay.com. The home page address for eBay leads to many other pages. (But a web site can also be just a few pages). A very large web site may be spread over a number of servers in different geographic locations. The web sites of certain company&#39;s consist of thousands of files spread out over many servers in world-wide locations. But a more typical example is probably a web site that resides on a commercial space provider&#39;s web server with a number of other web sites, where all of the web sites may or may not have anything to do with each other.  
     [0037] While an exemplary embodiment of the present invention is discussed below with reference to “items”, it will be appreciated that the present invention is not so limited. Accordingly, the word “item” shall be deemed to cover, but not be limited to, a transaction listing.  
     [0038] The term “data file” shall be taken to mean a collection of transaction listings. Accordingly, the phrase “data file” shall be deemed to cover, but not be limited to, a collection of transaction listings, for example, which is being propagated to a network-based transaction facility.  
     [0039] Transaction Facility  
     [0040]FIG. 1 is block diagram illustrating an exemplary network-based transaction facility  10 . While an exemplary embodiment of the present invention is described within the context of a network-based transaction facility  10 , the invention will find application in many different types of computer-based, and network-based, facilities (commerce, transaction or otherwise).  
     [0041] The network-based transaction facility  10 , in an exemplary embodiment, includes one or more of a number of types of front-end servers that each includes at least one Dynamic Link Library (DLL) to provide certain functionality. Page servers  12  deliver web pages (e.g., markup language documents), picture servers  14  dynamically deliver images to be displayed within Web pages, listing servers  16  facilitate category-based browsing of listings, search servers  20  that handle search requests to the network-based transaction facility  10  and facilitate keyword-based browsing of listings, and ISAPI servers  18  provide an intelligent interface to the back-end of the network-based transaction facility  10 . E-mail servers  22  provide, inter alia, automated e-mail communications to users of the network-based transaction facility  10 . Administrative applications(s) functions  32  facilitate monitoring, maintaining, and managing the network-based transaction facility  10 . API servers  13  provide a set of functions for querying the network-based transaction facility  10 . The API is a set of easy to use functions called through the HTTP transport protocol. information is sent and received using a standard XML data format. Applications utilized to interact (e.g., upload transaction listings, review transaction listings, manage transaction listings, etc.) with the network-based transaction facility may be designed to use the API. Such applications may be an HTML form or a CGI program written in C++, Perl, Pascal, or any other programming language. The API is more fully described in U.S. patent application Ser. No. 09/999,618, herein incorporated by reference.  
     [0042] The page servers  12 , API servers  13 , picture servers  14 , ISAPI servers  18 , search servers  20 , e-mail servers  22  and database engine server  26  may individually, or in combination, act as a communication engine to facilitate communications between, for example, the client machine  38  and the network-based transaction facility  10 . In addition, the page servers  12 , API servers  13 , picture servers  14 , ISAPI servers  18 , search servers  20 , e-mail servers  22  and database engine server  26  may individually, or in combination, act as a transaction engine to facilitate transactions between, for example, the client machine  38  and the network-based transaction facility  10 . Furthermore, the page servers  12 , API servers  13 , picture servers  14 , ISAPI servers  18 , search servers  20 , e-mail servers  22  and database engine server  26  may individually, or in combination, act as a display engine to facilitate the display of items between, for example, the client machine  38  and the network-based transaction facility  10 .  
     [0043] The back-end servers include 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 a respective database.  
     [0044] The network-based transaction facility  10  may be accessed by a client program, such as for example a browser  36  (e.g., the Internet Explorer distributed by Microsoft Corp. of Redmond, Wash.) that executes on a client machine  38  and accesses the network-based transaction facility  10  via a network such as, for example, the Internet  34 . Other examples of networks that a client may utilize to access the network-based transaction facility  10  include a wide area network (WAN), a local area network (LAN), a wireless network (e.g., a cellular network), or the Public Switched Telephone Network (PSTN) network.  
     [0045] Database Structure  
     [0046]FIG. 2 is a database diagram illustrating an exemplary database  30 , maintained by and accessed via the database engine server  26 , which at least partially implements and supports the network-based transaction facility  10 . In the exemplary embodiment, the database engine server  26  maintains two databases  30   a  and  30   b , a first database  30   a  being maintained for listing (or offering) information that is not included within a virtual “store” according to the present invention, with a second database  30   b  storing offering information for offerings that are presented via virtual “stores” supported by the network-based transaction facility  10 . The structure of these databases  30   a  and  30   b  are substantially the same, but differ in that the tables of the “store” database  30   b  may include a number of additional fields to facilitate the virtual stores. A general discussion of the basic structure of a database  30  is presented below, this being applicable to both databases  30   a  and  30   b .  
     [0047] The database  30  may, in one embodiment, be implemented as a relational database, and includes a number of tables having entries, or records, that are linked by indices and keys. In an alternative embodiment, the database  30  may be implemented as collection of objects in an object-oriented database.  
     [0048] Central to the database  30  is a user table  54 , which contains a record for each user of the network-based transaction facility  10 . A user may operate as a seller, buyer, or both, when utilizing the network-based transaction facility  10 . The database  30  also includes items tables  60  that may be linked to the user table  54 . The items tables  60  may include a seller items table  52  and a bidder items table  58 . A user record in the user table  54  may be linked to multiple items that are being, or have been, listed or offered for sale via the network-based transaction facility  10 . A link indicates whether the user is a seller or a bidder (or buyer) with respect to items for which records exist within the items tables  60 .  
     [0049] The database  30  also includes one or more category tables  47 . Each record within the category table  47  describes a respective category. In one embodiment, a specific category table  47  describes multiple, hierarchical category data structures, and includes multiple category records, each of which describes the context of a particular category within the one of the multiple hierarchical category structures. For example, the category table  47  may describe a number of real, or actual, categories to which item records, within the items tables  60 , may be linked.  
     [0050] The database  30  also includes one or more attributes tables  49 . Each record within an attributes table  49  describes a respective attribute. In one embodiment, a specific attributes table  49  describes multiple, hierarchical attribute data structures, and includes multiple attribute records, each of which describes the context of a particular attribute within the one of the multiple hierarchical attribute structures. For example, the attributes table  49  may describe a number of real, or actual, attributes to which item records, within the items tables  60 , may be linked. Also, the attributes table  49  may describe a number of real, or actual, attributes to which categories, within the category table  47 , may be linked.  
     [0051] The database  30  also includes a note table  46  populated with note records that may be linked to one or more item records within the items tables  60  and/or to one or more user records within the user table  54 . Each note record within the note table  46  may include, inter alia, a comment, description, history or other information pertaining to an item being offered via the network-based transaction facility  10 , or to a user of the network-based transaction facility  10 . Also, the database  30  includes a targeted site table  67  populated with targeted site records that may be linked to one or more item records within the items tables  60  and/or to one or more user records within the user table  54 .  
     [0052] A number of other tables are also shown to be linked to the user table  54 , namely a user past aliases table  48 , a feedback table  50 , a feedback details table  53 , a bids table  55 , an accounts table  64 , an account balances table  62  and a batch items table  40 . To enable one embodiment of the present invention, the database  30  is also shown to include a batch table  42 , a batch items table  40  and an items wait table  44 . Further details regarding the database tables  40 - 44  are provided below.  
     [0053] The present invention relates to a method and system for composing transaction listing descriptions in a network-based transaction facility  10 . FIG. 3 is a block diagram illustrating a network-based transaction environment  67 , according to an exemplary embodiment of the present invention, including a client-side  35  and a server-side  71 . The transaction listings  70  (e.g., offers for sale, auctions, fixed-price listings) are established on the network-based transaction facility  10 , in one embodiment, via the seller application  66 . The seller application  66  is utilized at a client machine  38  to assist in the communication of multiple transaction listings  70  to a network-based transaction facility  10 . In one embodiment, the seller application  66  may be utilized offline or the seller application  66  may be utilized online (e.g., connected to the network-based transaction facility  10 ). In one embodiment, the seller application  66  is a stand alone application that executes on the client machine  38 . In another embodiment, the communication of the multiple transaction listings  70  may be performed utilizing server-enabled applications, such as a web browser, or applet that executes within a web browser.  
     [0054] In one embodiment, the seller application  66  is installed and executed on a client computer with a view to assisting a user in propagating multiple transaction listings  70  and their respective start times to a network-based transaction facility  10 . The seller application  66  thus operates as a client application, and provides a number of user interfaces and other functionality to assist a user in defining multiple transaction listings  70  in a convenient manner. The seller application  66  also operates to compose a data file (e.g., batch text  68 ) that includes the multiple transaction listings  70  and their associated start times, and to propagate such a data file as a single transmission to a network-based transaction facility  10 . The propagating of such a single data file including multiple transaction listings  70  is a feature, that may reduce the number of interactions between a client machine  38  and the network-based transaction facility  10 , and thereby reduce the amount of time that a client machine  38  has to be connected to a network (i.e., be “on-line”).  
     [0055] The associated start times include a different starting time for at least a portion of the plurality of transaction listings  70  in the data file. The associated start times may include a starting date and time of a first transaction listing  70  in the data file  68 . In an exemplary embodiment, the start times may be staggered by a user-selectable amount of time. For example, transaction listings  70  scheduled to start at Dec. 25, 2002 at 7:00 a.m. with a user staggered time of 5 minutes selected by a user will result in the following:  
     [0056] the first transaction listing starting at 7:00 a.m.;  
     [0057] the second transaction listing starting at 7:05 a.m.;  
     [0058] the third transaction listing starting at 7:10 a.m.; and  
     [0059] the fourth transaction listing starting at 7:15 a.m.  
     [0060] Thus, the starting times of the four transaction listings  70  in the example are staggered by 5 minutes. In the exemplary embodiment, the user may chose numerous values with which to stagger the starting times (e.g., 10 minutes, 1 hour, 10 hours, 1 day, etc.). In one embodiment, the seller application  66  prevents the user from specifying associated starting times for transaction listings  70  where the associated starting times exceed a maximum advanced scheduling value. Furthermore, the seller application  66  may prevent the user from specifying an associated start time less than a minimum scheduling value. The maximum advanced scheduling value and the minimum scheduling value may be defined in terms of years, months, days, hours, minutes, or seconds defined by the network-based transaction facility  10 .  
     [0061] As the seller application  66  is, in one exemplary embodiment, executable on the client-side  35  as a stand-alone application, it provides the feature of allowing a user to compose multiple transaction listings  70  in an “off-line” manner (e.g., without necessarily establishing any network communications or session with the network-based transaction facility  10 ), and then to propagate such multiple transaction listings  70  to the network-based transaction facility  10  as the above-mentioned single data file transmission.  
     [0062] A further feature of the client-side  35  executable seller application  66  is that it is configurable to work with multiple targeted (e.g., customized) sites. Therefore, a user may use the seller application  66  to propagate the same transaction listing  70  to multiple targeted sites (e.g., geographically-targeted sites for each of the U.S., UK, DE, etc . . . ).  
     [0063] One embodiment of the present invention provides server-side facilitated viewing, editing and confirmation of multiple transaction listings  70  by a user, and also the committing of such multiple transaction listings  70  to an active state to initiate multiple transaction processes facilitated by the network-based transaction facility  10 .  
     [0064] Referring back to FIG. 3, the environment includes a client-side  35  and a server-side  71 . On the client-side  35 , a client machine  38  (e.g., a personal computer, Personal Digital Assistant (PDA), cellular telephone, set-top box, or any other networked device) is shown to host the seller application  66 , and a browser application  36 . While the seller application  66  and browser application  36  are illustrated as being separate, the browser application  36  may be configured to work as the seller application  66 , for example through the retrieval of HTML pages from the server-side  36  or through execution of an applet. The client machine  38  is coupled to a network in the exemplary form of the Internet  34 , or any Local Area Network (LAN) or Wide Area Network (WAN).  
     [0065] The seller application  66 , in one embodiment, presents a number of user interfaces to a user for the purposes of harvesting multiple transaction listings  70 . The seller application  66  further composes batch text  68  that embodies the multiple transaction listings  70  inputted via the multiple interfaces. The seller application  66  then communicates the batch text  68  to the network-based transaction facility  10  in accordance with the network-based transaction facility API. In an alternative embodiment, the seller application  66  interacts with an email application  69  to compose an electronic mail (e-mail) message that embodies the batch text  68 . The batch text  68  is communicated to the network-based transaction facility  10  by the email application  69  as an email message. Specifically, the email application  69  utilizes any one of a number of electronic e-mail or messaging protocols (e.g., Simple Mail Transport Protocol (SMTP)) to communicate the email message over the Internet  34 . It will of course be appreciated, in alternative embodiments, that any one of a number of other protocols (e.g., the File Transport Protocol (FTP)) may be utilized.  
     [0066] Turning to the server-side  71 , the network-based transaction facility  10  is shown to execute a transaction application  73  that includes a communicator module  75 , a parser module  76 , an upgrade control module  77 , a scheduler module  80 , and a publisher module  82 .  
     [0067] The communicator module  75  including the parser module  76  is to receive a data file  68  from the seller application  66  executed at a client machine  38 , the data file  68  including a plurality of transaction listings  70  and respective associated start times. The parser module  76  operates to parse received multiple transaction listings  70  from the batch text  68 . The parser module  76  may also perform various format, content and verification operations. The parser module  76  then populates the items wait table  44 , as maintained by the database engine server  26 , with the extracted transaction listings  70 . The scheduler module  80  schedules publication of the plurality of transaction listings  70  according to their respective associated start times. From the items wait table  44 , the transaction listings  70  are transferred to the live items table  60  according to their scheduled listing time, in the manner described below. The publisher module  82  publishes each of the plurality of transaction listings  70  at the network-based transaction facility  10  according to their associated start times.  
     [0068] In one embodiment, the communicator module  75  verifies user login information supplied by the seller application  66  with a connection request. The verification occurs before receiving the batch text  68 . Upon verifying the user login information, the communicator module  75  provides user information received to the upgrade control module  77 . The upgrade control module  77  determines if the seller application  66  requires any updates/upgrades. Such updates/upgrades, may include but are not limited to software components (e.g., main module) or data elements (e.g., category updates, attributes updates, etc.).  
     [0069] The transaction application  73  further encompasses the page server  12 , which in one exemplary embodiment, includes an Internet Server Application Program Interface (ISAPI)  18  where the page server  12  comprises the Internet Information Server, a web server developed by Microsoft Corporation of Redmond, Wash. In an alternative embodiment, the page server  12  may execute a Common Gateway Interface (CGI) program. The page server  12  operates dynamically to generate markup language documents (e.g., web pages) utilizing content retrieved from the database engine server  26 , and to communicate such markup language documents via the Internet  34  to the seller application  66  for viewing utilizing the browser application  36 . In one embodiment, the page server  12  serves up a reviewer page  72 , embodying a list of multiple transaction listings  70  successfully extracted by the parser module  76  from the list of transaction listings  70  for display within the browser application  36 . This is done for the purposes of allowing a user to view, edit, and confirm such transaction listings  70  before they are communicated to the live items table  60  from the items wait table  44 .  
     [0070] Basic Architecture of the Seller Application  
     [0071] In the exemplary embodiment, the seller application  66  architecture includes three layers. The three layers include the GUI layer, the data objects layer, and the communication and database layer. The GUI layer&#39;s modules handle all interaction with the user and all management of resource files. The data objects layer contains data objects that contain targeted site data. The data objects layer encapsulates XML parsing of the targeted site data as well as database access, easing GUI development. The communication and database layer provide simplified interfaces to the rest of the seller application  66 . An upgrade manager (e.g., upgrade module explained below) is provided for keeping the three layers of the seller application  66  up-to-date. This involves managing several types of data elements (e.g., category data) and components (e.g., modules). The upgrade manager is explained further below.  
     [0072]FIG. 4 is a diagram illustrating an exemplary seller application  66 . In the exemplary embodiment, the seller application  66  facilitates propagating a plurality of transaction listings  70  to a network-based transaction facility  10 .  
     [0073] Seller Application Components  
     [0074] In the exemplary embodiment, the seller application  66  includes a main module  84 , resource modules  81 , a data objects module  83 , a create/edit transaction listing module  85 , targeted site resource modules  87 , targeted site configuration files  86 , a communication module  95 , a data storage module  89 , an import engine module  91 , an upgrade manager module  92 , a helper module  93 , user independent databases  94 , the seller application database  97  and a configuration and registration module  96 . The create/edit transaction listing module  85  includes an interface module  88  and a composer module  90 .  
     [0075] Composition of the Seller Application  
     [0076] In the exemplary embodiment, the seller application  66  is built primarily using Microsoft standard libraries and components. The main executable and the GUI (graphical user interface) based components use MFC (Microsoft Foundation Classes). MFC is a large library of C++ classes developed by Microsoft. MFC is bundled with several C++ compilers and is also available as part of the Microsoft Developer&#39;s Network (MSDN).  
     [0077] In the exemplary embodiment, the communication and database layer uses OLEDB (OLE Data Base) and the Jet Engine. OLEDB is a programming interface for data access from Microsoft. Applications may use OLEDB to access data sources directly or they can use OLEDB to call ODBC to access ODBC databases. Jet Joint Engine Technology) engine is the database engine used in Microsoft Access and it accompanies Visual Basic and C++. Jet is typically used for storing data in the client machine. Developers using Access and Visual Basic access Jet via the DAO/Jet interface, which is a COM object.  
     [0078] In the exemplary embodiment, Microsoft components are utilized since many are already installed on many client machines  28 . For example, by requiring that a user of the seller application  66  have installed Internet Explorer 5.0 or later, there is reasonable certainty that the necessary version of the Jet Engine is available. In the exemplary embodiment, third party tools may be utilized for STL and XML parsing.  
     [0079] Multi-User and Security in the Seller Application  
     [0080] In the exemplary embodiment, a multi-user environment is supported by using a separate DB (database) for each user&#39;s preferences. When the user logs on, the database file for that user will be used. Password protection (e.g., Microsoft Access) is used to secure these user database files. The text fields of the user database may also be encrypted in a way that does not affect performance, but may prevent curious users from hacking the tables.  
     [0081] Some user-independent settings are kept in the seller application database  97  (e.g., site specific data). In the exemplary embodiment, there is only one seller application database  97 . The seller application database  97  is always opened by the seller application  66  regardless of which user logs in. The seller application database  97  contains a mapping from the network-based transaction facility user ID to the user independent database filename for that user, so the user independent database filenames do not indicate the network-based transaction facility user ID. This schema allows users to change their network-based transaction facility ID and keep using their existing user independent database  94 . That way, if a user does change their ID and/or password, they will not lose saved items.  
     [0082] Adaptability of the Seller Application  
     [0083] In the exemplary embodiment, the seller application  66  is adaptable for use with targeted (e.g., geographically or otherwise targeted) sites. Seller application strings are stored in resource modules  81 . The resource modules  81  consist of DLLs (Dynamic Link Libraries). The seller application strings are the strings for the seller application  66  language (e.g., primary language), which are distinguished from strings that appear in the targeted site language.  
     [0084] The user may choose the primary language that they want to work with and optionally install other seller application  66  language versions. In the exemplary embodiment, switching primary languages requires a restart. The primary language may be different than the language of the targeted site with which the user is communicating.  
     [0085] In the exemplary embodiment, the primary language utilized by the seller application  66  is translated into the language of the targeted site with which the user intends to communicate. The translation may occur at the seller application  66  off-line or at the network-based transaction facility  10  while the seller application  66  is connected to the network-based transaction facility  10 .  
     [0086] The targeted site language is the language and locale conventions used at a particular targeted site. The collections of strings for the targeted site language are also stored in the targeted site resource module  87 . The targeted site resource modules  87  may consist of DLLs (Dynamic Link Libraries). In the exemplary embodiment, the targeted site data provided by the collection of strings associated with the targeted site language can be switched during execution to allow users to list items on multiple targeted sites without restarting the seller application  66 . To accomplish the switching of a targeted site language, a targeted site resource module  87  should contain the correct collection of strings for the targeted site&#39;s language.  
     [0087] In addition to the targeted site-specific translations of strings, these targeted resource module  87  can also contain targeted site-specific dialog layout variations, which would make it possible for user interfaces utilized in the process of creating transaction listings  70  to differ in appearance for different targeted sites. This offers user and designer flexibility while minimizing the amount of site-specific code needed to facilitate the process of creating transaction listings  70 .  
     [0088] In the exemplary embodiment, there is some targeted site-specific XML configuration data that contains updateable values (e.g., categories, attributes, valid formats, etc.). If this configuration data is modified for targeted sites configured to work with the seller application  66 , then the seller application  66  should be updated to reflect such modification. In the exemplary embodiment, modifiable targeted site-specific data may be stored within targeted site resource module  87  or XML files. The most current XML data is kept in the seller application database  97 .  
     [0089] Upgradability of the Seller Application  
     [0090] The seller application  66  is designed to allow upgrades of both data elements and application modules. The upgrade manager module  92  and helper module  93  are utilized to facilitate such upgrades. Data elements are expected to change frequently. Data elements are acquired via existing API calls to the network-based transaction facility  10 . Upgrading data elements gives the seller application  66  the latest set of categories, attributes, and targeted site-specific constants (e.g., trading limits, publication durations, payment options, fee schedule, etc.). In the exemplary embodiment, the targeted site config file  86  is used to store targeted site data elements.  
     [0091] In the exemplary embodiment, the seller application  66  modules may be upgraded far less frequently than data elements. Upgrading the seller application  66  modules provides the latest set of the seller application  66  and targeted site language translations, computed rules (i.e., rules that relate user data to targeted site data), and targeted site-specific dialog layout.  
     [0092] In the exemplary embodiment, all of the seller application  66  modules are upgradeable, even the main module  84 . Upgrading of the modules is accomplished using a helper module  93 . After the download of new components, a helper script is generated that instructs the helper module  93  to replace the seller application  66  modules with the new versions of the seller application  66  modules. Whenever the seller application  66  is executed, this helper module  93  determines if there are possible file replacements to do before launching the main module  84 .  
     [0093] In the exemplary embodiment, to support minimal upgrades, a versioning mechanism is used to compare available versions of data elements and the seller application  66  modules at the network-based transaction facility  10  against the versions of the installed elements and modules of the seller application  66 . Upgrades only attempt to download the seller application  66  modules and/or data elements that have changed. The downloaded data may be compressed to shorten transfer times. Allowing both code and data to be updated is a feature that maximizes the upgradability of the seller application  66 .  
     [0094] In one embodiment, the network-based transaction facility  10  recognizes that the seller application  66  has been enabled to support a targeted site for which support has not yet been downloaded and installed. Upon recognizing that such support has not been downloaded and installed, the network-based transaction facility  10  downloads the targeted site&#39;s required support (e.g., data elements, the seller application  66  module updates).  
     [0095] Main Module  
     [0096] In the exemplary embodiment, the seller application  66  main module  84  will provide a MFC shell for all UI elements, which are displayed using the current application language (e.g., menu, toolbar, folders, inventory and listings view). The main module  84  is a starting point for the seller application  66 . All program flows and actions begin and end in the main module  84  regardless of whether they were initiated programmatically or by a user.  
     [0097] At startup, the main module  84  dynamically loads a resource module  81  based on the user&#39;s current application language setting. This setting is stored in the user independent database  94 . To change the application language, the user is required to restart the seller application  66  in order for the change to be recognized. In an alternative embodiment, the application language may be changed without restarting the seller application  66 .  
     [0098] In the exemplary embodiment, the main module  84  is also responsible for controlling the security of the seller application  66  by requiring the user to enter a password and connecting only to the user independent database  94  associated with that user. The seller application  66  allows only one user independent database  94  to be used at a time. To use a different user ID, the user must select another user ID, and enter the password for that user ID. Alternatively, one could exit and run the program again to log on as another user.  
     [0099] The user ID and password used to logon to the seller application  66  may be the same user ID and password configured for the user at the network-based transaction facility  10 . If the user changes his ID and/or password on the network-based transaction facility  10  without updating the seller application  66 , then future attempts to communicate with the network-based transaction facility  10  may fail. An error message indicating a login failure will be provided to the user.  
     [0100] In the exemplary embodiment, the main module  84  allows only one instance of the seller application  66  to execute on the user system at a time. If the user tries to execute a second copy, the first executing instance is activated (e.g., a window is restored and brought to the top of the desktop). In an alternative embodiment, multiple seller applications  66  may execute on a user&#39;s system at the same time.  
     [0101] When creating/editing new transaction listings  70 , the main module  84  calls the create transaction listing module  85 . In the exemplary embodiment, the main module  84  is a single threaded application and it dynamically loads the rest of the modules on demand.  
     [0102] The Seller Application Language Resource Module  
     [0103] In the exemplary embodiment, the resource module  81  provides the ability to change the seller application  66  language without any code change. In addition, the resource module  81  allow for the addition of new seller application  66  languages with minimum installation time and effort. Each resource module  81  contains a complete set of resources for one language. These resources include dialog templates, menus, icons and language strings.  
     [0104] As explained above, a resource module  81  is loaded by the main module  84  when the seller application  66  starts. The default seller application  66  language is set when the seller application  66  is installed and it matches the language of the network-based transaction facility  10  targeted site (e.g., geographic) from which the seller application  66  was obtained. Additional languages may be installed from the network-based transaction facility  10 .  
     [0105] In the exemplary embodiment, each resource module  81  contains a full set of all resources for the main module including:  
     [0106] String table  
     [0107] Dialog resources  
     [0108] Application icons, bitmaps, etc.  
     [0109] The resource module  81  may follow a naming convention so that the seller application  66  knows which resource module  81  contains which language (e.g., res001.DLL is US English, res002.DLL is German, res003 is . . . , etc.).  
     [0110] Data Objects Module  
     [0111] In the exemplary embodiment, the data objects module  83  provides a DB independent data model to the seller application  66  for Categories, Domains, Attributes, Items, and Sites. The data objects module  83  may consist of a DLL (Dynamic Link Library).  
     [0112] Data objects included in the data objects module  83  provide the seller application  66  with data-store independent access to data in the seller application database  97 . Data objects can encapsulate XML parsing when the data involved contains XML strings, providing the clients with C++ accessor functions for data fields. If the client requires the underlying XML, the data object module  83  may provide it.  
     [0113] There may be data objects for category, domain, attributes, and site data. In the exemplary embodiment, data objects are created with a factory function that is exported by the DLL that contains the implementation code for the data objects. A factory function returns a pointer to an interface supported by the data object. The supported interfaces are defined in a header file that is included by any client code that requires it.  
     [0114] Create/Edit Transaction Listing Module  
     [0115] In the exemplary embodiment, the seller application  66  create/edit transaction listing module  85  displays all UI (user interface) elements in the targeted site&#39;s language. The create/edit transaction listing module  85  is configurable to show the right set of SYI fields/attributes/fees etc per targeted site. One feature provided by the create/edit transaction listing module  85  is encapsulating item-related knowledge and logic in a single module to minimize the size of the future updates. Another feature is providing site language independent implementation to allow creation of transaction listings  70  for the different targeted sites utilizing the seller application  66  language. The create/edit transaction listing module  85  includes an interface module  88  and a composer module  90 . The interface module  88  presents an input interface to a user to receive a plurality of transaction listings  70 , each of the plurality of transaction listings  70  including a respective associated start time. The composer module  90  may automatically compose a data file including the plurality of transaction listings  70  received by the interface module  88 . The communication module  95  propagates the data file created by the composer module  90  from the client computer to the network-based transaction facility  10 .  
     [0116] Targeted Site Resource Module  
     [0117] In the exemplary embodiment, targeted site resource modules  87  are provided. Similar to the resource module  81 , the targeted site resource module  87  includes resources for just one language. Every time the user creates a new transaction listing  70  or edits an existing transaction listing  70 , the create/edit transaction listing module  85  loads the appropriate targeted site resource module  87 . The targeted site resource module  87  contains dialog templates, icons, and language strings.  
     [0118] The targeted site resource module  87  may also include targeted site dependent code. For example, code related to computations specific to the targeted sites currency. During installation of the seller application  66 , one targeted site resource module  87  is provided to the seller application  66 . This targeted site resource module  87  matches the default language of the installation. The default language is the language of the targeted site from which the seller application  66  was downloaded. Other targeted site resource modules  87  may be downloaded from the network-based transaction facility  10  if the user would like to list on multiple targeted sites.  
     [0119] A feature provided by the targeted site resource module  87  is providing language differences in targeted sites as opposed to burdening the create/edit transaction listing module  85  or main module  84  with that responsibility. Another feature provided by the targeted site resource module  87  is the ability to switch targeted sites easily without restarting the seller application  66 . A further additional feature of the targeted site resource module  87  is the ability to configure the seller application  66  to work with additional targeted sites easily (i.e., without altering create transaction listing module  85 ).  
     [0120] In the exemplary embodiment, each targeted site resource module  87  contains a complete set of dialog resources utilized by the create/edit transaction listing module  85  for that targeted site. Most of the information in the targeted site resource module  87  change infrequently. Therefore, data elements that are expected to change often are downloaded via a different mechanism (XML files) and the targeted site resource module  87  is only downloaded when required due to a changed dialog layout, or changed translation.  
     [0121] Communication Module  
     [0122] In the exemplary embodiment, the communication module  95  provides connectivity to the network-based transaction facility  10 . Its services are used during several phases of the seller application  66  operation including checking versions of site data, checking software module versions, download of software modules, download of site data, and the propagating of transaction listings  70  to the network-based transaction facility  10 .  
     [0123] The communication module  95  encapsulates formatting of standard elements in API requests. The communication module  95  also provides a generic request/response function to be used for common tasks such as for example getting version information, downloading software modules, downloading data elements, downloading all other miscellaneous data related to a targeted site, and creating new transaction listings  70 .  
     [0124] Data Storage Module  
     [0125] The data storage module  89  manages access to and from the user independent databases  94 . The data to be accessed includes user item listings, user settings, and application wide data.  
     [0126] The data storage module  89  manages database access to the local on-disk storage for both user files and applications wide data. This data may be stored in two types of files: one application database file (e.g., the seller application database  97 ) and one user database file (e.g., user independent database  94 ) for each user that is created.  
     [0127] The seller application database  97  contains tables for the seller application  66  settings, available categories for listings, and categories attributes. In the case of categories and attributes tables, fields are created only for important fields and fields that need to be indexed. Otherwise data is stored in XML blobs.  
     [0128] The user independent database  94  contains tables for user settings and for items. Again, fields are created only for important fields and fields that need to be indexed. Otherwise data is stored in XML blobs.  
     [0129] Import Engine Module  
     [0130] The import engine module  91  provides for the ability to import transaction listings  70  from applications other than the seller application  66 .  
     [0131] Upgrade Manager Module  
     [0132] The upgrade manager module  92  is used to keep the seller application  66  up-to-date, which involves managing several types of data and components:  
     [0133] Application components  
     [0134] EXEs, DLLs, etc.  
     [0135] Site configuration data  
     [0136] Categories  
     [0137] Attributes  
     [0138] options, restrictions, etc.  
     [0139] User configuration data  
     [0140] Store info  
     [0141] Trading limits  
     [0142] Payment address  
     [0143] etc.  
     [0144] In the exemplary embodiment, the most current data and components may be found at the network-based transaction facility  10  and it is the seller application&#39;s  66  responsibility to perform any required updates before propagating transaction listings  70  to the network-based transaction facility  10 .  
     [0145] The network-based transaction facility  10  may have updated versions of data but the update might not be required. In this situation, the user is made aware of the optional update and is given the option to not to receive the update.  
     [0146] Also, the network-based transaction facility  10  may have updated versions of more than one type of data for the seller application  66 . Some of the updates may be required and some may not. In the exemplary embodiment if any available updates are required, all available updates are downloaded. Also, in the exemplary embodiment, if the user chooses to perform an optional upgrade, all available updated data and modules are downloaded and applied. Furthermore, in the exemplary embodiment, compression may be utilized to expedite the transfer of updates from the network-based transaction facility  10  to the seller application  66 .  
     [0147] Each upgradeable file has an associated version. The version includes the file name, major version, minor version, and timestamp. The seller application  66  may be summarized by an array of version objects. In one embodiment, the following is a summary of the versionable files:  
     [0148] seller application component files  
     [0149] seller_application.exe  
     [0150] Helper.exe  
     [0151] CreateTransactionListing.dll  
     [0152] Res001.dll  
     [0153] seller_application data files  
     [0154] Site001.xml (contains categories, domains, fees, options, etc.)  
     [0155] User003.xml  
     [0156] A “version string” is an XML element with fields for the version components major, minor, timestamp, filename, and upgrade requirements. These elements can be concatenated together to describe the entire system version. The following is an example of an exemplary version string:  
                                  &lt;SELLERAPP_FILE_VERSION&gt;         &lt;FILENAME&gt;RES001.DLL&lt;/FILENAME&gt;         &lt;MAJOR&gt;1&lt;/MAJOR&gt;         &lt;MINOR&gt;8&lt;/MINOR&gt;         &lt;TIMESTAMP &gt;030802:22:01:01&lt;/TIMESTAMP &gt;         &lt;MINIMUM_VERSION_REQUIRED&gt;          &lt;MAJOR&gt;1&lt;/MAJOR&gt;          &lt;MINOR&gt;7&lt;/MINOR&gt;         &lt;/MINIMUM_VERSION_REQUIRED&gt;         // optional         &lt;FILE_URL&gt;http://www.ebay.com/files/sellerapp/res001.dll.gzip        &lt;/FILE_URL&gt;         &lt;INSTALLED/&gt;       &lt;/SELLERAPP_FILE_VERSION&gt;                  
 
     [0157] In the exemplary embodiment, a version comparison of files at the seller application  66  and the network-based transaction facility  10  is utilized in determining if updates to the seller application  66  modules or the data elements are required. The MINIMUM_VERSION_REQUIRED fields are used to version files at the network-based transaction facility  10 . If a user&#39;s seller application  66  version is lower than (or older than) the minimum version required, then the update is required. If the user&#39;s seller application  66  version is equal or greater than (or newer than) the minimum version required, then the upgrade of this file is optional.  
     [0158] In the exemplary embodiment, the user may reject either optional or required updates. However, if updates are required and the user refuses to accept them, the user may be limited in future communications with the network-based transaction facility  10 . For example, if a user refuses to accept required updates for a targeted site config file  86  (e.g., category updates), then that user may not be allowed to propagate transaction listings  70  to the network-based transaction facility  10  for the targeted site.  
     [0159]FIG. 5 is a flow chart illustrating a method  100 , according to an exemplary embodiment of the present invention, of adapting (i.e., customizing) the seller application  66  for use with a targeted site. The exemplary seller application  66  facilitates communication of listings to a network-based transaction facility  10 . In one exemplary embodiment, a network-based transaction facility  10  supports multiple targeted sites (e.g., web sites). In an alternative exemplary embodiment a network-based transaction facility  10  supports one targeted site.  
     [0160] Referring to FIG. 7, a diagram  130  of an exemplary seller application  66  communicating with multiple web sites is provide. The seller application  66  may work with one web site (e.g.,  132 ) or multiple web sites (e.g.,  132 ,  134 ,  136 ,  138 , and  140 ). Furthermore, the seller application  66  may work with web sites belonging to one network-based transaction facility  10  (e.g.,  142 ) or the seller application  66  may work with multiple web sites (e.g.,  132 ,  134 ,  140 ) all belonging to separate network-based transaction facilities  10  ( 142 ,  144 , and  146 ). For example, the seller application  66  may work with both the www.facility3.us  142  web site and the www.facility2.jp web site  138 . In the exemplary embodiment the seller application  66  may work with a broad range of web sites (e.g., commercial, educational, charitable, political, entertainment oriented, etc . . . ). In one embodiment, the seller application  66  may be configured to work only with web sites, which belong to a specific network-based transaction facility  10 .  
     [0161] Returning to FIG. 5, in the exemplary method  100 , the seller application  66  is utilized by a user at a client machine  38  for propagating transaction listings  70  to a network-based transaction facility  10 . The method  100  commences at block  102  at a user request to access the network-based transaction facility  10 . At block  104  the user&#39;s identity is verified. In order to access the network-based transaction facility  10  via the seller application  66 , the user must have previously obtained login information (e.g., UserID and Password). At block  106  the user is identified as a first time user.  
     [0162] The user identified as a first time user is requested to enter information including but not limited to a billing address, a personal address, a payment address, and the regional or demographic-specific sites at which the user wishes to list items (e.g., to propagate transaction listings  70 ). At block  108  the user selects the targeted sites at which to list items from a plurality of targeted sites presented to the user. In one embodiment, a targeted site may represent multiple countries. The user may select the targeted site preferences offline. Such offline selections become effective when the user connects to the network-based transaction facility  10  and the selections are recognized.  
     [0163] At block  110 , the user&#39;s seller application  66  is configured (e.g., set up) so that it may communicate with the targeted sites selected. In the exemplary embodiment, such configuration comprises enabling the seller application  66  to utilize each targeted site&#39;s currency when working with currency related fields for each of the targeted sites. That is, where relevant, operations involving currency are in the currency type of the targeted sites selected. Such operations include inputting currency values, displaying currency value, and calculating currency values. Configuration further may include preventing the propagation of certain transaction listings  70  (e.g., alcohol or tobacco at commercial web site serving teenagers). In the exemplary embodiment, configuration may further include providing the seller application  66  with category and attribute options available at, or specific to, the targeted site selected. Moreover, the exemplary embodiment configures the seller application  66  to work in the designated corresponding language of the targeted site selected. Configuration of the seller application  66  may further include but is not limited to providing the available format types (e.g. Auction, Store Items (fixed-price), etc.), reserve price options, payment options, shipping options, checkout options, picture service options, and options related to fees for each transaction listing  70 .  
     [0164]FIG. 6 is a flow chart illustrating a method  120 , according to an exemplary embodiment of the present invention, of scheduling listings, via the seller application  66 , at the network-based transaction facility  10 . In the exemplary method  120 , the seller application  66  is utilized by a user at a client machine for propagating transaction listings  70  and their respective listing times to a network-based transaction facility  10 . The respective listing time is the date and time at which a transaction listing  70  is published by a network-based transaction facility  10  on a website. This may include but is not limited to transaction listings  70  to be sold, auctioned, bartered, given away, or displayed. At block  122  a user interface for receiving a plurality of transaction listings  70  and their respective associated start times at the seller application  66  is presented to the user. At block  124  batch text  68  (e.g., data file) is composed at the seller application  66  to include the plurality of transaction listings  70  and their respective start times. At block  126 , the batch text created in block  124  is propagated to the network-based transaction facility  10 . In the exemplary embodiment, the user may include multiple transaction listings  70  in the batch text  68 , each including their respective start times. In the exemplary embodiment the user creates the batch text  68  while working offline. However, in alternative embodiments, the user may be connected to the network-based transaction facility  10  and enter each transaction listing  70  directly into the network-based transaction facility  10 , via the seller application  66 .  
     [0165]FIG. 8 is a flow chart illustrating a method  150 , according to an exemplary embodiment of the present invention, of scheduling the listing of transaction listings  70  at a network-based transaction facility  10 . In the exemplary method  150 , transaction listing(s)  70  are provided to the network-based transaction facility  10  from a user, via the seller application  66 . The user may provide the transaction listing(s)  70  within a data file communicated via the seller application  66  to the network-based transaction facility  10 . At block  152 , the transaction listings  70  and their respective start times are received by the network-based transaction facility  10 . At block  154 , the network-based transaction facility  10  schedules the publication of each transaction listing  70  according to each of the transaction listings respective associated start time. At block  156 , the transaction listings  70  are published according to the schedule devised in block  154 .  
     [0166]FIG. 9 is a flow chart illustrating a method  160 , according to an exemplary embodiment of the present invention, of entering a transaction listing  70  description via a transaction listing  70  description interface. In the exemplary method  160 , the seller application  66  is utilized by a user at a client machine for propagating transaction listings  70  and their respective listing times to a network-based transaction facility  10 . At block  162  the user indicates a desire to enter a new transaction listing  70 . At block  164  the user is prompted to enter the transaction listing&#39;s  70  description via a transaction listing description interface (i.e., “WYSIWYG interface”). The transaction listing description interface may also be known as a custom input screen. In the exemplary embodiment, the WYSIWYG interface includes a first compose user interface via which text can be input and graphics selected to be included in a transaction listing  70 . Also, in the exemplary embodiment, the WYSIWYG interface includes a second preview user interface to present a preview of the transaction listing  70  as it will be presented at the network-based transaction facility  10 . In one embodiment, the WYSIWYG interface includes a third compose user interface to present the transaction listing  70  in a descriptor language (e.g., HTML) which the user may modify. At block  166  the user completes and saves the transaction listing  70 .  
     [0167]FIG. 10 is a flow chart illustrating a method  170 , according to an exemplary embodiment of the present invention, of facilitating the updating/upgrading of the seller application  66 . In the exemplary method  170 , at block  172 , the network-based transaction facility  10  receives a user request to connect. The request is entered via the seller application  66 . At block  174 , the requestor login information is received and verified. In one embodiment verification includes verifying the UserID and Login. In an alternative embodiment verification further includes verifying user status. For example, if the user is suspended from listing transaction listings  70  at the network-based transaction facility  10  access may be denied. At block  176 , upon verification, the network-based transaction facility  10  downloads updates/upgrades to the seller application  66 . Before the network-based transaction facility  10  downloads updates/upgrades to the seller application  66 , a determination as to whether updates/upgrades exist for the seller application  66 , if so, then such existing updates/upgrades are downloaded to the seller application  66 . In the exemplary embodiment, updates/upgrades include, for example, category updates, attributes updates, program information updates and version upgrades. Also, in the exemplary embodiment, updates/upgrades may only be downloaded to the seller application  66  if automatic updating is enabled at the seller application  66 . At block  178 , the seller application  66  updates/upgrades automatically install at the client machine upon being received.  
     [0168]FIG. 11 is a flow chart illustrating a method  180 , according to an exemplary embodiment of the present invention, of downloading the seller application  66  from the network-based transaction facility  10  to a client machine  38 .  
     [0169] At block  182 , the network-based transaction facility  10  receives a request to download the seller application  66 . In one embodiment, this request may be received by user-selection of a hypertext link, or other location identifier, presented to the user within the context of a markup language document displayed by the browser application  36 .  
     [0170] At block  184 , the network-based transaction facility  10  further receives the requesting user&#39;s identifier. The user identifier is provided by the user via an interface, for example, presented to the user in the form of a markup language document displayed by the browser application  36 .  
     [0171] At decision block  186 , a determination is made by the network-based transaction facility  10  as to whether the requesting user maintains credit card details with the network-based transaction facility  10 . Specifically, should the requesting user be a registered user of the network-based transaction facility  10 , the network-based transaction facility  10  may during a registration process request the relevant user to provide details of a valid credit card.  
     [0172] At decision block  188 , a determination is made by the network-based transaction facility  10  as to whether a negative feedback rating for the requesting user exceeds a predetermined minimum. Specifically, in one embodiment, the network-based transaction facility  10  provides a feedback mechanism by which users may provide feedback regarding other users with which they have transacted. Such a feedback mechanism is useful for establishing trust between users of the network-based transaction facility  10 , and also provides an indication of the trustworthiness and reliability of the user.  
     [0173] At decision block  190 , a determination is made as to whether the requested user has been a registered user of the network-based transaction facility  10  for a predetermined time period. For example, should the requesting user have only been a registered user for a number of hours, or less than a week, insufficient time may have passed to establish the credibility, trustworthiness and reliability of the requesting user. Further, a user seeking to perpetrate a fraud utilizing the network-based transaction facility  10  may register under an alias for the specific purposes of perpetrating such a fraud. The check performed at block  190  seeks to reduce access to the seller application  66  by a user who has not been registered for a sufficient period of time so as to increase the probability of the detection of a fraudulent registration.  
     [0174] Following a negative determination at any one of decision blocks  186 ,  188  or  190 , the method  180  denies the download request at block  194 . On the other hand, following positive determinations at each of decision blocks  186 ,  188  and  190 , the network-based transaction facility  10 , at block  192 , proceeds to download the seller application  66  to the client machine  38  via the internet  34 . The method  180  then terminates at block  196 .  
     [0175]FIG. 12 is a detailed flow chart illustrating detailed method  200 , according to an exemplary embodiment of the present invention, of customizing (or configuring) the seller application  66  utilized to propagate transaction listings  70  and their respective start times to a network-based transaction facility  10 .  
     [0176] Through customizing the seller application  66 , a user may utilize the seller application  66  to list transaction listings  70  at multiple targeted sites (e.g., geographically targeted sites for each of the US, Germany, UK, etc . . . ). The default display language of the seller application  66  may match the local language of the targeted site from which it was downloaded. The user interfaces provided to create and edit transaction listings  70  for a specific targeted site displays in a customized manner (e.g., in the targeted site&#39;s local language). For example, if a user downloads the seller application  66  from the network-based transaction facility&#39;s  10  Germany site, the user interface may be presented in German. In a further example, if a user chose to create an item to be listed at the Taiwan targeted site, the Create transaction listing  70  flow (i.e., series of user interfaces presented) would display in Chinese. If the user wanted to edit that item later, the Edit Item panel text would display in Chinese.  
     [0177] If the seller application  66  needs to display text in a language that the user does not have a font pack installed for, the user is prompted to download or install that font pack from the network-based transaction facility  10 . In the exemplary embodiment, the font pack is automatically downloaded and installed when the user notifies the network-based transaction facility  10 , via the seller application  66 , that it would like to list at a targeted site for which a unique font pack is required. The seller application  66  allows the addition of additional targeted site(s). The ability to utilize additional targeted sites requires the user selecting the additional targeted sites, the network-based transaction facility  10  downloading any required software module and data elements to the user&#39;s seller application, installing the software and data elements, and configuring the seller application  66  to utilize the newly installed software and data elements. The user may select additional targeted sites from the seller application  66  while working offline or while connected to the network-based transaction facility  10 .  
     [0178] The content is displayed for the user in a customized manner, for example, in the current language configured for the seller application  66 . The content displayed online (e.g., at the targeted site) is in the local language of the current targeted site. In the exemplary embodiment, dates displayed at the seller application  66  appear in the format that corresponds with the current targeted site selected. In an alternative embodiment, the dates displayed at the seller application  66  appear in the language selected by the user at the seller application  66 .  
     [0179] The seller application  66  may support site-specific transaction parameters, such as trading limits. For example, targeted sites may have trading limits implemented. Trading limits are a preset amount, varying by site, of fees a seller may accrue without having a credit card on file. If a seller has placed his/her credit card information on file for automatic monthly billing, the network-based transaction facility  10  allows the seller unlimited listing, assuming the credit card information is valid. Otherwise, when the trading limit is reached the seller may be unable to list any new items until a payment is made to bring the balance of the account below the trading limit or a credit card number is placed on the account.  
     [0180] The network-based transaction facility  10  performs a trading limit check when a user attempts to send transaction listing(s)  70  in batch text  68  via seller application  66 . If the fees corresponding to a transaction listing  70  to be published at the network-based transaction facility  10  would cause the user to exceed their trading limit, the network-based transaction facility  10  may not allow the transaction listing(s)  70  to be propagated. In the exemplary embodiment, if the trading limit is exceeded before all transaction listings  70  in batch text  68  are read, the network-based transaction facility  10  accepts all transaction listings  70  read before the trading limit was exceeded.  
     [0181] The trading limit check applies to the targeted site of registration for a user. For example, if a targeted site (e.g., German transaction site) has trading limits, the trading limit check for is performed every time a user registered with the German transaction site attempts to send items to the network-based transaction facility  10 , regardless of the targeted site to which they are submitting their listings.  
     [0182] When a particular targeted site is chosen, the country&#39;s corresponding currency is utilized by the seller application  66 . For example, when the U.S. targeted site is selected, all fees display in US$. In an alternative embodiment, the seller application  66  utilizes currencies from multiple countries. For example, in the alternative embodiment, when the U.S. targeted site is selected, all fees display in U.S. currency and Canadian currency. In the exemplary embodiment, the seller application  66  recognizes and applies formatting unique to the particular targeted site with which the user has selected. As an example, for Germany and Taiwan, currency fields may only allow whole numbers. Also, US, AU, CA, UK include a decimal separator (for cents). In addition, France, Spain, Netherlands, Italy, Germany, Belgium(France), and Belgium(Netherlands) have a comma separator (for cents). Moreover, Netherlands and Belgium(Netherlands) have a comma separator for “Buy It Now” (BIN) and Reserve Price, but only allow whole numbers for minimum Bid.  
     [0183] Referring back to FIG. 12, the method  200  commences at block  202  where a user starts the seller application  66 . The method  200  progresses to block  204 , where the seller application  66  present a welcome screen  250 , an exemplary embodiment of which is shown in FIG. 13A. The welcome screen  250  provides the option to exit  252 , open a sample file  254 , create a new file  256 , or open a sample file  258 . In the exemplary embodiment, upon selecting one of options  252 - 258 , the “next” button  260  is selected to initiate the option selection. In an alternative embodiment, options  252 - 258  are initiated automatically upon their selection.  
     [0184] If open a sample file  254  is chosen, the method  200  progresses to block  206 , where the user is presented with a sample screen of transaction listings  70 . However, if create a new file  256  is chosen, the method  200  progresses to block  210 , where the process of entering transaction listings  70  into a collection (e.g., batch text  68 ) is initiated.  
     [0185] On the other hand, if open an existing file  258  is chosen, the method  200  progresses to block  208 , where the process of opening an existing collection (e.g., batch text  68 ) is initiated.  
     [0186] In the exemplary embodiment, if create a new file  256  is chosen at block  210 , then the method  200  progresses to block  212 , where the seller application  66  presents a login interface  262 , an exemplary embodiment of which is shown in FIG. 13B. A userid  264  and password  266  are requested at login interface  262 . The login interface  262  includes a checkbox  268  to notify the network-based transaction facility  10  of a desire to use the seller application  66  with multiple targeted or customized sites. In the exemplary embodiment, the userid and password must be obtained in advance of the user creating a new file. In an alternative embodiment, the user may obtain a userid and password upon connecting to the network-based transaction facility  10 .  
     [0187] At block  214 , the user issues a request to connect with the network-based transaction facility  10 . In the exemplary embodiment, to connect with the network-based transaction facility  10  the next button  270  from login interface  262  is selected after entering a userid and password. The method  200  then progresses to block  216 , where the seller application  66  presents a connection interface  272 , an exemplary embodiment of which is shown in FIG. 13C.  
     [0188] At block  216 , the userid and password are verified upon selection of the “connect now”  274  button in connection interface  272 . If the network-based transaction facility  10  is unable to verify the userid and password, the user is requested to reenter the userid and password at login interface  262 .  
     [0189] After verification at block  216 , the method  200  progresses to block  218 , where the seller application  66  presents personal information interface  276 , an exemplary embodiment of which is shown in FIG. 13D. Such personal information is utilized to identify the user, ensure security, and facilitate the transaction process between users accessing the network-based transaction facility  10 . The user information may be used to populate user preference fields (e.g., payment address and transaction listing&#39;s location) and to determine the user default targeted site. In the exemplary embodiment, the seller application  66  includes a default targeted site. In the embodiment, the default targeted site is the site from which the user downloaded the seller application  66 . However, the user may edit the default targeted site.  
     [0190] At block  220 , a determination as to whether the user would like to use the seller application  66  at multiple targeted sites. Following a negative determination at block  220 , the seller application  66  is configured at block  222  to work only with the targeted site (e.g., U.S.) from which it was downloaded. In one embodiment, to configure the seller application  66  includes configuring the seller application  66  to communicate with the network-based transaction facility  10  according to conventions associated with the targeted site selected. Also, in one embodiment, to configure the seller application  66  includes configuring the seller application  66  to present information to the user in a manner consistent with the conventions associated with the targeted site selected. On the other hand, following a positive determination at block  220 , the method  200  progresses to block  224 , where the seller application  66  presents targeted site interface  280 , an exemplary embodiment of which is shown in FIG. 13E.  
     [0191] At block  224 , multiple targeted sites to be utilized by the seller application  66  may be selected. In the exemplary embodiment, targeted site interface  280  presents the available targeted sites. It will be appreciated that other targeted sites may define more or less than a targeted site or any other attribute by which a targeted site is distinguished. For example, with regards to targeted sites distinguished by country name, a targeted site may define more than one country (e.g., continent), less than a country (e.g., region of a country, state, territory, province, etc . . . ). The user may select a targeted site by selecting a checkbox next to the desired targeted site. Multiple targeted sites may be selected. In an alternative embodiment, the user may select targeted sites by scrolling down a list and highlighting desired targeted sites.  
     [0192] At block  226 , configuration information corresponding to the targeted sites selected at block  224  is transmitted from the network-based transaction facility  10  to the seller application  66 . At block  228 , the seller application  66  is automatically configured with the information downloaded at block  226 . In the exemplary embodiment, configuration of the seller application may include providing software module updates, category updates, attribute updates, targeted site language updates, primary language updates, miscellaneous software miscellaneous data elements, etc. . . . Upon completion of the configuration at block  228 , the seller application  66  is available to propagate transaction listings  70  and their respective start times to each of the targeted sites selected at block  224 . The method  200  concludes at block  230 .  
     [0193]FIGS. 14A and 14B show a detailed flow chart illustrating a method  300 , according to an exemplary embodiment of the present invention, of scheduling transaction listings  70 , via the seller application  66 , at the network-based transaction facility  10 . In one embodiment, the method  300  is performed at the client-side  35  by the stand-alone, executable the seller application  66 . In alternative embodiments, the method  300  may be executed by a client-side  35  executable, such as a Java applet or an ActiveX control, that executes when the context of a browser application. Intelligence resides and executes on the client-side  35  to facilitate the convenient entry of multiple transaction listings  70  by, for example, providing templates that allow for a user to define repetitive content across multiple transaction listings  70 . This avoids requiring repetitive entry for each transaction listing  70 . Further, the method  300  introduces client-side  35  functionality to perform a verification operation on inputted data to check for allowable contents, and the legality of contents. Also, the method  300  proposes presenting lists for allowable contents, for example as drop-down menus, from which a user may select valid contents for a particular field of a transaction listing  70 . Moreover, the method  300  provides the option to schedule the transaction listings  70 .  
     [0194] The method  300  commences at block  302  with the invoking of the seller application  66  on the client machine  38  of a user wishing to compose and propagate multiple transaction listings  70  and their scheduled start times to a network-based transaction facility  10 . For example, a high volume user of a network-based transaction facility  10  may wish to propagate multiple transaction listings  70 , and thus invokes the seller application  66 . In one embodiment, the user may be charged a fee by the network-based transaction facility  10  for each transaction listing  70  propagated by the seller application  66  to the network-based transaction facility  10 . In the exemplary embodiment, the fee is based on the user level of service (e.g., high volume user discount).  
     [0195] At block  304 , the seller application  66  executes to present a new item box. The new item box presented at block  304  comprises a Create a New Item interface  350 , an exemplary embodiment of which is shown in FIG. 15A. The new item box prompts the user to select a type of transaction corresponding to the transaction listing  70 . In the exemplary embodiment, the type of transactions available at Create a New Item interface  350  include but are not limited to Auctions  352 , Stores  364 , and Ad Format  380 . Moreover, Create a New Item interface  350  provides a drop down site list  358 , from which a targeted (e.g., country) site to which the transaction listing  70  (or batch text  68  including multiple transaction listings  70 ) is to be propagated. In the exemplary embodiment, if no selection is made at drop down list  358 , the targeted site from which the seller application  66  was downloaded is chosen.  
     [0196] At block  306 , the user selects the next option presented in association with the Create a New Item interface  350 , responsive to which the seller application  66  prompts the user for information (e.g., title, category, etc.) associated with the transaction listing  70 . In one exemplary embodiment, the prompting at block  306  is performed via a new item interface  362 , an example of which is shown in FIG. 15B that includes a number of fields that may be populated by the user to compose the transaction listing  70 . Separate dialog boxes are presented in the event that a user selects either the stores format  354  or ad format  356  in Create a New Item interface  350 .  
     [0197] In the exemplary embodiment, the new item interface  362  is shown to include multiple input fields for receiving the item title  364 , the first item category  366 , the second item category  368 , and the store category  370 . Each of the three category input fields include a drop down list to facilitate user selection of a category. The new item interface  362  further includes attributes  376 . Attributes are category-specific information items that the seller can specify to help buyers find items, and may not exist for all categories. An example would be the category of Real Estate—Residential. For example, when listing an item in this category, a user may be prompted to specify Number of bedrooms, Number of bathrooms, Square footage, Air Conditioning, Pool (drop-down with: No, Inground, Out-of-Ground), etc. . . . The attributes allow a buyer to specify that they want to find an item in the Real Estate—Residential category according to the available attributes (e.g., Number of bedrooms, Number of bathrooms), etc. . . . Examples of some of the other categories with attributes include Computers (e.g., processor speed, hard drive size), Clothing (e.g., type, brand, color), and Tickets (e.g., event type, city, state, face value). Virtually any category may be further described using attributes  376 . To facilitate convenient navigation between the multiple screens utilized in creating the transaction listing  70 , “previous” and “next” buttons  372  and  374  are also displayed, user-selection of which allows a user sequentially to progress through multiple screens.  
     [0198] At block  308 , the user selects the next option presented in association with the new item interface  362 , responsive to which the seller application  66  prompts the user for more detailed descriptive information (e.g., transaction listing description) associated with the transaction listing  70 . In one exemplary embodiment, the prompting at block  308  is performed via a transaction listing description interface  450 , such as that shown in FIG. 16A. The transaction listing description interface  450  is further described below with reference to FIG. 17.  
     [0199] After the transaction listing description has been entered at block  308 , the method  300  progresses to block  310 , where the seller application  66  presents a format specifics interface  378 , an exemplary embodiment of which is shown in FIG. 15C. Various data items may be included in the format specific interface  378 . Exemplary data items are shown to include the listings duration time, pricing, quantity, payment and shipping data items. An “optional features” area with multiple checkboxes is also presented so as to allow a user to specify that a particular transaction be visually or otherwise differentiated or highlighted when displayed by the network-based transaction facility  10 . For example, a transaction listing  70  may be bolded, displayed with a particular background color, or have a graphic image or icon associated therewith.  
     [0200] At block  312 , the user selects a save option  380  presented in association with the format specific interface  378 , responsive to which the seller application  66  performs a verification check to determine whether the user has inputted sufficient data items to constitute a valid transaction listing  70 , or whether further information is required. For example, the user may inadvertently have forgotten to input a starting price.  
     [0201] Following a positive verification, the method  300  progresses to block  314 , shown in FIG. 14B, where the seller application  66  presents an inventory interface  382 , an exemplary embodiment of which is shown in FIG. 15D. The item inventory interface  382  presents a selectable list of transaction listings  70  in a collection  306  associated with the targeted site selected at block  304 . The user may proceed to enter another item to be included in the collection  306  by selecting the create new  384  button. In the exemplary embodiment, the user may also delete  386  or edit  388  transaction listings  70  via the item inventory interface  382 .  
     [0202] In the exemplary embodiment, the inventory interface  382  presents a listing summary of all transaction listings  70  that constitute the batch text  68 . Specifically, the main window  390  may include columns that display title, quantity, minimum price, reserve price and premium listing price information in a tabular form to the user. A user may double-click on any of the rows of transaction listings  70  presented in the main window to facilitate editing or deleting transaction listings  70 .  
     [0203] In the exemplary embodiment, a scheduled start date and start time  392  at which the relevant batch text collection  68  of transaction listings  70  should be posted by the network-based transaction facility  10  may be selected. If the user does not wish to provide a scheduled start date and time, the scheduled start time default is to start immediately  394  upon propagation to the network-based transaction facility  10 . In an alternate embodiment, a start date and time may be specified for each listing  70  within the collection  306 .  
     [0204] At block  316 , the user elects to provide a scheduled start date and start time  392  at which the collection  306  of transaction listings  70  is to be published at the network-based transaction facility  10 .  
     [0205] At block  318 , the user may optionally specify an interval  396  to stagger the multiple transaction listings  70  in the collection  306  apart by when they are published at the network-based transaction facility  10 . For example, the user may specify the collection  306  of transaction listings  70  to start Jul. 4, 2002 at 9:00 PM and further specify that an interval of five minutes be included between each of the transaction listings  70  in the collection  306 . Therefore, if there were three transaction listings  70  in the collection  306 , the first one would start at 9:00 PM, the second at 9:05 PM, and the third at 9:10 PM. The word “start” may also be recognized as published at the targeted site selected.  
     [0206] At block  320 , the user selects the add to propagate option  398  presented in association with the item inventory interface  382 , responsive to which the seller application  66  provides the listings waiting to propagate interface  400 , an exemplary embodiment of which is provided in FIG. 15E.  
     [0207] At block  322 , the user selects the propagate all option  402  presented in association with the waiting to propagate interface  400 , responsive to which the seller application  66  prompts the user for a network-based transaction facility password.  
     [0208] At block  324 , upon user verification, the collection  306  of transaction listings  70  is propagated to the network-based transaction facility  10 .  
     [0209] In one embodiment, batch text  68  is, as described above, propagated from the client machine  38  to the network-based transaction facility  10  via the network-based transaction facility API. In alternative embodiments, batch text  68  may be transferred via an e-mail message.  
     [0210] Each transaction listing  70  may include a transaction listing description. In the exemplary embodiment, the transaction listing description may be entered via a transaction listing description interface  450 , an exemplary embodiment of which is shown in FIG. 16A. The transaction listing  70  includes but is not limited to text, a photograph or photographs, and formatting (e.g. layout, color, font, etc . . . ). In the exemplary embodiment, the transaction listing description interface  450  provides three selectable dialog boxes to facilitate entering the transaction listing description. The three dialog box options include a design view option  452 , an HTML view option  454 , and a preview view option  456 . The design view option  452 , if selected, allows a user to enter descriptive text  458  in a WYSIWYG setting. The HTML view option  454  allows a user to enter HTML code for their transaction listing description. The preview view option  456  allows a user to preview the transaction listing description according to the HTML that has been defined by the WYSIWYG editor or HTML code input by the user. An exemplary embodiment of a Preview view dialog box  478  is shown in FIG. 16C.  
     [0211] Using a design view dialog box  466 , the user may input descriptive text  458  and format it using editing tools. If the user has multi-site support enabled, a tip is displayed indicating that it is preferred that transaction listings  70  be in the local language of each targeted site. A design view toolbar includes toolbar items the user may use to format their description. Each toolbar button may have a tooltip.  
     [0212] In the exemplary embodiment, double-byte character languages the available fonts and text controls are displayed appropriately. For example, Chinese fonts are a different set than Western, and are not compatible with Bold, Italic, or Underline. If the user is writing in Chinese, Chinese fonts are available and only applicable text controls should display.  
     [0213] Descriptive text  458  entered in the design view dialog box  466  is interpreted as text, including descriptor text (e.g., HTML code). However, a user may enter descriptor text in a descriptor text view dialog box  470 , an exemplary embodiment of which is shown in FIG. 16B. The descriptor text (e.g., HTML code) is entered in a descriptor language code window  472 . The descriptor language code window  472  automatically populates with descriptor text (e.g., HTML code) according to any text entered previously in the design view dialog box  466 .  
     [0214] In an exemplary embodiment, the transaction listing description interface  450  further provides templates  460  to enhance the transaction listing  70 . The templates may each include a theme (e.g., includes color scheme)  462  and layout  464  as shown in FIG. 16A. The themes  462  and layouts  464  may be selected independently. In addition, a user may add photos to a transaction listing  70  via the transaction listing description interface  450 . The photos may be added via photo service available through the network-based transaction facility  10  or another network facility, through a user&#39;s self-hosted picture service, or from a collection of pictures stored on a user&#39;s computer. The photos may be added into image wells included within the transaction listing description interface  450 .  
     [0215] Themes  462  may define the table border colors, any border images, background colors (description area only), etc. Layouts  464  may provide the display location of the description text and photos. The layouts  464  displayed to the user may be particular to their photo hosting preference. The seller application  66  may also provide an “Auto-resize” option. This option, if enabled, resizes the user&#39;s image to the optimal template image size.  
     [0216] A set of default color schemes and layouts may also be provided by the seller application  66 . Between 5 and 10 of each (e.g., color schemes and layouts) may be provided. The network-based transaction facility  10  may update and add templates via updates/upgrades to the seller application  66 . In an alternative embodiment, users may design their own layouts and themes. In a further alternate embodiment, layouts and themes may be imported.  
     [0217] Additional special features including supersize  463  and slideshow  465  may be used to enhance and/or alter the display of photos. In one exemplary embodiment, the supersize option  463  is included in the left navbar of the transaction listing description interface  450 . In the exemplary embodiment, supersize  463  may be applied to all IPIX photos that qualify. Also in the exemplary embodiment, the supersize  463  option is only available for users who are utilizing the network-based transaction facility  10  picture service. The supersize  463  option allows the user to enlarge the size of an image to be included in their transaction listing  70 .  
     [0218] The slideshow  465  feature may be selected via a special, slideshow-only layout. The dialog displayed from this template allows the addition of up to 6 photos at once as opposed to merely one photo. Therefore, the slideshow  465  feature allows a user to add up to six photos in one image well as opposed to only one photo. Photos added via the slideshow  465  feature are displayed with the transaction listing  70  at the network-based transaction facility  10 . A slideshow includes the presentation of a series of photos displayed one at a time. The photos are displayed at the same position on a display. For example, a user viewing a transaction listing  70  including a slide show is provided with each photo (e.g., photos 1-6) for a period of time defined by the network-based transaction facility  10  (e.g., 5 seconds). The series of photos in the slide show are continually rotated through until one is selected, or the user closes or exits the window including the transaction listing  70 .  
     [0219]FIG. 17 is a detailed flow chart illustrating a method  500 , according to an exemplary embodiment of the present invention, of entering a transaction listing description via a transaction listing description interface  450 . The method  500  commences at block  502 , where the seller application  66  presents a transaction listing description interface  450 . As described above, the transaction listing description interface  450  includes design view option  452 , HTML view option  454 , and preview view option  456 .  
     [0220] At block  504 , the user selects the design view option  452 , responsive to which the seller application  66  presents the user with the design view dialog box  466 . In the exemplary embodiment, design view dialog box  466  is the default dialog box and is presented to the user in the transaction listing description interface  450  at block  502 . At block  506 , the user enters descriptive text  458  at 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 .  
     [0221] At block  508 , the user selects the HTML view option  454 , responsive to which the seller application  66  presents the user with the descriptor language dialog box  470 , an exemplary embodiment of which is shown in FIG. 19B. The descriptor language dialog box  470  descriptor language code portion  472  automatically populates with descriptor language code (e.g., HTML code) according to the descriptive text  458  previously entered at block  506 . The user may modify (e.g., add, delete, edit) the descriptor language code in the descriptor language code portion.  
     [0222] At block  510 , the user selects preview view option  456 , responsive to which the seller application  66  presents the user with preview view dialog box  478 , an exemplary embodiment of which is shown in FIG. 16C. The preview view dialog box  478  displays the transaction listing&#39;s description as it appears when published at the network-based transaction facility  10 . Content may not be edited in the preview view dialog box  478 .  
     [0223] At decision block  512 , a determination is made as to whether the user wants to enter a photo corresponding to the transaction listing  70 .  
     [0224] At block  514 , if a photo is to be entered, the photo is retrieved and attached to the transaction listing  70 . The user initiates the photo selection process by selecting the “select photo” button from the design view dialog box  466 . In exemplary embodiments, the network-based transaction facility  10  photo hosting service may be utilized, a user specified hosting service may be utilized or the photos may be selected from a collection stored on the user&#39;s computer.  
     [0225] At block  516 , a layout  464  to be utilized in the display of the transaction listing  70  is chosen. The layout  464  is a selectable option available at the WYSIWYG interface. A default layout is utilized if none is chosen.  
     [0226] At block  518 , a theme  462  to be utilized in the display of the transaction listing  70  is chosen. The theme  462  is a selectable option at the WYSIWYG interface. A default theme is utilized if none is chosen. The method  500  concludes at block  1210 .  
     [0227]FIG. 18 is a detailed flow chart illustrating a method  550 , according to an exemplary embodiment of the present invention, of scheduling listings, entered via the seller application  66 , after they are received at a network-based transaction facility  10 . In an exemplary embodiment the transaction listings  70  define the parameters and content of an on-line commercial process (e.g., on-line store, on-line auction). Nonetheless, it will be appreciated that a transaction listing  70  may provide any transaction parameters (e.g., a product or service that is being offered for sale by any methodology, or a product service requirement description). Specifically, in an alternative embodiment, the transaction listings  70  may describe a product or service being offered for a fixed price by way of a classified advertisement or that has been offered or is required within the context of a B2B exchange or electronic marketplace.  
     [0228] The method  550  commences at block  552 , the batch text  68  is received at the network-based transaction facility  10 .  
     [0229] At block  554 , the parser module  76  of the transaction application  311  parses the batch text  68  to extract the various transaction listings  70  embodied therein, and performs various verification operations with respect to each of the each of the extracted transaction listings  70 .  
     [0230] At block  556 , the transaction application  311  communicates a confirmation message to the client machine  38  to confirm successful receipt and extraction of the various transaction listings  70 , including their scheduled start times. In one embodiment, the confirmation message may comprise an e-mail message communicated from the e-mail servers  22  of the network-based transaction facility  10 . In an alternative embodiment, the page server  12  may, responsive to a user request, generate a markup language document (e.g., a HTML document) that communicates the confirmation message to the user. The confirmation message communicated to the client machine  38  at block  556  may further include a location identifier (e.g., a Uniform Resource Locator (URL)) that provides a link to a listing of the collection of transaction listings  70  extracted by the parser module  76  at block  656  from batch text collection  68 . In an alternative embodiment, the confirmation message itself may present such a list of transaction listings  70 . For example, the confirmation message that is communicated via e-mail to the client machine  38  may comprise an HTML document that provides a list of transaction listings  70  included within batch text  68  including the collection  306 .  
     [0231] At block  558 , the user is presented with a number of interfaces that facilitate viewing and editing of the propagated collection (e.g., in the form of batch text  68 ) of transaction listings  70 . Consequently, the user may update the transaction listings  70  after they have been propagated via the data file (e.g., batch text  68 ) to the network-based transaction facility  10 . The user may either update the transaction listings  70  online while connected to the network-based transaction facility  10  or make updates at the seller application  66  and propagate them to the network-based transaction facility  10 . In one embodiment, the various interfaces that facilitate viewing and editing of the transaction listings  70  may be markup language documents that are generated by the page server  12  and communicated to the client machine  38  via the Internet  34  for viewing within the context of the browser application  36 . For example, such interfaces in the form of markup language documents may be invoked by user-selection, on the client-side  35 , of a URL included within the confirmation message communicated at block  556 . In an alternative embodiment, the interfaces presented at block  558  may be generated by the seller application  66  utilizing, for example, text and data communicated from the transaction application  311 . FIGS. 19A and 19B illustrate exemplary interfaces  600  and  602  that may be presented to a user by a network-based transaction facility  10  so as to allow the viewing, editing, previewing and confirmation of collections of transaction listings  70  and of individual transaction listings  70 .  
     [0232] The seller application  66  includes the ability to automatically update/upgrade itself with certain pieces of information provided by the network-based transaction facility  10 .  
     [0233]FIG. 20 is a detailed flow chart illustrating a method  650 , according to an exemplary embodiment of the invention, of facilitating the updating/upgrading of the seller application  66 . The method  650  commences at  652  at connection to the network-based transaction facility  10  by the seller application  66 .  
     [0234] At block  654 , the network-based transaction facility  10  determines if there are updates/upgrades, which the seller application  66  has not received. To support minimal updates/upgrades, a versioning mechanism is used to compare available versions of data elements (e.g., targeted site config files  86 ) modules (e.g., main module  84 , communication module  95 , resource module  81 , etc.) for the seller application  66  at the network-based transaction facility  10  against the versions of the installed data elements and modules at the seller application  66 . Updates/upgrades are downloaded for software modules and data elements that have changed. The downloaded data may be compressed to shorten transfer times. As explained earlier, in the exemplary embodiment, updates/upgrades include but are not limited to categories updates, attributes updates, program information updates and version upgrades. With regards to categories, the seller application  66  determines if there are new/different category structures for any of the seller application  66  enabled targeted sites. Providing automatic category upgrades to the seller application  66  upon connection the network-based transaction facility  10  is advantageous in that categories may change frequently (e.g., once a month).  
     [0235] With regards to attributes, the seller application  66  determines if there are new/different attributes structures for any of the seller application  66  enabled targeted sites. As previously explained, attributes are category-specific information items that the seller can specify to help buyers find items, and may not exist for all categories. An example would be the Real Estate—Residential category. For example, when listing an item in this category, a user may be prompted to specify Number of bedrooms, Number of bathrooms, Square footage, Air Conditioning, Pool (drop-down with: No, Inground, Out-of-Ground), etc. . . .  
     [0236] The buyers are then presented with a selector tool to use while searching that allows specification of certain attribute requirements (e.g., in the Real Estate—Residential category, with “New York” in the item title, 4 bedrooms, and 2 bathrooms). Without attributes, the sellers may specify such information but it is not standardized so a reliable search mechanism cannot be provided. With attributes, a user is assured that the right information is being searched and retrieved.  
     [0237] Some other example categories with attributes include a computers category (processor speed, hard drive size, etc . . . ), a clothing (or apparel) category (type, brand, color, etc . . . ), and a ticket category (event type, city, state, face value, etc . . . ).  
     [0238] In the exemplary embodiment, version upgrades include modifications made to the seller application  66  (e.g., software changes). Such modifications may also be known as program updates. Also in the exemplary embodiment, the seller application  66  updates/upgrades may be deferred. However, the network-based transaction facility  10  may force an upgrade (e.g., critical changes to the program) or update (e.g., critical changes to categories). The user does not have the ability to opt out of a forced update or upgrade.  
     [0239] At block  656 , if the network-based transaction facility  10  determines that there are updates/upgrades to the seller application  66 , the updates/upgrades are downloaded to the seller application  66 . In one embodiment, updates/upgrades are only downloaded if automatic updating of the seller application  66  is enabled. Following a positive determination at decision block  656 , the method  650  progresses to block  658 , where the updates/upgrades are automatically installed. In the exemplary embodiment, the seller application  66  includes routines to automatically install the updates/upgrades. In an alternative embodiment, install routines are downloaded with each series of updates/upgrades. The install routines are configured to automatically launch upon completion of the download and to install the program updates/upgrades. In one embodiment, the install routines are configured to automatically launch only if automatic updating of the seller application  66  is enabled. The method  650  concludes at block  660 .  
     [0240] FIGS.  21 A- 21 C provide further details regarding the database structure, maintained by the database engine server  26 , to support the above-described methodologies.  
     [0241] At FIG. 21A, the batch table  42  includes a record for each collection of transaction listings  70  as originally described, for example, within batch text  68  received at the network-based transaction facility  10 .  
     [0242] A one-to-many relationship exists between the batch table  42  and the batch items table  40 , which contains transaction listings  70  extracted by the parser module  76  from the batch text  68  into the database  30 , but which have not as yet gone live.  
     [0243] The items wait table  44  stores loaded transaction listings  70  that are waiting to go live as described above. The items tables  60  stores records of the actual transaction listings  70  that have gone live by the initiation of the transaction process (e.g., an auction process or an offer for sales prices) by the network-based transaction facility  10 .  
     [0244]FIGS. 21B and 21C illustrate an entity relationship diagram providing further details regarding exemplary fields that may be supported by the batch, batch items, items wait, items, user and related tables.  
     [0245]FIG. 22 shows a diagrammatic representation of machine in the exemplary form of a computer system  800  within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance, set-top box (STB) or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.  
     [0246] The computer system  800  includes a processor  802 , a main memory  806  and a static memory  808 , which communicate with each other via a bus  824 . The computer system  800  may further include a video display unit  812  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  800  also 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 generation device  822  (e.g., a speaker) and a network interface device  810 .  
     [0247] The disk drive unit  818  includes a machine-readable medium  820  on which is stored a set of instructions (i.e., software)  804  embodying any one, or all, of the methodologies described above. The software  804  is also shown to reside, completely or at least partially, within the main memory  806  and/or within the processor  802 . The software  804  may further be transmitted or received via the network interface device  810 . For the purposes of this specification, the term “machine-readable medium” shall be taken to include any medium which is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals. Further, while the software is shown in FIG. 22 to reside within a single device, it will be appreciated that the software  804  could be distributed across multiple machines or storage media, which may include the machine-readable medium.  
     [0248] Thus, a method and system to schedule transaction listings at a network-based transaction facility, via the seller application, have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.  
     [0249] In the foregoing detailed description, the method and system of the present invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present invention. In particular, the separate blocks of the various block diagrams represent functional blocks of methods or apparatuses and are not necessarily indicative of physical or logical separations or of an order of operation inherent in the spirit and scope of the present invention. For example, the blocks of FIGS. 11 a  and  11   b  represent portions of a method, which, in some embodiments, may be reordered or may be organized in parallel rather than in a linear or step-wise fashion. The present specification and figures are accordingly to be regarded as illustrative rather than restrictive.