US20100257045A1 - Invoicing system - Google Patents

Invoicing system Download PDF

Info

Publication number
US20100257045A1
US20100257045A1 US12/820,046 US82004610A US2010257045A1 US 20100257045 A1 US20100257045 A1 US 20100257045A1 US 82004610 A US82004610 A US 82004610A US 2010257045 A1 US2010257045 A1 US 2010257045A1
Authority
US
United States
Prior art keywords
transactions
seller
entity
combinable
invoice
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/820,046
Inventor
Paul Fu
Erik Hansen
George Liang
Deborah Liu
Ngan-Ha D. Nguyen
Andrew Leigh Sandler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
eBay Inc
Original Assignee
eBay Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US49560803P priority Critical
Priority to US50125103P priority
Priority to US10/882,633 priority patent/US7742947B2/en
Application filed by eBay Inc filed Critical eBay Inc
Priority to US12/820,046 priority patent/US20100257045A1/en
Publication of US20100257045A1 publication Critical patent/US20100257045A1/en
Assigned to EBAY, INC. reassignment EBAY, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LIU, DEBORAH, HANSEN, ERIK BECK, SANDLER, ANDREW LEIGH, FU, PAUL, LIANG, GEORGE, NGUYEN, NGAN-HA D.
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/04817Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance using icons
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance interaction with lists of selectable items, e.g. menus
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object or an image, setting a parameter value or selecting a range
    • G06F3/04842Selection of a displayed object
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/02Marketing, e.g. market research and analysis, surveying, promotions, advertising, buyer profiling, customer management or rewards; Price estimation or determination
    • G06Q30/0207Discounts or incentives, e.g. coupons, rebates, offers or upsales
    • G06Q30/0222During e-commerce, i.e. online transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/04Billing or invoicing, e.g. tax processing in connection with a sale
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping

Abstract

A method to facilitate invoicing for transactions established utilizing a network-based transaction system includes supporting establishment of transactions between a plurality of entities in the network-based transaction system, and identifying as part of an invoice generation process, a plurality of transactions to which a first entity is a party. The method further includes identifying first and second transactions from the plurality of transactions that satisfy combinable criteria, and generating an invoice for at least the first and second transactions that satisfy the combinable criteria. The method can also be implemented in a system and on a machine-readable medium.

Description

    RELATED APPLICATIONS
  • This application is a divisional of U.S. application Ser. No. 10/882,633 filed Jun. 30, 2004, which claimed the benefit of U.S. Provisional Application Nos. 60/495,608, filed Aug. 14, 2003 and 60/501,251, filed Sep. 8, 2003, all of which are incorporated herein by reference in their entirety.
  • TECHNICAL FIELD
  • The present invention relates generally to the technical field of commerce automation and, in particular, to methods and systems to facilitate generation of invoices combining multiple transactions established utilizing a network-based transaction system, and in particular, a multi-seller network-based marketplace.
  • BACKGROUND
  • Network-based marketplaces have, with the widespread adoption of Internet technologies, become increasingly popular venues for the buying and selling of goods and services. As more and more sellers turn to network-based marketplaces as an important distribution channel, the need to provide invoicing tools to such sellers has increased.
  • While a number of traditional invoicing tools (e.g., Quickbooks, developed and distributed by Intuit, Inc.) are typically available to sellers, such invoicing tools are typically independent of a marketplace at which a seller may have established transactions. Accordingly, the seller is required manually to input information relating to transactions for which invoices are to be generated.
  • In order to make a network-based marketplace more attractive to sellers, there is some incentive for an operator of the network-based marketplace to provide invoicing tools that are tightly integrated with the marketplace, and that can automatically retrieve and include information regarding transactions within invoices. However, the design of such integrated invoicing tools presents a number of technical challenges, specifically regarding how the invoices may be customized to accommodate the unique requirements of a particular transaction and of a particular buyer or seller. Further, a number of technical challenges exist with respect to the automation of invoice generation by such invoicing tools, given the large number of the variables that may be associated with a particular transaction.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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:
  • FIG. 1 is a network diagram depicting a commerce system, according to one exemplary embodiment of the present invention.
  • FIG. 2 is a block diagram illustrating multiple market applications provided as part of a network-based marketplace, according to one embodiment of the present invention.
  • FIG. 3 is a high-level entity-relationship diagram, illustrating various databases that may be utilized by and support the marketplace.
  • FIG. 4 shows various fields of database tables.
  • FIG. 5 is a flow diagram of one embodiment of a process for creating invoices combining multiple transactions established utilizing a network-based marketplace.
  • FIGS. 6 and 14 are block diagrams of two alternative embodiments of a seller-initiated process for generating invoices consolidating multiple items.
  • FIG. 19 is a block diagram of one embodiment of a buyer-initiated process for generating invoices consolidating multiple items.
  • FIGS. 29A-29B and 30A-30C are block diagrams of several embodiments of a process for defining rules for charges associated with combined transactions.
  • FIGS. 35 and 37 are block diagrams of two embodiments of a process for calculating charges for invoices including combined transactions using predefined charge rules.
  • FIGS. 7-13, 15-18, 20-28, 31-34 and 36 illustrate exemplary user interfaces (UIs) presented to a user of the marketplace, according to various embodiments of the present invention.
  • FIG. 38 is a diagrammatic representation of an exemplary computer system.
  • DETAILED DESCRIPTION
  • A method and system to facilitate generation of invoices combining multiple transactions, established utilizing a multi-seller network-based marketplace, 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.
  • Platform Architecture
  • FIG. 1 is a network diagram depicting a commerce system 10, according to one exemplary embodiment of the present invention, having a client-server architecture. Specifically, a trading platform, in the exemplary form of a network-based marketplace 12, provides server-side functionality, via a network 14 (e.g., the Internet) to one or more clients. FIG. 1 illustrates, for example, a web client 16 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State), and a programmatic client 18 executing on respective client machines 20 and 22.
  • Turning specifically to the network-based marketplace 12, an Application Program Interface (API) server 24 and a web server 26 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 28. The application servers 28 host one or more marketplace applications 30 and payment applications 32. In one embodiment, the application servers 28 include a marketplace server hosting one or more marketplace applications 30 and a payment server hosting one or more payment applications 32.
  • The application servers 28 are coupled to one or more databases servers 34 that facilitate access to one or more databases 36.
  • The marketplace applications 30 support a number of marketplace functions and services to clients that access the marketplace 12. The payment applications 32 likewise provide a number of payment services and functions to clients that access marketplace 12. While the marketplace and payment applications 30 and 32 are shown in FIG. 1 to both form part of the network-based marketplace 12, it will be appreciated that in alternative embodiments of the present invention, the payment applications 32 may form part of a payment service that is separate and distinct from the marketplace 12.
  • Further, while the commerce system 10 shown in FIG. 1 employs a client-server architecture, the present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system. The various marketplace and payment applications 30 and 32 could also be implemented as standalone software programs, which do not necessarily have networking capabilities.
  • The web client 16, it will be appreciated, accesses the various marketplace and payment applications 30 and 32 via the web interface supported by the web server 26. Similarly, the programmatic client 18 accesses the various services and functions provided by the marketplace and payment applications 30 and 32 via the programmatic interface provided by the API server 24. The programmatic client 18 may, for example, be a seller application (e.g., the TurboLister application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the marketplace 12 in an off-line manner, and to perform batch-mode communications between the programmatic client 18 and the network-based marketplace 12.
  • FIG. 1 also illustrates a third party application 38, executing on a third party server machine 40, as having programmatic access to the network-based marketplace 12 via a programmatic interface 40 and the programmatic interface provided by the API server 24. For example, the third party application 38 may, utilizing information retrieved from the network-based marketplace 12, support one or more features or functions on a website hosted by the third party. The third party website may, for example, provide one or more marketplace or payment functions that are supported by the relevant applications of the network-based marketplace 12.
  • Marketplace Applications
  • FIG. 2 is a block diagram illustrating multiple market applications 30 that, in one exemplary embodiment of the present invention, are provided as part of the network-based marketplace 12. The marketplace 12 may provide a number of listing and price-setting mechanisms whereby a seller can list goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, the marketplace applications 30 are shown to include one or more auction applications 44 with support auction-format listings and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). The various auction applications 44 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
  • A number of fixed-price applications 46 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings may be offered in conjunction with an auction-format listing, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price which is typically higher than the starting price of the auction.
  • Store applications 48 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
  • Reputation applications 50 allow parties that transact utilizing the network-based marketplace 12 to establish, build and maintain reputations which may be made available and published to potential trading partners. Specifically, where the network-based marketplace 12 supports person-to-person trading, parties to a transaction may have no history or other reference information whereby trustworthiness and credibility may be ascertained. The reputation applications 50 allow a party, for example through feedback provided by other transaction partners, to establish a reputation over time within the network-based marketplace 12. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness.
  • Personalization applications 52 allow users of the marketplace 12 to personalize various aspects of their interactions with the marketplace 12. For example a user may, utilizing an appropriate personalization application 52, create a personalized reference page at which information regarding transactions to which the user has been a party may be viewed. Further, a personalization application 52 may enable a user to personalize listings and other aspects of their interactions with the marketplace 12 and other parties.
  • In one embodiment, the network-based marketplace 12 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of the marketplace 12 may be customized for the United Kingdom, whereas another version of the marketplace 12 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace.
  • Navigation of the network based-marketplace 12 may be facilitated by one or more search applications 56. For example, a search application enables key word searches of listings published via the marketplace 12. A browse application allows users to browse various category, or catalogue, data structures according to which listings may be classified within the marketplace 12. Various other navigation applications may be provided to supplement the search and browsing applications.
  • In order to make listings available via the network-based marketplace 12 as visually informing and attractive as possible, the marketplace applications 30 may include one or more imaging applications 58 utilizing which users may upload images for inclusion within listings. An imaging application 58 also operates to incorporate images within viewed listings. The imaging applications 58 may also support one or more promotional features, such as image galleries that may be presented to potential buyers. For example, sellers may pay an additional fee to have an image associated with one or more of the listings included within a gallery of images for promoted items.
  • Listing creation applications 60 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the marketplace 12, and listing management applications 62 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. The listing management applications 62 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings. One or more post-listing management applications 64 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one or more auction applications 44, a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 64 may provide an interface to one or more reputation applications 50 so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 50.
  • Dispute resolution applications 66 provide mechanisms whereby disputes that may arise between transacting parties may be resolved. Specifically, the dispute resolution applications 66 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle the dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third party mediator or arbitrator.
  • A number of fraud prevention applications 68 implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within the marketplace 12.
  • Messaging applications 78 are responsible for the generation and delivery of messages to users of the network-based marketplace 12, such messages for example advising users regarding the status of listings at the marketplace 12 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users).
  • Merchandising applications 80 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the marketplace 12. The merchandising applications 80 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.
  • The network-based marketplace 12 itself, or one or more parties that transact via the marketplace 12, may operate loyalty programs that are supported by one or more loyalty applications 82. For example, a buyer may earn loyalty points for each transaction established and/or concluded with a particular seller, and be offered a reward for which accumulated loyalty points can be redeemed.
  • So as to enable sellers effectively to generate and communicate invoices to buyers, the marketplace applications 30 include one or more invoice applications 84. According to one exemplary embodiment of the present application, the invoice applications 84 may include an order application 86 that allows a user of the network-based marketplace 12 (e.g., a buyer or a seller) conveniently to combine multiple transactions into a single order for invoicing purposes. The invoicing applications 84 may also include a shipping and handling charge application 84 to at least partially automate the calculation of shipping and handling charges in connection with one or more orders, and an insurance charge application 86 to at least partially automate the calculation of insurance charges in connection with an order. The order application 86 is shown to include an order discount module 88, which automatically calculates and applies discounts in connection with various order conditions, and according to stored rules. Similarly, the shipping application 84 is shown to include a shipping discount module 90, which operates automatically to calculate and apply shipping discounts according to stored rules. Further details regarding the exemplary embodiments of the invoice applications 84 are provided below.
  • Data Structures
  • FIG. 3 is a high-level entity-relationship diagram, illustrating various tables 91 that may be maintained within the databases 36, and that are utilized by and support the marketplace 12 and payments applications 30 and 32. A user table 92 contains a record for each registered user of the network-based marketplace 12, and may include identifier, address and financial instrument information pertaining to each such registered user. A user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-based marketplace 12.
  • The tables 91 also include an items table 94 in which is maintained an item record for each item or service that is available to be, or has been, transacted via the marketplace 12. Each item record within the items table 94 may furthermore be linked to one or more user records within the user table 92, so as to associate a seller and one or more actual or potential buyers with each item record.
  • FIG. 4 shows various fields that may be supported for each record within the items table 94. Particularly pertinent to the exemplary embodiment of the present invention, it will be noted that each item record may include a “combinable” field 96, which may record an indication, provided by a seller, that a transaction pertaining to the relevant item is combinable with other transactions for the purposes of a creating a single order. Trade status, invoice status, payment status and currency identifier fields 98-104 may also be utilized by an invoice application 84, as described below, in the generation of an invoice pertaining to an order.
  • Referring to FIG. 3, the tables 91 also include a transaction table 106, which contains a record for each transaction (e.g., a purchase transaction) pertaining to items for which records exist within the items table 94. Specifically, a transaction record in connection with a particular item may be created in the transaction table 106 upon the establishment of an agreement between a buyer and seller to exchange value in connection with a particular good or service.
  • As illustrated in FIG. 4, each record within the transaction table 106 may include an item identifier 108 that links to an item record within the items table 94, a seller identifier 110 and a buyer identifier 112, each of the seller and buyer identifiers 110 and 112 linking to a user record within the user table 92. It should be noted that multiple transaction records within the transaction table 106 might link back to a single item record within the items table 94, where that single item record relates to a multi-quantity item.
  • An order table 114 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transactions table 106. As such, a particular order record within the order table 114 may reference multiple transaction identifiers 116. In the exemplary embodiment, each order record may indicate only a single buyer-seller pairing, this buyer-seller pairing being identified by the seller and buyer identifiers 110 and 112.
  • The tables 91 are also shown to include a rules table 118, which is shown to be linked to the user table 92. Specifically, the rules table 118 is populated with rule records, each rule record identifying various charge rules that are associated with users of the network-based marketplace 12. Referring specifically to FIG. 4, it will be noted that each rules record includes seller identifier and buyer identifier fields 110 and 112. Accordingly, a particular rule may be associated with a user in the role of a buyer or a seller. For example, a particular charge rule may be associated with a particular user when that user operates in a buyer role at the marketplace 12, and a different charge rule may be associated with the particular user when that user operates in a seller role at the marketplace 12.
  • Each rule record within the rules table 118 may also record a purchase charge rule 120, a shipping and handling charge rule 122, and a shipping insurance charge rule 124. An invoice application 84 references the rules 120-124 when calculating total charges for an order, to be reflected in an invoice. Accordingly, the rules 120-124 allow a user's preferences to be reflected in the automated (or at least partially automated) calculation of total charges in connection with an order. Specifically, a purchase charge rule 120 may specify a charge calculation rule to be invoked with respect to purchases involving an identified user. For example, a user, when acting in the capacity of a seller, may specify a purchase charge rule 120 in terms of which a discount (e.g., a percentage off a total purchase price) is offered when a buyer purchases multiple items. Similarly, a shipping and handling charge rule 122 may specify how shipping and handling charges are calculated with respect to items purchased from the user, when acting in the capacity of a seller. In one exemplary embodiment of present invention, such shipping and handling charge rules 122 include actual rate shipping charge rules and flat rate shipping charge rules, each rule type being customizable by a seller to reflect the seller's preferences. Further details regarding exemplary shipping and handling charge rules 122 are provided below. A shipping insurance charge rule 124 similarly reflects user preferences with respect to the calculation of shipping insurance charges, and may be invoked by an invoice application 84 to at least partially automate the calculation of such charges when generating an invoice.
  • FIG. 3 also illustrates the tables 91 as including a bids table 130. Each bid record within the bids table 130 relates to a bid received at the network-based marketplace 12 in connection with an auction form of listing supported by an auction application 44. A feedback table 132 is utilized by one or more reputation applications 50, in one exemplary embodiment, to construct and maintain reputation information concerning users. A history table 134 maintains a history of transactions to which a user has been a party. One or more attributes tables 136 record attribute information pertaining to items for which records exist within the items table 94. Considering only a single example of such an attribute, the attributes tables 136 may indicate a currency attribute associated with a particular item.
  • Invoices Combining Multiple Transactions
  • FIG. 5 is a flow diagram of one embodiment of a process 500 for creating invoices combining multiple transactions established utilizing a network-based marketplace. Process 500 may be performed by processing logic, which may comprise hardware, software, or a combination of both. In one embodiment, processing logic resides in a payment server (e.g., one of the application servers 28 of FIG. 1).
  • Referring to FIG. 5, process 500 begins with processing logic locating concluded transactions involving a first user in a predefined time period (processing block 502). A transaction is concluded when an agreement is established between two parties (e.g., a buyer and a seller) to exchange value in connection with an item (e.g., a good or a service) or multiple quantities of an item. The first user may represent either of the two parties. A predefined time period may be systematically defined or specified by the first user. In one embodiment, processing logic locates concluded transactions by searching a transaction table 106 of FIG. 3.
  • At processing block 504, processing logic identifies concluded transactions that satisfy combinable criteria. The combinable criteria may require, for example, that the transactions be from a common buyer and a common seller, be unpaid, be associated with the same currency and/or the same marketplace site (a marketplace customized for the same geographic region), etc. The combinable criteria may be configurable based on a specific marketplace or a marketplace site.
  • At processing block 506, processing logic identifies the combinable transactions to the first user. For example, processing logic may identify the combinable transactions by displaying them to the first user with a combinability indicator (e.g., an icon), providing a link to a screen displaying each or all subsets of the identified combinable transactions, requesting the first user to specify his or her trading partner and displaying all combinable transactions between the first user and the trading partner, etc.
  • At processing block 508, processing logic receives data indicating the first user's approval for consolidating a subset of combinable transactions into a single order. For example, processing logic may receive the data indicating the first user's approval when the first user selects two or more transactions from a displayed subset of combinable transactions and clicks a designated button (e.g., a send invoice button or a combine items button, a pay now button, etc.) on the screen. In another embodiment, the invoice may include multiple subsets of combinable transactions associated with the first user and different trading partners of the first user. In yet another embodiment, the invoice may include one or more subsets of combinable transactions and one or more individual transactions associated with the first user and different trading partners of the first user.
  • At processing block 510, processing logic adds charges to the order with combined transactions. The charges may include, for example, shipping costs, shipping insurance costs, etc. The charges may include a discount for consolidating combinable transactions into a single order. In one embodiment, the charges are applied based on rules specified by the seller. In another embodiment, the charges are applied based on rules established in the network-based marketplace. In yet another embodiment, the charges are applied based on input provided by the first user for the current order. In still another embodiment, the charges are applied based on input provided by the trading partner for the current order in response to the first user's request for this input.
  • Next, processing logic creates a preview invoice for the order, presents the preview invoice to the first user (processing block 512), and asks the first user to approve the preview invoice. If the first user approves the invoice (decision box 514), processing logic saves the invoice (processing block 516) and, in one embodiment, notifies the trading partner about the invoice. If the first user does not approve the invoice, processing logic cancels the invoice for the order (processing block 516) and, in one embodiment, creates an individual invoice for each transaction in the order.
  • In one embodiment, an order combining multiple transactions may be created either by a seller or a buyer. In one embodiment, an order has a specific state. For example, an order may be active, inactive, complete, or cancelled. An active order is the most recent order created by either the buyer or seller. A transaction may only be part of a single active order at any given time. An inactive order is an order that became inactive because either (a) the seller has uncombined a seller created active order, (b) the buyer has uncombined a seller created active order, or (c) the buyer has created a new order replacing a previous buyer created active order. A complete order is an order paid by the buyer (e.g., when the buyer completes checkout or pays through an electronic payment service on an active or inactive order). An order is cancelled when any of its transactions no longer satisfy the combinable criteria. For example, an order containing an item for which the buyer has made a payment is marked as cancelled.
  • In one embodiment, a buyer is allowed to create an order with combinable transactions that are not part of an existing active seller-created order or a complete order. If the buyer creates an order that consists of transactions from an existing active buyer-created order, this existing order is marked as inactive. The transactions may only be associated with a single active order. A seller is allowed to create an order with combinable transactions that are not part of a complete order. If the seller creates an order with combinable transactions that are part of an existing active buyer-created order, this buyer-created order is marked as inactive, and its transactions are associated to the new active seller-created order.
  • In one embodiment, a buyer can pay for any order that is not marked as complete. Any active or inactive order may be checked out or paid through the electronic payment service by the buyer. If the buyer completes checkout or pays through the electronic payment service on an active order, the status of the order is marked as completed. If the buyer completes checkout or pays through the electronic payment service on an inactive order, the status of the inactive order is marked as completed. For example, if the buyer first creates the order and proceeds to pay at the electronic payment service, and then the seller creates an order with the same items prior to the buyer completing the payment, the buyer-created order is marked as inactive, and the transactions are associated to the active seller-created order.
  • In one embodiment, each order is referenced by a unique sales record number associated with a seller.
  • FIGS. 6 and 14 are block diagrams of two alternative embodiments of a seller-initiated process for generating invoices consolidating multiple items. The process may be performed by processing logic, which may comprise hardware, software, or a combination of both.
  • Referring to FIG. 6, process 600 will be described in conjunction with exemplary user interfaces illustrated in FIGS. 7-13. In one embodiment, processing logic of process 600 resides in a payment server (e.g., one of the application servers 28 of FIG. 1).
  • Process 600 may start with any one of processing blocks 602, 604 and 606. At processing block 602, processing logic receives data identifying a seller's selection of a buyer for whom the invoice should be generated. In one embodiment, processing logic identifies subsets of items purchased from the seller that can be combined based on the combinability criteria, presents to the seller a user interface (UI) that displays a list of buyers who purchased combinable items from the seller, and allows the seller to select a specific buyer. When processing logic receives the seller's selection of the specific buyer, it proceeds to processing block 608 where a list of items purchased from the seller by the selected buyer is displayed. FIG. 7 illustrates an exemplary UI (Select a Buyer to Invoice UI) that allows a seller to specify a buyer for whom the invoice should be generated.
  • At processing block 604, processing logic receives the seller's selection of a combinability indicator associated with an item purchased from the seller. In one embodiment, processing logic identifies subsets of items purchased from the seller that can be combined based on the combinability criteria, displays a list of items purchased from the seller within a certain time period (e.g., as specified by the seller) with each combinable item having a combinability indicator (e.g., a designated icon), and allows the seller to select a combinability indicator of a specific item. When processing logic receives the seller's selection of a combinability indicator of a specific item, it proceeds to processing block 608 where a list of items that can be combined with the specific item is displayed. FIG. 8 illustrates an exemplary UI (Items I've Sold UI) that presents each combinable item with an icon and allows a seller to select an icon of a specific item to view the items combinable with the specific item.
  • At processing block 606, processing logic receives the seller's request to add other items to the invoice being created. In one embodiment, processing logic identifies items that can be combined, based on the combinability criteria, with the item for which the invoice is being created, and provides on the invoice page a link to a list of items that can be combined with the item on the invoice. When processing logic receives the seller's selection of the link, it proceeds to processing block 608 where a list of items that can be combined with the item on the invoice is displayed. FIG. 9 illustrates an exemplary UI (Send Invoice UI) that includes a link to a list of items combinable with the displayed item.
  • At processing block 608, processing logic displays a list of combinable items and allows the seller to modify this list (e.g., by removing some items from the list). At processing block 610, processing logic receives the seller's input regarding the displayed items and, in one embodiment, allows the seller to specify charges for the items (e.g., shipping and handling charges, shipping insurance, etc.). In another embodiment, processing logic calculates charges for the items based on rules specified by the seller or standard rules maintained within the marketplace. FIGS. 10A and 10B illustrate exemplary ins (Combine Purchases UI and Send Invoice UI) that allow the seller to check items to be combined in the invoice, specify charges (shipping and handling charges, shipping insurance, and sales tax) for the combined items, enter payment instructions for the buyer, and specify payment methods acceptable to the seller.
  • Next, upon receiving the seller's request to combine the specified items (e.g., via the Combine Purchase UI) (processing block 612), processing logic ensures that the items are still combinable (i.e., satisfy the combinable criteria) (processing block 613), and saves the resulting order in a database (processing block 614). One or more items may no longer satisfy the combinable criteria if, for example, the buyer has paid or completed the checkout on the items during the seller's interaction with the UI, or the seller has created another active order containing the items using a different browser window. Then, processing logic removes the items that no longer satisfy the combinable criteria from the order and asks the seller to review the remaining items.
  • The order saved in the database is subsequently retrieved from the database in response to the seller's request to send the invoice for the order to the buyer.
  • Alternatively, processing logic may receive the seller's request to send the invoice when receiving the seller's input regarding the displayed items and the applicable charges (e.g., via the Send Invoice UI) (processing block 616). Then, processing logic ensures that the items in the invoice are still combinable (i.e., satisfy the combinable criteria) (processing block 617), saves the invoice in the database and sends an email to the buyer, including a link to a page displaying the invoice (processing block 618). FIG. 11 illustrates an exemplary UI (Invoice Sent to Buyer UI) that informs the seller that an email with a link to the invoice was sent to the buyer.
  • In one embodiment, the seller may request to uncombine items included in the saved order or invoice. FIG. 12 illustrates an exemplary UI (Uncombine Purchases UI) allowing the seller to request that the items from the order or invoice be uncombined.
  • Further, upon receiving a buyer's request to view the invoice (e.g., the buyer's selection of the link to the invoice in the email) (processing block 620), processing logic displays the seller's created invoice to the buyer (processing block 622). FIG. 13 illustrates an exemplary UI (Pay Now for Multiple Items UI) that displays the content of the invoice to the buyer and allows the buyer to pay for the entire order or for each item individually.
  • FIG. 14 is a block diagram of an alternative embodiment of a seller-initiated process 1400 for generating invoices consolidating multiple items. Process 1400 will be described in conjunction with exemplary user interfaces illustrated in FIGS. 15-18. In one embodiment, processing logic of process 1400 resides in a payment service system providing payment services to multiple network-based marketplaces, including the marketplace 12 of FIG. 1.
  • Referring to FIG. 14, process 1400 begins with processing logic displaying items sold by a seller within a predefined time period (processing block 1402). FIG. 15 illustrates an exemplary UI (Post Sale Manager UI) that presents items sold by a seller in the past 30 days and a set of filters allowing the seller to view different categories of items sold by the seller (e.g., all items, unpaid items, paid items, unpaid uninvoiced items, unpaid combinable items, unpaid invoiced items, etc.).
  • At processing block 1404, processing logic receives seller's request to display a specific category of items sold by the seller (e.g., using a filter provided by the Post Sale Manager UI). In response, processing logic displays the items of the specified category. In the discussed embodiment, processing logic may display all unpaid items (processing block 1406) or combinable items that satisfy combinable criteria (processing block 1408). The combinable criteria may require, for example, that the combinable items include subsets of multiple unpaid items that have a common seller and a common buyer.
  • Next, processing logic receives data identifying the seller's selection of items for the invoice and a request to generate the invoice (processing block 1410). FIG. 16 illustrates an exemplary UI (Invoice Manager UI) that presents unpaid items sold by the seller, allows the seller to select items for the invoice (e.g., one or more subsets of combinable items and/or individual items) and to send a request to create the invoice. The seller may request to invoice a single buyer for different items or multiple buyers for different items.
  • Further, processing logic ensures that the selected items are still unpaid, creates the invoice, and sends the invoice to one or more buyers upon a seller request to send the invoice (processing block 1416). FIG. 17 illustrates an exemplary UI that presents the invoice to the seller and allows the seller to specify charges for each subset of combinable items or each individual transaction and to issue a request to send the invoice to one or more buyers. If the invoice is sent to multiple buyers, each buyer can only view an invoice portion that is relevant to this buyer.
  • At processing block 1418, processing logic receives the buyer's request to view the invoice (e.g., upon the buyer's selection of an invoice link in an email sent to the buyer). In response, processing logic displays the invoice to the buyer (processing block 1420). FIGS. 18A and 18B illustrate exemplary UIs (Payment Details UI) that present the invoice to the buyer.
  • At processing block 1422, processing logic receives the buyer's request to pay for the items (e.g., via a pay button on the Payment Details UI of FIG. 18B) and processes the payment.
  • FIG. 19 is a block diagram of one embodiment of a buyer-initiated process 1900 for generating invoices consolidating multiple items. The process may be performed by processing logic, which may comprise hardware, software, or a combination of both. In one embodiment, processing logic resides in a payment server (e.g., one of the application servers 28 of FIG. 1). Process 1900 will be described in conjunction with exemplary user interfaces illustrated in FIGS. 20-23.
  • Referring to FIG. 19, process 1900 begins with processing logic displaying items purchased by a buyer within a certain time period (e.g., as specified by the buyer) with each combinable item having a combinability indicator (e.g., a designated icon) (processing block 1902). FIG. 20 illustrates an exemplary UI (Items I've Won UI) that presents each combinable item with an icon and allows a buyer to select an icon of a specific item to view the items combinable with the specific item.
  • At processing block 1904, processing logic receives the buyer's request to view a list of combinable items. In one embodiment, processing logic receives the buyer's request to view a list of combinable items when the buyer selects a combinability indicator of a specific item purchased from a seller.
  • In response, processing logic displays the combinable items purchased from the seller, receives the buyer's input identifying items to be combined into a single order (processing block 1906) and calculates charges for the combined items. In one embodiment, processing logic calculates charges for the items based on rules specified by the seller or standard rules maintained within the marketplace. FIG. 21 illustrates an exemplary UIs (Combine Purchases UI) that allows the buyer to check items to be combined in the invoice, displays charges (shipping and handling charges, shipping insurance, and sales tax) for the combined items, and allows the buyer to issue a request to pay for the items.
  • Next, processing logic receives the buyer's request to pay for the combined items (processing block 1908), ensures that the items are still combinable (i.e., satisfy the combinable criteria) (processing block 613), creates an order including the combined items, and saves the order in the database.
  • One or more items from the order may no longer satisfy the combinable criteria. Then, processing logic informs the buyer and offers the buyer to pay for the items individually, or removes the items that no longer satisfy the combinable criteria from the order and asks the buyer to review the remaining items. FIG. 22 illustrates an exemplary UI displaying a message informing the seller that one or more items from the order are no longer combinable.
  • Further, processing logic asks the buyer to review order information to be sent to the seller (processing block 1912), and, upon receiving an approval of the order information from the buyer (processing block 1914), sends the order information to the seller (processing block 1916). FIG. 23A illustrates an exemplary UI (Send Information to Seller UI) displaying the order information and asking the buyer to confirm that the order information is correct.
  • Afterwards, processing logic instructs the buyer to pay for the order (processing block 1918). FIG. 23B illustrates an exemplary UI (Send Payment to Seller UI) displaying payment information and asking the buyer to make the payment.
  • In one embodiment, the buyer may request an invoice total from a seller prior to confirming the combination of items or verifying the correctness of information to be sent to the seller. FIG. 24 illustrates an exemplary UI (Request Total from Seller UI) displaying the combined items and asking the buyer to verify his or her shipping address to allow the seller to calculate charges for this order.
  • In one embodiment, a buyer or a seller can request the payment status of an order. FIGS. 25A and 25B illustrate exemplary UIs (Buyer's Payment Status UI and Seller's Payment Status UI) displaying the order information and the payment status of the order for a buyer and seller respectively.
  • In one embodiment, a seller can review a list of buyers with combinable items purchased from the seller using a selling manager tool that assists the seller in operations within the marketplace. FIG. 26A illustrates an exemplary UI (Selling Manager Summary UI) including a link to a list of buyers with combinable items purchased from the seller. FIGS. 26B and 26C illustrate exemplary UIs (Selling Manager Sold Listings UIs) displaying orders containing multiple transactions.
  • In one embodiment, a seller and a buyer may leave feedback for the entire order. Alternatively, they may leave feedback for each transaction within the order individually. FIG. 27 illustrates an exemplary UI (Selling Manager Leave Feedback UI) allowing the seller to leave feedback for the entire order.
  • In one embodiment, a shipping label and an invoice slip are automatically created for an order and can be printed by a seller for the package containing the order. FIG. 28 illustrates an exemplary shipping label and invoice combination created for an order.
  • Charge Rules for Combined Transactions
  • A seller may specify charge rules for combined transactions that will be applied to all subsequent combined purchases from this seller. In one embodiment, a seller is allowed to specify discount rules for charges associated with combined transactions, thus encouraging buyers to buy more items from the seller.
  • FIGS. 29A-29B and 30A-30C are block diagrams of several embodiments of a process for defining rules for charges associated with combined transactions. The process may be performed by processing logic, which may comprise hardware, software, or a combination of both. In one embodiment, processing logic resides in a payment server (e.g., one of the application servers 28 of FIG. 1).
  • Referring to FIG. 29A, process 2900 begins with processing logic receiving data indicating a willingness of a first user to have combined transactions on invoices issued by the first user (processing block 2902). In one embodiment, this data is received via a user interface soliciting input from the first user with respect to invoices consolidating multiple transactions.
  • At processing block 2904, processing logic defines a set of rules for calculating charges for transactions combined on the invoices issued by the first user. In one embodiment, the set of rules pertain to shipping and handling rates and shipping insurance rates. In one embodiment, the set of rules is defined based on input provided by the first user via user interfaces presented by processing logic.
  • At processing block 2906, processing logic stores the set of rules associated with the first user in a database for subsequent use with invoices issued by the first user. In one embodiment, the set of rules defined based on user input provided via UIs associated with a marketplace site can only be used with items purchased via this marketplace site.
  • Referring to FIG. 29B, process 2900 will be described in conjunction with exemplary user interfaces illustrated in FIGS. 31A-31F.
  • Process 2950 begins with processing logic presenting a Login to Preferences UI to a seller (processing block 2952). FIG. 31A illustrates an exemplary Login to Preferences UI.
  • At processing block 2954, processing logic presents options for combining transactions to the seller. FIG. 31B illustrates an exemplary Combine Purchases Preference UI.
  • If processing logic receives data indicating that the seller does not allow combined transactions (processing block 2956), processing logic disables combine purchases UIs (processing block 2958) and the display of shipping discount messages on UIs presented to users of the marketplace (processing block 2960).
  • If processing logic receives data indicating that the seller allows combined transactions with manual shipping discounts (processing block 2962), processing logic enables combine purchases UIs and the display of messages encouraging multiple purchases from the seller, and solicits the seller's input of insurance rate options (processing block 2970). FIG. 31D illustrates an exemplary UI displaying the message “See More Great Buys from this seller” for a seller who selected an option of combined transactions with manual shipping discounts.
  • If processing logic receives data indicating that the seller allows combined transactions with automated shipping discounts (processing block 2962), processing logic enables combine purchases UIs, solicits the seller's input of shipping discount rules for combined purchases (processing block 2966), solicits the seller's input of the date range within which combined purchases are allowed (processing block 2968), and solicits the seller's input of insurance rate options (processing block 2970). Processing logic also enables the display of messages advertising shipping discounts for combined purchases from the seller. FIGS. 31C, 31E and 31F illustrate exemplary UIs displaying shipping discount messages that vary depending on discount rules specified by the seller.
  • Referring to FIG. 30A, process 3000 begins with processing logic detecting a seller preference for automated shipping discount rules for combined transactions (processing block 3002) and presenting the seller with shipping rate rule options (processing block 3004). In the described embodiment, the shipping rate rule options include a flat rate rule option and an actual rate rule option. However, other embodiments may use additional and/or different rule options without loss of generality.
  • If processing logic receives data indicating the seller's selection of the flat rate option (processing block 3008), processing logic presents flat rate shipping charge options (processing block 3010) and flat rate insurance options to the seller (processing block 3012), and receives and stores shipping and insurance preferences of the seller in the database (processing block 3020).
  • If processing logic receives data indicating the seller's selection of an actual rate option (processing block 3014), processing logic presents actual rate shipping charge options (processing block 3016) and insurance options to the seller (processing block 3018), and receives and stores shipping and insurance preferences of the seller in the database (processing block 3020).
  • Referring to FIG. 30B, process 3020 begins with processing logic detecting a seller's selection of a flat rate shipping discount (processing block 3022) and presenting a set of options for the flat rate shipping discount. Based on user input, processing logic may receive data identifying the seller's selection of an option to charge a maximum shipping rate for the first item and a fixed amount for each additional item (processing block 3024), data identifying the seller's selection of an option to charge a maximum shipping rate for the first item and no charge for additional items (processing block 3026), or data identifying the seller's selection of an option to charge a maximum shipping rate for the first item and deduct a fixed amount from the shipping cost of each additional item (processing block 3026).
  • Next, in one embodiment, processing logic may receive the seller's instruction to deduct a certain percentage from the shipping cost of each item in the order (processing block 3030). Alternatively, processing logic may receive the seller's instruction to refrain from applying a discount to an item with the highest shipping cost (processing block 3032).
  • Once processing logic defines shipping rate rules, it begins defining shipping insurance rules. Specifically, processing logic displays a set of options for a flat rate shipping insurance (processing block 3034). These options may include, for example, an insurance not offered option, an optional insurance option, a required insurance option, and an insurance included in shipping and handling option.
  • If processing logic receives data indicating the seller's selection of an optional insurance option or a required insurance option (processing block 3036), processing logic allows the seller to specify fixed insurance amounts for different price ranges (processing block 3038), and saves the shipping and insurance rules in the database (processing block 3040).
  • If processing logic receives data indicating the seller's selection of an insurance not offered option or an insurance included in shipping and handling option, processing logic proceeds directly to processing block 3040.
  • FIG. 32A illustrates an exemplary UI (Combine Purchases Preference UI) displaying options for flat rate shipping and insurance discounts.
  • Referring to FIG. 30C, process 3050 begins with processing logic detecting a seller's selection of an actual rate shipping discount (processing block 3052) and presenting a set of options for the actual rate shipping discount. Based on user input, processing logic may receive data identifying the seller's selection of an option to charge an actual shipping cost (based on the weight of the items in the order) and full package and handling fee (processing block 3054), data identifying the seller's selection of an option to charge an actual shipping cost and no package and handling fee (processing block 3056), data identifying the seller's selection of an option to charge an actual shipping cost and a fixed amount for package and handling fee for the entire order (processing block 3058), or data identifying the seller's selection of an option to charge, for each item, an actual shipping cost minus a fixed package and handling discount (processing block 3060).
  • Once processing logic defines shipping rate rules, it begins defining shipping insurance rules. Specifically, processing logic displays a set of options for an actual rate shipping insurance. These options may include, for example, an insurance not offered option, an optional insurance option, a required insurance option, and an insurance included in shipping and handling option. Processing logic then detects the seller's selection of an insurance option (processing block 3062), and saves the shipping and insurance rules in the database (processing block 3040).
  • FIG. 32B illustrates an exemplary UI (Combine Purchases Preference UI) displaying options for actual rate shipping discounts.
  • In one embodiment, the charge rules for combined purchases can be modified by a seller. FIG. 33A illustrates an exemplary UI (Combined Purchases Preferences Changes UI) confirming changes to the charge rules.
  • In one embodiment, the date of modification is saved, and the seller or his trading partner can request to review a history of rule modifications. In addition, once the rules are modified, a message may be displayed to the seller's trading partners, indicating such a modification. FIG. 33B illustrates an exemplary UI (Combined Purchases UI) displaying a shipping discount modification warning.
  • In one embodiment, a seller can modify charge rules or specify new charge rules for combined purchases when describing a new item to be offered within the network-based marketplace. FIG. 34 illustrates an exemplary UI (Sell Your Item UI) including a link to a Combined Purchases Preference UI where the charge rules can be specified.
  • FIGS. 35 and 37 are block diagrams of several embodiments of a process for calculating charges for invoices with combined transactions using predefined charge rules. The process may be performed by processing logic, which may comprise hardware, software, or a combination of both. In one embodiment, processing logic resides in a payment server (e.g., one of the application servers 28 of FIG. 1).
  • Referring to FIG. 35, process 3500 begins with processing logic facilitating a combination of transactions on a single invoice to be issued by a first party (processing block 3502). In one embodiment, the combination of transactions is facilitated via an order creation process described in more details above.
  • At processing block 3504, processing logic identifies a rule, specified by the first user, for an automated calculation of charges in connection with invoices issued by the first party. The charges may include shipping charges, package and handling charges, insurance charges, etc. In one embodiment, the rule is identified by retrieving the rule associated with the first party from the database.
  • At processing block 3506, processing logic determines that the transactions being combined satisfy rule application criteria. The rule application criteria may require, for example, that each transaction have shipping details specified, all transactions have the same type of shipping cost (e.g., flat rate or actual rate), all transactions with the same type of shipping cost share the same shipping method, etc.
  • At processing block 3508, processing logic dynamically invokes the rule to calculate charges for the transactions included in the order, and displays the calculated charges with the order. In one embodiment, processing logic also computes a difference between the charges calculated using a discount provided by the charge rule and charges calculated without a discount, and displays the difference to the buyer. FIG. 36 illustrates an exemplary UI (Combine Purchases UI) that specifies how much the buyer can save on shipping by combining transactions into a single order.
  • Referring to FIGS. 37A-37C, process 3700 begins with processing logic receiving a call to calculate shipping costs for multi-transaction order (processing block 3702), determining whether each transaction meets rule application criteria (processing block 3704), and, if so, retrieving charge rules applicable to the multi-transaction order. The rule application criteria may require, for example, that each transaction have shipping details specified, all transactions have the same type of shipping cost (e.g., flat rate or actual rate), all transactions with the actual shipping rate share the same shipping method if using a combined weight measure, etc.
  • Next, processing logic determines whether the charge rules are based on actual rate (processing block 3706). If so, processing logic determines whether the rules are based on combined weight or individual weight (processing block 3708). If the rules are based on combined weight, processing logic determines whether the combined weight exceeds carrier limit (processing block 3712). If not, processing logic proceeds to processing block 3714.
  • If the combined weight exceeds the carrier limit, or the rules are based on individual weight, processing logic calculates actual shipping rate based on weight of individual items (processing block 3714) and proceeds to processing block 3714.
  • At processing block 3714, processing logic determines the seller's handling fee preferences. If the rules specify full packaging and handling fee (processing block 3716) and the rules are based on combined weight (processing block 3718), processing logic calculates combined shipping costs by adding the actual rate based on total weight to the sum of handling fees of all items (processing block 3720).
  • If the rules specify full packaging and handling fee (processing block 3716) and the rules are based on individual weight (processing block 3718), processing logic calculates combined shipping costs by adding the sum of actual rates based on individual shipping rate per item to the sum of handling fees of all items (processing block 3722).
  • If the rules specify actual shipping cost only (processing block 3724), processing logic does not add any handling fee to the combined shipping cost (processing block 3726).
  • If the rules specify fixed packaging and handling fee (processing block 3728) and the rules are based on combined weight (processing block 3730), processing logic calculates combined shipping costs by adding the actual shipping rate based on total weight to the seller-specified handling fee (processing block 3732).
  • If the rules specify fixed packaging and handling fee (processing block 3728) and the rules are based on individual weight (processing block 3730), processing logic calculates combined shipping costs by adding the sum of actual rates based on individual rate per item to the seller-specified handling fee (processing block 3734).
  • If the rules require that a fixed amount be deducted from a handling fee of each item (processing block 3736) and the rules are based on combined weight (processing block 3738), processing logic calculates combined shipping costs by computing, for each item, a difference between the handling fee of this item and the fixed amount, calculating the sum of all positive differences (differences that are equal to, or greater than, zero) and adding the calculated sum to the actual rate based on total weight (processing block 3740).
  • If the rules require that a fixed amount be deducted from a handling fee of each item (processing block 3736) and the rules are based on individual weight (processing block 3738), processing logic calculates combined shipping costs by computing, for each item, a difference between the handling fee of this item and the fixed amount, calculating the sum of all positive differences, and adding the calculated sum to the sum of actual shipping rate based on individual weight per item (processing block 3740).
  • If the charge rules are based on flat rate (processing block 3706), processing logic determines user-specified flat rate preference (processing block 3748). If the flat rate preference requires that the shipping cost be based on the highest single item charge plus a fixed amount for each additional item (processing block 3750), processing logic calculates the combined shipping cost by adding the highest single item charge and a fixed amount for each additional item (processing block 3752).
  • If the flat rate preference requires that the shipping cost be based on the highest single item charge plus a difference between the shipping cost and a fixed amount for each additional item (processing block 3754), processing logic calculates the combined shipping cost by computing differences between the shipping cost of each item and the fixed amount, calculating the sum of all positive differences, and adding the sum of positive differences to the highest single item shipping cost (processing block 3756).
  • If the flat rate preference requires free shipping for each additional item (processing block 3758), the combined shipping cost is equal to the highest single item shipping charge (processing block 3760).
  • If the flat rate preference requires that the shipping cost be based on item charge for each item minus a fixed percentage (processing block 3762), processing logic calculates the combined shipping cost by computing differences between the shipping cost of each item and the fixed percentage and calculating the sum of all positive differences (processing block 3764).
  • Exemplary Computer System
  • FIG. 38 shows a diagrammatic representation of machine in the exemplary form of a computer system 3800 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • The exemplary computer system 3800 includes a processor 3802 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 3804 and a static memory 3806, which communicate with each other via a bus 3808. The computer system 3800 may further include a video display unit 3810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 3800 also includes an alphanumeric input device 3812 (e.g., a keyboard), a cursor control device 3814 (e.g., a mouse), a disk drive unit 3816, a signal generation device 3818 (e.g., a speaker) and a network interface device 3820.
  • The disk drive unit 3816 includes a machine-readable medium 3822 on which is stored one or more sets of instructions (e.g., software 3824) embodying any one or more of the methodologies or functions described herein. The software 3824 may also reside, completely or at least partially, within the main memory 3804 and/or within the processor 3802 during execution thereof by the computer system 3800, the main memory 3804 and the processor 3802 also constituting machine-readable media.
  • The software 3824 may further be transmitted or received over a network 3826 via the network interface device 3820.
  • While the machine-readable medium 3892 is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
  • Thus, methods and systems to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace 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.

Claims (37)

1. A computerized method to facilitate invoicing for transactions established using a network-based transaction system, the method including:
supporting, by a server machine, establishment of transactions between a plurality of entities in the network-based transaction system;
identifying, with the server machine, as part of an invoice generation process, a plurality of transactions to which a first entity is a party;
identifying, with the server machine, first and second transactions from the plurality of transactions that satisfy combinable criteria; and
generating, with the server machine, an invoice for at least the first and second transactions that satisfy the combinable criteria.
2. The computerized method of claim 1, wherein the first entity is a seller, and the identification of the plurality of transactions is performed responsive to an initiation of the invoice generation process by a second entity.
3. The computerized method of claim 1, wherein the first entity is a buyer, and the identification of the plurality of transactions is performed as part of a payment process.
4. The computerized method of claim 3, wherein:
the identification of the plurality of transactions is performed responsive to the buyer initiating the payment process in connection with the first transaction; and
the method includes identifying a third transaction involving the buyer that is combinable with one or more of the first transaction and the second transaction based on the combinable criteria.
5. The computerized method of claim 1, wherein the identification of the first and second transactions includes determining that a seller agreed to combinability of transactions involving the seller.
6. The computerized method of claim 5, wherein the determining includes retrieving seller-defined preferences with respect to the combinability of transactions involving the seller.
7. The computerized method of claim 1, wherein the identification of the first and second transactions includes identifying each of the first and second transactions as being between a common buyer and a common seller.
8. The computerized method of claim 1, wherein the identification of the first and second transactions includes identifying each of the first and second transactions as having been established in terms of a common currency.
9. The computerized method of claim 1, wherein the supporting of the establishment of the first and second transactions between the plurality of entities is performed at a plurality of network-based transaction systems.
10. The computerized method of claim 9, wherein the plurality of network-based transaction systems includes a plurality of geographically customized network-based transaction systems.
11. The computerized method of claim 1, wherein the identification of the first and second transactions to which the first entity is a party includes identifying the first and second transactions as having been concluded within a predetermined time period.
12. The computerized method of claim 1, further comprising:
presenting the first and second transactions to the first entity as being combinable; and
prompting the first entity for confirmation regarding an inclusion of the first and second transactions in the invoice.
13. The computerized method of claim 1, wherein the identification of the first and second transactions comprises:
presenting to the first entity a list of unpaid transactions selected from the first and second transactions; and
receiving data identifying a selection by the first entity of one or more transactions from the list for the invoice.
14. The computerized method of claim 13, wherein the list of unpaid transactions comprises one or more subsets of combinable transactions, each of the one or more subsets being associated with the first entity and a buyer.
15. The computerized method of claim 14, wherein the invoice includes one or more subsets of combinable transactions and one or more independent transactions.
16. The computerized method of claim 1, wherein the network-based transaction system comprises a network-based marketplace.
17. The computerized method of claim 1, wherein the identifying the first and second transactions comprises displaying on a client machine the first and second transactions with an indicator of combinability.
18. The computerized method of claim 17, wherein the indicator of combinability is an icon.
19. The computerized method of claim 1, wherein the identifying the first and second transactions comprises providing, by the server machine, a filter for combinable transactions; and displaying on a client machine the first and second transactions in response to a selection of the filter for combinable transactions by the first entity.
20. The computerized method of claim 1, comprising providing a discount to the first entity when the first entity agrees to combine transactions that satisfy combinable criteria.
21. The computerized method of claim 1, comprising providing to the first entity an indication of savings resulting from combining the transactions.
22. A system to facilitate invoicing for transactions established using a network-based transaction system, the system including:
a server to support establishment of transactions between a plurality of entities; and
a server to identify, as part of an invoice generation process, a plurality of transactions to which a first entity is a party, to identify first and second transactions from the plurality of transactions that satisfy combinable criteria, and to generate an invoice for at least one of the first and second transactions that satisfy the combinable criteria.
23. The system of claim 22, wherein the identification of the first and second transactions includes determining whether a seller agreed to combinability of transactions involving the seller.
24. The system of claim 22, wherein the identification of the first and second transactions includes identifying each of the first and second transactions as being between a common buyer and a common seller.
25. The system of claim 22, comprising:
a server to present the first and second transactions to the first entity as being combinable; and
a server to prompt the first entity for confirmation regarding an inclusion of the first and second transactions in the invoice.
26. The system of claim 22, wherein the network-based transaction system comprises a network-based marketplace.
27. The system of claim 22, wherein the identification of the first and second transactions comprises providing, by a server, a filter for combinable transactions; and displaying on a client machine the first and second transactions in response to a selection of the filter for combinable transactions by the first entity.
28. The system of claim 22, comprising a server to provide a discount to the first entity when the first entity agrees to combine transactions that satisfy combinable criteria.
29. The system of claim 22, comprising a server to provide to the first entity an indication of savings resulting from combining the transactions.
30. A tangible machine-readable storage medium storing a set of instructions that, when executed by a machine, cause the machine to perform a method to facilitate invoicing for transactions established utilizing a network-based transaction system, the method including:
supporting establishment of transactions between a plurality of entities in the network-based transaction system;
identifying, as part of an invoice generation process, a plurality of transactions to which a first entity is a party;
identifying first and second transactions that satisfy combinable criteria; and
generating an invoice for at least the first and second transactions that satisfy the combinable criteria.
31. The machine-readable medium of claim 30, wherein the identification of the first and second transactions includes determining whether a seller agreed to combinability of transactions involving the seller.
32. The machine-readable medium of claim 30, wherein the identification of the first and second transactions includes identifying each of the first and second transactions as being between a common buyer and a common seller.
33. The machine readable medium of claim 30, comprising instructions for:
presenting the first and second transactions to the first entity as being combinable; and
prompting the first entity for confirmation regarding an inclusion of the first and second transactions in the invoice.
34. The machine readable medium of claim 30, wherein the network-based transaction system comprises a network-based marketplace.
35. The machine readable medium of claim 30, wherein the identifying the first and second transactions comprises providing, by the server machine, a filter for combinable transactions; and displaying on a client machine the first and second transactions in response to a selection of the filter for combinable transactions by the first entity.
36. The machine readable medium of claim 30, comprising instructions for providing a discount to the first entity when the first entity agrees to combine transactions that satisfy combinable criteria.
37. The machine readable medium of claim 30, comprising instructions for providing to the first entity an indication of savings resulting from combining the transactions.
US12/820,046 2003-08-14 2010-06-21 Invoicing system Abandoned US20100257045A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US49560803P true 2003-08-14 2003-08-14
US50125103P true 2003-09-08 2003-09-08
US10/882,633 US7742947B2 (en) 2003-08-14 2004-06-30 Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace
US12/820,046 US20100257045A1 (en) 2003-08-14 2010-06-21 Invoicing system

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/820,046 US20100257045A1 (en) 2003-08-14 2010-06-21 Invoicing system
US14/821,679 US10127531B2 (en) 2003-08-14 2015-08-07 Invoicing system
US16/168,490 US20190172031A1 (en) 2003-08-14 2018-10-23 Invoicing system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/882,633 Division US7742947B2 (en) 2003-08-14 2004-06-30 Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/821,679 Continuation US10127531B2 (en) 2003-08-14 2015-08-07 Invoicing system

Publications (1)

Publication Number Publication Date
US20100257045A1 true US20100257045A1 (en) 2010-10-07

Family

ID=34312263

Family Applications (5)

Application Number Title Priority Date Filing Date
US12/820,046 Abandoned US20100257045A1 (en) 2003-08-14 2010-06-21 Invoicing system
US12/820,066 Abandoned US20100257046A1 (en) 2003-08-14 2010-06-21 Invoicing system
US12/819,972 Active 2025-06-07 US8768798B2 (en) 2003-08-14 2010-06-21 Invoicing system
US14/821,679 Active 2026-01-30 US10127531B2 (en) 2003-08-14 2015-08-07 Invoicing system
US16/168,490 Pending US20190172031A1 (en) 2003-08-14 2018-10-23 Invoicing system

Family Applications After (4)

Application Number Title Priority Date Filing Date
US12/820,066 Abandoned US20100257046A1 (en) 2003-08-14 2010-06-21 Invoicing system
US12/819,972 Active 2025-06-07 US8768798B2 (en) 2003-08-14 2010-06-21 Invoicing system
US14/821,679 Active 2026-01-30 US10127531B2 (en) 2003-08-14 2015-08-07 Invoicing system
US16/168,490 Pending US20190172031A1 (en) 2003-08-14 2018-10-23 Invoicing system

Country Status (2)

Country Link
US (5) US20100257045A1 (en)
WO (1) WO2005026905A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100257046A1 (en) * 2003-08-14 2010-10-07 Ebay, Inc. Invoicing system

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080015982A1 (en) * 2000-09-20 2008-01-17 Jeremy Sokolic Funds transfer method and system including payment enabled invoices
US7146338B2 (en) 2001-06-28 2006-12-05 Checkfree Services Corporation Inter-network financial service
US7827103B1 (en) 2003-08-14 2010-11-02 Ebay Inc. Method and apparatus to maintain rules for charges associated with combined transactions established utilizing a multi-seller network-based marketplace
US20080288400A1 (en) 2007-04-27 2008-11-20 Cashedge, Inc. Centralized Payment Method and System for Online and Offline Transactions
US20100257020A1 (en) * 2009-04-02 2010-10-07 Microsoft Corporation User-targeted rebates

Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5070463A (en) * 1990-11-05 1991-12-03 Pitney Bowes Inc. Parcel processing system with end of day rating
US5778178A (en) * 1995-11-13 1998-07-07 Arunachalam; Lakshmi Method and apparatus for enabling real-time bi-directional transactions on a network
US5803500A (en) * 1997-03-27 1998-09-08 Mossberg; Bjoern E. F. Method and kit for conducting an auction
US5987429A (en) * 1997-12-16 1999-11-16 Sun Microsystems, Inc. Computer-based fee processing for electronic commerce
US6169791B1 (en) * 1997-07-25 2001-01-02 Mediacom Corporation System and method for least cost call routing
US6212556B1 (en) * 1995-11-13 2001-04-03 Webxchange, Inc. Configurable value-added network (VAN) switching
US20010027471A1 (en) * 2000-01-18 2001-10-04 Amy Paulose Order aggregation system for international shipments
US20010051878A1 (en) * 2000-06-02 2001-12-13 Bexcom Pte. Ltd. Global hub-to-hub exchange
US20020038266A1 (en) * 2000-07-07 2002-03-28 Tuttrup Robert W. Method and apparatus for effective distribution and delivery of goods ordered on the World-Wide -Web
US20020046191A1 (en) * 2000-10-14 2002-04-18 Joao Raymond Anthony Apparatus and method for providing transaction cost information
US20020077977A1 (en) * 2000-12-19 2002-06-20 Neely R. Alan Interactive invoicer interface
US20020095306A1 (en) * 2000-09-29 2002-07-18 Smith Joshua R. Personal mail piece tracing and tracking mechanism
US20020111876A1 (en) * 2001-02-09 2002-08-15 Rudraraju Panduranga R. Transaction aggregation system and method
US20020133434A1 (en) * 2001-03-19 2002-09-19 Nevel Keith Gerald System and method for controlling the delivery of items from a seller to a buyer
US20020198747A1 (en) * 2001-06-26 2002-12-26 Boyer Stanley Gene Event driven airport
US6615226B1 (en) * 1995-03-30 2003-09-02 Amazon.Com, Inc. Method and system for displaying and editing of information
US20030171998A1 (en) * 2002-03-11 2003-09-11 Omnicell, Inc. Methods and systems for consolidating purchase orders
US20030182222A1 (en) * 2002-03-25 2003-09-25 Sales Online Direct, Inc. Method and system for improved online auction
US20040039689A1 (en) * 2002-06-19 2004-02-26 Neill Penney Method and apparatus for managing financial transactions involving multiple counterparties and processing data pertaining thereto
US20040059673A1 (en) * 1998-03-03 2004-03-25 Bill Kitchen Dual mode electronic bill availability noticing and payment
US20050177448A1 (en) * 2003-08-14 2005-08-11 Paul Fu Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace
US20050210022A1 (en) * 1998-03-09 2005-09-22 Yan Philippe Method and system for integrating transaction mechanisms over multiple internet sites
US20070265962A1 (en) * 2001-09-28 2007-11-15 Siebel Systems, Inc. Method and system for automatically generating invoices for contracts
US7587362B2 (en) * 2001-10-12 2009-09-08 Royal Bank Of Scotland Plc Data processing system for managing and processing foreign exchange transactions
US7805365B1 (en) * 1999-10-25 2010-09-28 Jpmorgan Chase Bank, N.A. Automated statement presentation, adjustment and payment system and method therefor
US20100257046A1 (en) * 2003-08-14 2010-10-07 Ebay, Inc. Invoicing system
US20100280891A1 (en) * 2000-06-21 2010-11-04 Clubcom, Llc System and method for branding a facility
US20100280902A1 (en) * 2007-12-07 2010-11-04 Wei Pang System and method for creating social services based on buying experience

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5182715A (en) * 1989-10-27 1993-01-26 3D Systems, Inc. Rapid and accurate production of stereolighographic parts
US5960411A (en) * 1997-09-12 1999-09-28 Amazon.Com, Inc. Method and system for placing a purchase order via a communications network
US7222087B1 (en) * 1997-09-12 2007-05-22 Amazon.Com, Inc. Method and system for placing a purchase order via a communications network
AU4481600A (en) * 1999-04-22 2000-11-10 Qode.Com, Inc. System and method for providing electronic information upon receipt of a scannedbar code
US7197475B1 (en) * 1999-06-30 2007-03-27 Catalog City, Inc. Multi-vendor internet commerce system for e-commerce applications and methods therefor
US7720712B1 (en) * 1999-12-23 2010-05-18 Amazon.Com, Inc. Placing a purchase order using one of multiple procurement options
US7287003B2 (en) * 2000-06-02 2007-10-23 Iprint.Com Integrated electronic shopping cart system and method
AU1474802A (en) * 2000-06-12 2001-12-24 Infospace Inc Universal shopping cart and order injection system
KR20020004606A (en) 2000-07-06 2002-01-16 김성군 integrating system of shopping mole
AU7832001A (en) * 2000-07-27 2002-02-13 Borderfree Ltd Universal shopping basket
US7188081B1 (en) * 2000-10-30 2007-03-06 Microsoft Corporation Electronic shopping basket
US7363248B2 (en) * 2000-12-22 2008-04-22 Invenda Corporation Pre-filling order forms for transactions over a communications network
US20020133414A1 (en) * 2001-03-14 2002-09-19 Pradhan Salil Vjaykumar Mediated shopping method and system
US7120595B2 (en) * 2001-05-23 2006-10-10 International Business Machines Corporation Method and system for providing online comparison shopping
US20020198787A1 (en) * 2001-06-20 2002-12-26 Techno Mecca, Inc. Company and college online book ordering system, also known as cobos
US7035816B2 (en) * 2001-07-30 2006-04-25 Elie Jankelewitz System and method for reduced cost purchasing
US7827103B1 (en) 2003-08-14 2010-11-02 Ebay Inc. Method and apparatus to maintain rules for charges associated with combined transactions established utilizing a multi-seller network-based marketplace

Patent Citations (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5070463A (en) * 1990-11-05 1991-12-03 Pitney Bowes Inc. Parcel processing system with end of day rating
US20040083167A1 (en) * 1991-07-25 2004-04-29 Kight Peter J. Flexible integrated electronic bill presentment and payment
US6615226B1 (en) * 1995-03-30 2003-09-02 Amazon.Com, Inc. Method and system for displaying and editing of information
US5778178A (en) * 1995-11-13 1998-07-07 Arunachalam; Lakshmi Method and apparatus for enabling real-time bi-directional transactions on a network
US6212556B1 (en) * 1995-11-13 2001-04-03 Webxchange, Inc. Configurable value-added network (VAN) switching
US5987500A (en) * 1995-11-13 1999-11-16 Pi-Net International, Inc. Value-added network system for enabling real-time, by-directional transactions on a network
US5803500A (en) * 1997-03-27 1998-09-08 Mossberg; Bjoern E. F. Method and kit for conducting an auction
US6169791B1 (en) * 1997-07-25 2001-01-02 Mediacom Corporation System and method for least cost call routing
US5987429A (en) * 1997-12-16 1999-11-16 Sun Microsystems, Inc. Computer-based fee processing for electronic commerce
US20040059673A1 (en) * 1998-03-03 2004-03-25 Bill Kitchen Dual mode electronic bill availability noticing and payment
US20050210022A1 (en) * 1998-03-09 2005-09-22 Yan Philippe Method and system for integrating transaction mechanisms over multiple internet sites
US7805365B1 (en) * 1999-10-25 2010-09-28 Jpmorgan Chase Bank, N.A. Automated statement presentation, adjustment and payment system and method therefor
US20010027471A1 (en) * 2000-01-18 2001-10-04 Amy Paulose Order aggregation system for international shipments
US20010051878A1 (en) * 2000-06-02 2001-12-13 Bexcom Pte. Ltd. Global hub-to-hub exchange
US20100280891A1 (en) * 2000-06-21 2010-11-04 Clubcom, Llc System and method for branding a facility
US20020038266A1 (en) * 2000-07-07 2002-03-28 Tuttrup Robert W. Method and apparatus for effective distribution and delivery of goods ordered on the World-Wide -Web
US20020095306A1 (en) * 2000-09-29 2002-07-18 Smith Joshua R. Personal mail piece tracing and tracking mechanism
US20020046191A1 (en) * 2000-10-14 2002-04-18 Joao Raymond Anthony Apparatus and method for providing transaction cost information
US20020077977A1 (en) * 2000-12-19 2002-06-20 Neely R. Alan Interactive invoicer interface
US7702579B2 (en) * 2000-12-19 2010-04-20 Emergis Technologies, Inc. Interactive invoicer interface
US20020111876A1 (en) * 2001-02-09 2002-08-15 Rudraraju Panduranga R. Transaction aggregation system and method
US20020133434A1 (en) * 2001-03-19 2002-09-19 Nevel Keith Gerald System and method for controlling the delivery of items from a seller to a buyer
US20020198747A1 (en) * 2001-06-26 2002-12-26 Boyer Stanley Gene Event driven airport
US20070265962A1 (en) * 2001-09-28 2007-11-15 Siebel Systems, Inc. Method and system for automatically generating invoices for contracts
US7587362B2 (en) * 2001-10-12 2009-09-08 Royal Bank Of Scotland Plc Data processing system for managing and processing foreign exchange transactions
US20030171998A1 (en) * 2002-03-11 2003-09-11 Omnicell, Inc. Methods and systems for consolidating purchase orders
US7324968B2 (en) * 2002-03-25 2008-01-29 Paid, Inc. Method and system for improved online auction
US20030182222A1 (en) * 2002-03-25 2003-09-25 Sales Online Direct, Inc. Method and system for improved online auction
US20040039689A1 (en) * 2002-06-19 2004-02-26 Neill Penney Method and apparatus for managing financial transactions involving multiple counterparties and processing data pertaining thereto
US7742947B2 (en) * 2003-08-14 2010-06-22 Ebay Inc. Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace
US20050177448A1 (en) * 2003-08-14 2005-08-11 Paul Fu Method and apparatus to facilitate generation of invoices combining multiple transactions established utilizing a multi-seller network-based marketplace
US20100257046A1 (en) * 2003-08-14 2010-10-07 Ebay, Inc. Invoicing system
US20100280902A1 (en) * 2007-12-07 2010-11-04 Wei Pang System and method for creating social services based on buying experience

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
Auctioninc 1, http://web.archive.org/web/20030809092025/http://auctioninc.com/ *
Auctioninc 2, "Sales OnLine Direct's aiSeller(TM) Increases eBay Online Auction Sellers' Productivity by 50%+", PR Newswire. New York: Jun 24, 2003. pg. 1 *
Auctioninc 3, "Sales OnLine Direct Launches Advanced Checkout System for Auctions on eBay", PR Newswire. New York: Aug 22, 2002. pg. 1 *
Auctioninc 4, "Sales Online Direct Introduces The First Integrated Real-Time Auction and E-Commerce Multi-Carrier Shipping Calculator, Reduces Online Shopping Cart Abandonment"' , PR Newswire. New York: Mar 26, 2002. pg. 1 *
Auctioninc 5, http://web.archive.org/web/20030802025432/http://www.auctioninc.com/info/page/aiseller_tour_checkout_1 *
Auctioninc 6 http://web.archive.org/web/20030802025548/http://www.auctioninc.com/info/page/aiseller_tour_managesales_1 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100257046A1 (en) * 2003-08-14 2010-10-07 Ebay, Inc. Invoicing system
US20100280894A1 (en) * 2003-08-14 2010-11-04 Ebay Inc. Invoicing system
US8768798B2 (en) 2003-08-14 2014-07-01 Ebay Inc. Invoicing system
US10127531B2 (en) 2003-08-14 2018-11-13 Ebay Inc. Invoicing system

Also Published As

Publication number Publication date
WO2005026905A2 (en) 2005-03-24
WO2005026905A3 (en) 2005-08-25
US20160055463A1 (en) 2016-02-25
US10127531B2 (en) 2018-11-13
US20100257046A1 (en) 2010-10-07
US20100280894A1 (en) 2010-11-04
US20190172031A1 (en) 2019-06-06
US8768798B2 (en) 2014-07-01

Similar Documents

Publication Publication Date Title
US7774350B2 (en) System and method to provide and display enhanced feedback in an online transaction processing environment
US8799114B2 (en) Method and system automatically to support multiple transaction types, and to display seller-specific transactions of various transaction types in an integrated, commingled listing
US7779421B2 (en) Business event processing
US8001010B2 (en) Sharing information on a network-based social platform
US9892471B2 (en) Viewing shopping information on a network based social platform
US20150331591A1 (en) Methods and systems to process a selection of a browser back button
US7904346B2 (en) Method and system to adjust a seller fixed price offer
US7962374B2 (en) System and method for selling a product multiple times during the life of the product
US6944599B1 (en) Monitoring and automatic notification of irregular activity in a network-based transaction facility
US20060271460A1 (en) Method and system to provide user created social networks in a distributed commerce system
US8751326B2 (en) Introducing a fixed-price transaction mechanism in conjunction with an auction transaction mechanism
US7890375B2 (en) Method and system to facilitate pre-ordering via an electronic commerce facility, and to automatically facilitate satisfying of a pre-order upon listing of an appropriate offer via the electronic commerce facility
US8005719B2 (en) Method and system to publish a seller fixed price offer
US8364556B2 (en) Method and system to automate payment for a commerce transaction
US8762244B2 (en) Method and apparatus for deploying high-volume listings in a network trading platform
AU2006230277B2 (en) Making a payment via financial service provider
US8473360B2 (en) Suggested item category systems and methods
US7734544B2 (en) Authorization and capture with multiple currencies
US20060085253A1 (en) Method and system to utilize a user network within a network-based commerce platform
US8706567B2 (en) System to generate an aggregate interest indication with respect to an information item
US20080162295A1 (en) Method and system for payment authentication
US20100250337A1 (en) Application recommendation engine
US8015070B2 (en) Method, system and storage medium for providing a custom combination best offer from a qualified buyer
US9280786B2 (en) Product-based advertising
US8001007B2 (en) Method, and system to publish a proxy bid and a reserve price

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: EBAY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FU, PAUL;HANSEN, ERIK BECK;LIANG, GEORGE;AND OTHERS;SIGNING DATES FROM 20040629 TO 20041024;REEL/FRAME:045024/0727