WO2008029089A2 - Appareil et procédé de classement par ordre de priorité de vendeurs dans des marchés électroniques - Google Patents

Appareil et procédé de classement par ordre de priorité de vendeurs dans des marchés électroniques Download PDF

Info

Publication number
WO2008029089A2
WO2008029089A2 PCT/GB2007/003277 GB2007003277W WO2008029089A2 WO 2008029089 A2 WO2008029089 A2 WO 2008029089A2 GB 2007003277 W GB2007003277 W GB 2007003277W WO 2008029089 A2 WO2008029089 A2 WO 2008029089A2
Authority
WO
WIPO (PCT)
Prior art keywords
seller
prioritized
sellers
buyer
purchase
Prior art date
Application number
PCT/GB2007/003277
Other languages
English (en)
Other versions
WO2008029089A3 (fr
Inventor
Nicholas David Wingham Rowan
Original Assignee
Guaranteed Markets Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guaranteed Markets Ltd. filed Critical Guaranteed Markets Ltd.
Publication of WO2008029089A2 publication Critical patent/WO2008029089A2/fr
Publication of WO2008029089A3 publication Critical patent/WO2008029089A3/fr

Links

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

Definitions

  • the present invention relates to electronic markets, particularly those in which there are a plurality of sellers.
  • Examples of said mechanisms include (a) online auctions which are widely used for the offering of goods supplied by various sellers, for example www.eBay.com (b) bulletin boards in which the seller posts a message of their goods or services to be offered and awaits contact from buyers, for example www.craigslist.com (c) Request for Quote services in which a potential buyer displays details of a need and waits for potential sellers to respond, for example www.guru.com (d) online stock trading services, sometimes using a Continuous Double Auction mechanism to establish optimum price between seller and buyer, for example the service offered at www.island.com.
  • None of these widely available mechanisms is particularly suited to transactions involving the short term hire of a person or item, especially if the transaction is required at short notice. Examples of such transactions may include (a) a parent wishing to hire a babysitter from their local community for 2 hours this evening (b) a holidaymaker wanting to hire a surfboard this afternoon from any local resident with a board they were not using (c) a restaurant needing an extra catering assistant to cover today's 90 minute lunchtime rush.
  • Said mechanism for an online market can be characterized by features that may include: (a) sellers categorizing their offering from a list of market sectors (b) sellers inputting a geographic area in which their offering can be made available, typically this may be by selecting a postalcode where the person or item is based and then a radius of travel from that point, up to a possible maximum travel distance for that market sector; for some offerings, including by way of example remote work, the geographic area may be infinite (c) sellers listing the hours, or part thereof, when their offering is available for hire on any given day (d) sellers listing the times when they undertake to be contactable on behalf of buyers (e) sellers listing the terms on which their offering is to be available for purchase, this may be a flat rate per hour or a more complex formula that compensates the seller for travel distance, short notice bookings, short length bookings and other sale parameters.
  • said buyer can immediately be shown sellers who meet the following conditions: (a) currently offering in the Carpet Cleaning Devices sector (b) have indicated availability at the time specified (c) have a contactability record that shows they are accessible to messages in the interval between the present time and the time the device is required (d) are within a pre-determined radius of the buyer's zipcode and willing for the device to be transported to said zipcode. Additionally a price may be displayed based on the seller's terms for each resource offered. Once the purchaser has selected the device, or devices, he wishes to hire, verification, insurance and payment transfer means may be offered. The marketplace can be funded by a mark-up on each transaction that is retained by market operators as payment is then transferred from buyer to seller.
  • the mechanism may include: (a) a record of reliability for sellers and/or buyers, this could simply be a ranking of number of past transactions including a percentage which did not result in payment transfer suggesting the transaction failed because of unreliability by one of the parties (b) output of aggregated data on patterns of demand, supply and pricing for each sector and each locality, this enables buyers to purchase when demand is low and sellers to align their times of offering with peaks in demand (c) a system allowing individual buyers to rank individual sellers with whom they have transacted, said sellers can then be prioritized for future purchases.
  • Said marketplaces can transact any irregular commodity where there is an underlying unit of sale.
  • the time of a resource is the most likely focus.
  • Other resources may be offered based on other units. Examples include: (a) a market for cake making where the unit is pounds or kilograms of the final cake (b) a market for passenger or cargo journeys where the unit is the mile, or part thereof (c) a market in overnight accommodation where a night's stay is the underlying unit that is listed and purchased.
  • the invention can be applied to commodities offered in a variety of units. For simplicity, this document will refer to the markets just characterized as "GEMs markets”.
  • the markets just described are designed for small transactions. By making it very easy to buy, or sell, small allocations, for example hiring an item for two hours rather than purchasing a new item, they encourage fluidity of relationships between buyers and sellers. Thus a householder needing a lawnmower for 90 minutes once every four weeks during the summer months would currently be likely to buy his own mower and keep it unused in his garage when not required. But, with a mature GEMs market available he may choose to either (a) buy a mower and hire it out to a plurality of buyers when he is not using it (b) hire a machine each time it is required from any one of a plurality of sellers. This model works for both parties. Buyers purchase small amounts of resource exactly as required benefiting from dynamic price competition within every transaction. Sellers, having ascertained demand in their locality, can turn an idle resource into a source of revenue; ensuring it is priced for each individual booking so that the parameters of that booking reflect that seller's willingness to fulfil the requirements.
  • some sellers have an added value for an individual buyer.
  • Reasons for this might include: (a) previous interactions; "I favor seller A because he has delivered to my house before and I know he can find his way here" (b) mutual agreements; “I like to rent garden equipment from sellers who buy my services as a car mechanic” (c) ideological alignment; “I would rather buy from sellers who have identified themselves as members of my church” (d) a particular commitment by the seller "I aim to purchase from sellers who have signed the 'tidy neighborhood' charter".
  • the specified seller(s) bring additional value to the transaction in the view of the present buyer. He may be willing to pay more to purchase from these sellers.
  • the present invention recognises the advantages of seller prioritization and, in embodiments, allows a buyer to see all available options for his requirement but has prioritized offerings from sellers according to his personal formulae.
  • PCT/IB02/01475 discloses a means of enhancing said markets by underwriting commitments by provably reliable sellers.
  • PCT/GB2004/004756 covers a means of
  • PCT/GB2004/005126 explains additional technology to resolve problem transactions in such markets.
  • PCT/GB2005/000178 reveals a means to enhance Slivers of Time markets by enabling targeted investment in seller development.
  • PCT/GB05/001148 discloses an apparatus allowing sellers in such a market to input availability to sell conditional on multiple personalised factors.
  • PCT/GB2005/001917 outlines technology for building chains of personalised transactions across a plurality of underlying sectors in said markets.
  • GB0609037.7 discloses a means of resolving problems of instability in early stage GEMs markets.
  • Means of recommending particular purchase options, likely to be of interest to buyers in a marketplace are known. They include collaborative filtering, a mechanism for recommending goods to one buyer because they have been purchased by other buyers whose previous selections resemble his own.
  • AdWords offered at www.google.com rate offerings, in this case advertisements to be displayed, according to the amount paid by the provider.
  • Such offerings are market-wide; the same returns are displayed to any user who inputs the words or phrases bought by the advertiser. Additionally, ranking dependent on payment is unlikely to capture additional value to a specific buyer of seeing listings from a particular seller.
  • US7069097 proposes a method for calculating the scheduling density of any resource owned by the scheduler. Scheduling density can that be relieved by other resources similarly owned. Companies such as Ozgrid (US) with products such as Sl 5 Easy Tasks allow specific blocks of work to be allocated to members of a workforce most efficiently. Time Tracker software from Asgard Systems (US) allows a scheduler to see color-coded displays of her workers assignments hour-by-hour and make changes based on optimal use of available workers.
  • Ozgrid US
  • Sl 5 Easy Tasks allow specific blocks of work to be allocated to members of a workforce most efficiently.
  • Time Tracker software from Asgard Systems (US) allows a scheduler to see color-coded displays of her workers assignments hour-by-hour and make changes based on optimal use of available workers.
  • US6823315 covers a method for dynamically scheduling a workforce based on abilities, workforce preferences and the needs of the scheduler.
  • US6587831 covers the allocation of a geographically diverse pool of workers for maximum efficiency.
  • US6957188 proposes a degree of control for members of a workforce by facilitating swapping of shifts. Means of scheduling a workforce are particularly developed in the call center industry where units of work (the time taken to deal with a call) are short and monitoring of workers is inherent in the technology.
  • US6970829 discloses a means of allocating call center agents between calls so as to utilize their time most effectively. Outside of scheduling a formal workforce, US6985872 details a means of assigning human resources to service tasks.
  • the scheduling organization can not instantly fill its gaps in resource by turning to the external market, doing so requires a different system; for example, a call to a recruitment agency (c) the resources, for instance workers, are reliant on the organization for orders; they are not exposed to a range of buyers which could increase their opportunities (d) changes in the outside market, such as a rise in prices are experienced belatedly; for example as resources leave the organization in search of better rates outside.
  • the additional value of a prioritized provider can be made tangible. But pricing can be related constantly to the wider market; if prices in the wide market rise, so they will for the prioritized resource. For instance, a company purchasing labor in a town may hire a combination of general workers and its own former employees.
  • a transaction management system for managing the purchase of products and/or services by buyers from sellers, the system comprising: a data store for storing: buyer data comprising, for each of a plurality of buyers, a buyer identifier; seller data comprising, for each of a plurality of sellers, a seller identifier and seller offer data indicating at least one product and/or service offered for sale; and prioritized seller data comprising, for each of a plurality of buyers, a seller identifier for each of at least one seller whose product and/or service is to be prioritized for purchase by the buyer; a program store storing processor implementable instructions; and a processor coupled to the data store and to the program store for implementing the stored instructions, wherein the stored instructions comprise instructions for controlling the processor to implement a buyer interface to: receive a purchase inquiry from a buyer, the purchase inquiry comprising purchase criteria for a product and/or service; output seller offer data for a plurality of sellers, the sellers each being able to meet the purchase criteria for the product
  • the invention also provides a method for managing the purchase of products and/or services by buyers from sellers, the method comprising: storing in a data store: buyer data comprising, for each of a plurality of buyers, a buyer identifier; seller data comprising, for each of a plurality of sellers, a seller identifier and seller offer data indicating at least one product and/or service offered for sale; and prioritized seller data comprising, for each of a plurality of buyers, a seller identifier for each of at least one seller whose product and/or service is to be prioritized for purchase by the buyer; implementing a buyer interface to: receive a purchase inquiry from a buyer, the purchase inquiry comprising purchase criteria for a product and/or service; output seller offer data for a plurality of sellers, the sellers each being able to meet the purchase criteria for the product and/or service requirement; and receive a purchase request from the buyer accepting an offer of the product and/or service from one of the sellers, thereby creating a transaction, wherein the seller offer data of prioritized sellers is
  • Embodiments of the present invention provide for a module that sits alongside an underlying electronic marketplace.
  • the module allows a buyer to input requirements for a purchase then have selected sellers prioritized according to his desires, by varying degrees, in the options returned to him. It also allows each seller listed to have an individually constructed price at which that seller will complete each specific requirement for which they are eligible. This allows their personal price to reflect their willingness to fulfill this specific requirement. For example, the requirement might be to purchase a worker for four hours of cleaning work this afternoon.
  • the marketplace might simply return a list of all cleaners whose inputs showed they were: (a) available for those hours (b) could be contacted in time by the system to inform them of the booking (c) had no properties, or preferences input, that ruled them out of the present requirement. Additionally, the marketplace may use pricing data to compute a rate at which each seller, or all sellers, will fulfill the present requirements.
  • Embodiments of the present invention additionally prioritize sellers within the returns who are particularly valued by the buyer.
  • sellers may be: (a) former employees of the buyer now selling their time to a range of buyers in the marketplace (b) inducted individuals who are more useful because they require no acclimatization time at the beginning of a booking (c) part-time flexible employees who are to be purchased in preference to ordinary sellers in the open market.
  • these specific sellers have value to the buyer above sellers who have no relationship with the buyer.
  • Prioritization may take the form of: (a) highlighting the prioritized sellers in the list of returns to the buyer (b) manipulating the order of returns to put the prioritized sellers at the top or where most convenient to view and book for the buyer (c) introducing additional pricing data, possibly to reduce the displayed price of the seller.
  • a prioritized seller will be moved up the rankings by a formula that ensures they are not simply moved straight to the top but move up only relative to their added value to the buyer. It is possible a much cheaper non prioritized seller will be better value.
  • the relative value of a seller to the buyer might be expressed as: average market rate for the present booking + any percentage added value at which the present buyer will pay a premium to purchase from that seller.
  • an offer of prioritization may be subject to a seller committing to certain periods of availability or to specified levels of reliability, that is, to a maximum proportion of failed transactions as a percentage of all transactions.
  • the present invention can include two forms of prioritization of a seller by re-formulating their price for a specific transaction. This is most useful when returns for a purchase request are displayed in price order, possibly with automatic purchasing of the best value returns for a particular requirement.
  • the first form of prioritization is capping. This allows the buyer to say they will purchase a given seller for a particular transaction at a price for that transaction of, for instance, 20% above the average of comparable sellers. Furthermore, the seller's price for the present buyer may be re-calculated so it is just within that figure. This ensures the particular seller will always be best relative value, as defined above, for a buyer. Sellers who agree to be capped in this way may do so in return for a guarantee of some sort. For example an employer making 50 retail workers in one town redundant might guarantee to henceforth: (a) purchase $500 worth of hours of retail workers a week in that area through the marketplace (b) cap the individuals being made redundant at a 25% premium to the open market.
  • the second form of prioritization by price is to create favored units offered by specific sellers. These are units offered by sellers which the buyer will purchase at a premium to rates in the open market but for which the seller is able to set their own pricing parameters with no capping. It is unlikely such sellers, who are free to charge what they want, would be given any guarantee of purchasing by a buyer. In displays of options for purchase to a buyer, the units of favored sellers are ranked as if their price was reduced by a given percentage. Thus a seller whose actual price for a transaction is computed at $10 but has a permitted premium of 10% is ordered in returns as if their price was $9.
  • capped units and favored units can be offered to a seller.
  • a worker can be offered 3 capped hours a week, possibly accompanied by a guarantee of the spending power to be put into the market, plus 8 favored hours.
  • the capped hours will almost certainly be bought, assuming the spending power is commensurate with all such offers to sellers, but at a constrained rate.
  • the favored hours may be bought, at a rate above market average, but the seller has more freedom in pricing although having to remain competitive with the wider market.
  • Prioritization may be set by an individual buyer or she may sign up to prioritization awarded by another body. For instance a website portal set up by an environmental group might allow buyers to purchase in the underlying market with prioritization of sellers deemed environmentally friendly.
  • Fig. 1 shows one embodiment of an underlying marketplace to which the present invention could be attached;
  • Fig. 2 represents key datastores required for both the underlying marketplace and the present invention;
  • Fig. 3 is illustrative of data stored on. each prioritized seller, this data being input through a buyer terminal and stored;
  • Fig. 4 represents a design for processes within the core module of the present invention
  • Figs. 5a and 5b illustrate data output by the present invention to a buyer who has prioritized sellers within the marketplace;
  • Fig. 6 represents processes required for the Buyer's Central Fund embodiment; and Fig. 7 demonstrates a table of calculations pertinent to the Dynamic Calculation of the Permitted Premium embodiment.
  • FIG. 1 shows a generalised embodiment of a system that might underlie the present invention.
  • Such a system would run a number of markets in different sectors, examples of sectors might include: secretarial services, office rental and vehicle hire.
  • a Communications Network 103 is connected to Seller Terminals 101a and b and Buyer Terminals 102a and b and to a System Communications Interface 104.
  • the communications network may comprise any conventional communications network such as a telephone network or the Internet.
  • the communications network couples the buyer and seller terminals to the System Communications Interface 104 to provide user interfaces to the system to allow buyers and sellers to request and execute transactions using the system.
  • the Communications Interface 104 is coupled to a Communications Processor 105 which creates screens and messages for communicating with buyer and seller terminals 102 and 101.
  • the communications processor is connected to an Application Processor 106 for providing transaction management applications.
  • Application Processor 106 is also coupled to a system service provider terminal 108 to allow a system service provider/operator direct access to aspects of the system to which access via Communications Network 101 is restricted for security reasons.
  • Service Provider Terminal 108 may be used for system management, account management, program code updating, setting a mark-up on each transaction within the system for operator revenue purposes and similar functions.
  • Service Provider Terminal 108 may be connected through a wider communications medium such as the Internet.
  • Application Processor 106 is coupled to Data Store 107 storing system-related data. It is also able to communicate with external servers that perform specific additional tasks for the benefit of system users. Thus Application Processor 106 can process data for output to buyer and seller terminals 102 and 101 and Communications Processor 107 can access the data to send and receive messages to and from terminals 102 and 101. Thus data in Data Store 107 is indirectly accessible via buyer and seller terminals 102 and 101.
  • the Communications Interface 104, Communications Processor 105, the Application Processor 106 and the Data Store 107 may all be provided within a single general purpose computer or these functions may be distributed over a plurality of machines in a manner well known to those skilled in the art.
  • the Communications Network 101 in this embodiment is the Internet to which are coupled Buyer Terminals 102a and b and Seller Terminals 101a and b. Also coupled to Internet 101 is a gateway (not shown) to a mobile phone network 109 (or, more generally, any mobile communications network) which communicates with a Mobile Station 111, such as a phone handset, using base transceiver station 110.
  • a mobile phone network 109 or, more generally, any mobile communications network
  • Mobile Station 111 such as a phone handset, using base transceiver station 110.
  • Registered Sellers Datastore 202 records all sellers who are registered to use the underlying marketplace, in each case the record includes a unique identifier code.
  • Registered Buyers Datastore 204 lists all buyers permitted to purchase sellers in the underlying marketplace including, in each case, a unique identifying code.
  • Sellers' Terms Datastore 206 holds all details about the terms on which each seller will be offered to buyers. Such data may include (a) times of availability when their resource is in the market and may be purchased (b) times when the seller undertakes to be available to be contacted about prospective purchases (c) possibly, pricing rules allowing the underlying marketplace to construct a rate for any potential purchases for which the seller is available and can be contacted in time.
  • Datastore 208 registers all purchases of sellers' resources by a buyer, such capture possibly including (a) times/dates for which resource was booked (b) identity of buyer and identify of seller (c) the price paid
  • Prioritized Relationships Datastore 210 lists all registered sellers who have been prioritized by one or more buyers. That is a buyer has input terms on which he will purchase that seller at a rate based on the price at which sellers in the open market will fulfill his requirement. However, the rate for the prioritized seller may be above that of the sellers in the wider market.
  • the data stored from each buyer input about a seller is illustrated, with example inputs for ease of description only, in Fig. 3 and will now be described.
  • Line 302 lists the seller's unique identifier, that is the code by which they can be identified in Registered Sellers Datastore 202. The buyer will probably input this as a name of an individual.
  • 304 allows the buyer to identify a date, at midnight on which the commitment to this seller ends.
  • 306 is a record of the timeperiod over which the commitment is to be measured. For example: X hours to be capped every 7 days or X units to be favored over 28 days.
  • Line 308 records the number of capped units to be purchased in the given time period. For example, the number of hours every week at which the worker will have their price for a period of work fixed at 20% above the averaged price of all comparable sellers.
  • Line 310 registers the percentage above or below the averaged market rate at which the seller price will be capped.
  • Line 312 records the number of units for which the buyer will allow the seller to be bought at a rate above the average market price for comparable sellers for any given transaction. However, the system will not cap the individual's price. In the example shown in Fig. 3, a buyer is committing to purchase a worker for 10 hours a week if his rate is up to 10% above the average price of comparable sellers for his specific needs. Line 314 stores the precise percentage that is acceptable to the buyer.
  • Section 316 stores any conditions the buyer requires the seller to abide by if the buyer's commitment is to remain in force during any given time period.
  • Line 316a might stipulate that the seller's record in Sellers' Terms Datastore 206 feature a minimum availability for the resource being offered.
  • the commitment to buy a worker's hours at above the market average are dependant on her listing at least 30 hours of availability for work in the 7 days preceding any potential
  • Line 316b stores any targets for periods of contactability which must be input by the seller, and stored in Sellers' Terms Datastore 206, for the commitment to be activated. Finally, the buyer may choose to waive his commitment to purchase at favorable rates if the seller is unreliable in fulfilling transactions for either the present purchaser or the market as a whole. Such failed transactions are stored in Transaction History Datastore 208. Thus, line 316c can store a tolerance for non-completed transactions which, if exceeded by the present seller, nullifies the commitment made to that seller. Line 316d allows the buyer to select whether the formula for failed transactions applies only to his organization, or to all purchases by buyers in the market.
  • the later setting may be useful in assuring other buyers that sellers offering resources primarily to the present buyer are incentivized to be reliable for the market as a whole.
  • the conditions may include a requirement that the seller's base postalcode, that is the zipcode from which they undertake to travel to bookings, is within a given radius of the buyer's place of work, or other designated area.
  • Buyer Rules Datastore 212 lists any templates or defaults for each buyer who is using the present module. It also stores each buyer's rule for calculating the price point.
  • the price point for each transaction could be the mean rate for the cheapest X comparable sellers.
  • the price point could be the rate for that transaction of the cheapest seller in the whole market who has attained the same grade, or above, as the prioritized seller.
  • Another buyer may wish to amortize rates and avoid the impact of one improbably cheap seller. He may decide to average the five cheapest sellers of the same grade, or above, for a particular seller in a particular transaction. This creates a more representative calculation of the price point in the open market.
  • Prioritization Reporting Datastore 214 stores data about the activities of the present module on behalf of each buyer. For each transaction in which the present invention is activated this includes: (a) price points computed from the underlying data (b) any purchases made of capped units (c) any purchases made of favored units (d) the original seller price in each case.
  • the present invention is triggered by the receipt of a purchase request within Application Processor 106, that meets certain requirements. This will be explained with reference to Fig. 4.
  • Modules UM02 to UM08 are part of the underlying market.
  • UM02 receives a purchase request from a registered buyer.
  • UM04 searches Sellers' Terms Datastore 206 to find the sellers who are: (a) available (b) can be contacted in time about this requirement (c) not to be excluded from this transaction because of any properties or inputs about their preferences, for example an unwillingness ' to fulfill bookings with less than 4 hours notice.
  • Module UM04 may also use pricing data to construct a rate for this specific requirement for each seller, or all sellers. Assuming the absence of the present invention, UM06 then orders the sellers returned, this may be by price but could also include other parameters such as the seller's grade in the market. Finally, UM08 displays the qualified sellers to the buyer and invites him to choose which he wishes to purchase.
  • the present invention interfaces with the underlying marketplace between UM04 and UM06.
  • Step 402 is inserted. This reads the present transaction data to check if it meets two conditions: (a) the purchase request was received from a buyer who has entered at least one record of a seller whom he chooses to prioritize into Prioritized Relationships Datastore 210 (b) the data produced by UM04 includes at least one seller who has been prioritized by the present buyer and is eligible for prioritization. Eligibility for prioritization within the current transaction requires that the seller: (i) has capped or favored units still un-purchased within their allocation within the specified time frame (ii) has complied with any conditions set down by the buyer as illustrated in Fig. 3.
  • Prioritized Relationships Datastore 210 Data on allocations and conditions is stored in Prioritized Relationships Datastore 210. Data enabling a check on compliance with conditions is stored in Sellers' Terms Datastore 206 for availability and contactability, or in Transaction History Datastore 208 for records of successful transactions and failed transactions. Data on the number of units purchased when capped or favored over any given period is stored in Prioritization Reporting Datastore 214. If these conditions are not met the present invention is not activated. Core module of the present invention
  • the core module will now be described, again with reference to Fig. 4. If the module is triggered, at step 404, the returns generated by UM04 are checked to see if there are any units in the returns which have been designated by the present buyer as capped. That requires that two conditions are met: (a) the seller has been allocated a number of capped units in a given tune frame (b) the allocation has not been currently met within the timeframe. Thus a seller who has been allocated 10 capped hours in any 7 day period but has only had 4 purchased in the last 7 days has 6 capped hours available for the present transaction. If there are no capped hours in the transaction, the module moves to step 414.
  • the module computes a price point from the returns calculated by UM04. This is the base figure it will use in calculating acceptable pricing for prioritized sellers.
  • the present buyer's rules for computing a price point are read from Prioritized Relationships Datastore 210. They may simply be the price of the cheapest qualified seller. Alternately they may require averaging a given number of the cheapest sellers, or all sellers, to produce a more representative figure. Additionally, the sellers may be categorized, for example by the grade they have attained in the market. In this case a pricing point for each grade may need to be produced. Price point data is stored in Prioritization Reporting Datastore 214.
  • the first such seller's data is selected.
  • This data produced within UM04, will include the price at which this seller's resource can be purchased for the current purchase requirements.
  • this is used to compute the new price which factors in the value of the seller to the buyer.
  • This price is then stored ready for assembly of options at step 422.
  • the process for computation is as follows: (a) read Prioritized Relationships Datastore 210 to find the permitted premium for this seller (b) read appropriate price point data in Prioritization Reporting Datastore 214 (c) calculate maximum price allowable which is the appropriate price point plus percentage premium (d) is this above or below the actual price computed for the seller's units by UM04? (e) if above, store the price computed by UM04 for the capped units (f) if below, store the price computed at step c for the capped units. This price data is stored temporarily.
  • Step 412 checks if there are further sellers with capped units who have not been through this process. Once the list is exhausted step 414 checks if there are sellers with favored units within the current transaction. Note: a seller may have both capped and favored units within the same transaction. But capped units take priority over favored units. For example: suppose the booking requirement is for 16 hours of work; a seller has 3 capped hours and 5 favored hours outstanding. Within that transaction they could have 3 hours to be priced under their capping rules, 5 hours to be priced under their favoring rules and 8 hours which were priced purely by UM04.
  • step 414 If there are favored units within the transaction, at step 414, the first seller with such units is identified and, at step 416, their effective price is computed.
  • the process for calculating effective price is as follows: (a) read Prioritized Relationships Datastore 210 to find the permitted percentage premium on favored units for this seller (b) reduce the seller's rate as computed by UM04 by that rate (c) store that rate for ordering purposes. Step 420 checks if there are further favored units to be re-priced. Once there is not, the re-priced options for the buyer are assembled at step 422.
  • the display to the buyer may identify sellers by number of capped and favored hours included in the potential purchase. Additionally, in the case of favored units being offered, the display may include in brackets the actual price that will be paid by the buyer rather than the price determining the ranking of that seller by value.
  • a buyer is offered a screen of returns by UM08 he can choose to purchase as many options as he wishes.
  • additional data is recorded within Prioritization Reporting Datastore 214 once the buyer commits to the transaction. This recording allows the module to report to the buyer by outputting data as shown in Fig. 5a regarding each individual seller or in Fig. 5b regarding all prioritized sellers.
  • Each diagram is shown with illustrative examples of outputs.
  • the module may advise the buyer on how much he would have needed to spend to have purchased further available capped or favored units from his prioritized sellers.
  • Prioritized units reflect the long term value of seller relationships for an organization, but as the invention has previously been described additional costs are borne by budget holders within the organization who are making day to day purchases. Expecting their budgets to bear this cost may lead to unauthorized purchasing of non-prioritized, but cheaper, sellers. There therefore exists a need for a central fund to cover the additional costs. Thus a company may set aside, for example, $1,000 a month to pay the difference in price between the open market price points and purchases from prioritized sellers. A process for this is illustrated in Fig. 6 and will now be explained.
  • Core to the embodiment is process 610, a fund administrator that is able to: (a) receive cash, or permission to allocate money, in ways that are known in the art using buyer terminal 102 (b) move cash in and out of cash store database 612 (c) allocate cash to purchases of prioritized units stored in Prioritization Reporting Datastore 214 (d) record the current available cash in cash store database 612, that balance being recalculated as funds are received or monies committed to transactions (e) receive billing data from the underlying marketplace and transfer cash, or entitlement to cash, as required to make up the difference between prices computed by UM04 and prices paid to prioritized sellers.
  • a fund administrator that is able to: (a) receive cash, or permission to allocate money, in ways that are known in the art using buyer terminal 102 (b) move cash in and out of cash store database 612 (c) allocate cash to purchases of prioritized units stored in Prioritization Reporting Datastore 214 (d) record the current available cash in cash store database 612, that balance being recalculated as funds
  • UMlO is a process in the sample underlying marketplace whereby a buyer has received details of potential sellers and confirmed his intention to purchase one or more of them. This is stored in Transaction History Datastore 208.
  • the present embodiment calls for an additional module which includes the buyer reporting functionality outlined earlier in this document.
  • each individual purchase of a seller by the buyer within the received purchase confirmation is examined to see if there was prioritization of the seller's units within the transaction. If not, the module moves to the next unprocessed purchase.
  • step 606 which stores the details in Prioritization Reporting Datastore 214.
  • the fund administrator process then allocates funds to the purchase to make up the difference between the transaction price point (or the seller charge as calculated by UM04) and the payment due to the seller.
  • step 402 in Fig. 4 may include as a criteria of prioritization that there are funds above a certain limit available in cash store 612. If there are not, prioritization may not be implemented because there are no funds available to meet the additional cost.
  • a buyer does not want to set up a centralized fund to pay for the long term benefits of hiring sellers which the organization is committed to support. Instead, the buyer may wish to establish a fund that takes in money by: (a) tithing purchases of sellers in the open market for example by adding an extra 10% to the price of each unit (b) depositing that cash, paid by budget holders within the buyer organization, within cash store 612 in Fig. 6. Those injections of cash then replace, or can be combined with, the inputs of cash through buyer terminal 102 as described in the embodiment above.
  • Dynamic calculation of the permitted premium embodiment The present invention could be supplemented to increase the likelihood of capped and favored units being purchased from as wide a number of sellers within each time period. For instance, a company buying around 500 hours from the local workforce each week with 200 capped units from 75 sellers included, may want to ensure as many as possible of the 75 get at least some of their capped hours purchased. This can be made more likely if the permitted premium is weighted according to unsold capped or favored hours remaining. This will now be disclosed with reference to the table in Fig. 7 which shows sample calculations.
  • the table shows 6 sellers, each with eligible favored hours over a 7 day period for the buyer in a particular transaction.
  • Line 702 shows, by way of illustration, that each has had a rate of $10 per hour computed by step UM04 in Fig. 4.
  • Line 704 shows the maximum favored units to be bought within a 7 day period and line 706 the number that have actually been purchased by the present buyer.
  • Row 708 calculates the percentage of the maximum hours (the target) remaining unsold to this buyer.
  • Row 710 shows that, in this example, each seller has a permitted premium of 10%.
  • Line 712 multiplies rows 710 and 708 in each case to arrive at a weighting for that particular seller based on how many target hours they have yet to sell to this buyer.
  • line 714 shows the seller charge used for ordering purposes.
  • the invention as currently described implements caps on a unit price if it exceeds the buyer's tolerance to pay above the market rate for a prioritized seller.
  • the system may calculate the allowable capped rate, which is the price point for that transaction plus the permitted premium, and pay that even if it is higher than the rate at which the seller is prepared to fulfill the purchase request. Thus the seller is guaranteed a premium over the open market.
  • a buyer may choose to automate the decision about whether or not to prioritize a particular seller.
  • This module might invite inputs that trigger automatic creation of data of the type illustrated in Fig. 3 and the entry of that data into Prioritized Relationships Datastore 210.
  • Such grounds for prioritization might include: (a) the existence of the seller as a buyer of the present buyer's services when she acts in seller mode, thus an individual could decide to have anyone to whom they sold services prioritized as a seller, thus encouraging the formation of "trading circles” where traders repeatedly buy and sell different services from each other (b) a qualifying threshold of past trades, for example "favor at a 5% premium anyone who has worked for me 3 times in the past, at a 10% premium if they have completed 8 or more bookings and a 15% premium if they have done 20 or more bookings for me" (c) sellers who are prioritized but were not purchased last week (or other defined period) may have their permitted premium automatically raised this week (d) a self-selected criteria of the seller that is stored in Registered Sellers Datastore 202 or Sellers' Terms Datastore 206, for example that they are a vegetarian or a Medical (e) some other metric about the seller has been attained, for example they have been awarded a certain number of stars by the buyer using a
  • Further formulae could involve dynamic awarding and removal of prioritized status based on seller behavior. This requires the creating of parameters within which the data of the type illustrated in Fig. 3 is constantly re-calculated and re-entered. For example: a seller is given favored status for 20% of their total availability in the market as entered over the last 7 days. Alternately, sellers could input data that is used to calculate prioritization within a transaction. For instance, the selection of one seller by a buyer might trigger prioritization of others. Thus, a buyer seeking a group of workers to paint a house might first select a supervisor. This person has already entered a list of sellers whom he likes to have working for him.
  • prioritization criteria could change as the wider market evolves. When there are few sellers in the wider market, and little availability, prioritization might rise so the buyer increases the premium for his prioritized pool. This requires a formula such as, by way of example, "I require 1,000 hours of cleaning worker availability within 5 miles of my plant every week, for every 50 hours this falls below 1,000 increase my premium for prioritized sellers by 1%, for every 50 hours over 1,000 hours reduce it by 1%". Such formula would be input through buyer terminal 102 and refresh the appropriate data held in Prioritized Relationships Datastore 210. Likewise, prioritization data could change as the number of prioritized hours rises or falls. A buyer may choose to increase the permitted premium if there is below average prioritized hours on offer in a given time frame. This will make it more likely that what units there are from prioritized sellers will be bought.
  • Prioritization data could change based on the buyer's attainment of his targets. Thus, as he gets closer to meeting his target for prioritized units purchased the rate for further prioritized units is set to either rise or fall. This requires a link between Prioritization Reporting Datastore 214 and Prioritized Relationships Datastore 210.
  • a buyer may stipulate: "as 90% of my target prioritized units are purchased in any given week reduce all my permitted premiums by 10%". This would make it more likely that the 100% target would be achieved. Alternately he may wish to raise the premium on the basis that with so many prioritized hours bought he was more amenable to buying units from non-prioritized sellers.
  • prioritization data could change based on specific needs of the buyer concerned.
  • she might wish to change her permitted premiums by a fixed percentage across the board, thus making it more likely she would have desired workers in place. If this scaling up was a regular occurrence as a result of predictions by enterprise management software she may wish to have that software linked to Prioritized Relationships Datastore 210 so data can be changed constantly in line with expectations of need.
  • Hours specific embodiment Sellers could be prioritized for certain hours of the day only. Particularly those for which the buyer had most need of the resource. A match between the hours input through the data illustrated in Fig. 3 and the times of booking registered in step UM02 in Fig. 4 would then become a criteria for acceptance at step 402 in Fig. 4.
  • a number of alternative embodiments of the present invention will be immediately apparent to those skilled in the art. They include: (a) a version without pricing data where sellers for a requirement are ordered by percentage ranking which factors in their prioritization (b) a non-monetary version where there is no sale but providers of a need, for example tennis partners, are ranked (c) a version in which certain sellers are procured at a fixed rate and ordered within returns including floating rate sellers (d) using display options to signify prioritized sellers in a list of returns, for example highlighting those that are prioritized or coloring those that aren't in gray (e) the permitted premium could be a negative figure so that, for example, a particular seller was capped at 10% below, rather than above, the price point for that transaction. All such embodiments are herein included in the scope of the invention.
  • PCT/GB2005/000178 includes disclosure of a mechanism to identify, and nullify for reporting purposes, frivolous availability input by a seller. That is, availability entered to give the appearance of complying with conditions demanded by a third party but contrived so it is unlikely to be purchased.
  • the present invention may benefit from the same mechanism to enforce compliance with conditions laid down by a buyer who prioritizes a seller.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système de gestion de transactions permettant de gérer l'achat de produits et/ou de services par des acheteurs à des vendeurs. Le système comprend un dispositif de stockage de données destiné à stocker des données d'acheteur comprenant, pour chacun de la pluralité d'acheteurs, un identifiant d'acheteur, des données de vendeur comprenant, pour chacun de la pluralité de vendeurs, un identifiant de vendeur et des données d'offre de vendeur indiquant au moins un produit et/ou un service mis à la vente, et des données de vendeur prioritaire comprenant, pour chacun de la pluralité d'acheteurs, un identifiant de vendeur pour chacun d'au moins un vendeur dont le produit et/ou le service est prioritaire à l'achat par l'acheteur. Le système comprend également un dispositif de stockage de programme destiné à stocker des instructions mises en oeuvre par un processeur et un processeur couplé au dispositif de stockage de données et au dispositif de stockage de programme pour mettre en oeuvre les instructions stockées. Les instructions stockées comprennent des instructions de commande du processeur pour la mise en oeuvre d'une interface d'acheteur pour recevoir une requête d'achat d'un acheteur, la requête d'achat comprenant des critères d'achat pour un produit et/ou un service, pour générer des données d'offre de vendeur pour une pluralité de vendeurs, les vendeurs pouvant chacun remplir les critères d'achat correspondant aux exigences du produit et/ou du service, et pour recevoir une demande d'achat de l'acheteur acceptant une offre pour le produit et/ou le service d'un des acheteurs, créant ainsi une transaction. Les instructions stockées comprennent également des instructions de commande du processeur pour la modification des données d'offre de vendeur des vendeurs prioritaires, afin de donner priorité au produit et/ou au service d'au moins un vendeur prioritaire.
PCT/GB2007/003277 2006-09-06 2007-08-30 Appareil et procédé de classement par ordre de priorité de vendeurs dans des marchés électroniques WO2008029089A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0617454.4 2006-09-06
GB0617454A GB0617454D0 (en) 2006-09-06 2006-09-06 Apparatus & method for prioritising sellers in electronic markets

Publications (2)

Publication Number Publication Date
WO2008029089A2 true WO2008029089A2 (fr) 2008-03-13
WO2008029089A3 WO2008029089A3 (fr) 2008-05-15

Family

ID=37232385

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2007/003277 WO2008029089A2 (fr) 2006-09-06 2007-08-30 Appareil et procédé de classement par ordre de priorité de vendeurs dans des marchés électroniques

Country Status (2)

Country Link
GB (1) GB0617454D0 (fr)
WO (1) WO2008029089A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108604319A (zh) * 2016-02-05 2018-09-28 电子湾有限公司 混合电子库存
CN116823354A (zh) * 2023-06-08 2023-09-29 湖南华创科技发展有限公司 基于大数据的门店营销推送方法、装置及存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110414764A (zh) * 2019-05-10 2019-11-05 西安理工大学 基于多代理系统的微电网群能量博弈调度方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5396264A (en) * 1994-01-03 1995-03-07 Motorola, Inc. Automatic menu item sequencing method
EP0817042A2 (fr) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Système multiprocesseur avec dispositif pour optimiser des opérations spin-lock
EP1693795A2 (fr) * 1994-09-16 2006-08-23 PayPal, Inc. Système de paiement assisté par ordinateur des achats de produits d'information par transfert électronique sur Internet

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5396264A (en) * 1994-01-03 1995-03-07 Motorola, Inc. Automatic menu item sequencing method
EP1693795A2 (fr) * 1994-09-16 2006-08-23 PayPal, Inc. Système de paiement assisté par ordinateur des achats de produits d'information par transfert électronique sur Internet
EP0817042A2 (fr) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Système multiprocesseur avec dispositif pour optimiser des opérations spin-lock

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
COX B T H: "Maintaining Privacy In Electronic Transactions" THESIS, XX, XX, August 1994 (1994-08), pages 1-26, XP002403147 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108604319A (zh) * 2016-02-05 2018-09-28 电子湾有限公司 混合电子库存
CN108604319B (zh) * 2016-02-05 2024-03-19 斯达哈伯公司 混合电子库存
CN116823354A (zh) * 2023-06-08 2023-09-29 湖南华创科技发展有限公司 基于大数据的门店营销推送方法、装置及存储介质
CN116823354B (zh) * 2023-06-08 2024-05-31 湖南华创科技发展有限公司 基于大数据的门店营销推送方法、装置及存储介质

Also Published As

Publication number Publication date
WO2008029089A3 (fr) 2008-05-15
GB0617454D0 (en) 2006-10-18

Similar Documents

Publication Publication Date Title
US11900442B1 (en) System and method for identifying and co-ordinating an alternate delivery of one or more selected items
US20070192229A1 (en) Transaction management system and method
US8326676B2 (en) Systems and methods relating to a lead distribution engine that uses margin scores
KR100438307B1 (ko) 주식시세정보 제공시스템과 방법 및 그 방법에 관한컴퓨터 프로그램소스를 저장한 기록매체
US8255270B2 (en) Systems and methods relating to a lead distribution engine that accommodates internal and imported destination relationships
US20140229258A1 (en) Systems and methods enabling transportation service providers to competitively bid in response to customer requests
US8352306B2 (en) Systems and methods relating to a lead distribution engine with quality assessment of lead sources
US7424449B2 (en) Computer-implemented method to provide options on products to enhance customer experience
US8321256B2 (en) Systems and methods relating to an opportunity distribution engine and distribution simulation
US20150310468A1 (en) Flexible ship schedules and dynamic discounts
US20070130044A1 (en) Transaction management system and method
US20070112671A1 (en) Transaction management system and method
US20100017273A1 (en) Method Apparatus, and System for Grouping Transportation Services
US20100042456A1 (en) Integrated market-based allocation of resources within an enterprise
US20110246274A1 (en) Flexible ship schedules and demand aggregation
US20110246271A1 (en) Flexible ship schedules and demand aggregation
US20090222384A1 (en) Apparatus and method for intervention in electronic markets
US20090204547A1 (en) Transaction management system and method
US20130006805A1 (en) Online Marketplace for Collective Buying
US20140108183A1 (en) Task Exchange
US20150074000A1 (en) System, method, and computer program for negotiating online transactions
WO2008029089A2 (fr) Appareil et procédé de classement par ordre de priorité de vendeurs dans des marchés électroniques
WO2008093038A1 (fr) Appareil et procédé pour une gestion d'ensembles de vendeurs classés pour les besoins d'un acheteur individuel dans une place de marché en ligne

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07804086

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07804086

Country of ref document: EP

Kind code of ref document: A2