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
• • 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
• • 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/0601—Electronic shopping [e-shopping]
  • G06Q30/0623—Item investigation
• • 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
  • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

• This invention relates in general to digital processing and more specifically to a digital processing system for matching desired characteristics with item attributes.
• Matching engines One important use of electronic digital processing systems, such as computers, is to identify an item or object that is a "best match" with specified characteristics. Systems that perform such a matching function based on one or more criteria to identify a desired choice, or choices, are called “matching engines.”
• An example of a matching engine is a general database query engine.
• A, simple database query engine allows a user to specify one or more keywords and identifies documents containing the keywords.
• a best match is often identified by the number of times the keywords appear in a document, the proximity of keywords to each other within a document, the placement of the keywords in different sections of a document (e.g., a title), etc.
• Each document may be assigned a "score" or match value.
• a higher score can mean that the document is a better match to the query.
• a list of documents can be displayed where earlier-listed documents have higher scores than later-listed documents so that the list is prioritized, making it easier for the user to identify a desired document.
• An example of an online market is an online auto dealership where a user is asked to specify a car to be purchased. For example, a user can enter characteristics for a desired car such as the type of car, color and age of the car. A user can specify the characteristics as a "new, silver sport utility vehicle.” The matching engine will use the three desired characteristics of "new,” “silver” and “sport utility vehicle” to compare against the attributes of item entries in a database. Only those entries that include attributes matching the specified characteristics will be returned.
• the prior art matching process is not without shortcomings.
• the number and type of characteristics that can be entered by a user are typically defined by an administrator, or operator, of the site hosting the ecommerce engine, or marketplace.
• the user is often constrained to using all of the predefined characteristics.
• Another contraint is that only the predefined characteristics may be used. That is, the user can't specify any other characteristics other than those that the administrator has provided. This means that characteristics that are important to a buyer, such as airbags for example, may never enter into the matching process. Also, characteristics that are not important to a buyer may be required by the matching engine and might be used to eliminate items in which the buyer is actually interested.
• a second problem is that the prior art matching process is a one-to-one correspondence matching.
• the matching engine does not take into account that other colors, or even other characteristics, of the car items may be satisfactory to a buyer. This drastically limits the number of suitable matches that will be identified and presented to buyers and, hence, reduces the number of sales and amount of revenue for the participants (i.e., buyers, sellers and administrating entity) of the online marketplace.
• a company has a catalog of goods having different attributes. Even companies with small catalogs (hundreds of items) can experience problems with prior art matching engines. For instance, a company may have approximately 400 types of shoes available on a website. Based on descriptions of the shoes, there may be 9 to 10 different attributes of shoes that customers care about. These attributes can include shoe style, usage (running, basketball, cross-training, etc.), price, etc. If buyers are asked to specify each of the 9 attributes as a characteristic where each characteristic has 3 choices this results in a database filter of approximately 20,000 possible combinations. Each shoe type has one set of attributes. In this case, there are 20,000 possible 'categories' but only 400 shoes. This implies that 19,600 categories are empty. With this matching engine approach there is a 98% chance that the search result will create no matches.
• the present invention is a computer-based system for matching desired characteristics with item attributes.
• the system provides for weighting of variable values to be matched, and substitution of variables or values. Both discrete and continuous weighting can be used. This approach provides for more flexible matching to yield practical and useful results without placing high requirements on the computer system.
• Weights can be assigned to variable values as defaults. Such assignment is usually performed by a system administrator, or the assignment can be calculated by a process in the matching engine (e.g., as a discrete or continuous function) or otherwise automatically derived. Weights can be selected by users (both buyers and sellers) by using a user interface that translates common expressions (e.g., "not required,” “desired,” “required”) into weighting values between 0 and 1. Alternatively, users can assign weights as a number, or by other means.
• preferences i.e., characteristics and attributes
• buyer and seller preferences can be taken into account in creating a match.
• This allows sellers to eliminate items or services from a particular transaction based on seller goals of profitability, or where it makes a difference as to who the buyer is, or what is being offered in exchange for an item or service for sale.
• the "seller" is an employer who may require prospective candidates to have a minimum number of years of education.
• the matching engine can be applied to many types of applications.
• One envisioned application is to run an electronic marketplace such as an online store, auction, reverse auction, job placement center, etc.
• the invention provides a method for matching user preferences with item characteristics in an electronic database wherein items are stored in a database along with associated attributes and values, the method comprising accepting signals from the user input device to allow a user to specify preferences in the form of attributes and values; using the processor to identify one or more matches by using a weighted comparison among at least one value in the preferences and at least one value in the database.
• the invention provides a method for matching user preferences with item characteristics in an electronic database, wherein items are stored in a database along with associated attributes and values, the database coupled to a processor and user input device, the method comprising accepting signals from the user input device to allow a user to specify preferences in the form of attributes and values; and using the processor to identify one or more matches after performing a step of substituting one or more attributes in the preferences.
• Fig. 1 illustrates a preferred embodiment system including the matching engine of the present invention.
• the matching engine of the present invention can be applied to many applications where desired characteristics are used to determine best matches of items that are described using item attributes.
• a preferred embodiment of the invention creates and runs different types of online markets, such as an auction, reverse auction, exchange, etc.
• the preferred embodiment is incorporated into a suite of software products to be manufactured and distributed by Liquid Engines, Inc.
• the suite of software is referred to as IXE2000 and is further described in the related patent applications, cited above.
• Fig. 1 illustrates a preferred embodiment system of which the present invention is a part.
• company 102 uses "configurator" software 104 to create an ecommerce engine 106.
• Ecommerce engine 106 is used to conduct electronic commerce in specific goods and/or services and in one or more market types.
• Ecommerce engine 106 includes methods and processing described herein for the matching engine.
• Configurator software 104 includes an administrator interface and market behavior data. An administrator is a human operator who operates configurator software 104 and causes User Interface
• Generator software 108 to create user interfaces for buyers and sellers in different markets as shown by user interfaces 110, 112 and 114.
• data is collected into databases 120 and 122 for further use by the system.
• the data is accessed by ecommerce engine 106 for purposes of matching goods and services to buyers.
• Data such as transaction data is used in analysis, pricing and creating a stable market. In some situations, there are too few traders to create stable prices in a given market. The situation is highly volatile because any one buyer or seller can have a large effect on the equilibrium price. This causes problems since traders will wait until a favorable time to trade and may even refuse to trade at a price that they previously stated would be acceptable. The situation arises most in new markets, where the case of a few traders is more common.
• the "ramp up” module uses a statistical approach to estimate the equilibrium price and to smooth out day-to-day variations that are not meaningful. Past data can be used to complement the limited information available as they are ramping up so that the resulting matching and pricing information is meaningful and representative of the real word market.
• Market behavior and user profiles are used by the User Interface generator to create dynamic user interface screens that are personalized to the specific exchange as well as the particular user that logs in.
• Intelligence algorithms work in conjunction with the ecommerce engine, the various databases, and the configurator to recommend profitable, or desirable, markets to the administrator.
• the administrator can further model and analyze different potential markets, and can create and operate additional markets, as desired.
• a preferred embodiment of the invention uses an Oracle database, XML (Extensible Markup Language), Hyper Text Markup Language (HTML) and Microsoft Active Server Page (ASP) language, tools and applications to provide a system which executes on computers connected to the Internet.
• XML Extensible Markup Language
• HTML Hyper Text Markup Language
• ASP Microsoft Active Server Page
• Any type of data communication can be used such as an intranet, local-area-network, point-to- point communications, etc.
• the processing and interfaces of the invention can operate on any digital processing platform such as desktop computers, servers, laptop or handheld computers or processors, etc.
• the matching engine described herein is used as part of ecommerce engine 106 of Fig. 1.
• the engine is a completely flexible, fully configurable piece of software that can run virtually any kind of market. All parameters can be set by the market administrator and modified at any time.
• the configurator allows the market administrator to set up the market in a short period of time without any technical expertise.
• the user interfaces generated by the configurator enable users to access the market by answering simple questions.
• the engine has default settings, but is completely customizable.
• the matching engine allows for substitution of characteristics. A number of attributes are defined and each attribute is then described and valued, or "weighted," by a buyer, seller, or both. For example, an employer can specify that a desired characteristic of a recruit be that the recruit have a college degree.
• the employer is asked, by the interface, to specify how important the degree requirement is ranging from "essential” to "irrelevant.”
• the language and manner used to specify the weighting can vary and is typically set by the administrator.
• the engine is able to generate matches with potential employees and arrive at a total score which is a function of all desired characteristics and weighting levels.
• weights can also be applied to item attributes. For example, a recruit can specify that a geographic location of San Francisco is an attribute of the recruit, but the weighting can be at 50% which can mean that a San Francisco location is "fairly” desirable as opposed to being a "mandatory" requirement.
• weighting values and schemes can be set by an administrator or computed or assigned by the engine, itself. For example, a default weighting can automatically be assigned to attributes such as salary, or location. A function can be used to assign a weight to an attribute based on almost any type of criteria. An example is increasing the weighting of a salary attribute in relationship to a prospective employee's geographic proximity to a job's location that is specified as a desired characteristic. Note that by using the matching engine of the present invention, both sides'
• Matching in the present invention can be continuous in addition to being graduated, or "binary" (i.e., a match or no match). To use the above example, most cars neither match a buyer's desires perfectly nor not at all. Each potential buyer/seller match is valued. That match value becomes the basis on which all markets are run and all matches are made. There is no limit to the number or types of attributes that can be used. The function allows for any finite number of characteristics. The probability of a match is not reduced by specifying more categories as would be the case in a prior art discrete matching approach.
• An example of an ecommerce market uses a matching of prospective car buyers' desired characteristics with dealers' car attributes stored in a database.
• An administrator designs a buyer interface that allows a buyer to define characteristics of color, type, age and other features of a desired car.
• the characteristics can be input in a variety of ways. In a simplest format, the buyer merely answers "yes” or “no” to questions such as whether tilt steering, power windows, airbags, etc., must be present in the car.
• Other characteristics can be specified with a multiple-choice menu selection by the buyer such as the color of the car as "red,” “blue,” etc.
• Other characteristics may require a numerical input that can range continuously over many possible values such as the existing mileage of the car, and its horsepower.
• the buyer is permitted to specify the importance of a characteristic.
• the importance value, or weight, of a characteristic, or attribute ranges from 0 (ignore the characteristic) to 1 (the characteristic must be present in the match and must match exactly).
• the buyer may assign an importance rating of 0.9 which could mean that the characteristic is very important but not essential.
• the administrator designs a buyer interface so that a buyer need not be absolutely mindful of the weightings. This is accomplished by providing default, or automatically calculated, weights in some cases and by providing mappings of weights to common words or expressions in other cases.
• An example of an automatic weighting is a weighting of 0 given to those characteristics that the buyer omits, or fails to specify. For example, if the buyer does not reply "yes" or “no" to a "tilt_steering" characteristic specification then a weight of 0 can be assigned to the "tilt_steering" characteristic so that it is ignored in the matching process.
• a default non-zero importance, or weight can be assigned to a characteristic that is omitted by the user.
• the weight of the characteristic to an average user can be assigned when the weight is not specifically provided by the user.
• Another example of default weighting is where the buyer selects a value for a characteristic but fails to provide a weighting.
• the default can be 0.3 when the buyer fails to specify a weighting since most buyers who fail to make color mandatory, or highly desirable, probably don't care too much about the color.
• For a car type characteristic a likely default would be 1 since car type (e.g., sedan, convertible) is usually an important, inflexible, characteristic for most buyers.
• Other weightings can be calculated by the matching engine, or another process in the ecommerce system, based on a specified characteristic, multiple characteristic, or external data or factors.
• the default weighting for a full-size spare tire can be higher where the buyer specifies an off-road vehicle type as opposed to an economy coupe.
• the matching engine can act to translate, or modify, buyer-specified weightings. Typically a buyer will not be asked to input a numeric value in the range of 0-1 but can specify the weighting by using common expressions such as "not required,” “not important,” “desired,” “very important” and “required.” These expressions can be mapped to numeric weightings such as 0, 0.3, 0.5, 0.9 and 1, respectively.
• the matching engine can substitute characteristics and attributes.
• the engine can substitute an overall safety rating and give higher-rated cars higher scores for the safety-rating attribute.
• the engine can convert buyer-specified characteristics such as a "red" color into a numerical representation of the color such as a light wavelength, hue classification, etc., so that colors are matched on a continuous scale where dark orange colors result in a higher color attribute score than blue, or shorter-wavelength colors.
• the matching engine can use discontinuous functions to perform attribute value matching such as where a buyer specifies that a car be "new.”
• the matching engine can be configured to deem "new" cars as those cars with logged mileage under 100 or some other fixed number. "Average” and “old” cars ages can be defined where each definition is a range of miles. Alternatively, a continuous function can be used where the higher the number of miles, the lower the score for the "age" attribute, or characteristic.
• the matching engine can use any type of function including discrete, continuous, limited set (e.g., based on alphabet values), etc., to describe variables and weightings. This eliminates the need to reduce the number of variables in a search to avaoid ending up with no matches.
• the present invention can accept the mileage as any number and use an appropriate continuous function to achieve matching. This is discussed in more detail, below.
• the matching engine can accept characteristics from a buyer that are not predefined in the engine.
• the car dealer specifications of available cars - in the form of records in the ecommerce database - allow dealers to add attributes, values and weightings in a similar manner. If the same attribute names are used the attributes and characteristics can be matched in the same way as for pre-defined attributes.
• Table I illustrate the previously mentioned aspects of the matching engine.
• buyers 1 and 2 have a set of desired characteristics in a car that they want to purchase.
• Sellers 1, 2 and 3 (which may be different sellers or different cars of the same seller), also attach a weight to each characteristic (either verbally or numerically).
• buyer 1 wants a blue car and seller 1 has a blue car. Thus, they match perfectly on this attribute, getting a score of 1.
• Buyer 1 attaches a weight to this of .6. (E.g., he might have answered that color was "somewhat important" which the engine transforms according to previous instructions into a numerical value. Alternatively, the buyer could have merely reported a numerical value.)
• Color is a discrete variable in this example since it must be one of only a relatively few values. Note that seller's weight is zero, because he does not care about buyer's preferences over color, whereas the buyer cares about the actual color of the car.
• Mileage is a continuous variable where less is better.
• Buyer 2 prefers a car with about 20,000 miles, but fewer miles are better and more are worse. This is a continuous variable so a car with 10,000 miles receives a higher score on this attribute than one with 40,000 or even 20,000.
• the 20,000 response by the buyer benchmarks the function to be used in the tradeoff. Note also that buyer 2 is quite flexible on mileage, giving it a weight of only .2.
• Buyer 2 views Seller 2 best on this characteristic and seller 1 worst. Buyer 1 has the same ranking as buyer 2, but places heavier weight on this characteristic. Note that the engine does not treat all cars with, say, less than 20,000 miles the same. Those with 10,000 are a better match than those with 18,000.
• date of delivery is a continuous variable that is transformed from the actual date desired. The closer to the desired date the better, but too early might be just as bad as too late because the buyer might not have the funds to purchase the car.
• sellers have preferences over delivery dates as well. Sooner may be better because the seller does not have to cover holding costs. Later may be better because the seller will have more time to acquire and service the car.
• the ability to allow users to specify preferences is provided by the administrator and user interfaces of the present invention as discussed in the related application, referenced above. Any specified preferences or characteristics can also have an attached weight, as well.
• the above examples illustrate the types of variables that can be accommodated.
• the approach of using weights with values can be generalized to any kind of characteristic, attribute, property, preference, data, etc. that can be transformed into a value.
• the weighting function can handle any finite number of attributes, still providing non-zero matching values as long as a match does not violate an absolute restriction (e.g., when a non-matching value is discrete and its weight is 1).
• an absolute restriction e.g., when a non-matching value is discrete and its weight is 1).
• a score of zero results when at least one party to the match says that there must be a perfect match on one discrete attribute and the attributes do not match.
• the quality of the match between buyer 1 and seller 1 depends on both the quality of the match on any given attribute and its importance. In particular, it satisfies the property that there can still be a good match when buyer and seller disagree on a characteristic, but the characteristic is deemed to be irrelevant (or almost irrelevant) to the parties.
• the matching engine compares characteristics values and weightings for each pair, triplet, or any number of agents with all other values in the database.
• a mathematical description of the matching process is provided in the next section below. Descriptive examples of the matching process are provided in the following paragraphs.
• the matching engine calculates the value of the match on each attribute, the weight on each attribute and then takes a linear or non-linear function of the attributes and weights to compute a score. That score in this example is the worker's view of the quality of the match with the seller in question.
• the function that combines attributes and weights to obtain a score that rates the quality of the match to one of the parties can have any form. However, in the preferred functional form, given below, there is a linear and non-linear part combined with a power function that normalizes results.
• an overall match score for a pair of agents is computed as a function of each party's score.
• the algorithm allows for the value of a match to be a function of both the buyer's view of the seller as well as the seller's view of the buyer. Any function can be used to combine buyer score with seller score. In the preferred method described below, it is the square root of the product of the score for agent i and score for agent j, but it need not be restricted to that function.
• one attribute makes sense for one side, but not for another.
• a firm might care about a worker's education, but not the reverse. Then, the weight for the worker's view of that attribute is zero, and the firm's weight is between 0 and 1.
• the reverse is true and sometimes both hold. For example, a person trying to buy a shoe on a web site cares about color, but not how much profit the firm earns on the sale of the shoe. The firm cares about profit, but not the color of the shoe since all shoe colors may cost the same to produce.
• the attributes that matter to the firm receive positive weights in the firm's scoring, but zero weights in the buyer's scoring. Those that are of concern to the buyer receive positive weights in the buyer's scoring, but zero weights in the firm scoring. This can be done behind-the-scene as a default setting in the configurator or it can be entered explicitly by the users.
• Default weightings, weighting substitution, weighting calculation as a function of elements in a database and user input and attribute substitution can all be dealt with.
• missing attributes can be dealt with in a number of ways. For example, a potential car purchaser might leave the "color' field blank.
• the weighting can then be set to zero (indicating that the user does not care about this attribute) or other rules can be used, e.g., assigning the mean or modal value to the attribute and the mean or modal weight.
• the algorithm can report matches when a criterion level is met or can report all matches in order of their quality.
• the criterion level can be computed as a number or a function of other data in the database or can be specified directly by the users.
• the matching engine of the present invention can be used in various applications that would previously suffer from the shortcomings of prior art systems in handling "many-to-many” matching problems with many attributes.
• the matching engine of the present invention allows these problems to be solved and computed more quickly.
• the matching engine can be used advantageously in diverse applications such as (1) assigning 1000 idiosyncratic consultants to 10,000 clients each with different preferences so as to maximize profits, overall value of matches or other criteria; (2) assigning flight attendants to flight slots; (3) assigning nurses with predefined qualifications and availability to patients with specified needs; (4) assigning resources to departments, etc.
• the matching engine is capable of providing are shown in Table II.
• Various embodiments and variations of the matching engine can provide one or more (including all) of the features of Table II, below.
• characteristic x is essential to agent A, then A views every match with a party not possessing characteristic x to be unacceptable.
• characteristic x is more important to agent A than to B, then A values every match with a party possessing characteristic x to be no worse than B views it.
• agent A cares more about characteristic x than agent B, then A views a match with another agent who possesses characteristic x as being no worse than agent B views that match (other factors constant).
• Keywords should be able to be handled.
• a set of attributes that are important in determining the value of a match between buyer and seller is defined.
• These attributes can take a variety of forms such as being discrete (e.g., in an occupation or not), continuous (e.g., level of education), an input to another variable (e.g., zip code), etc.
• the key variables are formed in the model according to a number of possible methods, depending on the type of variable.
• the importance of each attribute is ranked on a scale from zero to 1 which can correspond to irrelevant to essential, completely flexible to completely inflexible, or other verbiage depending on the context of the variable in question.
• the importance is assigned to a ⁇ r meaning the importance that seller i attaches to attribute r or a jr meaning the importance that buyer j attaches to attribute r.
• X ⁇ r meaning the rth attribute for individual i (a seller) or X jr .
• D ljr are created which are variables that go from zero to 1, depending on how well a buyer's desires are satisfied by a seller's characteristics
• R is the total number of attributes indexed by r
• D ljr is the value of the match between seller i and buyer j on attribute r
• C ljr is a constructed variable based on a table look up or some other procedure.
• C ljr is defined to be non-negative.
• the best value of C ljr is zero. All positive values are worse.
• C ljr could be defined as distance between two locations or C ljr max is the max tolerable value. All values greater than this should give the calculated D, j a value of zero.
• X ha i , r is the mean or median value of X for that attribute in the sample.
• This method guarantees that there is always a best match.
• the quality of the match can be relatively good or relatively poor, but there is no doubt that a best match can always be found, simply defined as the highest Zij for any given seller i or buyer j.
• increasing the number of variables does not diminish the probability of finding a match. More variables means a more detailed description of what is a good match, but this may be improved or weakened by adding more attributes.
• Possible markets include Goods Exchanges, Service Exchanges, Competitive Markets, Modified Competitive Markets, Consignment Stores, Barter, Electronic Pawnshops, Trading Posts, Qualified Auctions, Forward Contracts, Futures and Credit Markets, Electronic salesperson and Internal Allocation.
• Properties of a specific ecommerce market can be set in a variety of ways and are not specific to the engine.
• Each market can use a variety of match algorithms and number of matches. For example, a buyer might want to see m sellers and a seller might want to see n buyers.
• Each match can be priced (so that the exchange gets a commission for each match), fees can be charged on the basis of actual trades that occur or a subscription fee can be charged.
• Transaction data is entered into the ecommerce system.
• the market is a job market
• job seekers specify attributes and values regarding their qualifications, location, etc.
• a prospective employer can enter desired characteristics of candidates in the form of attribute/value pairs, also.
• the attribute/value (a v) pairs can receive a weighting that is used in the matching engine process as described above.
• Another example of a market is an exchange where User_l is a provider of item_A and seeks to obtain item_B. Both item_A and item_B are described using a/v pairs with optional weightings.
• User_l's item_A is matched to the desired items of other users in the market.
• User_l 's item_B is matched to provided items of other users in the market.
• the matching procedure can be designed to provide only the best single exchange between two users, or can be used to resolve (or "clear") item exchanges among all users, or a subset of all users. For example, the ten best matches can be presented to the users for acceptance.
• the entity running the ecommerce marketplace can obtain a commission on completed exchanges.
• the two agents need not be a buyer and seller at all.
• the "buyer” could be a route that electricity could follow and the "seller” could be a particular bundle of electrical power that is ready to be transmitted.
• the matching capability allows for any two or more agents or entities to be matched with one another.
• Electronic Salesperson Another type of market is a simple "salesperson" market where buyers provide desired characteristics of an item to be purchased. The desired characteristics are matched to item attributes.
• One important property of the salesperson market is that the buyer is allowed to state a price that the buyer is willing to pay. Price consideration is important since, unlike many other characteristics, it will often be the pivotal characteristic upon which the sale hinges. The seller's position on price is taken into consideration so that sellers (or item providers) can be assured of obtaining an optimal, desired, or at least minimum profit.
• Z is the buyer side and is defined using the relevant characteristics including a D for price, where D, j price is defined as
• xij is the price that the consumer states that he expects to pay
• x jr is the price of the article in question
• ⁇ r is the standard deviation of the bid prices for consumers.
• Z y J can be constructed as it normally is, but there is an alternative.
• a firm wants to maximize expected profit by offering the good, j, that maximizes the following: max ⁇ (prob buys good_l)(profit on good_l), (prob buys good_2)(profit on good_2), ...(prob buys goodJ)(profit on goodj) ⁇ .
• Z, ⁇ * can be used as an estimate of square of prob buys 1. Later (see below) use market data to estimate logit where D ljr and a, r are right hand variables (using functional form in the Z function). Then Z l ⁇ ⁇ is just the square of the profit made on goodj. Since everything will be ordinal, Z can be normalized to between zero and one by defining
• ⁇ j is the profit on goodj
• ⁇ max is the maximum profit on all goods in the set
• ⁇ max is the minimum profit on all goods in the set.
• Prob(Z, j ') is the predicted probability from the logit, given Z ⁇
• Prob(Z, j ') is the predicted probability from the logit, given Z ⁇
• the Z is simply the predicted probability of sale from the logit, where the a and D data are entered by the user. This is probably the better approach, although the fit of the logit (-2 log likelihood) will tell us.
• the price should not be taken as given. Instead, marginal cost of the item should be given as data rather than the profit per item.
• Can solve the problem by calculating the profit maximizing price for each of the j items and then offer the one at the price (e.g., list minus the calculated discount) that maximizes profit across all items.
• an analagous type of computation can be performed for the advantage of the buyer.
• the buyer is typically not interested in profit margin - but only in ultimate price.
• prices of all goods j are compared while taking into account discounts, regional taxes, promotional offerings, etc., to minimize the ultimate price.
• a prefe ⁇ ed embodiment shows up to 3 offerings.
• the offerings can be made dynamic so that the displayed offerings, or possible buyer choices, are changed periodically based on real-time gathering and computation of market data. If changes in market data create price differences among the offerings that disfavor the seller (or, alternatively, disfavor the buyer) then offerings can be removed (or added). For example, if the expected profit from best to second best choice falls off too dramatically, i.e., exceeds some critical value (or function), then only one choice can be shown. Similarly, the same approach can be taken among all offerings such as between offerings 2 and 3, etc.
• the present invention allows sellers to "push" products that they prefer to sell. For example, if a buyer prefers item A over item B, but item B's sale would yield a higher profit for a seller, the matching engine can be set to offer item B and not item A.
• the matching engine has been discussed with respect to specific embodiments thereof, these embodiments are merely illustrative, not exclusive, of the invention.
• the matching engine has been discussed by using the terms “desired characteristics” and “item attributes.” However, these terms are functionally equivalent so that the notions of "characteristics” and “attributes” can be interchanged throughout the discussion, herein.
• characteristics has been used to indicate attributes that a user specifies to search for a match among stored items in a database.
• attributes has been used to describe traits of items to match with the characteristics.
• the engine can match stored item attributes with stored item attributes (as where two databases of items are compared); specified characteristics with specified characteristics (as where two groups of users indicate preferences and the preferences are matched), etc.
• any manner of hardware and software can be employed to achieve the present invention.
• client computers coupled to one or more server computers via the Internet
• other approaches include using a local-area network or standalone system.
• a dedicated network can be used, or a single machine can be used to provide all of the processing and user interfaces.
• a multi-user time- shared environment where users access a single computing machine can be used.
• Other approaches are possible.
• the matching engine and associated components and processing can be distributed over several digital processing, or digital handling, hardware components and software processes.
• the design of hardware and software can vary widely.

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=22715719

Family Applications (3)

Family Applications Before (1)

Family Applications After (1)

Country Status (3)

Cited By (4)

Families Citing this family (100)

Citations (3)

Family Cites Families (15)

• 2001
  • 2001-03-30 WO PCT/US2001/010401 patent/WO2001075548A2/en active Application Filing
  • 2001-03-30 AU AU2001251182A patent/AU2001251182A1/en not_active Abandoned
  • 2001-03-30 US US09/823,239 patent/US20020032638A1/en not_active Abandoned
  • 2001-03-30 AU AU2001253042A patent/AU2001253042A1/en not_active Abandoned
  • 2001-03-30 WO PCT/US2001/010449 patent/WO2001075736A1/en active Application Filing
  • 2001-03-30 US US09/823,955 patent/US20020013735A1/en not_active Abandoned
  • 2001-03-30 WO PCT/US2001/010452 patent/WO2001075737A1/en active Application Filing
  • 2001-03-30 AU AU2001253055A patent/AU2001253055A1/en not_active Abandoned

Patent Citations (3)

Also Published As

Similar Documents

Legal Events