BILATERAL BIDDING PLATFORM FOR USE IN BULK SALE OF ITEMS IN AN ELECTRONIC MARKETPLACE

Abstract

Utilities (e.g., systems, methods, etc.) for facilitating a bilateral bidding process between buyers and sellers of items (services, products, bundles, etc.) to allow buyers to obtain lower prices on the items through crowd bidding while simultaneously allowing sellers to essentially offset such lower prices on the items through increased sales volume of the items. Specifically, the disclosed utilities may make use of a network-based ecommerce system or platform that provides sellers of items access to real-time buyer demand and the optimum price that a plurality of buyers (e.g., customers) are willing to pay that yields increased profits. The disclosed platform also benefits buyers in cases when multiple sellers compete for the then current plurality of buyer demand resulting in a reduced price for the item based on the then real-time demand.

Claims

1-15. (canceled)

16. A method comprising: receiving, into a staging register of a computerized bidding system, a plurality of bid objects for a product and/or service from a plurality of potential buyers, wherein each of the plurality of bid objects includes a price object defining an upper limit of a price at which a buyer of the plurality of potential buyers is willing to pay for the product and/or service; organizing, by a bidding engine of the computerized bidding system, the plurality of bid objects in the staging register, wherein after the organizing the plurality of bid objects in the staging register comprise organized bid objects; moving, by the bidding engine at the beginning of a bid session, the organized bid objects into an active register of the computerized bidding system; receiving, by the bidding engine during the bid session, an indication of a particular bid object of the organized bid objects from a potential seller of the product and/or service; and generating, by the bidding engine at a conclusion of the bid session, an indication of a bid block.

17. The method of claim 16, wherein the organizing comprises organizing the plurality of bid objects in the staging register starting with a first bid object having a price object defining a highest price and continuing to at least a second bid object having a price object defining a lowest price.

18. The method of claim 16, wherein the bid block includes the particular bid object and at least one other bid object of the organized bid objects having a price object defining a price greater than or equal to a price defined by the price object of the particular bid object.

19. The method of claim 16 further comprising removing, from the active register by the bidding engine at the end of the bid session, any organized bid objects of the bid block having a price object defining a price less than a price defined by the particular bid object, wherein after the removing the organized bid objects remaining in the active register comprise remaining bid objects.

20. The method of claim 19 further comprising receiving, by the bidding engine during a subsequent bid session, an indication of another particular bid object of the remaining bid objects.

21. The method of claim 19 further comprising generating, by the bidding engine, an indication of a subsequent bid block.

22. The method of claim 21, wherein the subsequent bid block includes the another particular bid object and at least one other bid object of the remaining bid objects having a price object defining a price greater than or equal to a price defined by the price object of the another particular bid object.

23. The method of claim 19, wherein the bid session occurs for a first predetermined period of time, wherein the subsequent bid session occurs for a second predetermined period of time, and wherein the first and second predetermined periods of time are non-overlapping.

24. The method of claim 19, wherein receiving the plurality of bid objects into the staging register comprises receiving the plurality of bid objects into a bidding pool of the computerized bidding system.

25. The method of claim 24, wherein each bid object of the plurality of bid objects further includes a bid duration object defining a period of time that the bid object is valid in the bidding pool.

26. The method of claim 25 further comprising identifying any bid objects in the active register at the end of the bid session having expired bid duration objects and that are not in the bid block.

27. The method of claim 26, wherein the removing comprises removing the identified bid blocks having expired bid duration objects.

28. The method of claim 19 further comprising receiving, into the staging register during the bid session of the active register, a plurality of additional bid objects for the product and/or service.

29. The method of claim 28 further comprising moving, by the bidding engine at the beginning of the subsequent bid session, the additional bid objects into the active register.

30. The method of claim 16, wherein the receiving includes receiving, by the bidding engine during the bid session, a plurality of indications of a respective plurality of different ones of the bid objects in the active register from a respective plurality of potential sellers of the product and/or service.

31. The method of claim 16 further comprising disallowing receipt of bid objects from the staging register into the active register during the bid session.

32. One or more non-transitory computer readable media having program instructions stored thereon which, when executed by at least one processor, cause a machine to: cause a plurality of bid objects for a product and/or service from a plurality of potential buyers to be received into a staging register of a computerized bidding system, wherein each of the plurality of bid objects includes a price object defining an upper limit of a price at which a buyer of the plurality of potential buyers is willing to pay for the product and/or service; direct a bidding engine of the computerized bidding system to organize the plurality of bid objects in the staging register, wherein after the organizing the plurality of bid objects in the staging register comprise organized bid objects; direct, at the beginning of a bid session, the bidding engine to move the organized bid objects into an active register of the computerized bidding system; cause, during the bid session, an indication of a particular bid object of the organized bid objects to be received by the bidding engine from a potential seller of the product and/or service; and direct the bidding engine to generate an indication of a bid block at the conclusion of the bid session.

33. The one or more non-transitory computer readable media of claim 32, wherein when executed by the at least one processor, the program instructions further cause the machine to direct, at the end of the bid session, the bidding engine to remove from the active register any organized bid objects of the bid block having a price object defining a price less than a price defined by the particular bid object, wherein after being removed from the active register the organized bid objects remaining in the active register comprise remaining bid objects.

34. A computerized bidding system comprising: at least one web server configured to communicate via a network with: a plurality of buyer devices, and at least one seller device; one or more memory storage devices including: a staging register, and an active register; and at least one processor communicatively coupled to: the at least one web server, and the one or more memory storage devices, the at least one processor configured to: cause a plurality of bid objects for a product and/or service to be received, via the at least one web server, into the staging register from a plurality of potential buyers, wherein each of the plurality of bid objects includes a price object defining an upper limit of a price at which a buyer of the plurality of potential buyers is willing to pay for the product and/or service; direct a bidding engine of the computerized bidding system to organize the plurality of bid objects in the staging register, wherein after the organizing the plurality of bid objects in the staging register comprise organized bid objects; direct, at the beginning of a bid session, the bidding engine to move the organized bid objects into the active register; cause, during the bid session, an indication of a particular bid object of the organized bid objects to be received, via the at least one web server, by the bidding engine from a potential seller of the product and/or service; and direct the bidding engine to generate an indication of a bid block at the conclusion of the bid session.

35. The computerized bidding system of claim 34, wherein the at least one processor is further configured to remove, from the active register and at the end of the bid session, any organized bid objects of the bid block having a price object defining a price less than a price defined by the particular bid object from the , wherein after being removed from the active register the organized bid objects remaining in the active register comprise remaining bid objects.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] FIG. 1 is a system diagram of an ecommerce marketplace platform that facilitates bilateral bidding of bulk items between sellers and buyers.

[0031] FIG. 2 is a schematic diagram illustrating a bidding session between sellers and buyers on the disclosed platform.

[0032] FIG. 3 illustrates how a plurality of merchant sellers may create a plurality of bid blocks from bid objects in a bidding pool for an item on the platform

[0033] FIG. 4 is a schematic diagram of a bid object as created by a bidding engine of the platform in response to a bid submitted to the platform by a buyer.

[0034] FIG. 5 is another schematic diagram illustrating active and staging registers of a bidding pool for an item in the platform.

[0035] FIG. 6 is a flow diagram of a method that may be employed by the disclosed platform for facilitating a bilateral bidding process between buyers and sellers during a bidding session for bulk items.

[0036] FIG. 7 is a flow diagram of a method of provisioning an active register of a bidding pool for use in a subsequent bidding session.

[0037] FIG. 8 is a flow diagram of a method that may be engaged in by a buyer of a bulk item on the disclosed platform.

[0038] FIG. 9 is a flow diagram of a method that may be engaged in by a seller of bulk items on the disclosed platform.

[0039] FIG. 10 is a table illustrating a plurality of bid session use cases on the disclosed platform.

[0040] FIG. 11 illustrates a plurality of exemplary buyer bids submitted to the disclosed platform as well as a seller bid block that includes a subset of the buyer bids.

[0041] FIG. 12 illustrates a buyer web/native app client that may be used by a buyer to submit bids for an item on the disclosed platform, according to an embodiment.

[0042] FIG. 13 is a screenshot of a user interface through which a buyer may peruse items for sale on the disclosed platform and submit bids for items, according to an embodiment.

[0043] FIG. 14 is a screenshot of the user interface of FIG. 13 after a buyer has selected one of the items.

[0044] FIG. 15 is a screenshot of the user interface of FIG. 14 after the disclosed platform has determined that the buyer won the item for which a bid was submitted.

[0045] FIG. 16 is screenshot of a user interface through which a seller may review items for which the seller has subscribed on the disclosed platform.

DETAILED DESCRIPTION

[0046] Disclosed herein are utilities (e.g., systems, methods, etc.) for facilitating a bilateral bidding process between buyers and sellers of items (services, products, bundles, etc.) to allow buyers to obtain lower prices on the items through crowd bidding while simultaneously allowing sellers to essentially offset such lower prices on the items through increased sales volume of the items. Specifically, the disclosed utilities make use of a network-based ecommerce system or platform (computerized system or platform) that provides sellers of items access to real-time buyer demand and the optimum price that a plurality of buyers (e.g., customers) are willing to pay that yields increased profits. The disclosed platform also benefits buyers in cases when multiple sellers compete for the then current buyer demand resulting in a reduced price for the item based on the then real-time demand.

[0047] Initial reference is made to FIG. 1 which presents a system diagram illustrating how each of one or more buyers 101 and one or more sellers 102 may interact (e.g., over one or more networks 130 such as the Internet) with an ecommerce marketplace platform 140 (also known as a bilateral bid auction marketplace platform) that is owned or managed by an ecommerce marketplace provider 103 to facilitate bilateral bidding of bulk items between the seller(s) 102 and buyer(s) 101. While shown separately, the one or more sellers 102 may in some arrangements be the provider 103 or license use of the platform 140 for use with their own web site. For instance, a large retailer that currently does not offer others to sell on their network can leverage the utilities disclosed herein to capitalize on bulk sales through the disclosed crowd-based bidding process.

[0048] The platform 140 may include any appropriate combination of servers, databases, and/or other systems (e.g., disposed at one location or interconnected at a plurality of locations) that are configured to substantially seamlessly implement a bilateral bidding process between sellers and buyers for bulk items. Broadly, the platform 140 may include one or more application servers 143 for interfacing with one or more servers, systems and/or databases necessary to manage the bilateral bidding processing disclosed herein. As an example, the application servers 143 may include at least one auctioning system 152 that is configured to manage items subscribed to and/or added to the platform by sellers as well as bids for items received by the platform 140. For instance, the auctioning system 152 may include a bidding engine 153 (e.g., one or more sets of computer readable instructions executable by one or more processors of the auctioning system 152) that is configured to implement a plurality of rules, algorithms, processes and/or tools to execute the bilateral bidding processes disclosed herein.

[0049] The application servers 143 may also include (or be networked to and make use of) one or more payment systems 154 dedicated to payments and other financial processes and functions between the sellers 102, buyers 101, and ecommerce marketplace provider 103. The one or more application servers 143 (e.g., the auctioning system 152, payment system(s) 154) may communicate with one or more databases 145 via one or more database servers 144 as part of the bilateral bidding process. The database(s) 145 include any appropriate collection of structured data to enable the bilateral bidding process and may include or represent data provided by actors (sellers 102, buyers 101, ecommerce marketplace provider 103, third party entities, and other actors, etc.) and information systematically generated by the platform 140 and/or received from other systems, networks and devices used for the bilateral bidding process.

[0050] The platform 140 may communicate with buyers 101 and sellers 102 in any appropriate manner. For instance, the platform 140 may include at least one web server 141 (e.g., server software and associated hardware that processes incoming network requests over HTTP and/or other related protocols over the network(s) 130) and/or at least one API server 142 (e.g., servers dedicated for API functions and processes and enables third party applications used by seller device 113 and/or buyer devices 112 to interface with the platform 140). In relation to each buyer 101, the buyer 101 may utilize any appropriate buyer device 112 (e.g., smartphone, tablet, server, etc.) to access a web client 121 (e.g., browser) or a native app client 122 (e.g., app) to communicate with the at least one web server 141 over network 130. In relation to each seller 102, the seller 102 may utilize any appropriate seller device 113 (e.g., smartphone, tablet, server, etc.) to access a web client 123 (e.g., browser) or a native app client 124 (e.g., app) to communicate with the at least one web server 141 over network 130. In one arrangement, the seller device 113 may access any appropriate API 126 (e.g., developed by the ecommerce marketplace provider 103 or licensee of the provider 103 and includes a set of routines, protocols, and tools for building software applications) of an enterprise resource planning (ERP) system to integrate business functions (e.g., such as planning, purchasing, inventory, sales, marketing, finance and human resources) into the bilateral bidding process disclosed herein.

[0051] Turning now to FIG. 2, a schematic diagram is presented that broadly illustrates a bidding session between sellers 202 (e.g., sellers 102) and buyers (e.g., buyers 101) on the disclosed platform 140 via one or more networks 230 (e.g., networks 130) for items. As used herein, an “item” 270 may be a product 271, service 272, or bundle 273. A product 271 is a commercially distributed good that is tangible personal property with output or result of a fabrication, manufacturing, or production process, and passes through a distribution channel before being consumed or used and is available for purchase on the platform 140. A service 272 is work performed by the seller (or third-party actor(s) represented by the seller) that is uniquely identifiable and repeatable and is performed by an individual, team, organization or technology system for the benefit of the buyer (and is available for purchase on the platform 140). A bundle 273 is two or more products 271, two or more services 272, or one or more products 271 and one or more services 272.

[0052] The platform 140 may maintain a listing (e.g., as part of a relational database management system (RDBMS) or the like) of various items 270 (e.g., in database 145 of FIG. 1) for sale from sellers 202 to buyers 201, where each item 270 may be uniquely identified by any appropriate identifier (e.g., ID, part number, code, etc.) relative to other items 270 of the platform 140. In some situations, the platform 140 may create its own unique identifier for the items while in other situations the platform 140 may use a manufacturer part number or the like. In connection with each item identifier, the platform 140 may maintain (or at least have access to) numerous associated data and analytics for corresponding item for use by the platform 140, sellers in connection with selecting items to sell and engaging in the disclosed bilateral bidding process, buyers in connection with selecting items on which to bid in the disclosed bilateral bidding process, and the like. For instance, some of the data that may be maintained by the platform 140 with each of the items is MSRP, 30 (or other) day high price, 30 (or other) day low price, ratings, reviews, item images and/or videos, and the like.

[0053] With additional reference now to the method 500 of FIG. 9, a seller 202 (e.g., manufacturer, solution provider, reseller, provider of ecommerce system, etc.) may (e.g., either manually or via API) initially access the platform 140 via seller device 113 over network 230 and search 510 or browse for an item 270 that they intend to offer on the platform 140. Before searching or browsing 510, sellers may be required to register with the platform 140 by way of providing any appropriate information (e.g., name, mailing address, email address, contact name, bank account information, etc.) to create an account. The seller 202 may then query 520 whether the item is already available on the platform 140 and then “subscribe” 530 to the item 270 if it is already available or create 525 the item if not available. Part of creating 525 the item may include providing the platform 140 with information and data such as name, part number, manufacturer, and/or the like. In other arrangements, the platform 140 may, upon receiving one or more pieces of information (e.g., part number), actively acquire additional information regarding the item (e.g., manufacturer, name, type) in any appropriate automated manner. After creating 525 the items, the seller may then subscribe 530 to the item.

[0054] FIG. 16 illustrates a screenshot of a user interface 1700 of the platform 140 that may be accessible to a seller 202 to view items 1704 to which the seller has subscribed. For each item 1704, various information may be displayed such as items name and ID, the seller's respective in stock inventory of the items, cost of goods sold (COGS), and the like. Furthermore, any appropriate user manipulatable features 1708 (e.g., buttons, etc.) may be presented that may allow a seller to join a current bidding session for the item as discussed in more detail below. Turning back to FIG. 9, the method 500 may then include the seller monitoring 540 buyer bids for each of their subscribed items and then joining 550 an active bid session for one or more of the items (via selecting one of the buttons 1708 in FIG. 16) as discussed below.

[0055] On the buyer side and with reference now to the method 400 of FIG. 8, a buyer may access the platform 140 via buyer device 112 over network 230 (e.g., network 130) and search or browse 410 for at least one item that they want to purchase, select 420 the desired item, set 430 a bid period (e.g., start date, end date, end time, etc.) for the bid, set 440 the bid price, set 450 the bid to active status and submit the same, and then await 460 an outcome of the bid. For instance, FIG. 12 presents a schematic diagram 800 of a buyer web/native app client 810 that may be used by the buyer to submit bids for an item on the disclosed platform 140. As shown, a selected item 820 may have a corresponding unique identifier 821 (as to other items on the platform 140). Furthermore, the app client 810 may include one portion 830 in which the buyer may enter a bid and another portion 840 where the buyer may set the bid duration. The app client 810 may also have a user manipulatable feature 850 (e.g., button) that may allow the user to submit the bid to the platform 140 for use in a bidding session disclosed herein.

[0056] FIG. 13 presents a screenshot 1400 of a web client (e.g., browser) that a buyer may utilize to browse for items available on the platform 140. FIG. 14 presents a screenshot 1500 of the web client upon the buyer identifying a particular item. The web client may include various information to assist the buyer in deciding whether to submit a bid (e.g., MSRP, high-low prices, etc.). Before submitting a bid, each buyer may be required to register with the platform 140 by way of providing any appropriate information (e.g., name, mailing address, email address, contact name, bank account and/or credit card information) to create an account. As part of determining a particular price at which to submit a bid, a buyer's goal in one characterization may be to submit the price they are willing to pay for the item that drives down the selling price for the product through collective bargaining power with other buyers interested in the item (e.g., that they could not otherwise find through other retail sources or commerce methods).

[0057] Returning now to FIG. 2, the platform 140 may broadly be configured to manage (e.g., simultaneously) a plurality of active bid sessions 220 for a plurality of items 270 on the platform (only one active bid session 220 being shown in the interest of clarity). The bid engine 280 (e.g., bid engine 153) may generally be configured to move incoming bids for a particular item into a bid pool 222 (e.g., memory space) and organize the bids from highest price to lowest price. In one arrangement, the bid engine 280 (and/or other engines/servers disclosed herein) may be configured to build and make use of respective “bid objects” 261 (e.g., data structures) for each respective bid that each broadly includes a plurality of objects to define the respective bid. As shown in FIG. 4, each bid object 261 may for instance include a price object 263 that defines a price at or below which the respective buyer is willing to pay for the respective item, an item ID object 265 that defines an ID that uniquely defines the item for which the bid was submitted relative to other items on the platform 140, a bid ID object 267 that uniquely defines the bid relative to other bids on the platform 140, a duration object 269 that defines a period of time submitted by the buyer for which the respective bid is to be effective on the platform 140 (or time until which the bid is to be effective), a user ID object 271 that uniquely identifies the buyer/user relative to other buyers/users of the platform 140, a preferences object 273 that defines one or more various preferences of the particular buyer (e.g., such as whether a first bid for a first item of a first type is to automatically expire upon the buyer winning a second bid for a second item of the first type on the platform 140), and/or one or more other objects 275 (e.g., bid creation timestamp, etc.) that may help to define the bid and that may be generated based on information submitted by the buyer or supplied or obtained by the platform 140. Bid or bid objects that have been organized from highest to lowest price by the bid engine 280 are referred to herein as “organized bids” or “organized bid objects”.

[0058] Turning back to FIGS. 2 and 9 and after a seller joining 550 an active bid session for a particular item on the platform 140 (e.g., using interface of FIG. 17), the seller may create 555 a “bid block” 251 from the organized bid objects 261 in the bid pool 222, where the bid block is a group of consecutive adjacent ones of the organized bid objects. Stated differently, a bid block is a string of the organized bid objects that includes all of the bid objects between the highest price bid object and the lowest price bid object in the string (the lowest price bid object being a lowest bid object price selected by the seller). FIG. 3 schematically illustrates how each of a plurality of sellers (e.g., merchants) that have subscribed to a common item have created difference respective bid blocks from the organized bid objects in the bid pool 222. For instance, each seller may select (in any appropriate manner) the one of the organized bid objects in the bid pool 222 having the lowest price at which the seller is willing to sell the item based on the volume of bid objects including and above the selected bid object up to the most expensive one of the organized bid objects. The volume of bid objects including and above the selected bid object up to the most expensive one of the organized bid objects represents a bid block for the respective seller.

[0059] In this example, Merchant 1 has selected the bid object 261 associated with customer/buyer E at a bid price of $765, Merchant 2 has selected the bid object 261 associated with customer/buyer H at a bid price of $699.99, and Merchant 3 has selected the bid object 261 associated with customer/buyer F at a bid price of $756. In one characterization, each seller's goal may be to select a particular one of the bid objects to create a respective bid block that offers the best ratio of price to volume they can provision based on current demand to maximize direct margins on bid transactions. Each seller may submit their bid object selections during an active bidding session and thereby create their respective bid blocks manually or via API for instance (e.g., where the API could execute rules to automatically create bid block based on item, bid object price, number of bid objects and thus buyers in the bid block, etc.). FIG. 11 presents another schematic diagram 700 illustrating a seller's bid block 710 defined by a selected bid object 711 (e.g., a seller bottom bid price) in a bid pool 730 as well as bid objects 710 above the selected bid object 711. Bid objects 720 are not included in the seller's bid block.

[0060] At step 560 in FIG. 9, it may be queried whether each seller's bid block conflicts with that of another seller's (e.g., whether a subsequent seller selected the same bid object as a prior seller during the bid session). If so, the seller may be prompted by the platform 140 to select another one of the organized bid objects and thereby create another bid block. Otherwise, the method 500 may proceed to confirm 570 each of the seller bid blocks for the particular active bid session 220 whereby each seller may await 580 an outcome of the active bid session 220. During the active bid session 220, each seller may be unaware as to the bid blocks being created by the other sellers.

[0061] At a conclusion of the particular active bidding session 220, the bidding engine 280 may automatically identify the lowest (cheapest) selected bid object (or in other words the bid block with the most bid objects of all of the bid blocks) and then generate an indication regarding the same. For instance, the generated indication may be in the form of any appropriate data structure identifying the particular seller (e.g., a seller ID) associated with the identified bid object, the price of the bid object, all other bid objects above the selected bid objects and their corresponding prices and seller IDs, item ID, buyer IDs of all bid objects in the winning bid block, and/or the like. Turning back to FIG. 3, the winning bid block may for instance be that associated with Merchant 2 and include the bid objects 261 associated with customer/buyer H up through customer/buyer A.

[0062] Referring again to the method 500 of FIG. 9 in response to querying 590 (for each seller) whether the seller won the active bid session 220, the seller may be required to provision 591 the item to each of the buyers associated with each of the bid blocks in the winning bid block (e.g., in the case of Merchant 2). For instance, as part of registering with the platform 140, each buyer may be required to submit mailing address, payment information, etc. which may be stored in the database(s) 145 or elsewhere. The platform 140 may automatically associate each such set of information with a unique buyer or user ID which may be included in each bid submitted by the buyer (and thus be found in each bid object 261 created by the platform 140. Accordingly, upon winning a particular bidding session, the platform 140 may be configured to utilize the particular user ID object 271 of each bid object 261 in the winning bid block to access the mailing address (and other pertinent information of the buyer) and send the same to the winning seller for the winning seller's use in shipping the corresponding item to the buyer. The platform may facilitate payment as a third-party intermediary such that payments flow through the platform (ecommerce provider) rather than directly from buyers to the seller. For all other sellers of the active bidding session 220 (e.g., Merchants 1 and 3), such sellers would not provision 592 the items to buyers as part of this active bidding session 220.

[0063] In one arrangement, the winning seller may be required to sell the item to each buyer in the winning bid block at the lowest bid price in the bid block. In other arrangement, the winning seller may sell the item to each buyer in the winning bid block at the respective bid price submitted by the respective buyer. From the buyer's perspective and referring to the method 400 of FIG. 8 and if the buyer's bid is included 461 in the winning bid block, the buyer may receive the corresponding item from the winning seller discussed above. As an example, FIG. 15 presents a screenshot 1600 of a user interface that may be presented on each winning buyer's device and that presents various information for use by the buyer. In the case where the seller was required to sell the item to each buyer at the lowest bid price in the bid block, the interface may indicate how much the respective buyer saved relative to their submitted bid. Other displayed information may include a breakdown of the purchase price (e.g., product, taxes, etc.), protection plans, etc. The interface may also include a “checkout” button that when manipulated brings the buyer to a payment page to purchase the product. Other possible outcomes include the buyer's bid not being included 462 in the winning bid block whereupon the buyer's bid may be provisioned for a subsequent bidding session for the item, the buyer's bid expiring 463, or the buyer terminating 464 their bid.

[0064] Returning to FIG. 2, the platform 140 may maintain a number of data structures for use by the bid engine 280 in managing the bilateral bidding sessions such as a bid session ID 223 (e.g., identification that uniquely identifies each bid session, a bid session period 224 (e.g., length of the particular bid session), a bid session cyclic schedule 240 (e.g., period the ecommerce marketplace provider establishes (e.g., start date, start time, end date, end time) to conduct the bilateral bid auctioning process, where the process is cyclic), current date 225, and current time 226. For instance, each respective adjacent pair of bid sessions may be identical but non-overlapping periods of time.

[0065] FIG. 6 presents a flow diagram of a method 750 for use by the platform 140 in conducting a bilateral bidding process for one type of item as discussed herein. It is to be understood that the platform 140 may respectively engage in the method 750 for a plurality of different types of items simultaneously, sequentially, and/or the like. At step 754, the platform 140 may receive a plurality bid objects from buyers (e.g., or as created by the platform 140 in response to receiving bids from buyers) for an item and into a staging register of a bidding pool. With reference to FIG. 3, a bidding pool 320 (e.g., bidding pool 222 of FIG. 2) for a particular item 310 may include a staging register 322 and a separate active register 321, where each of the registers may be in the form of discrete memory spaces for use by the bidding engine 280 to conduct bilateral bidding sessions. For instance, new buyer bids 340 may be received and corresponding bid objects 261 may be disposed into the staging register 322.

[0066] The method 750 may then include the bidding engine organizing 758 the bid objects 261 from the most to the least expensive or in other words organizing the bid objects from the bid object 261 having the price object 263 (see FIG. 4) with the highest price and continuing to the bid object 261 having the price object 263 with the lowest price (e.g., similar to the bid objects in FIGS. 2, 3, and 11). In the case where two or more bid objects are received or created that all of the same price, the bid engine 280 may automatically arrange such bid objects in order of their time stamps or in other words when they were received by the platform 140 (or created by the buyers). For instance, the one of such bid objects having the earliest time may be placed highest in the organized list (i.e., closer to the most expensive bid object that the other ones of such bid objects) to increase the likelihood that such bid object is included in a winning bid block (assuming such respective buyer should get a benefit by being the first one to submit a bid object at such price). While the method discusses moving and organizing the bid objects 261 themselves, it is to be understood that each bid object 261 in some arrangements may merely be represented in the bid pool 320 via the bid ID object 267 or other unique identifier, where other objects that define each bid object 261 may be stored in the database(s) 145 or elsewhere and accessed using the bid ID as a key or the like.

[0067] At or just before a beginning of a next active bid session (e.g., as known by the bid session cyclic schedule 240), the bidding engine 280 may move 762 the bid objects 261 from the staging register 322 into the active register 321, the bid objects 261 also being organized from most to least expensive in the active register 321. Once the bid objects 261 have been moved into the active register 321 and the next (now current) active bid session has begun, the bidding engine 280 may “lock” the active register 321 from addition of new bid objects 261 into the active register 321 and removal of existing bid objects from the active register 321 during the current active bid session. In this regard, new bid objects 261 received by the platform 140 for a particular item while a current bid session is being conducted for the same particular item are placed into the staging register 261 of the bid pool 320 for the same particular item in preparation for a subsequent bid session for the item. In one arrangement, the bid engine 280 may constantly organize the bid objects 261 in the staging area from most to least expensive. In other arrangement, the bid engine 280 may organize the bid objects 261 from most to least expensive at or just prior to movement of the bid objects 261 from the staging register 322 into the active register 321 for a next active bid session.

[0068] At 766, the method 750 may include receiving respective indications from respective sellers of bottom bid block prices, where each respective bottom bid block price and the bid objects above the bottom price (i.e., the more expensive bid objects) make up a respective bid block. In other words, the platform 140 may receive indications from respective sellers of different respective ones of the bid objects in the organized bid object list in the active register 321, where different respective bid blocks are created for each seller. For instance, see bid blocks 221 in FIG. 2 and bid block 710 in FIG. 11. Generally, only one seller may select each bid object 261 in the active register 321 such that each respective bid block is at least slightly different from all of the other bid blocks. In the case where two sellers attempt to select the same bid object, the bid engine will grant the bid object (and the bid block created from the bid object) to the received seller indication having the earliest time stamp and then generate and send an indication to the other seller to make another selection. Each seller may generally be unaware of whether any other sellers are also making selections during the current active bid session.

[0069] In one arrangement, the bid engine 280 (or a seller's API) may be configured to automatically adjust the seller's bid block based on seller preferences embodied in any appropriate rules as applied by the bid engine 280 or seller's API. As an example, in an effort to ensure that a seller's bid block wins the current bidding session, the seller may establish preferences on the platform 140 (e.g., stored on database(s) 145) dictating that the seller approves for the seller's bid block to automatically increase in size (e.g., by automatically reducing the seller's bottom bid object price) in response to another seller selecting a lower bottom bid object price. For instance, a seller could establish a rule that in the event another seller establishes a lower bottom bid object prices, the seller's bottom price is to automatically be adjusted (thus increasing the seller's bid block) to the next bid object below the other seller's bottom bid object) in the organize list of bid object, but not below a particular price. The seller may establish such preferences based on desired price to volume ratios it is seeking to achieve.

[0070] At or before an end of the current bid session, the method 750 (e.g., the bid engine) may query 770 whether each seller's in stock total of the particular item is greater than or equal to the number of bid objects in the seller's respective bid block. With reference to FIG. 3, for instance, the bid engine 280 may query whether Merchant 1's in-stock total of the particular item (“Telebox 62 inch TV” in the example) is equal to or greater than five, Merchant 2's in-stock total is equal to or greater than eight, and the like. Seller in-stock totals for various items may be maintained in the database(s) 145 or the like. For instance, the screenshot 1700 of FIG. 16 illustrates a particular seller's in-stock totals (“inventory”) for various types of TVs being sold on the platform 140. In response to a negative answer to the query 770, the bid engine 280 may generate 774 an indication that the particular bid block has been rejected due to insufficient inventory and then request another indication from the seller (i.e., another bottom price bid object).

[0071] At the end of the current bid session, the method 778 may query 778 whether more than one seller indication has been received or in other words whether more than one bid block was created during the bid session. If no (e.g., only one bid block was created), the bid engine 280 may then generate in indication to the single winning seller that the bid block was won (where the seller would then need to provision the items to the buyers in the bid block as discussed herein) and then the method may proceed to provision 790 the active register 321 for the subsequent bidding session for the item. If no indications were received (no bid blocks created during bid session), the method may proceed directly to step 790 without generating an indication regarding a winning bid block. If the answer to the query 778 is yes such that more than one seller indications were received (i.e., plurality bid blocks created by bid engine), then the bid engine 782 may automatically select 782 the one of the bid blocks having the lowest bottom price (i.e., the cheapest bid object 261) and then generate 786 an indication to the particular seller that selected the cheapest bid object 261 that their respective bid block has won the current active bid session. For instance, FIG. 5 illustrates how bids 323 included in the winning bid block (e.g., the winning bid objects 261) may be used to provision 370 the particular item to the buyers associated with the winning bids while bids 324 not included in the winning bid block (e.g., the bid objects 261 not included in the winning bid block) may be provisioned for a next bid session 360. FIG. 9 presents a table 600 illustrating a plurality of bid session use cases 610-690 that may take place on the platform at a conclusion of each respective bid session.

[0072] FIG. 7 illustrates a flow diagram of a method 850 of provisioning the active register 321 of the bidding pool 320 for use in a subsequent bidding session for the same particular item (where the provisioning occurs before a start of the subsequent bidding session). The method 850 may include removing 854 from the active register 321 any bid objects that were included in the winning bid block from the immediately previous bid session. In the example of FIG. 3 where Merchant 2 won the bid session and all of the bid objects were in the active register 321 of FIG. 5, the bid objects associated with all of Customers A-H may be removed leaving the bid objects associated with Customers I-L. Furthermore, any bid objects 261 that had accrued in the staging register 322 during the previous bid session may be moved 858 into the active register. Another step of the method 850 may include querying 862 whether any bid objects have expired. For instance, the bid engine 280 may access the duration object 269 of each bid object 261 to determine whether or not the bid object 261 has expired. Part of this process may include the bid engine 280 accessing the current date 225 and current time 226 as maintained by the platform 140.

[0073] As another example, the bid engine 280 may access the preferences object 273 of each bid object 261 to determine whether the bid object has expired. For instance, in the case where the preferences object 261 for a particular bid object indicates the bid object 261 is to expire if another bid object 261 of the buyer in another bid pool for another type of item was previously include in a winning bid block. If so, the first bid object 261 may expire. The bid engine 280 may analyze each of the bid objects 261 in this manner and remove 866 any expired bid objects. For instance, FIG. 5 illustrates expired and terminated bid objects 350, 351. In some arrangements, the bid engine 280 may analyze the bid objects 261 for expiration before moving the bid objects 261 from the staging register 322 into the active register 321. The method 850 may also query 870 whether the bid objects 261 are arranged from most to least expensive in the active register 321 and organize or arrange 874 them in this way if not. In any case, active register 321 may now be provisioned or in other words prepared for the subsequent bidding session for the particular item and the method 878 may then proceed to step 766 of FIG. 7 for the subsequent (now active) bidding session.

[0074] In one embodiment, the bid engine 280 may create or make use of a different respective pair of staging and active registers 322, 321 for a particular item during each subsequent bidding session for the item. For instance, as part of provisioning the bidding pool for a subsequent bidding session, the bid engine 280 may move remaining (and unexpired) bid objects from the active register 321 of the previous bid session into the active register 321 of the subsequent bid session. Furthermore, bid objects 261 received at the platform for a particular item during the prior bid session for the item would be received and stored into the staging register 322 for the subsequent bid session rather than for the prior bid session. In this regard, the bid engine would move unexpired bid objects from the staging register 322 of the subsequent bid session into the active register 321 for the subsequent bid session as part of provisioning the active register for a beginning of the subsequent bid session.

[0075] In some variations, the API server(s) 142 can include an ERP API to interface with the seller's ERP system 125. In some versions, the servers through the API receive UPC codes and quantities of goods of various types from the seller's/merchant's ERP 125. The system may then associate the items with current listings or even automatically create new listings. The merchant ERP's 125 may include pricing rules for each item or the merchant may direct the servers to selectively include its items in the active listings or begin bid sessions for new listings. In at least some embodiments, sellers can request analytics from the platform 140 server(s) concerning a whole host of information about the items it has listed and sold as well as historical information concerning the performance of bid sessions for a certain item. Based on trends and historical data, the sellers can more accurately gauge demand and market price for a particular item or class of particular items.

[0076] The disclosed utilities are integrated into a practical and non-conventional application by facilitating a bilateral bidding process between sellers and buyers that allows buyers to obtain lower prices on the items through crowd bidding while simultaneously allowing sellers to essentially offset such lower prices on the items through increased sales volume of the items. Specifically, the dynamic and systematic manner in which the disclosed platform introduces bid objects into the bidding pool and organizes them from most to least expensive, receives seller offers to sell different respective blocks of the bids in the pool, identifies a winning bid block and then provisions the bid pool for subsequent cyclical bidding sessions for the same type of item (e.g., by way of analyzing duration and preference objects of the bid objects to remove expired bid objects, introduce accumulated new bid objects, etc.) is non-conventional and therefore presents an inventive technical innovation.

[0077] It will be readily appreciated that many deviations may be made from the specific embodiments disclosed in the specification without departing from the spirit and scope of the invention. The illustrations and discussion herein have only been provided to assist the reader in understanding the various aspects of the present disclosure. Furthermore, one or more various combinations of the above discussed arrangements and embodiments are also envisioned.

[0078] Embodiments disclosed herein (e.g., the bidding engine 280) can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus (processors, cores, etc.). The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. In addition to hardware, code that creates an execution environment for the computer program in question may be provided, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0079] A computer program (also known as a program, software, software application, script, or code) used to provide the functionality described herein can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0080] While this disclosure contains many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular embodiments of the disclosure. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.