WO2006075212A2 - System and apparatus for bidding - Google Patents
System and apparatus for bidding Download PDFInfo
- Publication number
- WO2006075212A2 WO2006075212A2 PCT/IB2005/050113 IB2005050113W WO2006075212A2 WO 2006075212 A2 WO2006075212 A2 WO 2006075212A2 IB 2005050113 W IB2005050113 W IB 2005050113W WO 2006075212 A2 WO2006075212 A2 WO 2006075212A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- item
- bidder
- auction
- items
- bidders
- Prior art date
Links
- 238000000034 method Methods 0.000 claims description 71
- 230000008569 process Effects 0.000 description 26
- 238000013515 script Methods 0.000 description 20
- 230000008929 regeneration Effects 0.000 description 16
- 238000011069 regeneration method Methods 0.000 description 16
- 238000013459 approach Methods 0.000 description 13
- 230000008901 benefit Effects 0.000 description 13
- 230000006870 function Effects 0.000 description 10
- 238000012545 processing Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000006855 networking Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000012552 review Methods 0.000 description 3
- 230000001174 ascending effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000001727 in vivo Methods 0.000 description 2
- 241001122315 Polites Species 0.000 description 1
- 208000003251 Pruritus Diseases 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000001152 differential interference contrast microscopy Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000000126 in silico method Methods 0.000 description 1
- 244000144972 livestock Species 0.000 description 1
- 230000035515 penetration Effects 0.000 description 1
- 230000001172 regenerating effect Effects 0.000 description 1
- 238000006748 scratching Methods 0.000 description 1
- 230000002393 scratching effect Effects 0.000 description 1
- GOLXNESZZPUPJE-UHFFFAOYSA-N spiromesifen Chemical compound CC1=CC(C)=CC(C)=C1C(C(O1)=O)=C(OC(=O)CC(C)(C)C)C11CCCC1 GOLXNESZZPUPJE-UHFFFAOYSA-N 0.000 description 1
- 230000003245 working effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
Definitions
- the would-be bidder In a classic Christie's or Sotheby's auction, the would-be bidder is either present in the auction room (directly or through a proxy) or is not. If the would-be bidder is not present, then the would-be bidder will stand no chance of winning bids, but this simply follows automatically from the fact of not being present at the auction. To the extent there is some missed opportunity to bid, the would be bidder who has failed to attend will not feel that the system has filed him or her, as the problem could have been readily cured simply by showing up for the auction. On the other hand, if the would-be bidder is present in the room, then it is easy enough to keep track of every single item being auctioned, as the auctions take place seriatim.
- a would-be bidder can "drill down” through a classification system.
- a would-be bidder may start in “Computers & Networking” and then narrow the search to "Networking,” then to “Wireless Networking,”, then to “WiFi,” then to "PC Cards,”, then to “USB, Adapters, NICs,”, and finally to "PC Cards, PCMCIA (Laptop),", in a numerical classification (in the case of eBay) of 45000. Having done this, the would-be bidder can return again and again to the numerical class and can review the pending items for auction which are in this class, perhaps bidding for one or more such items.
- a would-be bidder can search, looking for particular words or phrases in the titles or titles and descriptions of pending auctions. This may yield a list of items matching the search terms, and the would-be bidder can review the pending items, perhaps bidding for one or more such items.
- a would-be bidder can search "closed items," that is, items for which the bidding has ended and for which a winning bidder has been identified. Such a search is generally carried out just as described above, for example, through numerical classes or word searches or a combination of both, and identifies items which the would-be bidder missed.
- 2004/0267731 entitled “Method and system to facilitate building and using a search database”
- US 2004/0193525 entitled “Online bidding system and method of the same”
- US 2002/0082977 entitled “Aggregation of on-line auction listing and market data for use to increase likely revenues from auction listings”
- US 6732161 entitled “Information presentation and management in an online trading environment”
- US 6058417 entitled “Information presentation and management in an online trading environment”
- US 6044363 entitled “Automatic auction method”
- US 6012045 entitled “Computer-based electronic bid, auction and sale system, and a system to teach new/ non-registered customers how bidding, auction purchasing works”
- US 2002/0023037 entitled “Exchange method and apparatus”
- international patent publication WO 00/62225 entitled “Marketplace system fees enhancing market share and participation.”
- the auction system communicatively coupled with sellers and bidders, the system having records indicative of sellers of items and records indicative of bidders for the items and identifying for each item a winning bidder in an auction
- a first bidder selects a first item.
- information is obtained indicative of identities of second bidders other than the first bidder who previously placed respective bids for the first item.
- Second items are found other than the first item for which bids have been placed by one or more of the second bidders.
- a second item is chosen by the first bidder, for which the first bidder was not aware of the second item until after this work is done.
- the first bidder may then attempt to discern why the first bidder was not aware of the second item until after the auction ended.
- this approach is used to identifying a second item for which the auction has not yet ended, and the first bidder places a bid higher than any bids previously placed for that second item.
- Fig. 1 shows in functional block diagram form a typical online auction system, together with apparatus 22 according to the invention.
- FIG. 2 shows apparatus 22 of Fig. 1 in greater detail, in functional block diagram form.
- FIG. 3 shows in flowchart form a first method according to the invention.
- FIG. 4 shows in flowchart form a second method according to the invention.
- Fig. 5 depicts relationships among various data records in the system according to the invention.
- FIG. 6 shows a user interface flowchart for apparatus according to the invention.
- Fig. 1 shows in functional block diagram form a typical online auction system 13, together with apparatus 22 according to the invention.
- Online auction system 13 may be seen, which is communicatively coupled (e.g. by the Internet through web-based interfaces) with sellers 19 and bidders 20 through links 23 and 24 respectively.
- a database 15 of sellers there is a database 15 of sellers, a database 14 of bidders, a database 10 of items being auctioned, and a database 11 of bids placed for the items being auctioned.
- a seller listed in database 15 may list an item for auction by causing the item to be listed in database 10.
- Bidders listed in database 14 place bids, indicated by arrow 18, which are accumulated in bid database 11.
- Sellers and bidders are, in a typical system 13, identified by unique identifiiers called user IDs which serve as pointers into database 16. Items being auctioned are, in a typical system, identified by unique item numbers which serve as pointers into database 10 and optionally into database 11.
- system 13 may be arranged in any of several ways as a matter of design decision by the designer of the system 13. In a very simple case a single computer and disk storage system can perform all the functions just discussed. In a large system with millions of users and millions of listed items, it is preferable to break up the many functions into separate physical parts. For example one server may serve as "front end" for web-interface visitors, while a second server may be devoted to servi ng up images and other items of data that change only slowly (e.g. item descriptions). Yet another server may collect bids while a fourth server may authenticate visitors who are logging into the system.
- Ten bid- related servers may divide up the task of receiving bids and keeping track of who is the highest bidder, each based upon the final digit of the item number, for example.
- a bidder 21 who enjoys the benefits of the invention is communicately coupled with the system 13 by means of link 25.
- the bidder 21 uses system 22 in an attempt to bid optimally, minimizing lost bidding opportunities.
- System 22 is, in an exemplary embodiment, a general-purpose personal computer running a suitable stored program, the computer located nearby to the user 21 and having a user interface 26 such as a keyboard, pointing device, and screen, and the computer connected by means of the Internet to the system 13.
- a user interface 26 such as a keyboard, pointing device, and screen
- this embodiment which might be termed a "thick client" embodiment, there are typically as many personal computers (each providing system 22) as there are users 21.
- system 22 is a server and the user interface 26 is a web-based interface.
- System 22 in this embodiment actually serves many users 21, each user having a respective user interface 26. It will be appreciated that there are advantages and disadvantages to these two approaches to providing the benefits of the invention to users 21, and it will also be appreciated that the invention can provide its benefits in embodiments differing from these two approaches, none of which depart in any way from the invention.
- Fig. 2 shows apparatus 22 of Fig. 1 in greater detail, in functional block diagram form.
- User interface 26 is coupled with apparatus 22.
- apparatus 22 includes a database 29 of items of interest to the bidder 21, a database 28 of competing bidders, and a database 27 of search keys used for searching.
- the search keys from the database 27 are, as described below, used among other things to perform searches upon database 10 of items being auctioned.
- the database 28 of competing bidders will, in an exemplary embodiment, consist in large part of user IDs of such competing bidders, and are used to perform queries in system 13 to learn what items (if any) those competing bidders have bid on.
- the database 29 of items of interest will, in an exemplary embodiment, consist in large part of item numbers, and are used to perform queries in system 13 to learn the status of items being auctioned.
- Fig. 3 shows in flowchart form a first method 45 according to the invention.
- this method 45 is carried out with respect to computer-based auction system 13, the auction system communicatively coupled 23, 24 with sellers 19 and bidders 20, the system 13 having records (in database 15) indicative of sellers of items and records (in database 14) indicative of bidders for the items and identifying for each item a winning bidder in an auction.
- a first bidder 21 selects a first item for which there is a winning bidder. In a simple case it is an item for which the winning bidder is not the same as the first bidder. (Alternatively this may be a case where the item is one where the first bidder was indeed the winning bidder, or may be a case where the item is simply one where the first bidder has placed a bid.)
- the user of the invention learns that he or she has lost an auction.
- the apparatus 22 then, in an automated way at box 41, obtains from system 13 information indicative of identities of second bidders other than the first bidder who previously placed respective bids for the first item.
- the identities of the second bidders are placed for example in database 28.
- the apparatus 22 then, in an automated way at box 42, finds second items other than the first item for which bids have been placed by one or more of the second bidders.
- the first bidder can then choose (at box 43) from among those second items, perhaps identifying an item that the first bidder had not previously found through previous searches of the kinds employed in the prior art.
- the first bidder will not even learn of the existence of this item until after its auction has ended at which time it is too late to bid on it. It is not, however, too late to attempt to learn something from what happened.
- the first bidder can then (at box 44) attempt to discern why the first bidder was not aware of the second item until after the auction ended. This may include studying to see how this second item was classified by its seller; this may educate the user as to classifications that this seller, or other sellers, might choose to use in future for such items. This may also include studying to see the vocabulary that was selected by this seller, which may educate the user as to the vocabulary which this seller, or other sellers, might use in future.
- the learning opportunities provided in this way can benefit the user in at least two different ways.
- the user may, through more informed searching in future, come to learn of items that can be had at lower prices than items that would have been found through less effective searches. Or the user may learn of an item sooner, win it sooner, and enjoy its benefits sooner. Finally, for some unique items, such as collectables, there may be only one chance to obtain a given item and if the item is lost that may be the end of the matter.
- Fig. 4 shows in flowchart form a second method 50 according to the invention.
- the user selects (at box 51) a first item of interest. This may for example be an item for which someone else was the winning bidder. Alternatively this may be an item that has an auction in progress, an item of interest to the user.
- the system 22 then (at box 52) obtains information indicative of identities of second bidders other than the first bidder who have already placed respective bids for the first item.
- the system 22 finds second items other than the first item for which bids have been placed by one or more of the second bidders.
- the first bidder may then choose a second item for which the auction has not yet ended and for which the first bidder has not yet placed a bid.
- the first bidder (user) places a bid electronically for the second item prior to the end of the action, the bid higher than any bid previously placed for the second item.
- the would-be bidder will have learned of some item available for bidding that the would-be bidder might well not have learned about through conventional searching techniques.
- these approaches can save the human user hours of searching time as compared with previous methods of searching. To take up again the "photograph" example mentioned above, if a competing bidder has noticed the item of interest in the corner of the photograph, this approach may permit coming to learn of the item (and its reason for being interesting) in enough time to place a bid on the item.
- this new information may save money for the bidder by permitting winning the present item for a lower price than some other comparable item for which the bids have risen (or will later rise) to a higher price.
- this new information may enable the bidder to learn of, and purchase, an item right away, when a comparable item might not otherwise have come to the attention of the bidder (through conventional searching) until some later time.
- this new information may permit finding and acquiring unique items that would otherwise be lost and for which there is no ready substitute.
- One variant of the invention calls for "auto-adding" competing bidders. The user looks at items that other bidders are bidding on.
- the user looks at how frequently it has happened that some other bidder has bid on the same items that the user has bid on, and if some threshold is reached that other bidder will be added to a bidder list. Alternatively, such an other bidder can be manually added to the bidder list.
- One way to think about the apparatus according to the invention is that it permits tracking and analyzing the actions of other participants in an auction system in order to locate items which might otherwise not have been found.
- the apparatus analyzes the similarities between the user and the other participants in the auction system.
- the apparatus can allow the user to designate which categories (classifications) he or she typically browses when searching for items in an auction. These categories are entered into the system, perhaps by selecting them from a web-based menu or by entering in numerical classification values.
- the system keeps a current cache of items listed in these categories. This cache is updated at predefined intervals or as requested by the user. A set of user-defined filters may be applied to the results of this searching.
- the apparatus can allow the user to define search terms.
- the system fetches all matching items from the auction system and saves them in a local database. Again, user-defined filters may be applied to the results of this searching.
- the system can also allow the user to designate other auction participants that the user typically competes with in the bidding process. This is done by storing user IDs of those participants. The system then fetches all of the others items that these participants are bidding on. These items are stored in the aforementioned item cache.
- the system can also allow the user to specify manually item numbers of items of interest.
- the system retrieves the status of such items from the auction system and makes this information available to the user.
- the system can also look for all auctions which the user has bid on, and can retrieve the identifiers of all of the sellers for those items, as well as all of the competing bidders for those items.
- the system desirably permits the user to set up filters so that not all of the retrieved items are displayed.
- Typical filters can be on maximum price, minimum price, geographic region, or items that have received fewer than some number of bids.
- a "filter-out" keyword can filter out items containing certain key . words.
- the system will keep track of how often a particular bidder turns out to be a competing bidder. When this happens more than some predetermined number of times (set by the user, or by default) then this bidder will be put into a list of "bidders to watch.” The system then automatically tracks everything that such a bidder bids on, and reports it to the user. The same can be done for sellers who turn up repeatedly among sellers of items of interest.
- Fig. 5 depicts relationships among various data records in the system according to the invention, all of which are discussed in detail below. Reading down the first column on the left, there is a search entity, and below it a category entity. Call tracking and error logging records are shown, discussed below. Reading down the middle column, there are data records representing bidders. Below that is a data record representing a user of the system, and a data record called BS_ITEM_CACHE, representing a cache of items found by analysis of buyers and sellers. Reading down the right column are data records representing sellers, an item cache, data records indicative of other bidders, and an archive of items of interest.
- Username stores the username of the user storing this category.
- Category_id stores the auction system's unique identifier. The next few fields are:
- Parent_name the text name of the category ' s immediate parent. NULL if said category is top-level.
- Sort_order code that indicates how the items in the category should be sorted.
- Filter_minbids minimum number of bids an item in this category must have in order to be displayed
- Filter_minprice minimum price an item must have in this category in order to be displayed
- Filter_maxprice maximum price an item may have in this category in order to be displayed
- Filter_keywords list of keywords the item must not include in order to be displayed
- Filter_region a region code the item must possess in order to be displayed in this category.
- Highlight_words a list of words that, if contained in the auction title, should be highlighted in some fashion.
- Active flag that tells the system whether or not to download items for this category.
- Last_regen_date date and time at which the system last fetched items for this category.
- Last_item_count number of items downloaded from this category the last time the category was processed.
- Last_item_total number of items the auction system claimed were in this category last time the category was processed.
- Region_name the name of the region associated with the filter_region column.
- In_regen data and time at which the current regeneration process was started.
- NULL indicates the category is not currently being processed.
- Pid process ID number the system assigned to the script that is processing this category. NULL indicates it is not currently being processed.
- search database (item 27 in Fig. 2), this stores all the search queries users want items downloaded for. Its primary key is "Search_id.” Fields include: [87] Search_id: unique id number automatically assigned by the database each time a new search term is added. Uniquely identifies each stored search query. [88] Query: the actual stored search query (text) to be sent to the auction system when searching for items.
- Username username of the site user that is storing the query.
- Category_id optionally, a user can specify a category to confine the search to.
- Category_name the textual name of the aforementioned category.
- Parent_name the name of the parent category of the aforementioned category_id.
- Sort_order code that indicates how the items resulting from the query should be sorted.
- Filter_minbids minimum number of bids an item resulting from the query must have in order to be displayed
- Filter_minprice minimum price an item resulting from the query must have in order to be displayed.
- Filter_maxprice maximum price an item resulting from the query may have in order to be displayed.
- Filter_keywords list of keywords the item must not include in order to be displayed
- Filterjregion a region code the item must possess in order to be displayed in the query results.
- Highlight_words a list of words that, if contained in the auction title, should be highlighted in some fashion.
- Active flag that tells the system whether or not to download items for this stored search.
- Last_regen_date date and time at which the system last fetched items for this search.
- Last_item_count number of items downloaded from this search the last time the search was processed.
- Last_item_total number of items the auction system claimed resulted from the stored search last time the stored search was processed.
- Last_prefilter_total number of items the stored search yielded before server-side filtering took place.
- Region_name the textual name of the region if the region filter was specified above.
- Injregen date and time at which the current regeneration process started. NULL if search is not currently in regen.
- Search_desc flag that indicates whether auction descriptions should be searched in addition to titles. 1 : search them. 0: don't.
- Search_option field to hold additional search options to be passed on to the auction provider.
- Pid process ID number the system assigned to the script that is processing this search. NULL indicates it is not currently being processed.
- the Bidder database this is a table (item 28 in Fig. 2) that stores all of the other bidders being watched by users of the site. Its primary keys are the bidder Ebay_user_id and the Username. Fields include: [118] Ebay_user_id: unique user identifier that the bidder uses on the outside auction system.
- Source flag that indicates whether the site user or the system added this bidder to the database.
- date_added date this bidder was added to the database.
- Num_matches the number of items the user of the site had in common with this bidder. IE: how many auctions did they both bid on.
- Filter_words list of words that, if present in the title of the auction, should be used to remove the item from the result set.
- Filterjminprice minimum price an item must have in order to be part of the result set from this bidder.
- Filter_maxprice maximum price an item may have in order to be part of the result set from this bidder.
- Last_regen_date date and time of the last successfully completed regeneration process for this bidder.
- In_regen date and time at which the current regeneration process started for this bidder.
- NULL indicates bidder is not being regenerated.
- Active flag to indicate to the system whether or not items should be downloaded for this bidder.
- Pid process ID number the system assigned to the script that is processing this bidder. NULL indicates it is not currently being processed.
- the next database is the Seller file, a table that stores all of the other sellers being watched by users of the site. Its fields include: [132] Ebay_user_id
- Ebay_user_id unique user identifier that the seller uses on the outside auction system.
- Username unique user identifier of the user of this site.
- Source flag that indicates whether the site user or the system added this seller to the database.
- date_added date this seller was added to the database.
- Num_matches the number of items the user of the site had in common with this seller. IE: how many auctions did they both bid on.
- Filter_words list of words that, if present in the title of the auction, should be used to remove the item from the result set.
- Filterjninprice minimum price an item must have in order to be part of the result set from this seller.
- Filterjmaxprice maximum price an item may have in order to be part of the result set from this seller.
- Items_with_bids flag to indicate to the system whether or not items being downloaded must have at least one bid on them. 1 : only get items with bids, 0: doesn't matter.
- Last_regen_date date and time of the last successfully completed regeneration process for this seller.
- In_regen date and time at which the current regeneration process started for this seller. NULL indicates seller is not being regenerated.
- Active flag to indicate to the system whether or not items should be downloaded for this seller.
- Pid process ID number the system assigned to the script that is processing this seller. NULL indicates it is not currently being processed.
- a next database is the Username datbase, containing all the user account information for users of the site. Fields include:
- Name_first first name of the registered user.
- Name_last last name of the registered user.
- Max_cat_items maximum number of items to be downloaded for each category, by the system, for this user.
- Max_srch_items maximum number of items to be downloaded for each stored search query, by the system, for this user.
- Globaljbdghlight list of words that should be highlighted if encountered in an auction title.
- Auto_add_bidder numerical constant specified by the user to tell the system when another bidder should be auto-added to the bidder watch list.
- Auto_add_seller numerical constant specified by the user to tell the system when another seller should be auto-added to the seller watch list.
- Ebay_user_id stores the unique identifier (username) this user uses on other auction sites.
- In_regen stores the date and time at which the current regeneration process started.
- a next database is the Item Cache database. This is a table that stores information about individual auctions that are downloaded as a result of the system browsing categories or running search queries for the user of the site. The contents of this table will change often - nothing is permanently stored. Fields include: [162] Username: unique alphanumeric identifier users of the site use to log in.
- Category_id unique identifier used by an outside auction system to identify a specific category.
- Search_id relates to a stored search query in our database.
- Item_num unique identifier used by an outside auction system to identify a specific auction item.
- Price price of the item up for auction.
- Bids number of bids currently on the item.
- Ends string that describes when the auction ends - can either be a date or a number of days/hours.
- Highlighted flag indicating whether this item should appear as "highlighted" in the result set. 1: highlight, 0: not highlighted.
- a next database is the buyer-seller cache.
- This is a table that stores information about individual auctions that are downloaded as a result of viewing the buying/selling habits of other auction system users. The contents of this table will change often - nothing is permanently stored. Fields include:
- Username unique alphanumeric identifier users of the site use to log in.
- Item_num unique identifier used by an outside auction system to identify a specific auction item.
- Source flag that indicates whether the system entered this auction item or the user did. 1: user, 2: system.
- End string that describes when the auction ends — can either be a date or a number of days/hours.
- End_date the 'end' column converted into a MySQL date type - for better sorting.
- Bids number of bids currently on the item.
- Price price of the item up for auction.
- Seller_user_id the unique identifier the seller of the auction uses on the external auction system.
- Highlighted flag indicating whether this item should appear as "highlighted” in the result set. 1: highlight, 0: not highlighted.
- Hbs acronym for 'highlighted bidder or seller' — will store the unique identifier of the high bidder of the auction or the marked seller.
- Type flag that indicates whether this item belongs to a bidder or a seller on the external auction system. 1: seller, 2: bidder.
- Ebay_user_id the unique identifier the marked bidder or seller uses on the external auction system.
- a next database is a database 29 of items of interest to the bidder 21.
- This is the item archive, a table that stores auction items that have been bid on, sold by, or specifically added by the user of the site. Items in this table are permanent and do not change very frequently. Fields include:
- Item_num unique identifier used by an outside auction system to identify a specific auction item.
- Source flag that indicates whether the system entered this auction item or the user did. 1: user, 2: system.
- End string that describes when the auction ends — can either be a date or a number of days/hours.
- Price price of the item up for auction.
- Seller_user_id the unique identifier the seller of the auction uses on the external auction system.
- Hbs acronym for 'highlighted bidder or seller' — will store the unique identifier of the high bidder of the auction or the marked seller.
- Currencyjype indicates the type of currency the auction is using.
- Date_added date and time at which this item was entered into the system.
- a next database is the call tracking database, which is a table to log each time a call is made to eBay (page download) and what type of call it was. Fields include:
- Username username of the system that was logged in and is responsible for the call being made.
- Call_id number that identifies what type of call was made:
- date_time the date and time at which the call was made to the external auction system.
- Another database is the "other bidders" table, which keeps a running tally of which external auction users have bid on which items in the item_archive. Fields include:
- Item_num unique identifier used by an outside auction system to identify a specific auction item.
- Error_id auto_incremented number assigned by the database every time a new error is logged.
- Date_time date and time at which the error was logged.
- Fig. 6 shows a user interface flowchart for apparatus according to the invention.
- a user login page This leads to a main page from which the user can jump to any of several sub-pages.
- Buttons on the main page include "View Items From Other Bidders” which leads to a page which shows all items from bidders on the 'bidder watch list' in a sorted table.
- the next main-page button is "View Items From Other Sellers” which leads to a page which shows all items from sellers on the 'seller watch list' in a sorted table.
- the next main-page button is "View Search Results” which leads to a page which shows all items downloaded from the stored searches in a sorted table.
- the next main-page button is "Browse Categories” which leads to a page which shows all items downloaded from the categories in a sorted table. (Note that the term “categories” as used here corresponds to the "classifications” discussed above.)
- Binder/Seller Manager which permits the user to add, edit, or remove external auction users from the user's bidder/seller watch lists.
- a "Search Manager” button which permits the user to manage stored search queries that will retrieve auction items.
- a “Category Manager” button which permits the user to manage categories that will retrieve auction items.
- Another button on the main page is "Manage My Items Archive.” This permits the user to view and manage the auction item archive kept by the system. User may also manually add auctions of interest here, though typically items sold by or bid on by the invention user are kept here.
- Yet another part of the user interface is a button permitting the user to configure the number of matches that will trigger adding a competing bidder to one's list of competing bidders, or for adding a seller to a premier seller list.
- PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.
- the language also has a vast array of functions available that are tailored to downloading information in an efficient manner from the Internet.
- the apparatus according to the invention uses PHP not only to display information to the user dynamically through the web interface, but also as the scripting language of choice for gathering data from external auction sources on the Internet.
- PHP is extremely fast and well-integrated to the Apache web server software. This makes for fast and efficient processing of data both inside and outside the current invention system.
- the relational database management system (RDBMS) used in the preferred embodiment of the current invention is MySQL (www.mysql.com). MySQL is a continually-evolving open-source software creation, meaning it benefits from the input of many contributors around the world. MySQL is particularly good at interfacing with the PHP scripting language for the purposes of storing and retrieving small or large amounts of data with relatively good speed and scalability.
- PHP and MySQL being used together for the purposes of the current invention, is the process of storing values such as how many items are listed on a particular external auction service that match a particular search query.
- the apparatus requests, receives, parses, and consequently stores auction data related to a category on the eBay auction system.
- 'browseCategory' is defined for the purpose of downloading and parsing auction data based on a category ID number passed into the function.
- the filters are retrieved from the MySQL database that are associated with this category for the particular user that is currently logged in. The username logged in is globally known because it is part of the session's data.
- each page is fetched via an HTTP call and broken down into its separate tables by a function called page2tables.
- $tmp_tables page2tables($next_link, $indicator, 1, $first_page, $saved_line_ptr);
- Page2tables is passed a string called an 'indicator', which tells the function what text to look for that should indicate that a group of 5-celled item tables are coming soon.
- the string "items found" indicates that the very next table encountered in the HTML will be an item table, so we will capture its data!
- a function called tables2items does this and stores the results in an item_array, which is a multi-dimensional associative array used to stored multiple auction listings and all of the data associated with each auction in an organized fashion.
- #11-22-2002 - &category is showing up in item num, strip it out
- the error message will indicate what line of code the exception occurred, what the session variables were at the time of the error, and what some of the circumstances were, regarding eBay, at the time of the error. All of this information is invaluable when tracking down a bug or when compensating for changes on eBay's end of the operation.
- regeneration refers to the process of the invention making HTTP requests to the external auction service, receiving raw HTML back, parsing the HTML, applying filters and highlights, and saving the auction data in the local database. This process can be scheduled to run at any given interval or can be done upon user login.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/IB2005/050113 WO2006075212A2 (en) | 2005-01-11 | 2005-01-11 | System and apparatus for bidding |
AU2005324768A AU2005324768A1 (en) | 2005-01-11 | 2005-01-11 | System and apparatus for bidding |
CA002594521A CA2594521A1 (en) | 2005-01-11 | 2005-01-11 | System and apparatus for bidding |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/IB2005/050113 WO2006075212A2 (en) | 2005-01-11 | 2005-01-11 | System and apparatus for bidding |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2006075212A2 true WO2006075212A2 (en) | 2006-07-20 |
WO2006075212A3 WO2006075212A3 (en) | 2006-09-08 |
Family
ID=36677989
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2005/050113 WO2006075212A2 (en) | 2005-01-11 | 2005-01-11 | System and apparatus for bidding |
Country Status (3)
Country | Link |
---|---|
AU (1) | AU2005324768A1 (en) |
CA (1) | CA2594521A1 (en) |
WO (1) | WO2006075212A2 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6044363A (en) * | 1996-09-04 | 2000-03-28 | Hitachi, Ltd. | Automatic auction method |
US20020128949A1 (en) * | 2001-03-08 | 2002-09-12 | International Business Machines Corporation | Read-only user access for web based auction |
US20030022867A1 (en) * | 1998-04-27 | 2003-01-30 | Medimmune Oncology, Inc. | Topical administration of amifostine and related compounds |
-
2005
- 2005-01-11 WO PCT/IB2005/050113 patent/WO2006075212A2/en not_active Application Discontinuation
- 2005-01-11 AU AU2005324768A patent/AU2005324768A1/en not_active Abandoned
- 2005-01-11 CA CA002594521A patent/CA2594521A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6044363A (en) * | 1996-09-04 | 2000-03-28 | Hitachi, Ltd. | Automatic auction method |
US20030022867A1 (en) * | 1998-04-27 | 2003-01-30 | Medimmune Oncology, Inc. | Topical administration of amifostine and related compounds |
US20020128949A1 (en) * | 2001-03-08 | 2002-09-12 | International Business Machines Corporation | Read-only user access for web based auction |
Also Published As
Publication number | Publication date |
---|---|
AU2005324768A1 (en) | 2006-07-20 |
CA2594521A1 (en) | 2006-07-20 |
WO2006075212A3 (en) | 2006-09-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9892156B2 (en) | System to generate related search queries | |
US8719176B1 (en) | Social news gathering, prioritizing, tagging, searching and syndication | |
US8712868B2 (en) | Listing recommendation using generation of a user-specific query in a network-based commerce system | |
US20080306853A1 (en) | System and Apparatus for Bidding | |
US8484099B1 (en) | Method, medium, and system for behavior-based recommendations of product upgrades | |
US20070011082A1 (en) | System and Method for Automating Listing and Re-Listing of Auction Items | |
JP5398413B2 (en) | Brand recommendation system and brand recommendation program | |
US10025807B2 (en) | Dynamic data acquisition method and system | |
US20110071917A1 (en) | Suggested item category systems and methods | |
US9449322B2 (en) | Method and system of suggesting information used with items offered for sale in a network-based marketplace | |
US8392290B2 (en) | Seller conversion factor to ranking score for presented item listings | |
WO2011159361A1 (en) | Determining and using search term weightings | |
WO2006013571A9 (en) | System and method for ranking and recommending products or services by parsing natural-language text and converting it into numerical scores | |
US8117060B2 (en) | Geographic demand distribution and forecast | |
US9330071B1 (en) | Tag merging | |
US20150221023A1 (en) | Information providing device, information providing method, information providing program, and computer-readable storage medium storing the program | |
US20140067786A1 (en) | Enhancing product search engine results using user click history | |
US20090319511A1 (en) | Desirability value using sale format related factors | |
US20050182705A1 (en) | System and apparatus for bidding | |
US20110119117A1 (en) | Generation of products in catalogs from divergent listings | |
WO2006075212A2 (en) | System and apparatus for bidding | |
AU2015204354B2 (en) | System to generate related search queries | |
US20200294114A1 (en) | System and method for generating a plurality of product listing pages in an e-commerce platform | |
AU2013203878B2 (en) | System to generate related search queries | |
CN116910129A (en) | Enterprise tag display method and device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2005324768 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2594521 Country of ref document: CA |
|
NENP | Non-entry into the national phase in: |
Ref country code: DE |
|
ENP | Entry into the national phase in: |
Ref document number: 2005324768 Country of ref document: AU Date of ref document: 20050111 Kind code of ref document: A |
|
WWP | Wipo information: published in national office |
Ref document number: 2005324768 Country of ref document: AU |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 05702632 Country of ref document: EP Kind code of ref document: A2 |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 5702632 Country of ref document: EP |