Systems and Methods for Wine Ranking

FIELD OF THE INVENTION(S)

The present invention(s) relate to wine selections, and more particularly, to systems and methods for wine ranking.

DESCRIPTION OF THE RELATED ART

Although the number of mobile and web applications that recommend wines to users based on user-defined categorical requests (e.g., wine type, varietal, region, or food type) is becoming commonplace, these applications generally employ one of two inefficient techniques: a simple relational database or crowd sourcing (social networking). Typical relational databases tend to be crude and have static (i.e., unchanging) relationships between wines and foods without regard to user-specific preferences (e.g., based solely on expert opinion). For example, a typical relational database approach may always mandate a specific wine varietal for a specific food (e.g., Chardonnay or White Burgundy with chicken in cream sauce). This approach completely ignores the preferences or palate of the consumer in favor of an expected static interplay of the characteristics of food and a property of wine.

While crowd sourcing techniques try to provide wine recommendations based on either personal relationships or some statistical similarity based on demographics between a given user and all other users (i.e., the crowd), they can easily fail to distinguish the popularity of a given wine from an individual's preferences. In order for crowd-sourced opinion to be practical, a wine must be “sampled” by many users in order to provide reasonable statistical relationships. For a wine to be sufficiently sampled for crowd-sourcing, the wines must be widely available. Smaller and/or elite wineries may be virtually ignored because of the lack of availability (i.e., the number of people who have sampled the wines may not be statistically significant so these wines are not recommended).

A wine recommendation utilizing crowd-sourcing techniques may have no basis of the consumer's personal taste or individual preferences, rather, the wine recommendation is based on the consumer's friends or demographics. Many crowd-sourcing techniques group potential consumers with wine scored by wine experts (e.g., scores published by Wine Spectator). Unfortunately, recent studies by wine economists have suggested that the range in wine preferences between users and experts can be significant. In fact, the studies suggest a negative correlation between expert opinion of quality and non-expert preferences.

SUMMARY OF EMBODIMENTS

An exemplary method comprises describing a plurality of wines, each wine of the plurality of wines being described using descriptors, receiving at least one predetermined intensity value associated with each descriptor, storing the descriptors within a wine database, generating a consumer wine preference profile that includes a plurality of user preference intensity values, at least one of the plurality of user preference intensity values being associated with at least one of the descriptors, selecting at least one wine from the plurality of wines by correlating at least a subset of the plurality of user preference intensity values with at least a subset of the predetermined intensity values, and providing identification of the selected at least one wine from the plurality of wines. The consumer wine preference profile may be associated with a consumer who is provided the identification of the selected at least one wine.

The method may further comprise receiving a wine request, the wine request including an identifier and at least one wine categorical classification, retrieving a subset of the descriptors from the wine database based on the wine categorical classification to identify the at least the subset of the predetermined intensity values, and retrieving the consumer wine preference profile based on the identifier. In some embodiments, the at least one wine categorical classification is a wine varietal. In various embodiments, the at least one wine categorical classification is a wine color. The wine request may comprise location information and the subset of the descriptors is associated with the location information.

In some embodiments, selecting the at least one wine comprises selecting the at least one wine based on a similarity of the subset of the plurality of user preference intensity values with the at least the subset of the predetermined intensity values. Selecting at least one wine from the plurality of wines may comprise selecting a subset of the plurality of wines.

Correlating the at least the subset of the plurality of user preference intensity values with the at least the subset of the predetermined intensity values may comprise correlating a first subset of the plurality of user preference intensity values associated with a first wine of the subset of the plurality of wines with the at least the subset of the plurality of user preference intensity values and correlating a second subset of the plurality of user preference intensity values associated with a second wine of the subset of the plurality of wines with the at least the subset of the plurality of user preference intensity values. The method may further comprise ranking the first and second wines based on the correlations. Further, providing information of the selected at least one wine from the plurality of wines may comprise providing the ranked first and second wines.

In some embodiments, the method may further comprise receiving a wine profile update request comprising an identifier and a wine attribute, retrieving the consumer wine preference profile based on the identifier, and updating the plurality of user preference intensity values based on the wine attribute.

An exemplary system may comprise a wine description module, a training module, and a ranking module. The wine description module may be configured to describe a plurality of wines, each wine of the plurality of wines being described using descriptors, to receive at least one predetermined intensity value associated with each descriptor, and to store the descriptors within a wine database. The training module may be configured to generate a consumer wine preference profile that includes a plurality of user preference intensity values, at least one of the plurality of user preference intensity values being associated with at least one of the descriptors. The ranking module may be configured to select at least one wine from the plurality of wines by correlating at least a subset of the plurality of user preference intensity values with at least a subset of the predetermined intensity values, and provide identification of the selected at least one wine from the plurality of wines.

An exemplary computer readable medium may comprise instructions executable by a processor to perform a method. The method may comprise describing a plurality of wines, each wine of the plurality of wines being described using descriptors, receiving at least one predetermined intensity value associated with each descriptor, storing the descriptors within a wine database, generating a consumer wine preference profile that includes a plurality of user preference intensity values, at least one of the plurality of user preference intensity values being associated with at least one of the descriptors, selecting at least one wine from the plurality of wines by correlating at least a subset of the plurality of user preference intensity values with at least a subset of the predetermined intensity values, and providing identification of the selected at least one wine from the plurality of wines. The consumer wine preference profile may be associated with a consumer who is provided the identification of the selected at least one wine.

Other features and aspects of various embodiments will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the features of the various embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts two digital devices in communication with a wine ranking system over a communication network in some embodiments.

FIG. 2 is a block diagram of a wine ranking system in some embodiments

FIG. 3 depicts an exemplary abbreviated wine database entry in some embodiments.

FIG. 4 is a block diagram of a digital device in some embodiments.

FIG. 5 is a flow chart for generating a wine database in some embodiments.

FIG. 6 is a flow chart for training a user database in some embodiments.

FIG. 7 is a flowchart for a user receiving ranked wines on the user's digital device in some embodiments.

FIG. 8 is a flowchart for providing ranked wines to the user's digital device in response to a wine request in some embodiments.

FIG. 9 is a flowchart for updating a user wine database in some embodiments.

FIG. 10 is a block diagram of an exemplary digital device in some embodiments.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

In various embodiments, user-specific input, experiences, and feedback may be used to train a system to rank wines from a general wine database. The system may provide wine rankings in the context of user preferences without regard to other users or static relationships. One exemplary method uses numerical (or other scoring criteria) wine characteristics (e.g., based on a predefined character “map” and an expert-derived intensity scale), which are compiled for wines from a user-specific wine experience database to compute a statistical “proxy” of the user's experiences and preferences in wine characteristics. This “wine proxy” may be treated as a linear mathematical operator by which future user wine requests or searches can be filtered in order to provide user-specific ranked results for the purposes of purchase or general wine education. Once users have tried wines from the system's ranked wines, they can provide their own ratings which are incorporated (e.g., via a proxy regression) into future rankings from the database.

Some embodiments allow a relatively small wine database to be used to generate useable statistics thereby making the system efficient. The user proxy and subsequent filtering operations may be generated with little computational overhead (i.e., the system may be scalable). Those skilled in the art will appreciate that, in some embodiments, the wine characteristics used for analysis may be uncorrelated and/or may be statistically independent.

As opposed to other techniques known in the fields of machine learning such as Bayesian classification (based on poorly informed prior probabilities or poor assumptions of parameter independence), or cluster analysis (which usually depends on vague distance measures in a parameter space), some exemplary embodiments may: 1) assure that parameters are uncorrelated (and usually independent in cases of Gaussian posterior probability distributions); 2) be implemented so as to be insensitive to statistical priors; and 3) maintain wine character correlation information for future classifications or rankings. In addition, the analysis may be performed in a reduced-dimensional user preference space, which may add efficiency to the problem of statistical classification with large datasets.

The following example method can have several embodiments including, but not limited to, web-based or mobile application, static platform-specific application (e.g., PC/MAC/Linux), or cloud-based (server-based) application.

FIG. 1 depicts two digital devices 102 and 104 in communication with a wine ranking system 108 over a communication network 106 in some embodiments. The digital device 102, digital device 104, and the wine ranking system 108 may be digital devices. A digital device is any device with memory and a processor. In some examples, digital devices 102 and 104 may be a mobile or stationary user device such as, but are not limited to, smart phones, cell phones, laptops, media tablets, desktop computers, ultrabooks, smart peripherals (e.g., smart glasses), media players, or the like. In some embodiments, the digital device 102 and/or digital device 104 may comprise an application (e.g., an app) that communicates with the wine ranking system 108.

In various embodiments, a user of either digital device 102 and 104 may register with and/or request wine rankings from the wine ranking system 108. In one example, digital device 102 provides the wine ranking system 108 with information regarding a user's wine preferences. The wine ranking system 108 may build a user wine database based on the user's past wine consumption and indications of the user's preference for the wine. The wine ranking system 108 may determine the user's preferences of different wine characteristics (e.g., acidity, sugar, alcohol, and tannins) and then rank a list of wines based on the user's personally desired characteristics.

The wine ranking system 108 may comprise a wine database. The wine database may comprise wine identifiers as well as wine descriptors correlated with each wine identifier. A wine identifier identifies a particular wine (e.g., Robert Foley Claret 2010). A wine descriptor is a characteristic of a wine (e.g., acidity, alcohol, sugar, tannins, or the like). Each wine descriptor may have an associated intensity value. An intensity value represents a degree of actual and/or perceived presence of the wine characteristic. An intensity value may be defined for a certain range. For example, an intensity value may be zero to six, with zero indicating that the related wine characteristic is not present (e.g., no perceivable tannins) and a six being a maximum amount of the related wine characteristic. Those skilled in the art will appreciate that there may be any range or representation of intensity values.

The wine ranking system 108 may utilize the user wine database to select wines based on a similarity of the user wine characteristic preferences with the different intensity values of descriptors of wines contained in the wine database.

In one example, the user may register with the wine ranking system 108 and train a user wine database based on previously preferred wines and the user's past experiences. The user may train and/or update an associated database by providing wine identifiers (e.g., brand names, varietals, and/or vintages) as well as an indication of how much they enjoyed the wine (e.g., one to five stars).

After the user wine database is created and trained, the digital device 102 may provide a wine request to the wine ranking system 108 to request a selection of wines as well as a ranking of wines selected. The wine request may identify the user (and/or the digital device 102) and may provide one or more categorical classifications. A categorical classification is a category associated with wine such as, but not limited to, a name of a wine, a varietal of a preferred type of wine, a region of preferred wines, a color of preferred wines, and/or the like. The wine database may associate one or more wines and/or intensity values with categorical classifications. In various embodiments, the user may not be sophisticated and, as a result, the user may provide general types of wine or categorical classifications.

The wine ranking system 108 may generate a wine proxy for the user based on the user's past experiences with wine and preferences. The wine proxy may be utilized to select and rank a list of wines based on the wine database. For example, the wine ranking system 108 may correlate or find similarities of the user wine proxy to the predetermined descriptors and/or intensity values of different wines contained within the wine database. The system may utilize these similarities or correlations to select and/or rank wines for the user. The wine ranking system 108 may also utilize one or more categorical classifications from a wine request and the user's wine proxy to select, rank, and/or filter a list of selected wines as further described herein. The ranked wines may be provided to the user via the requesting digital device 102.

In various embodiments, the wine ranking system 108 may comprise or be associated with a web server that provides wine recommendations and/or rankings to the digital device 102 via the Internet. The wine ranking system 108 may include any number of digital devices (e.g., servers) configured to identify and/or rank wines for users.

Those skilled in the art will appreciate that the wine database and/or user wine databases may be stored on any digital device such as the digital devices 102 or 104 or the wine ranking system 108. Further, the wine database and user database may be stored on one or more other databases in one or more other digital devices coupled to the communications network 106, the digital device 102, the digital device 104, or the wine ranking system 108.

Although only two digital devices are depicted in FIG. 1, those skilled in the art will appreciate that there may be any number of users with user databases and/or associated digital devices. Further, there may be any number of networks 106 and/or wine ranking systems 108. In some embodiments, the wine ranking system 108 recommends wine based on the user's preferences as described herein. Those skilled in the art will appreciate that the wine ranking system 108 may operate to recommend wines, rank wines, or both.

FIG. 2 is a block diagram of a wine ranking system 108 in some embodiments. The wine ranking system 108 may comprise a wine description module 202, a training module 204, a ranking module 206, an update module 208, a registration module 210, a user profile database 212, and a wine database 214. The wine description module 202 may generate and/or update a wine database. The wine database is a database or any data structure that comprises wine identifiers with corresponding wine characteristics. Each discrete characteristic for a wine, or descriptor, may be based, for example, on aroma or taste. A wine descriptor is a wine characteristic such as, but not limited to, acidity, alcohol, sugar, tannins, or the like which may be used to describe any number of wines. These discrete characteristics, or descriptors, for each wine may be elementized (i.e., identified), and quantified (i.e., intensities assigned) to create a discrete parameter. Each wine descriptor may have an associated intensity value. An intensity value may be any value such as a number or score that represents a degree of actual and/or perceived presence of the descriptor in a particular wine.

In some embodiments, one or more wines in the wine database may be associated with any number of categorical classifications (e.g., wine name, varietal, vintage, region, and/or appellation). Categorical classifications include categories that may apply to and classify wine. The categorical classifications may include categories that relate to wine that may represent a type of wine (e.g., color, varietal, vintage, region, winery, wine name, appellation, or the like).

The wine database may comprise information regarding wines numbering as few as hundreds to as many as millions of distinct wines (constituting an appropriate representation spanning various wine types, varietals, regions, etc.).

In some embodiments, experienced individuals (e.g., experts) identify wines and quantify a set of discrete parameters. The experienced individuals may be any individual with training and/or experience to describe wine utilizing the discrete parameter set. Wines that define a set of discrete data may be analyzed by the experienced individuals in terms of the wine characteristics or parameter set. An exemplary method defines wine characters using wine tasting criteria and descriptive language.

Experts or any individuals may be trained to utilize a scoring system (e.g., determine intensity values) for a limited number of wine characteristics (e.g., descriptors) of the discrete set. By training the individuals to use the scoring system and the previously determined descriptors, different experts may utilize a similar language (e.g., based on the descriptors) and a more objective approach to describing wine.

In some embodiments, each experienced individual may assign numerical values(i.e., scores or intensity values) denoting how much a particular character is perceived to be represented in each wine. The intensities may be assigned utilizing a taster-subjective (i.e., expert opinion) intensity scale. The intensity value may be based on or converted to any scale. In one example, the intensity values may range from 0-6 for each character (i.e., for each descriptor). Those skilled in the art will appreciate that any range of intensity values may be utilized. The intensity values need not be restricted to integers. The intensity values may be positive, negative, or a combination of both.

The character data, the relative intensities, and the wine descriptive information constitute a wine parameter database that may cover many different wine varietals, geographic regions, wine producers, and vintages.

FIG. 3 depicts an exemplary abbreviated wine database entry in some embodiments. In this case, the first six columns correspond to various identifying and searchable information for the wine, while the last four columns represent example wine characteristics and their relative intensities assigned by the system. Here, the wine has characteristics denoting “Fruit, Earth, Spice, and Resin” with respective intensities equal to “0.5, 2.5, 2.0 and 3.5,” respectively. This wine with its four parameters and intensities would then represent one datum for a 4-parameter character set. Those skilled in the art will appreciate that the number of characters may be much larger than four and the number of wine entries much larger than one.

Those skilled in the art will appreciate that any group of individuals and/or analytical devices may be used to associate wine with different descriptors and intensity values. An individual may not need to be a recognized expert to be able to associate the wine with a descriptor and intensity value. For example, a set of individuals (e.g., students) may be trained to utilize the system to associate different wines with descriptors and intensity values. The information may be stored in the wine database.

In various embodiments, natural language processing (NLP) techniques such as machine learning may be used to interpret contextual semantic text from existing wine tasting notes. For example, wine tasting notes or wine reviews from any expert or other individual may be processed to identify descriptors and intensity values associated with those descriptors. Natural language processing may be utilized with any document describing wine, including documents such as web pages or portions of web pages available on the Internet. Other sources may include wine bottle labels, wine descriptions in magazines or trade publications, blogs, Facebook discussions, or the like.

Natural language processing may scan and convert language to descriptors and intensity values. See Table 1 for an example of a very simple semantics-based character intensity scale.

TABLE 1

Example of semantic description and corresponding

intensities for relative wine character scale.

Words typical of level of intensity
Suggested Scale Value

“aromas, nose of”
0.5 (MINIMUM)

“nuance, hint, pungent-nose”
1.0

“mild, little, bit, light, touch”
1.5

“some, notes of”
2.0

If character is mentioned with NO descriptor
2.5

“(spice)‘y’, (fruit)‘y’, etc.”
3.0

“plenty, long, moderate, layered, concentrated”
3.5

“lingering, pungent, powerful, generous”
4.0

“extravagance, abundance, intense, over-
4.5

powering”

“lots, burning, excessive”
5.0 (MAXIMUM)

Wine identifiers (i.e., identifiers that identify a specific wine), associated descriptors and related intensity scores (e.g., by utilizing experts and/or natural language processing) may be stored in the wine database.

The training module 204 of FIG. 2 is configured to generate and/or train a user wine database based on wines identified by the user. In various embodiments, in order to train the system to rank wines for each user, a user database of wines (e.g., a subset of the wine database) that is unique to each user is determined from input about the user's wine experiences. In one example, a user input may comprise messages from the user regarding wines, preference scores, and/or any other information.

In some embodiments, to keep the input simple, the system need not require the user to input specific characteristics in wine they like (since the user may or may not be knowledgeable of wine characteristics). Rather, the system (e.g., training module 204) may ask the user and/or the user may provide examples of wines or wine types that they have experienced and prefer. An exemplary system query for the user may request general wine information related to wines preferred or consumed in the past (See Columns 1-6 in FIG. 3). Such categorical classifications may include, but are not limited to: user preference for wine type(s), region(s), varietal(s), or producer(s). This information may then be used to limit (i.e., match) the wines in the wine database to a subset of wines (i.e., the “training” database) unique to each user's experiences.

In various embodiments, the training module 204 may translate one or more categorical classifications to wine descriptors and/or user preference intensity values. For example, the user may be provided a limited list of categorical classifications to choose from. The selections may be provided to the training module 204 which may associate the categorical classifications with one or more descriptors. The user preference intensity values related to the categorical classifications may be determined. A user preference intensity value is an intensity value associated with a descriptor. The intensity value may be provided by the user or determined based on information provided by the user. If the categorical classification does not relate to an intensity of the descriptor, the user preference intensity value associated with the categorical classification may be given a neutral value.

For example, the user may provide the wine ranking system 108 one or more categorical classifications. The training module 204 may retrieve wines from the wine database that match the one or more categorical classifications. The intensity scores of descriptors associated with the selected wines may be utilized to generate (e.g., by averaging the preexisting intensity scores) user preference intensity values. In some embodiments, the user may provide additional information, such as wine preference and appreciation value which may be used to weigh and determine the user preference intensity values. For example, the user may provide a categorical classification indicating that the user prefers red wine. Descriptors and related intensity values of wines associated with red wines may be utilized to generate the user's wine proxy (further discussed herein).

The training module 204 may also determine when limited user input is sufficient for further analysis based on statistical and hypothesis tests for small sample populations (e.g., critical T-values). The resulting training database may be used to calculate user-specific statistics. The user database may be stored and updated as necessary by the system for future use. Those skilled in the art will appreciate that any number of wines may be sufficient.

The ranking module 206 is configured to identify wines of interest to users based on descriptors and user preference intensity values from the associated user database (e.g., user profile). In various embodiments, the ranking module 206 takes parametric information (characters and intensities) from the user training database, performs a spatial correlation across parameters and wine entries, and uses the resulting statistical correlations to mathematically reduce the parameter set to a limited number of new uncorrelated variables which, taken in linear combination, may uniquely define the user's wine preference (i.e., the user wine proxy). There are multiple embodiments of this statistical de-correlation process which may include, but not limited to: principal component analysis (PCA), independent component analysis (ICA), singular value decomposition (SVD), or other matrix de-correlation method (e.g., discrete cosine transform (DCT), wavelet transform, or orthogonal polynomial decomposition).

Describing an approach utilizing principal component analysis as one example, the mathematical procedure transforms, a number of correlated variables (i.e., wine characters in this case) into an equal number of uncorrelated variables (vectors), called principal components, while maintaining their full variance and ordering the components by their contribution. The resulting transformation may be such that the first principal component represents the largest amount of variability (i.e., has the largest weight), while each successive component may account for at least some of the remaining variability. The number of wine parameters can be reduced significantly by replacing them with the first few principal components (based on relative amplitudes of weights) that capture most of the wine character variance.

In one example, let us assume that the training database has M wines and that each wine has N characters (e.g., descriptors). A wine character covariance (N×N) matrix then can be estimated from the training database according to the approximation:

$\begin{matrix} C = 1 / M \sum_{i = 1}^{M} {[{ch}_{i} - 〈 ch 〉]}^{T} [{ch}_{i} - 〈 ch 〉] & (1) \end{matrix}$

where M is the total number of wines in the training database, custom-character ch is the wine mean character intensity vector computed for all N characters (i.e., intensity values) across all M wines, and ch_iis each character intensity vector (length=N) for each of the M wines in database.

The covariance matrix may include all or some wines that are included in the wine database. The covariance matrix, which may be termed an “experimental covariance,” may be an estimate of the true covariance of all wines (including those that are not in the database). The covariance may be estimated (i.e., the estimated or experimental covariance). Every covariance may be centered.

In some embodiments, the statistics across all wines and all descriptors are averaged to get the mean which is subtracted from all wine in the wine database. In one example, an average of all descriptors across all wines is taken (e.g., average vector) and subtracted. The summation is the residuals (what is left) for all descriptors of all wines. The covariance may be computed by taking the correlation between every descriptor and every other descriptor. In some embodiments, the process correlates and/or relates descriptors with each other (e.g., how sugar relates to color, how sugar relates to alcohol, and the like).

For a twenty-seven (27) descriptors matrix, the covariance should be 27×27 (e.g., 27 squared values including a correlation between themselves and every other descriptor). The summation is the correlation between every descriptor in the database. Since C is a symmetric semi-positive definite matrix, the principal components of the training database may be computed by solving what is known as the Eigenvalue problem for the N wine characters:

Cλ=λV (2)

The matrix V contains the N Eigenvectors (i.e., principal components) of the de-correlated user wine parameter basis. The vector λ contains the N Eigenvalues (principal component weights representing the relative importance of each individual Eigen-character, V_i, in describing the user's wine “type”).

In various embodiments, the ranking module 206 may pick a small or smallest subset, P <<N, of Eigenvectors (e.g., in order to reduce ambiguity or uncorrelated noise in our character space) from this base that adequately account for most of our wine character variability according to the criteria, e.g.:

Σλ_i[1:P]/trace[C]≧70% (3)

Trace of C may be the summation of diagonal terms in a matrix. Weights for all columns of matrix V may be decreasing from largest to smallest. As a result, the first principal component of V first column may have a large λ compared to all the others. Although 70% represents the number of λ values whose sum is approximately 70% of the summation of all λ values, equation (3) may be to any percentage (e.g., higher or lower than 70%). In various embodiments, by cutting off λ values, noise may be reduced. Further, as the percentage is decreased, the process may become more efficient. In some examples P<10.

Whether the system uses all N or just P components of the de-correlated basis, these new wine Eigen-characters approximate the variance (and to a lesser extent the correlation) of wine characteristics (about the mean “composite wine” vector custom-character ch in each user's wine database (e.g., user profile) following the mathematical form:

var[wine]
_user
=
custom-character
ch

+λ
_user
V. (4)

We have denoted the user's variance in preferred wine experiences as var[wine]_Y4ser. In this context, the larger each λ_i, the more important (and more correlated across the database) each component, V_i, may be in describing the likes of the user for the particular set of wines in the training database; equation 4 may completely describe the user's individual “wine proxy” as the set of Eigen-characters V (i.e., a linear mathematical filter), the mean character vector custom-character ch and the relative importance values λ_user(i.e., the filter weights). All or some of the components of the user proxy may be stored by the system for future steps.

In essence, equation 4 may project the wine characters into a new mathematical space (i.e., the user “proxy space”) that exploits the statistical relationship between different wine characters. This is useful, because it: 1) allows the system to define wines with fewer variables (since, for example, “acidity” and “resin” wine characteristics may be perfectly correlated in many wines, we can represent both with a single principal component rather than the more complicated individual characteristics), and 2) it provides the system with a filter to make certain all future user wine requests and rankings are statistically consistent with each users' prior experiences.

Those skilled in the art will appreciate that the largest Eigenvalue (λ₁) in equation 4 may represent the least distinguishing proxy character for wine, because all wine share this character (this v₁represents the maximum correlation between all wines in the subset), while the smallest Eigenvalue (λ_N) may represent the most distinguishing proxy character, because it is correlated between wines less than all other wine characters—it may be the most unique Eigen-character.

In some embodiments, matrix V is consistent with equation 2 and specific to the user. The statistical proxy may include the user's λ values, V, and CH. The ranking module 206 may utilize this process to create a basis for initial ranking of wine.

Once the user proxy is computed, future user wine requests may be filtered by the operator V in order to transform all wines from a new “dynamic” database into the user's proxy space. To this end, equation 4 may allow the user to specify new wine descriptors (e.g., wine type, varietal, producer, region) they are currently interested in having the system rank. The update module 208 then uses this information to build a dynamic database which is distinct from the training discussed herein. In one example, the update module 208 updates the existing user database with wines to those of current interest. Then the update module 208 “projects” each wine (e.g., the update module 208 projects each wine's characteristics as defined herein) contained in this dynamic database to the user proxy space by solving the small (P×P) principal component (PC) problem:

λ_wine_i=[ch_wine_i− custom-character ch]V

Here, λ_wineis each of i wines PC defined by each character vector, ch_wine, contained in the dynamic database and filtered by the Eigen-vector operator V.

The system may rank (in either ascending or descending order) all i wines from the dynamic database according to their mathematical similarity/difference, S_i, in the proxy space to the previously defined user wine proxy values, λ_user, from equation 4:

$\begin{matrix} S_{i} = \sum_{i = 1}^{P} \langle λ_{user} - λ_{{wine}_{i}} \rangle & (6) \end{matrix}$

This similarity/difference values can also be determined using any number of techniques including Euclidean norm (simple summed difference as shown in equation 6), mean difference, root-mean-squared difference, chi-squared, etc.

In various embodiments, every wine in a database that matches a search may be assessed. In one example, wines are retrieved that match a search based on a user wine request and then the related descriptors may be converted to a mathematical space to look for similarity with the statistical proxy.

In various embodiments, the term ranking may include that the system includes all matching wines from the dynamic database, but then ranks them according to similarity, S, to user likes/dislikes (e.g., correlating the preexisting intensity values stored in the wine database with the user preference intensity values of the user wine database. Then the user can choose any of the wines they want according to or regardless of ranking. That is, the system may return all wines with additional information, but allows the user to decide on the wine. The term recommendation may include that the returns either a very limited subset of all matching wines from the dynamic database for the user to then choose from or the system returns all wines that match search terms irrespective of degree of similarity, S. Here, the system does most of the choosing for the user.

Because the system has statistical information regarding the user's wine preferences, the system may rank wines that are not in the dynamic database from Step 3. For example, if the composite wine, custom-character ch, from equation 4, is more similar to the user's proxy than any other single wine from the dynamic database. In this sense, the exemplary system may interpret the mean wine vector to be a new composite wine (one derived from statistics not from the database of wines) that itself can be matched against the complete Step 1 static database, per equation 6, to compute a new ranking for all other wines outside the dynamic database. This may allow the system to provide the user with a set of alternative wines that potentially fit their taste better than any single wine from the types, producers, regions, etc. that they requested.

In one example, the user wine database is trained to include information regarding a preference for light-bodied wines from the south of France. Subsequently, the user may request that the system rank Barolos from Italy and Napa Valley cabernets. In computing the mean composite wine, custom-character ch, from equation 4, the system may determine that the statistical mean fits the user's proxy (according to equation 6) better than any individual Barolo or Napa Valley cabernet. The system then may then match the composite to the entire static database and rank all wines relative to the composite. In this sense, the system may triangulate to rank wines that may be preferred by the user more than (but are still consistent with) either Barolos or Napa Valley cabernets.

In some embodiments, the system stores at least some wine rankings from Steps 2 and 4 that the user specifies and allows the user to rate (e.g., on a relative scale from 0-5) the wines they have tried from this list over time. The user wine proxy may then be updated to reflect these user feedback ratings by solving a regression problem (mathematical fitting problem). This technique (which has many embodiments) may incorporate new observations (user ratings) into the user proxy vector (λ) via the general mathematical form:

[λ_update]=[λR_wλ^T++εI]⁻¹λ^TR_wC (7)

R_wis a diagonal weighting matrix containing the relative user ratings for each wine, I is identity matrix, ε is a damping term for stabilization, C is the vector containing the sum of each wine vector residual (projected into the proxy space) for all wines (stored by the system from the previous training and ranking steps), and λ is per equation 5 for each wine. This updated λ_updateis used to update λ_user(λ_new+λ_update·λ_update), is stored by the system, and replaces λ_userin all future Step 4 rankings. The average custom-character ch is also updated accordingly from the composite list of all wines rated and in the dynamic database. Then as the user tries/rates more wines, the system will better adapt to the user's likes/dislikes and rankings will increase in accuracy going forward.

Retrieved (e.g., selected) wines may be ranked based on the similarity to the statistical proxy. The identifiers (e.g., labels, names, or the like) of the wines may be ranked. In some embodiments, when the ranked wines are provided, wine identifiers, location where the wine is available, degree of similarity, and/or pricing may be provided to the user. In some embodiments, the ranking module 206 may provide a value number based on price and fitness (e.g., akin to a PE ratio of a stock).

In various embodiments, the wine ranking system 108 provides a ranking of wines based on a subset of the wines in the wine database. For example, the user may request wines that are available based on location (e.g., restaurant, wine bar, or the like) and/or based on categorical classifications (e.g., wine color, winery, or the like). In some embodiments, the wine ranking system 108 may select a subset of the wine database to correlate with the user's wine proxy.

In one example, the selected subset of the wine database may include wines that are available at the user's location (e.g., wines of Forbes Mill Steakhouse of Los Gatos, Calif.) but not include wines that are not available at the user's location. Similarly, the wine ranking system 108 may select a subset of wines from the wine database based on categorical classifications. For example, the user may request a selection and/or ranking of wines that are red in color and is described as having a light body. The wine ranking system 108 may receive the categorical classifications in a wine request and select a subset of wines from the wine database that meet the categorical classifications.

In some embodiments, the wine ranking system 108 may utilize all wines in the wine database but subsequently select a subset of ranked and/or individually identified wines based on the user's location and/or categorical classifications. For example, all wine of the wine database may be ranked based on the user's wine proxy. The results may be filtered based on the user's location (e.g., only wines currently available at Beltramos Wine and Spirits or Beverages and More!) or based on the categorical classification(s) (e.g., red wines from Paso Robles, Calif.). The subset or filtered results may be provided to the user. Those skilled in the art will appreciate that there are many ways to identify and/or rank one or more wines based on the wine request.

The update module 208 is configured to update the user database (i.e., the user profile). In various embodiments, the update module 208 may receive an update request from a user via a digital device 102. The update request may include an identifier (e.g., a user or digital device identifier), a wine identifier as well as an indication of preference (e.g., 1-5 stars). The update module 208 may update the user's proxy based on the new information. For example, the update module 208 may retrieve a wine from the wine database based on the wine identified in the update request, weigh preexisting intensity values from the wine database based on the indication of preference and recalculate the user's wine proxy including the new information.

The registration module 210 is configured to register users. In various embodiments, the digital device 102 may provide the wine ranking system 108 a wine registration message. The wine registration message may include a user identifier (e.g., username, password, and the like) as well as other information personal to the user. In one example, the wine ranking system 108 comprises a web page that requests registration information (e.g., user identifier and other information) from an interested user. The registration module 210 may receive the information and generate a consumer wine preference profile for the user. The consumer wine preference profile may identify and link the user with the user's associated user wine database. The registration module 210 may issue a username, password, account number of the like. The registration module 210 may allow for communication of wine rankings and other information via a mobile device or any other device.

If registration is successful (e.g., sufficient user information is provided), the registration module 210 may trigger the training module 204 to request information regarding past wines consumed by the user and/or other experiences. Subsequently, the training module 204 may generate and/or train the user database.

The user profile database 212 may include any database(s) or other user structure(s) to store user databases. As discussed herein, a user database and/or the consumer wine preference profile may include any information regarding a user's past experiences with wine, including past wines consumed, user scores of the wine, past wine requests, past wine recommendations and rankings, location of the user, price point preferences of the user, user intensity preference values, and the like. In some embodiments, the user database comprises a wine proxy for the user based on information as described herein.

Those skilled in the art will appreciate that the user profile database 212 may be remotely located from the user and/or the wine ranking system 108. In some embodiments, the user profile database 212 may be stored in the user's digital device.

The wine database 214 may include the wine database as described herein. The wine database 214. The wine database 214 may include any database(s) or other user structure(s) to store one or more wine databases. The wine database 214 may be remotely located from the user and/or the wine ranking system 108.

A module is any hardware, software, or combination of both hardware and software. Those skilled in the art will appreciate that the modules identified in FIG. 2 may perform more or less functionality as described herein. For example, some modules may perform the functions of other modules. Further, functions shown with respect to FIG. 2 are not limited to a single digital device but may be performed by multiple digital devices performing different functions. In some embodiments, multiple digital devices perform functions simultaneously.

In some embodiments, one or more of the functions described herein may be performed on the user's digital device 102. For example, instead of sending an update request, the user may input the update information into the digital device 102 which may, in turn, generate the user database and/or wine proxy. The wine proxy or any other information may be provided to the wine ranking system 108 to receive a recommendation or wine ranking. In some embodiments, some information is provided to the digital device 102 which subsequently may apply the wine proxy, select wines, and/or rank wines. Those skilled in the art will appreciate that the functions described herein may be performed by different devices in any number of ways.

FIG. 4 is a block diagram of a digital device 102 in some embodiments. The digital device 102 may comprise a communication module 400, a GUI module 402, a wine request module 404, a wine categorical classification module 406, a location module 408, an update module 410, a wine selection module 412, and a local database 414.

In some embodiments, the digital device 102 is a mobile device such as a smart phone, tablet, or the like. The digital device 102 may comprise an application, app, or any other functionality to communicate with the wine ranking system 108 and provide wine selections and/or rankings. In one example, the communication module 400 comprises a browser configured to access a web page provided by the wine ranking system 108. The browser may be used to register, provide training information, provide update information, request wines, and/or request wine rankings. The communication module 400 may comprise any hardware or software configured to communicate with the wine ranking system 108.

In some embodiments, the communication module 400 communicates with the wine ranking system 108 over an encrypted link to protect user privacy and information. For example, a user may digitally sign communication or establish an encrypted connection with the wine ranking system 108 prior to registration, training the user wine preference profile, updating the user wine preference profile, and/or requesting wine rankings from the wine ranking system 108. Examples of encrypted technologies that may be utilized include, but are not limited to, hypertext transfer protocol secure (HTTPS), VPN, SSL, or the like.

The GUI module 402 may provide a graphical user interface to the user. The GUI module 402 may be a part of a wine ranking application or provide an interface for the user to provide and receive information. In some embodiments, the GUI module 402 may utilize one or more APIs of the wine ranking system 108 and/or any other device or software.

The wine request module 404 may provide a wine request to the wine ranking system 108. In one example, the user may activate a wine ranking application on a smartphone. The user may request a wine selection and/or a ranking of wines with the wine request module 404. The wine request module 404 may generate a wine request including a user identifier (i.e., an identifier of the user, the digital device 102, and/or the application providing the request) as well as categorical classifications for a desired wine (e.g., red wine). In some embodiments, the wine request module 404 generates a wine request including a type of food or other information that may assist in the determination of a selected wine or assist in the ranking of wines.

The wine categorical classification module 406 may provide a pull down menu or other selection options to assist the user in selecting relevant information that may affect wine selection and/or ranking of wines. As discussed herein, a user is not required to be sophisticated, rather, the user may have a general appreciation of wine. The wine categorical classification module 406, may provide the user with a vocabulary to help the user identify the desired wines. Selections provided by the wine categorical classification module 406 may be incorporated within the wine request by the wine request module 404.

The location module 408 may provide location information within the wine request provided by the wine request module 404. In various embodiments, the user may provide a location, such as restaurant, winery, or wine store information (e.g., identifying the restaurant, winery, or wine store), within the wine request. The wine request module 404 may provide the wine request, including the location, to the wine ranking system 108.

In various embodiments, the wine ranking system 108 may select wines based on the user's wine proxy and the categorical classifiers discussed herein. The wine ranking system 108 may select a subset of selected wines based on the location information (e.g., wines that are available at the location identified in the wine request). The subset may be ranked as discussed herein.

The update module 410 may be configured to generate and provide an update request to the wine ranking system 108. In various embodiments, the update module 410 and/or the GUI module 402 provides an interface to allow the user to input an identifier which identifies a previously consumed wine. The interface may include a field for the user to input the name of the wine. In some embodiments, the interface may include a list of possible wines (e.g., via a pull down menu or with radio buttons) or a grouping of fields and lists (e.g., a field for the name of the wine and pull down menus for the vintage and varietal). The update module and/or the GUI module 402 may also provide the user with a selection of options to score or otherwise rate the wine (e.g., 1-5 stars). Those skilled in the art will appreciate that the update module 410 may provide the wine ranking system 108 with any information to update the user database.

In various embodiments, the update module 410 may update the user database and/or update the wine proxy locally utilizing methods described herein.

The wine selection and ranking module 412 is configured to receive a wine selection and/or ranking from the wine ranking system 108. In various embodiments, the wine ranking system 108 provides wine selections and/or rankings in response to a wine request received from the wine request module 404. The wine selection and ranking module 412 may retrieve the wine selections and/or rankings received from the wine ranking system 108 and provide the results to the user. Those skilled in the art will appreciate that a single wine selection received from the wine ranking system 108 may be termed a wine recommendation.

In some embodiments, the wine selection and ranking module 412 may provide pricing and/or availability information to the user. For example, once wines are selected and ranked, the wine selection and ranking module 412 and/or the wine ranking system 108 may retrieve availability and/or pricing information for the ranked wines (or the wines ranked in the top ten). Pricing information may be retrieved from any source including retail stores, distributors, or collected information by the wine ranking system 108. Further, the wine selection and ranking module 412 may provide availability information to the user based on location information from the location module 408, the digital device's 102 location, location information provided in the user registration (e.g., based on state, city, or zip code), or general availability.

In some embodiments, the GUI module 402 may provide a preference ratio based on price and ranking. For example, the GUI module 402 may display highly ranked wines that are available under $20 with different colors, animations, a score (e.g., similar to a PE ratio in a stock), or other indicator that may encourage the user to try the wine, even if the wine is not identified as the highest ranked wine based on the user's historical wine characteristic preferences.

The local database 414 may comprise all or part of the consumer wine preference profile or user wine database. In some embodiments, the local database 414 may store information that may be used by the update module 410 (e.g., past wine preferences, past wine tried, purchase history, or the like). In one example, the update module 410 may provide update information periodically. For example, the update module 410 may provide update information after a predetermined duration, at predetermined times, or after a predetermined amount of information is gathered. In this example, information may be stored in the local database 414 at least until the update module 414 provides the update request to the wine ranking system 108.

In some embodiments, one or more of the functions described herein may be performed on the wine ranking system 108. Those skilled in the art will appreciate that the functions described herein may be performed by different devices in any number of ways.

FIG. 5 is a flow chart for generating a wine database in some embodiments. By utilizing a panel of experts and/or trained individuals utilizing a common set of descriptors, individual taste preferences and other subjectivity may be reduced. Further, the collective scoring of the descriptors by the trained experts and/or individuals based on observation allows for objective weighting of the descriptors. As a result, a wine database may be generated and utilized to more accurately select and rank wines based on the user's experiences and tastes.

In step 502, a plurality of wines are described utilizing descriptors. In various embodiments, a common set of descriptors (e.g., a corpus of descriptors) may be identified based on different wine characteristics (e.g., acidity, tannins, structure, alcohol, terror, and the like). The common set of descriptors may be used to describe all wines. For example, each wine may be associated with different intensity values associated with the different descriptors. As such, all wines may be commonly scored. The descriptors may be determined in any number of ways. Further, there may be any number of descriptors. In some embodiments, there are twenty-seven different descriptors that may be associated with intensity values to describe one wine.

Those skilled in the art will appreciate that the common set of descriptors may be defined using any methodology. For example, descriptors may be identified and included in the set based on common experience of the experts, ease of communication, and/or utility of meaning.

In step 504, the wine description module 202 is configured to receive predetermined intensity values for each descriptor. In some embodiments, experts or other individuals are trained to utilize the common set of descriptors as well as a scale for intensity values. Once trained, the experts and/or other individuals may taste a variety of different wines and individually assign intensity values for each descriptor associated with each wine. Once the intensity values for the descriptors associated with one or more wines is determined, the wine description module 202 may receive the intensity values. For example, the wine description module 202 may directly receive the intensity value data and/or tasting notes (e.g., the wines tasted, descriptors, and/or the assigned intensity values) from the experts and/or individuals. The wine description module 202 may be configured to translate the tasting notes from the experts and/or individuals into intensity values using NLP as discussed herein.

In some embodiments, the intensity values are averaged or combined in any number of ways. In various embodiments, the intensity values are not averaged but are maintained separately until a sufficient amount of information for each wine is gathered and then the information regarding the respective wine may be averaged or otherwise combined.

In step 506, the wine description module 202 generates a wine database based on the common set of descriptors and the predetermined intensity values (i.e., the intensity values provided by the experts and/or individuals described herein). In various embodiments, the wine description module 202 generates any number of databases or other data structures that contain any number vectors associating intensity values with wine descriptors and/or wine identifiers.

Those skilled in the art will appreciate that the wine database may be continuously updated based on new tastings of previously tasted wines by experts and/or individuals. In this example, one or more experts may taste a previously tasted wine and provide intensity values that may be combined and/or added with the previous intensity values (e.g., previous intensity values of a particular descriptor may be combined with the new information and the average recalculated).

In some embodiments, the wine description module 202 may age wine and/or information regarding previous tasting. Those skilled in the art will appreciate that certain wines may improve or otherwise change over time. The wine description module 202 may apply less weight to previous tasting information (e.g., apply less weight to previous intensity values associated with a previous wine tasting past a predetermined duration of time) and apply more weight to current tasting information (e.g., apply equal or increased weight to intensity values associated with a more current wine tasting). In some embodiments, the wine description module 202 may be configured to reduce weights of some intensity values associated with descriptors that tend to reduce over time and, similarly, may be configured to increase weights of some intensity values associated with descriptors that tend to increase over time).

FIG. 6 is a flow chart for training a user database in some embodiments. Those skilled in the art will appreciate that, unlike systems in the prior art, various embodiments described herein rely on objective descriptions of wines in terms of descriptors.

In step 602, once the user has registered with the wine ranking system 108, the wine ranking system 108 may receive one or more customer wine characteristics and/or preferences. For example, the user may provide information regarding past wines that the user has tasted. In some embodiments, the user may provide only general information (e.g., categorical classifications) including wine type, varietal, or other general information. The user provide other categorical classifications including, for example, specific wine information such as wine maker, winery, specific name, vintage, or any other information.

In step 604, the wine description module 108 may estimate wine character covariance. For example, a wine character covariance may be an N×N matrix (where N is the number of descriptors) for the wines identified in step 602. In some embodiments, if the user provides sufficient information, intensity values may be included for sufficiently identified wines (e.g., from the wine database). Intensity values may be estimated based on the wine information provided the user (e.g., based on wines that are information provided by the user such as a similar wine maker, winery, specific name, region of wine, vintage, or other information).

The wine character covariance may be based on the total number of wines identified by the user, the wine mean character intensity vector computed for all N characters across the identified wines, and character intensity values for each of the wines. As discussed herein, may be an estimate of the true covariance of all wines (including those that are not in the database).

In step 606, the wine description module 108 determines principal components. The principal components of the training database is determined by solving the Eigenvalue problem for N wine characters utilizing on a matrix that contains N Eigenvectors (i.e., principal components) of the de-correlated user wine parameter basis.

In step 608, the wine description module 108 approximates variance of wine characteristics. For example, the wine description module 108 may pick a subset of Eigenvectors to recue ambiguity or uncorrelated noise. The new Eigen-characters may approximate variance of wine characteristics. The calculated variance may be utilized as the user's individual “wine proxy” as the set of Eigen-characters, mean character vector, and relative importance values (i.e., filter weights).

In step 610, the wine description module 202 stores the variance (e.g., the user's “wine proxy”) within the user's preference profile. The wine description module 202 may store the information within the user profile database 212, the wine database 214, and/or on the user's digital device (e.g., digital device 102).

FIG. 7 is a flowchart for a user receiving ranked wines on a user's digital device 102 in some embodiments. In various embodiments, the user may indicate a desire to receive a list of ranked wines. The user may engage an application or contact the wine ranking system 108 to provide a wine request. In step 702, the GUI module 402 displays available descriptors and/or categorical classifications to the user. In one example, the user may be encouraged to select one or more of the provided categorical classifications to indicate the type of wines to be ranked.

For example, the GUI module 402 may provide a list of descriptions of wines including possible wine regions of preferred wines, color of wines, common vintages, or the like. In some embodiments, a limited set of categorical classifications may be provided to the user to train the user wine database. The wine ranking system 108 may comprise translators to associate the user's selected categorical classifications with any number of descriptors and/or related intensity values. In some embodiments, the intensity values may be neutral until or unless the user indicates a degree of preferences (e.g., number of stars or other indication of preference). In some embodiments, the GUI module 402 provides fields that the user may provide text input identifying descriptors and/or categorical classifications.

In step 704, the GUI module 402 may receive a selection of one or more categorical classifications from the user. In step 706, the wine request module 404 may generate a wine request including an identifier (e.g., identifying the user, a related user account, and/or the device to receive the wine ranking). The wine request may also include the categorical classifications from the user. In some embodiments, the wine request includes the contents of fields input by the user.

In step 708, in response to the wine request, the wine selection and ranking module 412 may receive a wine request response in response from the wine ranking system 108. The wine request response may comprise a recommended wine (e.g., a selected wine) or a list of ranked wines based on the provided information as well as the previously provided information from the user. The list may comprise wine identifiers ranked by the user's preference as represented by the user wine database.

In step 710, the GUI module 402 displays ranked wine identifiers (e.g., the ranked list) from the wine request response. In various embodiments, the GUI module 402 may reorder the list or re-rank the list based on availability, location of the digital device, price, or any preferences not provided by the wine request module 404. In some embodiments, the GUI module 402 allows the user to filter the ranking in any number of ways.

In step 712, the update module 410 may receive a user's wine identifier selection (e.g., a selection of at least one of the ranked wines) indicating that the user has chosen to try the selection. In step 714, the update module 410 may provide the selection to the wine ranking system 108 to update the user's wine database and/or wine proxy. In some embodiments, the user may provide a score (e.g., star rating) to a wine at the time the update module 410 provides the selection. Alternately, the user may provide the scoring at a later time (e.g., the wine ranking system 108 may provide a message requesting that the user provide a score to the wine identified by the update module 410).

In various embodiments, the user may update the user wine database and/or consumer wine preference profile utilizing a card such as a loyalty card and/or credit card during purchases. For example, a user may provide such a card during wine purchases. An employee at a restaurant, retail establishment, winery, or the like may scan the card. As a result, the wine ranking system 108 may receive an indication of wines purchased by the user during the transaction. The wine ranking system 108 may updated the user's consumer wine preference profile based on the information. In some embodiments, the wine ranking system 108 may provide the user with an email or other communication requesting that the user provide a score or other indication of user preference which may be used to weight intensity values associated with the purchased wine(s). In some embodiments, if no response is received, the wine ranking system 108 may apply a neutral weight or disregard the purchases.

Those skilled in the art will appreciate that the purchase may not be limited to cards, but may include providing a code or other identifier during online purchases. Digital passports or wallets (e.g., possibly utilizing NFC communications) may similarly be used to provide purchase information to the wine ranking system 108. Moreover, in some embodiments, an application may be provided that allows a user's mobile device to scan bar codes and/or provide photographs of labels to allow the wine ranking system 108 to update the consumer wine preference profile. In this example, the wine ranking system 108 may include a bar code database that allows the wine ranking system 108 to identify the related wine. Similarly, the wine ranking system 108 may include a scanning module configured to process images from smartphone cameras to identify wines. Various labels and/or label information may be stored within one or more databases. The label information may be utilized to identify at least portions of a label to allow for matching (e.g., utilizing hashed information of the labels for matching) and wine identifications.

FIG. 8 is a flowchart for providing ranked wines to the user's digital device 102 in response to a wine request in some embodiments. In step 802, the wine ranking system 108 receives a wine request from the digital device 102. In various embodiments, the ranking module 206 receives the request. The request may comprise an identifier that identifies the user (e.g., username, password, and/or account number) or the digital device 102.

In step 804, the ranking module 206 may retrieve the consumer wine preference profile based on the identifier from the wine request. The consumer wine preference profile may comprise the user's precalculated wine proxy and/or other information. In some embodiments, the ranking module 206 retrieves the user's wine database based on the consumer wine preference profile.

In optional step 806, the ranking module 206 may retrieve a subset of descriptors and/or predetermined intensity values from the wine database based on information contained in the wine request. For example, the user may include location information and/or categorical classification information within the wine request. The ranking module 206 may retrieve a subset of descriptors and/or predetermined intensity values from the wine database that are consistent with the location information (e.g., available at the user's current location) and/or categorical classification (e.g., white wine from France).

In some embodiments, the ranking module 206 may retrieve all descriptors and predetermined intensity values from the wine database and correlate the information with the user's wine proxy (e.g., the user preference intensity values). After wines are selected based on the correlation, the ranking module 206 may filter the results to remove wine that are not associated with the location and/or categorical classifications of the wine request. In some embodiments, the filtering may occur after the wines are ranked. In some embodiments, the entire selection and/or ranking may be provided to the digital device 102 of the user which performs the filtering step.

In step 808, the ranking module 206 may retrieve at least a subset of the user preference intensity values based on the categorical classifications within the wine request. For example, the ranking module 206 may select only those user preference intensity values associated with wines that meet the categorical classifications. In some embodiments, the ranking module 206 retrieves all of the user preference intensity values and/or the user's wine profile for all wines identified by the user.

In step 810, the ranking module 206 correlates the user preference intensity values with predetermined intensity values from the wine database as retrieved in step 806. The ranking module 206 may select any number of wines based on the correlation. The correlation process is described herein.

In step 812, the ranking module 206 selects and ranks two or more wines based on the correlation. As discussed herein, the system may rank wines based on an objective assessment calibrated to the user's preferences based on the user's personal experience. In step 814, the ranking module 206 may provide identification(s) of the selected wines (e.g., a ranked list) to the digital device 102.

FIG. 9 is a flowchart for updating a user wine database in some embodiments. In various embodiments, the wine ranking system 108 receives a wine update request from a digital device 102. The wine update request may comprise a wine identifier and/or a preference rating (e.g., a score of 1-5 indicating the user's preference or enjoyment of the identified wine). Those skilled in the art will appreciate that there may be any range of ratings (e.g., 1-4 stars, 1-10 points, or the like). Further, those skilled in the art will appreciate that rankings may be any numerical or non-numerical value.

In step 904, the update module 208 may retrieve the wine identifier and the preference rating. The update module 208 may incorporate the new observations into the user's wine proxy. In some embodiments, the process is similar to a mathematical regression whereby a new lambda is generated (see equation 7 herein) which updates the user's lamba for future rankings in step 906. The wine average custom-character ch is also updated. As a result, as new wines are tried and added to the system, the rankings, selections, and/or recommendations of the wine ranking system 108 may improve.

Those skilled in the art will appreciate that systems and methods described herein may be applied outside of wine. In various embodiments, systems and methods described herein may be utilized to recommend and/or rank food and wine pairings, foods in general, or the like. In some embodiments, a “pseudo-wine” may be calculated based on shared descriptors between wines and food. For example, there may be eight descriptors that related to food and wine. The eight descriptors may be used to describe the characteristics of the food in question. Different foods with different intensities (i.e., intensity values) related to descriptors may be used to create a “food proxy” in a manner similar to the construction of the wine proxy (e.g., utilizing the descriptors and associated intensity scores for the food(s) of interest). Similarity between the food proxy and wines in the wine database may be utilized to provide a wine pairing recommendation. Those skilled in the art will appreciate that any number of descriptors may be utilized to describe food.

In one example, experts and/or trained individuals may establish or may utilize a common parameter set of descriptors to describe foods. The experts and/or trained individuals may taste a wide variety of foods and/or types of one or more foods (e.g., meats). The experts and/or trained individuals may score intensity values based on the descriptors to describe the food. This information may be used to translate a request for a food and wine pairing (e.g., a request to match rib eye steak and wine) into a food proxy as described herein that may be utilized for the similarity assessment, selection, and/or ranking.

Various embodiments described herein may be utilized to apply to foods (e.g., olive oils or combinations of different foods such as different meats combined with other non-meat consumables) or other goods. For example, the ranking module 206 of the wine ranking system 108 described with regard to FIG. 2 may be configured to identify foods of interest to users based on descriptors and user preference intensity values from an associated user database (e.g., user profile). Similar to the wine method, the ranking module 206 may take parametric information (characters and intensities) from the user training database, perform a spatial correlation across parameters and food entries, and use the resulting statistical correlations to mathematically reduce the parameter set to a limited number of new uncorrelated variables which, taken in linear combination, may uniquely define the user's food preference (i.e., the user food proxy).

Describing an approach utilizing principal component analysis as one example, the mathematical procedure transforms, a number of correlated variables (i.e., food characters in this case) into an equal number of uncorrelated variables (vectors) (principal components) while maintaining full variance and ordering the components by contribution. The resulting transformation may be such that the first principal component represents the largest amount of variability (i.e., has the largest weight), while each successive component may account for at least some of the remaining variability.

For example, a training database, similarly generated as that of the training database for the wine example, has M foods and that each food has N characters (e.g., descriptors). A food character covariance (N×N) matrix then can be estimated from the training database according to the approximation:

$\begin{matrix} C = 1 / M \sum_{i = 1}^{M} {[{ch}_{i} - 〈 ch 〉]}^{T} [{ch}_{i} - 〈 ch 〉] & (1) \end{matrix}$

where M is the total number of foods in the training database, custom-character ch is the food mean character intensity vector computed for all N characters (i.e., intensity values) across all M foods, and ch_iis each character intensity vector (length=N) for each of the M foods in database.

Since C is a symmetric semi-positive definite matrix, the principal components of the training database may be computed by solving the Eigenvalue problem for the N food characters:

Cλ=λV (2)

The matrix V contains the N Eigenvectors (i.e., principal components) of the decorrelated user food parameter basis. The vector λ contains the N Eigenvalues (principal component weights representing the relative importance of each individual Eigen-character. V_i, in describing the user's food “type”).

The ranking module 206 may pick a small or smallest subset, P<<N, of Eigenvectors from this base that adequately account for most of our food character variability according to the criteria, e.g.:

Σλ_i[1:P]/trace[C]≧70% (3)

Whether the system uses all Nor just P components of the de-correlated basis, these new food Eigen-characters approximate the variance (and to a lesser extent the correlation) of food characteristics follow the mathematical form:

Var[food ]
_user
=
custom-character
ch

+λ
_user
V (4)

In this context, the larger each λ_i, the more important (and more correlated across the database) each component, V_i, may be in describing the likes of the user for the particular set of foods in the training.

As similarly described herein, equation 4 may project the food characters into a new mathematical space (i.e., the user “proxy space”) that exploits the statistical relationship between different food characters.

Those skilled in the art will appreciate that the largest Eigenvalue (λ₁) in equation 4 may represent the least distinguishing proxy character for food, because all food may share this character (this v₁represents the maximum correlation between all wines in the subset), while the smallest Eigenvalue (λ_N) may represent the most distinguishing proxy character, because it is correlated between foods less than all other food characters—it may be the most unique Eigen-character.

Once the user proxy is computed, future user food requests may be filtered by the operator V in order to transform all foods from a new “dynamic” database into the user's proxy space. To this end, equation 4 may allow the user to specify new food descriptors they are currently interested in having the system rank. The update module 208 then uses this information to build a dynamic database which is distinct from the training discussed herein. In one example, the update module 208 updates the existing user database with foods to those of current interest. Then the update module 208 “projects” each food (e.g., the update module 208 projects each wine's characteristics as defined herein) contained in this dynamic database to the user proxy space by solving the small (P×P) principal component (PC) problem:

λ_food_i=[ch_food_i− custom-character ch]v (5)

Here, λ_foodis each of i foods PC defined by each character vector, ch_food, contained in the dynamic database and filtered by the Eigen-vector operator V.

Then the system can rank (in either ascending or descending order) all i foods from the dynamic database according to their mathematical similarity/difference, S_i, in the proxy space to the previously defined user food proxy values, λ_user, from equation 4:

S
_i=Σ_i=1^P|λ_user−λ_food_i| (6)

In various embodiments, every food in a database that matches a search may be assessed. In one example, foods are retrieved that match a search based on a user food request and then the related descriptors may be converted to a mathematical space to look for similarity with the statistical proxy.

Retrieved (e.g., selected) foods may be ranked based on the similarity to the statistical proxy. The identifiers (e.g., labels, names, or the like) of the foods may be ranked. In some embodiments, when the ranked foods are provided, food identifiers, location where the food is available, degree of similarity, and/or pricing may be provided to the user. In some embodiments, the ranking module 206 may provide a value number based on price and fitness.

As discussed herein regarding wine, the user food proxy may then be updated to reflect these user feedback ratings by solving a regression problem (mathematical fitting problem). This technique (which has many embodiments) may incorporate new observations (user ratings) into the user proxy vector (λ) via the general mathematical form:

[λ_update]=[λR_wλ^T+εI]⁻¹λ^TR_wC (7)

As discussed herein, R_w, is a diagonal weighting matrix containing the relative user ratings for each wine, I is identity matrix, ε is a damping term for stabilization, C is the vector containing the sum of each wine vector residual (projected into the proxy space) for all wines (stored by the system from the previous training and ranking steps), and λ is per equation 5 for each wine. This updated λ_update, is used to update λ_user(λ_new=λ_update·λ_update), is stored by the system, and replaces λ_userin all future Step 4 rankings. The average custom-character ch is also updated accordingly from the composite list of all wines rated and in the dynamic database. Then as the user tries/rates more wines, the system will better adapt to the user's likes/dislikes and rankings will increase in accuracy going forward.

In various embodiments, the food ranking system 108 provides a ranking of foods based on a subset of the foods in the food database. For example, the user may request foods that are available based on location (e.g., restaurant, wine bar, or the like) and/or based on categorical classifications (e.g., meat, vegetable, texture, or consistency). In some embodiments, the system may select a subset of the wine database to correlate with the user's food proxy.

Those skilled in the art will appreciate that systems and methods described herein may not be limited to consumable good such as food and drink, but may be extended to ranking and/or recommendation of coupons or the like.

FIG. 10 depicts an exemplary digital device 1000 according to some embodiments. The digital device 1000 comprises a processor 1002, a memory system 1004, a storage system 1006, a communication network interface 1008, an I/O interface 1010, and a display interface 1012 communicatively coupled to a bus 1014. The processor 1002 may be configured to execute executable instructions (e.g., programs). In some embodiments, the processor 1002 comprises circuitry or any processor capable of processing the executable instructions.

The memory system 1004 is any memory configured to store data. Some examples of the memory system 1004 are storage devices, such as RAM or ROM. The memory system 1004 may comprise the RAM cache. In various embodiments, data is stored within the memory system 1004. The data within the memory system 1004 may be cleared or ultimately transferred to the storage system 1006.

The storage system 1006 is any storage configured to retrieve and store data. Some examples of the storage system 1006 are flash drives, hard drives, optical drives, and/or magnetic tape. In some embodiments, the digital device 1000 includes a memory system 1004 in the form of RAM and a storage system 1006 in the form of flash data. Both the memory system 1004 and the storage system 1006 comprise computer readable media which may store instructions or programs that are executable by a computer processor including the processor 1002.

The communication network interface (com. network interface) 1008 may be coupled to a data network (e.g., communication network 106) via a link. The communication network interface 1008 may support communication over an Ethernet connection, a serial connection, a parallel connection, or an ATA connection, for example. The communication network interface 1008 may also support wireless communication (e.g., 802.11a/b/g/n, WiMAX). It will be apparent to those skilled in the art that the communication network interface 1008 may support many wired and wireless standards.

The optional input/output (I/O) interface 1010 is any device that receives input from the user and output data. The optional display interface 1012 is any device that may be configured to output graphics and data to a display. In one example, the display interface 1012 is a graphics adapter.

It will be appreciated by those skilled in the art that the hardware elements of the digital device 1000 are not limited to those depicted in FIG. 10. A digital device 1000 may comprise more or less hardware elements than those depicted. Further, hardware elements may share functionality and still be within various embodiments described herein. In one example, encoding and/or decoding may be performed by the processor 1002 and/or a co-processor located on a GPU.

The above-described functions and components may be comprised of instructions that are stored on a storage medium such as a non-transitory computer readable medium. The instructions may be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage medium are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with some embodiments. Those skilled in the art are familiar with instructions, processor(s), and storage medium.

Various embodiments are described herein as examples. It will be apparent to those skilled in the art that various modifications may be made and other embodiments can be used without departing from the broader scope of the present invention. Therefore, these and other variations upon the exemplary embodiments are intended to be covered by the present invention.

Systems and Methods for Wine Ranking

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims

CROSS-REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)