EP2915063A1 - Systems and methods for providing enhanced neural network genesis and recommendations to one or more users - Google Patents

Systems and methods for providing enhanced neural network genesis and recommendations to one or more users

Info

Publication number
EP2915063A1
EP2915063A1 EP13852285.9A EP13852285A EP2915063A1 EP 2915063 A1 EP2915063 A1 EP 2915063A1 EP 13852285 A EP13852285 A EP 13852285A EP 2915063 A1 EP2915063 A1 EP 2915063A1
Authority
EP
European Patent Office
Prior art keywords
data
venues
user
venue
recommendation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP13852285.9A
Other languages
German (de)
French (fr)
Other versions
EP2915063A4 (en
Inventor
Nathan R. Wilson
Luyao LI
Emily A. Hueske
Eleanor KENYON
Thomas C. Copeman
Michael D. Houle
Joakim A. Sternberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nara Logics Inc
Original Assignee
Nara Logics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/669,150 external-priority patent/US20140129371A1/en
Priority claimed from US13/842,665 external-priority patent/US8732101B1/en
Priority claimed from US13/842,165 external-priority patent/US20140279196A1/en
Application filed by Nara Logics Inc filed Critical Nara Logics Inc
Publication of EP2915063A1 publication Critical patent/EP2915063A1/en
Publication of EP2915063A4 publication Critical patent/EP2915063A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G06N5/022—Knowledge engineering; Knowledge acquisition
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0251—Targeted advertisements
    • G06Q30/0259—Targeted advertisements based on store location
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0251—Targeted advertisements
    • G06Q30/0261—Targeted advertisements based on user location
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0251—Targeted advertisements
    • G06Q30/0269—Targeted advertisements based on user profile or attribute

Definitions

  • Search engines may output lists of hyperlinks for web pages that include information of interest. Some search engines base the determination of corresponding hyperlinks on a search query entered by the user. The goal of the search engine is to return links for high quality, relevant sites based on the search query. Most commonly, search engines accomplish this by matching the terms in the search query to a database of stored web pages or web page content. Web pages that include the terms in the search query are considered "hits" and are included in the list of hyperlinks presented to the user.
  • a search engine may rank the list of hits or hyperlinks according to the relevance or quality. For example, the search engine may assign a grade or rank to each hit, and the score may be assigned to correspond to the relevance or importance of the web page. Conventional methods of determining importance or relevance are based on the content of each web page including the link structure of the web page.
  • indexing system for identifying web pages available on the Internet.
  • the indexing system identifies words in the pages and creates an index of those words.
  • the system responds to user queries by analyzing the index and identifying the pages that are most relevant to the users query.
  • the relevance ranking or determination can be executed in various ways.
  • the citation of one site or page by other sites or pages is sometimes used as one measure of relevance.
  • Web page metadata is also sometimes used in a determination of relevance.
  • Neural networks have also been used in the field of Internet searching. It is assumed, for purposes of this description, that the reader is familiar with how neural networks operate.
  • a neural network can consist of three basic aspects—a neuron or node, definitions of how the neurons or nodes are interconnected or related to each other, and the manner in which that topology is updated over time.
  • Person A may be connected with Person B by way of a social networking interface.
  • the social networking interface may allow users to indicate a preference for certain consumer goods, movies, music, television shows, venues, and the like.
  • the social network may provide recommendations to Person A based on the stated preferences of Person B. That is, Person B's preferences are directly mapped to Person B.
  • systems are available for providing recommendations based on personality traits.
  • online dating services may develop a personal profile for a user, and provide recommendations on potential partners based on personality metrics indicating a likely favorable match. Again, these systems merely provide individualized recommendations for partners; however, such systems fail to provide harmonized
  • a shift in consumer technology from desktop computing to mobile applications has led to a pronounced emphasis on computation and interfaces that incorporate a user's location.
  • systems can provide particular information of interest arising out of that geographic location. For example, upon detecting that a user has entered a new city or neighborhood, a mobile application may provide local restaurants or shopping areas of interest to the user in that area.
  • a recommendation generator builds a network of interrelationships between venues, reviewers and users based on their attributes and reviewer and user reviews of the venues which are enhanced by dynamic resonance between source sites.
  • the recommendation engine in certain embodiments determines recommended venues based on user attributes and venue preferences by performing geometric contextualization on generated recommendation sets and determining recommendation resonance with past recommendations.
  • Remote businesses may also link with the recommendation generator to receive recommendations custom-tailored to their business.
  • interconnectivity augmentation provides for enhanced neural network topology and recommendations for foreign locales.
  • Various user interfaces are also contemplated thereby providing users with a view of the neural network topology as well as the ability to collaboratively determine meeting places.
  • a system may receive attribute data corresponding to attributes of a plurality of users and to one or more venues for which the plurality of users has an affinity.
  • a user personality matrix may be calculated for one or more of the plurality of users based on interrelational nodal link strengths between the one or more users and the venues.
  • the user personality matrices may be merged to calculate a combined personality matrix representing a unified taste profile for the one or more users.
  • a candidate list of venues having the highest link strength with the combined personality matrix may be determined.
  • One or more recommended venues from the candidate list of venues that have the strongest links to the combined personality matrix may be determined, and
  • recommendation data corresponding to the recommended venues may be output.
  • data is spatially segmented into a variety of grids having particular keyed location data. Items of interest located within the boundaries of each grid are identified and stored in association with the grid information. Data with respect to attributes of items of interest is encoded and stored in association with corresponding grid data. The system will identify a grid or grids based on a recommendation request or based on the user data and will generate a list of items of interest in that grid and neighboring grids. This information is filtered based on the particularities of the user request to form a final filter set. The encoded information is then parsed to determine venue attributes of the final filter set. User attribute weights are then applied to the final filter set to determine an overall score for each item of interest. Items of interest are provided as recommendations to the user based on the overall scores.
  • Figure 1 A is a block diagram of an environment for developing and utilizing a network of interrelated nodes
  • Figure IB is a diagram of a process flow executed by an exemplary content collection system
  • Figure 1C is a diagram of a process flow executed by an exemplary content organization system
  • Figure 2 is a diagram showing the interrelationships between venues, reviewers and users
  • Figure 3 is chart including reviewer ratings according to one example
  • Figure 4 is a chart including venue attributes according to one example
  • Figure 5 is a chart including reviewer attributes according to one example
  • Figure 6 is a chart including user attributes according to one example
  • Figure 7A and 7B show a matrix of content-based venue links according to one example
  • Figures 8A and 8B show a matrix of collaborative venue link according to one example
  • Figure 9 is a chart illustrating a recommendation generation according to one example
  • Figure 10 is a chart illustrating a connection grown according to one example;
  • Figure 1 1 is a chart illustrating pre-normalization matrix data according to a second example;
  • Figure 12 is a chart illustrating post-normalization matrix data according to a second example
  • Figure 13 is a chart illustrating connection creep according to a second example
  • Figure 14 is an exemplary user interface
  • Figure 15 illustrates a topographical world view user interface displaying the neural network topology according to one example.
  • Figure 16 illustrates a topographical local view user interface displaying the neural network topology according to one example.
  • Figure 17 illustrates a collaborative decision making user interface according to one example.
  • Figure 18 is a chart illustrating the data repository of previous recommendations served to users according to one example.
  • Figure 19 is a chart illustrating aggregate data repository recommendation data according to one example.
  • Figure 20 is a flow chart illustrating error correction and data verification processing according to one example.
  • Figures 21 A-21D illustrate recommendation generation and recommended data values after geometric contextualization according to one example.
  • Figure 22 is a flow chart illustrating geometric contextualization processing according to one example.
  • Figure 23 is a chart illustrating reviewer ratings between different locales according to one example.
  • Figure 24 shows a matrix of collaborative venue links based on the reviewer ratings illustrated in Figure 23 according to one example.
  • Figure 25 illustrates inter nodal connections after interconnectivity augmentation processing according to one example.
  • Figure 26A is a chart illustrating venue attributes according to one example.
  • Figure 26B is a chart illustrating congruency factors determined via interconnectivity augmentation according to one example.
  • Figure 27 illustrates inter nodal connections after interconnectivity augmentation processing according to one example.
  • Figure 28 illustrates an exemplary interaction via the system API between the server and a plurality of merchants.
  • Figure 29 is an exemplary algorithmic flow chart for calculating a user personality matrix according to one example
  • Figure 30 is an exemplary user personality matrix according to one example
  • Figure 31 is an exemplary algorithmic flow chart for calculating a combined personality matrix according to one example
  • Figures 32A and 32B are illustrative examples of calculating a combined personality matrix according to one example
  • Figure 33 is an exemplary algorithmic flowchart for determining shared resource
  • Figure 34 is an exemplary algorithmic flowchart for filtering candidate venues according to one example
  • Figure 35 is an exemplary algorithmic flowchart for applying user weights to shared recommendations according to one example.
  • Figure 36 illustrates an exemplary user interface according to one example
  • Figure 37 illustrates an exemplary user interface according to one example
  • Figure 38 illustrates an exemplary user interface according to one example
  • Figure 39 illustrates an exemplary user interface according to one example
  • Figure 40 is chart including venue attributes according to one example
  • Figure 41 is a chart including user attributes according to one example
  • Figure 42 is a chart illustrating user attribute weight data according to one example
  • Figure 43 is a flow chart illustrating geospatial segmentation according to one example
  • Figure 44 is a diagram of a geospatially segmented geographic location according to one example
  • Figure 45 is a chart including keyed segmentation data according to one example
  • Figure 46 is a flow chart illustrating data encoding according to one example
  • Figure 47 is a chart including encoding parameters according to one example
  • Figure 48 is a chart including encoded data according to one example.
  • Figure 49 is a flow chart illustrating the process of providing personalized recommendations according to one example.
  • a recommendation engine may generate recommendations based on attributes and data associated with venues, users, reviewers and reviews.
  • the system may harvest reviews generated by various reviewing entities parse those reviews into an organized database of review data. That data may include attributes of the venue (such as a restaurant) and the rating or assessment provided by the reviewer.
  • the system may also gather or generate data concerning the attributes of reviewer, such as gender, age, profession, marital status, review frequency and review accuracy.
  • the system in one implementation, also gathers data concerning the attributes of user, such as gender, age, profession, marital status, and affinity (whether positive or negative) for certain venues.
  • the exemplary system may generate a neural network of interrelationships based on venue attributes and reviewer attributes. For instance, venues may be linked by common features such as price, genre, attire, location, or affinity expressed by the same reviewer. Reviewers may be linked by personal characteristics or common affinities for certain venues. Reviewers and venues may be linked by common attributes of reviewers with a given affinity for a specific venue or common venue attributes for venues liked by a given reviewer.
  • the system may create interrelationships between and amongst venues and reviewers of different species.
  • interrelated venues may include restaurants, theaters, events and institutions.
  • Interrelated reviewers may include periodicals and individual reviewers.
  • Each link may incrementally strengthen or weaken the overall interrelationship between two venues, a venue and a reviewer, or two reviewers.
  • Each link may affect neighboring links, either by causing the neighboring links to strengthen or weaken based on the magnitude of the origin link.
  • the system can generate an additional link or
  • the interrelationships can be broadly categorized as collaborative and content-based. Collaborative relationships are a function of affinities expressed by a given reviewer. Stated another way, collaborative links are usually between things a given user likes, often irrespective of why the user likes them. Content-based relationships are a function of the features held in common among venues in a given subset. Stated another way, content-based links are usually between things within a group which have common features. Hybrids of these approaches may also be used, for example, a link may identify venues among those liked by a given reviewer which have features in common.
  • the neural network of interrelationships grows dynamically as further review, reviewer and venue data is added.
  • the system may continuously analyze the data to add positive or negative collaborative links, content links, or content-collaborative links.
  • the system may create new derivative links, normalize the data to adjust for data skew, and adjust links based on neighboring link values.
  • the system may generate recommendations based on user attributes and data associated with a recommendation request.
  • the system may provide a plurality of recommendations based overall link strengths that factor in collaborative and content-based interrelationships.
  • the recommendations may include venues complementary to that specifically requested, for instance, in response to a user request for a restaurant recommendation the system may generate a theater or night club recommendation as well.
  • personalization profiles may be determined concurrently for a plurality of users for the purpose of providing "shared recommendations.”
  • Shared recommendation generation may include defining a "user personality matrix" defining features of each user in the plurality of users (i.e., the group), generating a combined personality matrix defining features of the group, and determining a set of shared recommendations based on the combined personality matrix.
  • a user's affinity for a particular entity or property may be determined when generating a user personality matrix.
  • Mathematical computations for determining a user's affinity for a particular entity or property may include data mining functions for analyzing previous indications of an affinity for the entity or property.
  • a positive or negative affinity for an entity or property may include an analysis of purchase history, user reviews, interrelationships with users and/or venues, similarities between properties, survey results, and other factors described herein.
  • aspects of the present disclosure may include creating and utilizing a unified taste profile (i.e., a combined personality matrix derived from aggregated user personality matrices) when determining recommendation candidates for a group of users.
  • the recommendation candidates may, e.g., indicate an optimal decision
  • a recommendation engine may generate recommendations based on attributes and data associated with venues, users, and reviews.
  • the system harvests this information from throughout the Internet and stores it in a data repository.
  • geographic data is spatially segmented into a variety of grids having particular keyed location data. Each grid can be associated with other neighboring grids. Further, items of interest located within the geographic boundaries of each grid are identified and stored in association with the grid location information. Data with respect to venue attributes is encoded and stored in association with corresponding grid location data.
  • users of the system will request recommendations or the system will automatically provide recommendations based on the grid data and encoded data.
  • the system will identify a location of the request or the user and generate a list of items of interest in that location and neighboring locations. This information is then filtered based on the particularities of the user request to form a final filter set. User attribute weights determined from user affinity data are then applied to the final filter set to determine an overall score for each item of interest. Items of interest having an overall score above a predetermined threshold are then provided as recommendations to the user.
  • Figure 1A illustrates an exemplary network architecture for a server-based recommendation generation system 100. It will be understood that some or all of the functionality described herein may be relocated to a client device application (such as a smart phone application) based on the client device's communication, data storage, and
  • the server 102 may host a plurality of engines and modules.
  • the user interface module 110 resides on the server 102 and serves web pages and/or suitable content to a client side application.
  • the crawl and parsing module 1 14 executes the web crawling and source data collection operations described below.
  • the recommendation engine 1 12 accesses the matrices of interrelationships and/or combined personality profile matrices to generate recommendations according to the techniques described herein.
  • the merchant interface provides the functionality described below concerning venue operators' interaction with the server and accessing projections and reports generated thereby.
  • the data repository 118 stores the matrices of interrelationships.
  • the repository includes a matrix builder 126 that builds data structures reflecting nodal interrelationships based on review data 122, which is collected from review sites 106 by the crawl and parsing module 114.
  • the matrix builder 126 also incorporates at least venue, reviewer, and user data 124 collected from users 108, venues 104, and other web pages (by the crawl and parsing module 114).
  • the network 120 includes the Internet or World-Wide Web.
  • the network may also comprise proprietary and semi-propriety networks such as cellular data networks, intranets, VPNs, or extranets.
  • the nodes in the neural network in one implementation are venues such as restaurants, theaters, night clubs, hotels, concerts and other events. However, due to the flexibility of the systems and methodologies described herein they may be applied in a variety of other manners.
  • Nodes in the network may be sub-venue items such as specific menu items or specific rooms inside a hotel.
  • the nodes may also be style consumables such as clothing, furniture, or wine.
  • the nodes may also be content such as music, books, magazines, TV shows, or movies.
  • the nodes are optionally set to be services such as mechanics, barbers, transportation, doctors, dentists, landscape architects, interior designers, or nanny services.
  • the nodes may be neighborhoods or cities in which to live, real estate to purchase/rent, colleges to apply to, careers that are a good fit, or grocery stores.
  • the nodes may be associated with social aspects such as friends and activities the user or group of users might like.
  • the nodes in other embodiments may be medical conditions or treatments.
  • the nodes may be business, political, and military strategies, which may included simulated outcomes.
  • the techniques described herein may also be used for fraud detection by providing predictions of what a user or group of users is unlikely to do, which in turn is more likely to be associated with fraudulent use of a credit card (for instance).
  • the techniques may also be used for marketing/co-branding opportunities by predicting brand affinity even across disparate categories.
  • the techniques may also be applied to actuarial/risk assessment applications by analyzing co-occurrences between a user's fine-scale likes and dislikes, which can be utilized as indicators of risk.
  • the techniques may also be used to predict financial market behavior or trends by aggregating markets into "group users” and predicting behavior of that group user as described hereinbelow. In a similar vein, predictions on mass human behavior can be achieved with respect to geographic movement (migratory patterns) and thereby census and demographic projections over time may be generated for use by retailers, real estate developers, and others.
  • the techniques may be used to gauge affinity for certain types of media (such a television shows) or media channels (cable or web).
  • the nodal attributes, reviewer attributes, and the corresponding interrelationships will be selected to correspond in part to the factors that are causally associated with a user or group of users' preferences for certain nodes.
  • the nodal attributes may includes skills associated with each profession and user attributes may include aptitude scores or survey questionnaire results.
  • the system 100 is described in connection with exemplary systems in which the nodes are venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • venues such as restaurants, hotels, or theaters.
  • a user's or reviewer's affinity (again, positive or negative) for a venue may be derived from both evaluations and assessments of venues, such as reviews or ratings, and implicit data sources, such as ant trails. Individuals may publish ratings on social web pages, review forums and websites or blogs. Ratings may also be published by votes placed via "Like” or "Digg” buttons disposed on various websites. As one example, user reviews of restaurants can be found at menuism.com, dine.com, opentable.com, google.com,
  • An individual's affinity for certain venues can also be discerned from their spending habits or purchase history, data of which can be gleaned from financial transaction records such as credit card statements.
  • An individual's web browsing history or ant trail can also provide insight into affinities for certain venues, as discerned from cookies or the various reviews an individual generates across multiple forums, including but not limited to websites associated with each venue.
  • An individual's website navigation bookmarks and browsing history also reflect browsing behavior and may likewise be mined for source data.
  • the geographic position of an individual over time such as information derived from cellular GPS data, can likewise be correlated with venues and thereby generate data reflective of venue affinity. This approach may provide dwell time data as well, which can be used to sort or arrange the data. Magazine subscription information may also be used as an indicator of an individual's affinity for given venues (as that term is broadly used herein).
  • An individual's professional licenses can also be used as data sources for determining an affinity for venues, including but not limited to organizations.
  • the foregoing sources of data concerning venue affinity can be prioritized based on factors germane to the strength of the correlation between the data and the affinity of interest.
  • Data or sites that refer to a greater number of venues might be more probative since such sites are more likely to compare, contrast or rank venues.
  • sites that specify a greater number of properties, such as in structured fields, for each venue or reviewer tend to be more effective or probative.
  • Sites with a greater number of reviews per venue and/or reviews per reviewer are, on balance, to include more reliable affinity.
  • the inclusion of "related items,” “also viewed,” or "people who purchased this also purchased” fields or boxes can also be considered as indicators that the site's data will be strongly correlated to actual affinities.
  • a site's inclusion of geographically proximate recommendations can also be considered as indicators that the site's data will be strongly correlated to actual affinities.
  • complementary venues may be indicative of more reliable data.
  • the behavior of the more effective or accurate reviewers also can be analyzed to differentiate various data sources, for example, by determining where those reviewers tend to post reviews.
  • the existence of grouping structures, such as data structures associated with a plurality of socially networked individuals, can also be used as a metric to grade or rate the potential value of the site's data. Blogs may also be crawled to determine which reviews or ratings sites are the most commonly referenced.
  • numeric values are associated with some or all of the foregoing variables and weights are assigned to each variable based on the system designer's estimation of the relative strength of correlation between the variable and the predictive value of the review data on the site. For instance, the density of the best reviewers on a site may be weighted more heavily than the number of venues referenced on a site. The resulted weighted numerical grades can be used to prioritize harvesting operations.
  • the reviews may be harvested using web crawling techniques such as those described in US 6,631,369, entitled “Method and System for Incremental Web Crawling,” and assigned to IBM Corporation, which is incorporated herein by reference. According to that technique, in an initial crawl, the crawler creates a first full index for the document store after which incremental crawls are executed.
  • the system 100 may target cached web pages served by commercial search engines.
  • a suitable protocol for rebuilding content sites from search engine caches is as follows. First, a complete venue listing for a category by crawling a directory such as a Yellow Pages or other suitable directory. For each item in the directory, the system 100 runs a series of search queries in various search engines, each query restricted to results for the content site of interest, such as dine.com. The search results are parsed and the URLs for the relevant cached pages are retrieved. The cached pages are then retrieved and in a repository, after which they are parsed based on the name, city, phone number, and other data fields associated with a venue of interest. In this manner the cached review page for the venue of interest may be identified. This process is optionally repeated across search engines and across multiple venues, targeting the sites prioritized as set forth in the preceding section, to collect the desired array of source data.
  • the data may optionally be validated by checking parsed venue or reviewer content for blank fields. Venue or reviewer content may also be checked against unique
  • identification information (a venue phone number or a reviewer email address or screen name) to ensure sure that it corresponds to the target venue or reviewer.
  • the pages may be parsed to extract the data of interest. Parser code may be used to segregate out the structured fields of interest, the reviews, and other information of interest as described above.
  • the extracted data may be uploaded to database tables or files to be analyzed for computing personalization. Techniques such as those taught in US 7,788,293, entitled “Generating Structured Information,” assigned to Google Inc., the contents of which are herein incorporated by reference, may be used for this purpose.
  • the same approaches can be used to harvest data concerning reviewers or users (discussed in more detail below).
  • the data is preferentially in a structured format on a public site and is predictive of personality and affinities.
  • the data sources may be prioritized or ranked as set forth in the preceding section, such as according to the number of reviews given by the reviewer, the citation of a reviewer's reviews on other sites and the alignment of a reviewer's reviews with overall ratings generated by the system 100 (as discussed below) and third party review sites from which data is harvested.
  • the reviewer data is then selectively crawled and parsed as explained above.
  • the crawl and parser module 114 may be configured to coordinate the crawling and digestion of certain web or network nodes. Due to practical limitations, the entire World Wide Web cannot be crawled and parsed simultaneously. The crawling and parsing process may be coordinated across different content- gathering computers or agents. Multiple remote crawling engines (at remote network nodes) may be deployed, each of which can check data sources (such as web pages or cached web pages) for the properties described above and recruit crawling and parsing nodes in the event rich data sources are located. The remote crawling nodes can coordinate their crawling based on real-time breaking news events, or optimize content gathering in response to shifts in mass user behavior as reflected in the data matrices described herein.
  • Figure IB illustrates the process executed by the content collection system, which may include the crawl and parsing module 114.
  • the crawl and parsing module 114 identifies subject matter targets, such as rock-climbing, are needed in the neural network. The targets may also take the form of specific URLs or collections thereof.
  • the module 1 14 identifies the current content, in the form of previously collected web pages (or representations thereof), that already resides within the system's storage network.
  • the content collector determines from a comparison and analysis of the two inputs which subject matter or URLs are to be gathered by the module 114.
  • the content collector verifies the addresses and content of the target sites containing the subject matter which is to be collected and creates a queue of items to be crawled and parsed by the module 114.
  • the distributed queue's first entry might be [Boston, restaurants, google.com, 'all'], which corresponds to a request that the crawler nodes collect all cached pages associated with google. corn's reviews of any Boston area restaurant.
  • the content collector may also dynamically allocate certain queue items to specific crawling nodes based on their relative priority (160).
  • the content collection engine which includes a distributed array of crawler nodes, receives or access the distributed queue and dynamically assigned collection commands from the content collector.
  • the content collection engine under the control of crawl and parsing module 114, collects cached web pages as discussed above.
  • the output is a library of cached web content which is parsed according to the methods described herein.
  • Figure 1C shows an exemplary process executed by the content organizer, which may comprise the matrix builder 116.
  • a set of cached pages to organize is obtaining as an input at step 170.
  • the content organizer receives or accesses the library of cached pages to be parsed and added to the network.
  • the content organizer may be a persistent system network node in various embodiments.
  • the content organization engine (see step 182) may include a distributed array of parsing nodes that access a distributed queue of parsing assignments and receive assignments which are dynamically assigned, optionally to specific crawling nodes or crawling nodes having certain attributes such as bandwidth or throughput.
  • the content organization engine also accesses an array of site-specific parsers that are specially designed to parse data as it is presented on certain sites.
  • a parser engine specific to Google's hotel pages is presented to the content organization engine for use in parsing corresponding cached web pages.
  • This architecture may facilitate modification of parser engines as sites alter the manner in which they present data. For example, local.yahoo.com may alter the data format of its hotel pages, in response to which a single parser engine can be updated.
  • the output of the content organization engine (182) is used by the matrix builder 1 14 to create additional nodes and matrices of interrelationships as described herein.
  • the resulting matrices and databases of web content are presented for simultaneous access by multiple instances of web servers which present the user interface described below or which communicate with mobile device client applications as discussed herein.
  • the system 100 may require a user to input various data including gender, age, marital status, children ages, children gender, third parties with whom the user is socially networked, hobbies, interests, favorite venue information (in one or more venue categories), preferred or non-preferred reviewing entities (if any). [00103] The user is then asked to list favorite or preferred venues. As an example, the user may list favorite restaurants, movies, or activities. The system 100 may asks for alternative favorites in the event a venue is not included within the neural network.
  • the system 100 optionally may crawl the web for additional information concerning the user and then parse and validate the data according to the methods described above.
  • This supplemental data may be added to the user's profile, data from which will be used in various operations as set forth below.
  • nodal interrelationships The following provides an exemplary description of aspects of creating nodal interrelationships. For the purposes of the present disclosure, it should be appreciated that these aspects may be applicable to forming nodal interrelationships as part of determining an individual user's personality matrix, as well as a group of users' combined personality matrix. Therefore, for simplicity the term "user” hereinafter may represent an individual user or a unified set of users represented by a combined personality matrix.
  • Nodes in the data network may represent venues, venue properties, users, user properties, reviewers, reviewer properties, and the like.
  • Links represent relations between those nodes. The number of links between two items might therefore grow as data on two items grows. The strength of each link denotes the affinity between the two connected items, such as similarity of star rating (in a review of a venue), number of attributes held in common. Links can be either positive or negative in sign.
  • Links can be associated to designate affinity between and amongst, venues, properties of venues, users, reviewers, content sources, or any combination thereof.
  • venues 200, 210 may be interrelated in that they have several attributes 201, 211 in common, namely that they are both Italian restaurants in the same neighborhood.
  • Reviewers 220, 230 are related in that they likewise have multiple attributed in common.
  • Users 240, 250 are likewise interrelated by shared attributes.
  • Reviewer 220 is interrelated with both venues 200 and 210 in that Reviewer delivered a review to both venues and that in turn creates an additional relationship between venues 200 and 210 (namely, they were reviewed by the same reviewer.
  • User 250 is related to both Reviewers 220 and 230 via shared attributes and User 240 is related only to Reviewer 220 via the shared attributes.
  • Reviewers 220 and 230 are thus interrelated also in that they share attributes of user 240.
  • User 240 is also directly linked to venue 200 by virtue of the fact that the user has expressed an affinity for that specific venue. Reviewers 220 and 230 thus have a second order relationship with venue 200 through user 240.
  • This data architecture permits links, or interrelationships, to be adjusted
  • Links touching the same node can be adjusted for one partner node but not others. Links on the same node can be "scaled" together to maintain relative values of each of their partners while changing the overall drive/influence to that node.
  • subtractive or "anti-related" links can weaken
  • Subtractive nodes also can be added to the network to normalize the total positive timbre of local nodes where the average link values are too strongly positive. Subtractive nodes also can serve to mediate competition between nodes to influence one another, as the strength of the link dictates the effect one node will have on the other. Subtractive nodes can help sharpen, or focus, the positive influence cast by a given node.
  • Links can in various implementations be sorted according to priority of influence over (or strength of link to) their downstream node. Links may interact and influence one another, where the addition of one changes the strength or presence of another, in a manner that is restricted or targeted to other links on the same node.
  • Links from reviewer nodes can be normalized based on how positive or negative they are. In other words, if a given reviewer is an "easy grader" his or her reviews may be lessened in magnitude to normalize the reviews to a statistic goal or mean. Links from reviewer nodes may also be normalized to lessen the influence of those links where, for instance, a reviewer has an extraordinarily high number of reviews (each of which creates a link) and thus that single reviewer's opinion would unduly influence the data network if not scaled appropriately. Conversely, the strength of a reviewer link make by scaled upwards based on measured or perceived effectiveness or accuracy of the reviewer. This may be executed, for instance, through rankings or ratings of reviewers or statistical feedback whereby accuracy or predictiveness of reviewers is measured.
  • Weighting or normalization may also be used to alter a link's strength based on the number of attributes in held in common.
  • the system 100 may be configured to give each additional link of a given type a linearly or exponentially decreasing affect, such as where a substantial number of interrelated reviewers given a venue a similar review.
  • Links between nodes that are hyper-connected may be likewise be scaled downward to reduce the effect that one of the two nodes has on the extended network.
  • Links may also be weighted based on the predictiveness of the reviewer. For instance, reviewers may be graded based on number of reviews, number of citations on other web sites, or ratings of reviewers on third party sites crawled by the system. The links created based on each reviewer's reviews may accordingly be scaled linearly or non-linearly according to the relative grade of the reviewer. Reviews provided by more highly rated reviewers may be assigned correspondingly higher values or strengths.
  • Reviewers may be weighted on a user-specific basis as well.
  • the neural network of links may be re-weighted based on the fact that the user requesting a recommendation, or a "unified user" represented by a combined personality matrix, has affinities or attributes held in common with certain reviewers.
  • certain reviewers with which a user and/or a unified user has indicated a negative association may result in re- weighting to correspond with the negative association.
  • Reviewers' ratings may be correspondingly weighted more heavily or more lightly in correspondence to the link between the user and the various reviewers.
  • Reviewers may optionally be pruned from the network if they have below a threshold level of relevance as measured by a corresponding grade or effectiveness.
  • the grades of reviewers may be based on ratings of reviewers at third party sites and/or feedback of users of the system 100 concerning agreement or disagreement with recommendations which were calculated in part based on a given reviewer's review. If a reviewer is pruned from the system the remaining reviewer's weightings may be adjusted upwards to maintain normalization.
  • aspects of the present disclosure may allow for indicating certain "filters" related to affinities or attributes other than reviewers, which can be utilized to screen against candidate recommendations.
  • Screening candidate recommendations may, e.g., include re- weighting link strength or eliminating a link altogether.
  • the links in the neural network may be bidirectional (as shown in the figures) or unidirectional.
  • the predictiveness of a link may be asymmetrical or unidirectional. For example, it may be the case that almost everyone who likes restaurant A likes restaurant B, but very few who like restaurant B also like restaurant A. In that case, the links associated with affinity for restaurant A may unidirectionally point to (i.e., be linked to) restaurant B, but the converse would not be true (i.e., node B would not have a positive link to restaurant A based on this data point).
  • the figures address the simpler scenario wherein all data points are symmetrical, but in various implementations some or all of the links may be unidirectional or have asymmetric strengths (such as +1.5 in one direction and +0.5 or -0.5 in the other direction).
  • the neural network may be refined based on an active feedback loop concerning the effectiveness of the recommendations provided by the system 100.
  • Links can be refined (in either direction) based on feedback for how effective the recommendation was.
  • One measure of the effectiveness of the recommendation is whether funds were spent by the user based on the recommendation, which in turn might be measured via data provided by partners such as financial transaction card issuers.
  • Another measure may be feedback provided by the user in response to a query or survey concerning the recommendation or venue in question.
  • Yet another measure of recommendation effectiveness is a user's browsing behavior and the fact that the user left a positive review for the recommended venue on a third party site (which can be collected and parsed as set forth above).
  • Still another technique to assess effectiveness of a recommendation is geographic dwell time at a physical location associated with a venue, as measured by mobile device GPS data, for instance.
  • first order connections are updated based on feedback.
  • second and higher order connections are optionally updated based on feedback.
  • the second order connection between two restaurants which are both liked by the reviewer may be updated or correspondingly modified as well.
  • Mismatch between the recommendation and the user's evaluation can drive a reduction or weakening of the links between the associated nodes such that the converse could also be executed.
  • the links between that node and neighboring nodes may be strengthened.
  • links created by the reviewer's reviews may be assigned a greater strength.
  • the nodal structure facilitates computations and scaling of the network.
  • the nodal network may create a natural look-up table that is convenient to search and operate over.
  • the nodal structure with inter-node links of varying types provides a convenient way to update the structure as new pieces of information are added, and in certain embodiments this may be executed without losing the original information as in traditional databases that represent affinity as single number weights between items.
  • the data in various embodiments may be represented as either an indexed rows of databases, linked lists, or distributed files.
  • the matrix of interrelationships or links can be broadly categorized as content-based interrelationships, collaborative interrelationships, and content-collaborative
  • the first type, content-based links are in certain embodiments premised on venue attributes for multiple venues reviewed by same reviewer.
  • the content-based links establish interrelationships between venues based on shared attributes.
  • the strength of the link (or anti-link) may be dependent on the number of things held in common, comparative ratings, and other factors as described herein.
  • Collaborative venue interrelationships associate venues that are liked by the same reviewer, often without any dependency or relation to the reason(s) why the reviewer likes the venue.
  • the strength of the link may be dependent on reviewer rating, proximity on same list, and other factors described herein.
  • Collaborative links arise when two venues co-occur, for example, in the same person's list of favorite or preferred venues, on the same "top 10" or other grouping lists on ranking or recommendation sites, or on the same search engine search results page. Proximity within the list may be used as a variable to control link strength.
  • Ant trails may also be used to create collaborative links by tracking people's surfing behavior and linking venues a given user often visits, independent of spiderwebbing.
  • restaurant A may be deemed interrelated to museum B if many tracked users visit both of those sites.
  • the user's dwell time at each site or the fact that a user left a rating or review may also factor into whether a link is created.
  • this tracking is accomplished without the use of cookies, rather by collecting from the web data concerning the user's activities on rating and review sites according to the techniques described elsewhere herein.
  • Content-collaborative interrelationships or links may arise from common (or anti- common) reviewer attributes for reviewers who liked (or disliked) the same venue.
  • the venue attributes may be analyzed for common or anti-common features, and links may be established between either a specific venue and reviewer attributes or between venue attributes and reviewer attributes. The strength of the link may depend on the incidence of an attribute among reviewers giving a venue a certain grade, or similar comparative ratings.
  • the exemplary architecture illustrated in Figures 3-12 facilitates in certain embodiments dynamic updating and adapting of the network. For example, when a new restaurant or review is added to the network, those nodes each create first, second and higher order links which are added to the network.
  • the affected links can be updated by a relatively computationally simple (and non-resource intensive) addition or other arithmetic operation and the neural network need not be substantially entirely recalculated or reformed.
  • Either the system or users may trigger the recommendation engine.
  • the users may do so by entering through a web portal, client application, or electronic message a request that a shared recommendation be generated based on provided venue attributes such as type, geography, or price.
  • the system 100 may access user profiles to collect data for each user in a group requesting a shared recommendation.
  • Exemplary user data collected by the system 100 includes other venues liked, gender, profession, age, location, pricing preferences, cuisine preferences, entertainment content preferences (e.g., favorite movies, music, books, etc.), preferred venue features, allergies, preferred modes of transportation, relative weight in shared decision making, schedule/calendar information, style preferences, and any other user information set forth herein.
  • user data collected by the system 100 may be utilized to form a user personality matrix and combined personality matrices with which to determine shared recommendations.
  • the system 100 may also automatically generate recommendations for inclusion in electronic messages, such as text messages, or email messages, sent to targeted users or for presentation on a web portal or client application accessed by users.
  • the system 100 may also include features for determining available times for a show, reservation, appointment, etc. Accordingly, the system 100 may control an interface for scheduling an event and/or purchasing tickets for shared recommendation results.
  • the recommendation engine may responsively identify venues with strongest links according to the following protocols in selected embodiments. Based on the identified "liked venue(s)" the system 100 may identify the top N venues that have strongest link value to that the identified venue and which have the specified venue attributes. Alternatively or in addition, based on highest rated venue(s) having specified attributes, the system 100 may identify the top N venues that have strongest link value to that the identified venue. Still another alternative which can be used alone or in combination with the foregoing is to, based on the highest rates venue(s) having specified attributes and being recommended by friends or selected reviewers, identify the top N venues that have strongest link value to that the identified venue.
  • the recommendation engine may also generate recommendations based on the user attributes, for instance by identifying the top N venues that have strongest link to attributes of the user personality matrix and the combined personality matrix. Further, in selected embodiments a recommendation threshold at which the nodal link strengths have to cross may be implemented such that the recommendation engine will not recommend venues with link strengths below the recommendation threshold.
  • a plurality of these techniques are used and resulting venue recommendations are weighted based on empirical observations concerning the
  • the weight factors may be simple coefficients or first, second, or higher order equations.
  • Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data.
  • the system 100 may send an electronic message or alert either including a recommendation based in part on the location and/or time or prompting a user to access an interface to receive the recommendation. For instance, if one or more users is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular combined personality matrix, the system 100 may generate an electronic alert to the one or more users including the recommendation, a hyperlink to the system 100 web portal, or a link to activate a client recommendation application that can launch a user interface, such as the exemplary interfaces described herein.
  • Alerts or recommendations may be accompanied by, and be generated based on, promotional offers related to the venues.
  • an electronic notification may contain a recommendation along with a promotional discount offer for the related potential booking or reservation.
  • Recommendations presented in the interface may also be selected based in part on promotional status. That is to say, the recommendation engine may strengthen links nodes associated with promotional offers and thus the engine will factor in promotional offers when determining nodes to recommend (i.e. those most strongly linked to nodes associated with the user or a recommendation request).
  • FIG. 3-12 illustrate one simplified implementation of the recommendation engine described herein. Those skilled in the art will understand that this example can be extended to incorporate any or all of the additional features described herein. Selected of these substitutions and extensions will be mentioned below and those explanations are not intended to be limiting.
  • Figure 3 shows an exemplary matrix of reviewer ratings.
  • Reviewer 1 has provided reviews for nine out of the twelve restaurants, the ratings spanning from one star to five, five being the highest.
  • Reviewers 2-7 have likewise each provided ratings for a different subset of the twelve restaurants.
  • the venues could be venues of different types, such as four restaurants, four night clubs, and four theaters.
  • the ratings may use a wider numerical or alphabetic scale, and integer or non-integer values.
  • Figure 4 shows the corresponding matrix of attributes for the venues of Figure 3.
  • each restaurant is in Boston, MA and the price varies on a ten point scale.
  • Attire is assigned alphabetic codes (formal and casual), although numeric codes may be used in certain embodiments.
  • Zip codes may be used as neighborhood values in this example, although neighborhood values may be determined based on GPS position location
  • the hours of operation may be assigned a code selected from a predetermined library of operational hours and in other embodiments the hours of operation is provided various fields, one for each day of the week.
  • Figure 5 shows the reviewer attributes for the Reviewers 1-7 of Figure 3.
  • reviewer attributes are limited to gender, age, profession, education, marital status, number of children, number of reviews, and review accuracy.
  • the codes may be selected from predetermined libraries.
  • the number of reviews is based on the data collected as described above.
  • the review accuracy may be calculated based on the feedback control data as discussed above.
  • a composite reviewer grade may be used, which optionally factors in number of reviews, citations of reviews on other sites, number sites hosting reviews, and/or consistency of recommendation with positive user feedback.
  • Figure 6 is a chart showing an array of user attributes for seven users. The
  • each user is asked for four favorite venues.
  • a list of preferred venues in various different venue categories may be included in the user profile.
  • This user data may be input by each user and/or collected from web data sources in the manner set forth above. Additionally, as will be discussed in further detail in later sections, the user data may be used to form user personality matrices and combined personality matrices for shared recommendations.
  • Figures 7A and 7B illustrate an array of content-based venue links based on the venue attributes of Figure 4. Referring to Figure 7A, Restaurant 4 has one link with
  • Restaurant 2 associated with common attire.
  • the value of the link, +0.25, is less than the other links such that it has a lesser impact on the recommendation, as will be seen. In other words, the link is relatively weak.
  • Restaurant 4 has three links with Restaurant 1 , +1.25 associated with the common neighborhood, +1 based on the common genre and +0.25 based on the same attire.
  • the net value of the content-based links between links Restaurant 4 and Restaurant 1 is +2.50.
  • the exemplary matrix of Figures 7A and 7B could optionally include links associated with a plurality of additional venue attributes and could also include anti- links (or negative links) associated with anti-common properties, as will be illustrated in connection with Figure 8.
  • Figures 8A and 8B show a matrix of collaborative venue links based on the reviews set forth in Figure 3. Taking as an example the association between Restaurant 7 and Restaurant 3, there is a +1 link associated with the fact that Reviewer 2 rated both of these restaurants as four star. Restaurants 6 and 7 are given a stronger positive link based on common positive reviews because Reviewer 3 rated both restaurants as five star. Returning to the link between Restaurant 7 and 3, an anti-link of -0.75 is assigned based on the opposite affinity for these restaurants expressed by Reviewer 1 (who gave the Restaurant 3 four stars and Restaurant 7 one star). A higher negative magnitude could be used where a review rated restaurants in a more strongly opposite manner (i.e.
  • a matrix of content-collaborative interrelationships may reflect links arising from common or anti-common features between each venue and each reviewer. For example, reviewers may have a characteristic called "genre affinity," and a link of predetermined strength may be created when a genre affinity matches the venue genre.
  • the content-collaborative matrix may show links between affinity for a venue and reviewer attributes.
  • common attributes among reviewers who rated a venue highly may be linked to the venue. For instance, reviewers aged 31-35 may disproportionately rate a venue poorly, in which case an anti-link may be created between the venue and the reviewer attribute "age 31-35.”
  • Figure 9 shows illustrative exemplary outputs of the recommendation engine based on a query for a recommendation for an American restaurant and a user affinity for
  • Restaurant 7, which may be indicated by an aggregated user taste profile represented by a combined personality matrix. In other embodiments more inputs may be used, such as venue attributes and other preferred venues.
  • the recommendation is a blending of the content-based link strength 901 , collaborative link strength 903, and content-collaborative link strength 905.
  • Each link strength is assigned a distinct weighting factor 902, 904, 906, although in other embodiments the blending equation may be a second order or higher order equation rather than a first order sum of products.
  • the values 910-914 derive from the fact that Restaurant 3 and Restaurant 7 have no link shown in Figure 7. The same is true for Restaurants 6/7, while Restaurants 9/7 and 12/7 show a +0.25 link.
  • the matrix in Figure 9 shows the cumulative link strengths 915-918 for restaurant links 3/7, 6/7, 9/7 and 12/7, respectively.
  • the content-collaborative link strength are based on the content- collaborative link matrix (not shown).
  • the weighting factors 902, 904, 906 are constant but may be set to vary according to the predictiveness or accuracy of each type of link (based on feedback control as discussed above).
  • the resulting recommendation values 920-923 reflect the overall link strength 907 between each restaurant and restaurant 7, as shown above.
  • Second order relationships could also be included in the link matrices used to calculate overall link strength. For example, Restaurant 8 is liked by both Reviewer 4 and Reviewer 5. Those reviewers, in turn, both like Restaurant 5. Restaurant 5 could be assigned a direct +0.25 link to Restaurant 8 based on this second order relationship. That link could operate in the matrix independently of the nodes associated with Reviewer 4 or Reviewer 5.
  • FIG. 10 An alternative form of a second order relationship is shown in Figure 10.
  • Figure 10 illustrates second order links arising from collaborative venue links.
  • Restaurant 8 is positively linked to both Restaurant 3 and Restaurant 5, so a +0.25 link is created directly between Restaurants 3 and 5.
  • Restaurants 12 and 7 are both negatively linked to Restaurant 8 so a +0.15 link is created to reflect the belief that this anti-link is weaker than the positive link previously mentioned.
  • an even weaker second order link is established between Restaurants 1 1 and 12 because while both are negatively linked to Restaurant 8 the links are substantially different in magnitude.
  • These second order relationships can be added directly to the related matrices or otherwise computationally combined when calculating overall link strength between two nodes.
  • Figure 1 1 shows an exemplary set of arbitrary link values in a more complex system that factors in a wider variety of links (such as second order links) across the same nodes. It can be seen that the values are strongly positive and few values are negative. This can be observed where the data has a skew associated with reviewer tendency to give generous ratings, for instance. If the data of Figure 11 is content based, it may have a skew different than parallel matrices for collaborative links or content-collaborative links. Accordingly, it may be useful to normalize the data of Figure 1 1 to facilitate computational combination with links in the other matrices.
  • Figure 12 shows the data after an exemplary normalization operation.
  • a constant value of five was subtracted from all data points.
  • the value subtracted may be selected such that the data set hits a common or desired mean or median.
  • normalization may be accomplished by multiplication or division. For example, a certain percentage may be subtracted like a tax from affected links by multiplying the link strengths by (1 -X), wherein X is a tax rate from 0 to 1.
  • the tax rates in this approach may be progressive to accommodate the tendency of users and reviewers to aggregate toward a small number of more popular venues, which as discussed herein can cause those venues to cast too large a shadow or have an undue influence on the remainder of the neural network.
  • normalization can occur at local level or at the network level. At the local level, all links connected to a certain nodes may be normalized or all links coming to or going from a certain node may be normalized (recalling that links may be unidirectional or asymmetric). Alternatively, normalization may occur at the data matrix level. For example, content-based link matrices may be normalized or other data subsets of network may be normalized.
  • Figure 13 shows another form of higher order connection, referred hereinafter as connection creep.
  • connection creep the link between Restaurant 10 and Restaurant 1 in Figure 12 is considered too high in that it might have an undue influence on the connected nodes. Accordingly, a link strength value of 1.5 is subtracted from link 10/1 and 0.5 is added to the less strongly positive links 10/2, 10/7 and 10/8. No portion of link 10/1 's strength is reassigned to link 10/9 because it is already above a predetermined threshold above which links are not to have connection creep bonuses added or above which no higher order links should be added.
  • Figure 14 illustrates an exemplary user interface for deployment at a web portal or client device such as a desktop computer, smart phone, tablet PC, automotive multimedia interface, or other mobile computing device.
  • the server or local application provides an evolving personalized brand logo and personalized audio soundtrack to match the displayed itinerary.
  • the sound track may persist and "travel" with the user as he or she navigates different functionalities or pages through the interface.
  • the interface is also designed to provide bio-visual data feedback to the user.
  • the system permits users to state their goals and intentions based on the feedback they have received from the system.
  • Figure 14 is an overview page that provides users with an immediate perspective on options, a space for collection/comparison/pre-screening/deliberation, and the ability to immediately act. Specifically, the overview page has three distinct sections and
  • the interface of Figure 14 may be provided as an interface for initiating shared recommendation requests and/or viewing results and taking corresponding actions.
  • a plurality of recommendations is presented.
  • two to seven, three to six, four to six, four to eight, four to nine, or two to ten recommendations are provided.
  • the number of recommendations may be on a per- venue basis so that five recommendations are provided for restaurants and a like number of hotels are recommended. Alternatively, a lesser number of complementary venue (e.g. hotel) recommendations are provided.
  • the collection and comparison panel 1420 provides a place to compare and contrast recommendations of interest.
  • the panel provides venue genre or type, the venue name, geographic area, and price.
  • the panel also provides buttons to book a reservation or check availabilities or rates for the various venues. Buttons for adding the event to a calendar are optionally provided adjacent each venue. Also provided are status identifiers indicating the current state of activities and/or bookings for each venue. Optionally, buttons may be provided to launch a window or image that depicts the venue on a map.
  • the calendar panel may feed or import a view of the user's personal calendar and provide interactivity for immediate assessment of the user's schedule and available times.
  • the calendar permits import of the user's other appointments and export of the calendar items to any third party calendar systems such as Outlook, Google, and iCal.
  • a user can directly book a recommendation at any of these three stages, or add to calendar at either of the first two stages. This arrangement may in certain embodiments enhance the likelihood that a user makes reservation or booking based on the
  • Additional optional functionalities include a transportation reservation interface.
  • the interface may present a transportation button that launches an booking or reservation portal which communicates with a third party transportation provider, such as a taxi service, and makes a reservation corresponding to a restaurant or other reservation.
  • the interface may also permit the arrangement of transportation services between and amongst a plurality of other recommended events spanning one or more days.
  • booking functionality may be provided for a variety of
  • Examples include hotel rooms, airline reservations, movie tickets, theatre tickets, museum tickets, music tickets, sporting events, product delivery (such as flowers or flowers), rental car services, car share services, public transportation services, restaurant takeout/delivery services, parking services, real estate services, or moving services (such as inter-city packing and transportation services).
  • the interface may selectively suggest alternative actions or venues based on a first booked venue or action. For instance, the booking of a restaurant reservation may prompt the generation of night club or theater recommendations. As another example, the booking of a real estate tour through a real estate agency may prompt a recommendation for moving services. Subsequent bookings may in turn generate additional recommendations
  • These follow-on recommendations may be filtered and selected according to the techniques set forth above.
  • the recommendations may be a function of the user's profile, attributes, venue preferences, past booking behavior and/or previous feedback concerning certain venues.
  • the recommendations may be filtered as set forth above according to the user's most recent reservations and the user's expressed preferences for given venues that are linked to potential secondary or tertiary recommendations.
  • Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data.
  • the system 100 may send an electronic message or alert either including a recommendation based in part on the location and/or time or prompting the user to access an interface to receive the recommendation.
  • the system 100 may generate an electronic alert to the user including the recommendation, a hyperlink to the system web portal, or a link to activate a client recommendation application that can launch an interface such as those described herein.
  • Alerts or recommendations may be accompanied by, and be generated based on, promotional offers related to the venues.
  • an electronic notification may contain a recommendation along with a promotional discount offer for the related potential booking or reservation.
  • Recommendations presented in the interface may also be selected based in part on promotional status. That is to say, the recommendation engine may strengthen linked nodes associated with promotional offers and thus the recommendation engine may factor in promotional offers when determining nodes to recommend (i.e. those most strongly linked to nodes associated with the user or a
  • Users may be provided a profile page or "my account” page that provides analytics on that data and any other data collected or contributed to provide perspective and insight into behavior.
  • the page provides a feedback mechanisms to the user that is "habit honing" in that analytics on self activity is provided in a visual format.
  • the page may present graphical trends of actions within customizable goal categories such as health (gym, yoga), family (museums, travel, dining), and errands (dentist, mechanic, groceries).
  • the overview page suggestions can be featured to highlight relevant activities to fill existing calendar time-slots.
  • the interface may also provide other prompts to facilitate actions and hone habits.
  • the interface may provide cues and triggers embedded in mobile device applications to cue initiation of plans and transitions between scheduled events.
  • the mobile client application may trigger chimes upon next scheduled event, music to reduce anxiety surrounding errands, tailored music transitions upon the occurrence of the next scheduled event, or visual (blinking LED) cues upon next scheduled events.
  • the user interface described above presents a plurality of recommendations to the user based on a user search query thereby allowing a user to pick various venues and/or add them to a calendar. However, based on this view, a user may not fully grasp the
  • the recommendation engine 1 12 may not have as much of an incentive to provide more information to the system 100 thereby enabling an enhanced neural network topology that will provide better recommendation results.
  • an additional bio-visual personalized feedback interface is provided to users of the system 100.
  • the user is able to view an overall network topology of various nodes within the system 100 and the interconnections therebetween thereby allowing users to grasp the nodal link strengths and relationships between venues.
  • the bio-visual feedback interface is a two-dimensional interface that provides an overhead aerial "bird's eye" view of the network topology presented topographically in an easy to understand manner. For instance, at the highest level, a topographical view of the system may depict clusters of nodes in various regions with some node clusters being venues of interest to the user based on previous recommendations and/or nodal interrelationships having strong overall link values and other cluster areas may include nodes known to have low overall link scores or, in other words, nodes that would be bad recommendations to the user.
  • nodal clusters having nodes that would be strong recommendations for a user or nodes that have previously determined to have been effective to the user can be displayed in hot colors, such as red or orange, whereas other nodal clusters having poor recommendation choices can be displayed in cold colors, such as blue or purple.
  • Nodal links may or may not be provided at this level to give the user an understanding of how various nodes are linked to each other.
  • the topographical view of the nodes can further be enhanced via contour mapping features. Accordingly, certain areas of the clusters which include strong nodal links therein can be presented in an "elevated" contour with a different color mapping than venues with lesser overall link strengths positioned in lower elevations. Further, nodes having antilinks with other nodes may be positioned farther apart in the aerial view and have dotted links to indicate the negative link strength therebetween. Further, nodes that do not have links to other nodes may be placed apart from the nodal clusters to represent their independence from the other nodes of the neural network.
  • Figure 15 illustrates an exemplary bio-visual personalized feedback user interface using a topographical contour mapping system based on a user search query for Restaurant 7.
  • the neural network topology, or neural network "world" view 1500 includes nodes representing Restaurants 1-3, 7-11 and Restaurants X and Y.
  • Restaurants 1-3 and 7-11 are the same Restaurants illustrated in Figure 4 and therefore have the same venue attributes, content-based relationships, collaborative relationships and content-collaborative relationships as described above with respect to at least Figures 5-9. Accordingly, the links shown between the nodes are in accordance with the content-based venue links and collaborative venue links identified in Figures 7 and 8.
  • Restaurants X and Y represent two venues that are not linked to any other venues within the neural network.
  • the world view 1500 represents the "highest" aerial view the user can obtain via the bio-visual feedback user interface.
  • Restaurants 1-3 and 10 represent a cluster of venues having strong overall link strengths with Restaurant 7 and as such may be represented using hot colors.
  • Restaurant 7 itself may be indicated in a neutral color to identify that it is the restaurant expressed in the search query by the user. Further, Restaurant 7 could be displayed larger than the other nodes in the topology depicted in Figure 15 to identify it as a restaurant that was part of a search query.
  • Restaurants 8, 9 and 11 may be depicted in cold colors as they have low recommendation values based on low overall link strengths with respect to Restaurant 7. Further, as illustrated in Figure 15, the links between Restaurant 7 and
  • Figure 15 further includes elevated contour zones 1501 , 1502, 1504 and 1506. These topographical contours represent elevated nodal areas containing nodes having strong overall link strengths with a node or nodes included in a search query. Accordingly, contour zone 1501 includes Restaurant 7 and Restaurant 1 and is depicted as having the highest elevation as Restaurant 1 has strong content-based and collaborative venue link strength. Further, contour zone 1502 has a median elevation and includes Restaurant 10 which has a higher overall link strength with Restaurant 7 than Restaurants 2 and 3 but has a lower overall link strength than Restaurant 1. As Restaurants 2 and 3 have the lowest overall link strengths with Restaurant 7 when compared to Restaurant 1 and Restaurant 10, they are depicted at the lowest elevation or "ground" level.
  • contour zones 1501 and 1505 provide the user with an easy-to-understand view of restaurants that would be good recommendations with respect to Restaurant 7.
  • contour zone 1504 and 1506 represent elevations containing nodes that would be bad recommendations as contour zone 1504 and 1506 contain nodes having lower overall link strengths with respect to Restaurant 7.
  • contour zone 1506 includes Restaurant 9 and Restaurant 1 1 which have comparable negative overall link strength values with respect to Restaurant 7 but that are elevated higher than Restaurant 8 as Restaurant 8 has a lower negative overall link strength value with respect to Restaurant 7. Accordingly, alternatively from the depiction of Restaurants 2 and 3, the lowest elevation or ground level may be depicted via a contour zone.
  • the system 100 can also display links to nodes in other locales.
  • the world view 1500 may include different locales such as New York and Boston.
  • link 1508 identifies a connection between Restaurant 7 of Boston and Restaurant Z of New York.
  • the link between different locales may be represented in various manners such as a squiggly line in order to indicate to the user that the link represents a connection to a different area. Further, as the line is solid and not dashed it represents a positive overall link strength between Restaurant 7 and Restaurant Z as described above. While not shown, New York will likely have its own neural network topology with corresponding contours and internodal connections.
  • the bio- visual personalized feedback user interface provides the user with the ability to quickly identify restaurants in different locales that may be strongly connected to known restaurants in the user's location. In other words, if the user is planning on traveling to New York he can "virtually travel" over transit link 1508 to determine restaurants in New York that he may want to visit based on their relationship with Restaurant 7.
  • the contour zones may also be colored using hot or cold colors based on overall link strength with respect to a designated restaurant.
  • the user may interact with the nodes in order to redefine and redisplay the neural network image.
  • world view 1500 identifies the neural network topology with respect to Restaurant 7 but the user may designate, via a mouse, speech or other input device, another node in which to view the network topology.
  • the system 100 will then recalculate the overall link strengths as previously described herein and will redisplay the world view 1500 based on the newly designated node. Therefore, the bio-visual feedback user interface allows the user to easily grasp interconnections between a variety of different nodes and to realize an expansion of internodal links based on input provided by the user.
  • Figure 15 illustrates a world view 1500 representation
  • the system 100 also allows the user to zoom into lower levels of "aerial coverage". Accordingly, if there are too many connections between nodes in various clusters, the user may not be able to fully grasp specific connections between specific nodes. Therefore, the user can zoom in on a particular portion of the world view 1500 to see more granular arrangements of nodes and connections therebetween. The user may zoom in by clicking a magnification button (not shown), by right clicking a specific node which pops up a dropdown menu having an option to zoom in with respect to that node, by speech, touch or any other method as would be understood by one of ordinary skill in the art.
  • a magnification button not shown
  • Figure 16 represents a local view 1600 of the world view 1500 of Figure 15 based upon a command from the user to zoom in with respect to Restaurant 1.
  • the local view 1500 illustrated in Figure 15 depicts nodal connections based on Restaurant 1.
  • the system may center on the screen whichever node has been selected by the user.
  • Figure 16 is intended to be exemplary and therefore only a handful of the connections are illustrated for the ease of explanation.
  • Restaurant 1 has a variety of connections with Restaurants 2, 3, 7, 9 and 10 and the user is able to grasp a better understanding of these connections as compared with the world view 2500.
  • different link strengths are represented by different link thicknesses and anti-links are represented by dashed lines. The user can further designate particular lines themselves and the system 100 will display the overall link strength values for that particular connection.
  • link 1602 connecting Restaurants 1 and 7 has the thickest line as compared to other connections as they share the same neighborhood and genre and both received highly positive reviews from Reviewer 2.
  • Link 1606 connecting Restaurant 1 and Restaurant 2 has a small line thickness as they only share the same attire and do not share any positive review data.
  • Link 1604 connecting Restaurant 1 and Restaurant 9 is dashed as they share a negative overall link strength due to an opposite affinity expressed by Reviewer 2. However, the link 1604 is not that thick as the overall link strength value, while negative, is close to zero.
  • the links may be depicted in different colors to identify which links have strong or small overall link strengths with respect to a designated node. For instance, link 1602 may appear to be bright red due to a strong overall link strength between Restaurant 7 and Restaurant 1 and link 1604 may appear blue based on a low overall link strength value between Restaurant 1 and Restaurant 9. Alternatively, the user may request link colors solely based on the designated node such that link 1606 would be assigned a "hotter" color than link 1602 because it is a direct link with Restaurant 1. Further, links having a stronger overall link strength with respect to a designated node may appear closer to the designated node than other links. For instance, Restaurant 7 is closer in proximity to Restaurant 1 than Restaurant 3 as Restaurant 3 has a lower overall link strength with
  • both the world view 2500 depicted in Figure 25 and the local view depicted in Figure 16 provide an easy-to -understand view of the neural network topology thereby providing the user with insight into potential recommendations while also providing an incentive to present more information to the system to bolster internodal links.
  • the nodes illustrated in Figure 15 and Figure 16 are represented by the number of the restaurant, other depictions are contemplated such as thumbnail pictures, logos and/or names of the restaurants.
  • the system in selected embodiments may display a three-dimensional view of the neural network topology thereby giving the user a real-world impression of the internodal connections.
  • connections with strong overall link strengths may represent highways whereas connections with low overall links strengths may be represented as dirt roads.
  • venues that are located close to each other which are thereby in "walking distance" may represent strong overall link connections as opposed to venues that appear far off in the horizon.
  • Group events can often cause problems between individuals in the group because it may be hard for everyone to come to agreement on particular topics. For instance, a group of friends that are also users of the system 100 may have plans to go out to dinner but may be unsure of which restaurant to go to or may be unable to come to an agreement with respect to a restaurant. As such, each user may have his own opinion of where the group should go based on recommendations provided by the system 100. Therefore, in addition to providing users with a variety of ways in which to view recommendation data and nodal connections between various venues, the system 100 also provides user interfaces enabling a group of users to collaboratively select venues.
  • the system 100 performs a group search using information provided by members of the group.
  • the members of the group may submit a venue choice and a list of requirements to the system 100 in which they want the search query to adhere to when determining recommended venues.
  • some members may specify the genre whereas other members may request a low price point.
  • the recommendation engine 1 12 will then perform a search for each particular member based on their individual requests and recommendations are generated by the recommendation engine 1 12 as previously described herein such that each member has their own recommendation set.
  • the collaborative decision making user interface depicts each group member in a different row with recommendations for each corresponding member appearing in a column beneath that member.
  • the system 100 also highlights one of the recommended venues for each member that represents the strongest overall link strength based on the venue provided by the user and the filter state input as part of the search query.
  • the highlighted venue may be displayed in a certain color, have a varied border as compared to other recommendations, may be displayed larger than the other recommendations or may be displayed in a particular order with respect to the position of the member information.
  • the recommendation engine 112 will also determine, based on the information included the search queries by each member, a recommended group venue having the greatest average affinity with respect to the recommendations identified for each member.
  • the recommendation engine may also use attribute information to prevent clashes between members of the group. For example, the system may not recommend a steakhouse as a group venue when one or more of the members of the group are known vegetarians. Further, for example, if a majority of group members dislike seafood, the recommendation engine may avoid generating a seafood restaurant as a group recommendation regardless of how close other calculations come with respect to other attributes such as price and attire. Accordingly, to generate a group recommendation, the recommendation engine 1 12 takes into account at least the nodal interrelationships between venues identified by the group members and user attribute data.
  • the system 100 highlights the group recommendation if it already appears in the user interface and/or displays the recommended venue separately for the members of the group to see.
  • each member of the group will have the ability to vote on the recommended venue or to select a different venue from the options listed on the display screen.
  • the recommendation engine 112 will then continuously recalculate a recommended group venue or venues having the strongest overall affinity based on the recommendations provided by recommendation engine 112 or those voted on by the members.
  • each member may be limited to a certain number of votes and/or a time limit, such as a certain time before the planned event, may be prescribed to ensure a limited voting period.
  • Figure 17 illustrates an exemplary collaborative decision making user interface, or group interface.
  • Members 1-4 represent a group of users of the system 100 who are planning to meet for dinner on October 8, 2012, at 5:00 PM.
  • one user may setup the meeting time of an event and can send invites to other users of the system 100. If these users accept the invite, the system 100 will indicate that they are part of a group.
  • the users may each provide a venue and other filter parameters to have the recommendation engine 112 provide a recommendation set for each user.
  • the recommendation set of a founder of the group may hold more weight or may be the only recommendation set provided to the group members.
  • the system 100 displays these recommendations as illustrated in Figure 17 such that each user is shown along with their corresponding recommendations.
  • a recommended venue (1706, 1708, 1710 and 1714) having the strongest overall link strength with a venue provided by the user as part of the search query is highlighted.
  • Some users may have more recommended venues in their recommendation set based on the development of the neural network with respect to the particulars of the search query made by that user. For example, Member 4 only was provided three recommendations by the recommendation engine 112.
  • the system 100 calculates a group recommendation having the greatest average affinity based on the recommendations identified by the recommendation engine 112 and presents the venue as a current group recommendation 1700.
  • the previous group recommendation 1702 may also be provided to illustrate to the members of the group that the venue has changed.
  • the collaborative user interface also identifies the last time at which the group recommendation was changed as well as the last vote for a venue and who placed that vote. Further, a deadline for submitted votes can be set by the group founder and/or voted upon by group members and is displayed to inform group members of the last time at which a vote may be cast. Accordingly, as the meeting time is set to 5:00 PM on October 8, 2012, the group members must submit their final votes, if any, by October 8, 2012, at 12:00 PM. As such, the initial group recommendation is dynamic and can change up to the deadline by receiving different votes and recalculating the group recommendation based on overall link strengths and user attribute data with respect to the newly voted venue and previously identified venues for particular group members. In other selected embodiments, the group founder may prevent voting thereby locking the group recommendation calculated by the system 100.
  • the system 100 calculated Restaurant 7 as being the best group recommendation 1700 based on the individual recommendations generated for each user by the recommendation engine 1 12.
  • Recommendation 1704 is highlighted to indicate that Member 4 changed his choice for a venue from Restaurant 1 to Restaurant 1 1 by voting for Restaurant 11. This change may have been made from the original recommendation made by the system 100 or a from a previous vote cast by Member 4. For the purposes of this example, it is assumed that the recommendation engine 112 originally generated Recommendation 1704 and based on this recommendation in conjunction with the Recommendations 1706, 1708 and 1710 for
  • the recommendation engine 112 recalculated a group recommendation of Restaurant 7 based upon the vote for
  • recommended venues other than those highlighted within the user interface are used by the system 100 to calculate a group recommendation 1700.
  • Group recommendations are based, in part, on recommended venue attributes such as those illustrated in Figure 4.
  • Recommendations 1706 and 1708 have the same genre but have different price points than Recommendation 1710 and Recommendation 1704 with Restaurant 7 being expensive and Restaurants 1 and 12 being inexpensive.
  • Recommendations 1710 and 1704 have different genres, the Japanese genre of
  • Recommendations 1706 and 1708 is the dominant genre. Accordingly, as the predominant genre was Japanese but the price points were opposite, the system 100 originally generated the group recommendation 1702 of Restaurant 4 having the same Japanese genre but a medium price point. However, when Member 4 decided to vote for Recommendation 1714, the system 100 recalculated the group recommendation and recommended the current group recommendation 1700 of Restaurant 7. For instance, Recommendation 1714 has a high price point and therefore only one recommendation, Recommendation 12, has a low price point. Further, as Recommendation 1710 and Recommendation 1714 have different genres, the Japanese genre of Recommendations 1706 and 1708 is still predominate.
  • the system calculated Restaurant 7 as the group recommendation as it has the predominate genre and a high price point.
  • these examples are for the sake of illustration and user attributes, other venue attributes, and link strengths based on the neural network topology between the various recommendations can all be used by the system 100 to calculate a group recommendation 1700.
  • the collaborative user interface illustrated in Figure 17 is exemplary and as such can be displayed in a variety of ways. Members of a group may be listed in columns with corresponding recommendations being listed in rows adjacent to the group members.
  • Members may customize images representing their virtual user identity within the system 100. Thumbnail images, logos, or videos may be used in addition to or alternatively to the textual display of the restaurant in the recommendation slots.
  • the strongest recommendations, such as 1706, 1708, 1710 and 1714 illustrated in Figure 17, may be highlighted, may appear larger than other recommendations, and/or may contain animations or audio representations of the recommended venue itself.
  • video streams of group members themselves may be depicted in the collaborative user interface via an imaging device to virtually interact with each other when determining meeting times, discussing group recommendations, or taking votes. Further, a group member may vote on recommendations listed for the group member or any other group member as well as for venues not illustrated in the collaborative user interface.
  • the collaborative user interface illustrated in Figure 17 thereby presents users with the option of having the system 100 generate a group recommendation when members are having a hard time determining a venue amongst themselves.
  • the group recommendations further provide the user with the comfort of knowing that the group recommendation is not only based on strong links to the interests of the user but also to other members of the group thereby increasing the likelihood of a speedy resolution when determining venues amongst large groups.
  • the system 100 may incorporate votes may by users into the data repository 1 18 such that the system 100 may further update the neural network topology and enhance future recommendations. Additionally, the system 100 may in real time repopulate the recommendations within the collaborative user interface based on updated nodal links between venues with respect to votes cast by one member or other group members.
  • the interfaces described herein may be presented, as noted, through a variety of devices. Still additional devices are contemplated, including television screens, third party websites (through partnerships), in-store kiosks, or personal keychains or dongles.
  • the recommendation engine 1 12 generates
  • recommendations for venues based on a variety of information such as user data, venue data and reviewer data. More specifically, the user data, venue data and reviewer data are combined as previously described herein to form link matrices the strength of which can be used to generate the recommendations for the user.
  • link matrices the strength of which can be used to generate the recommendations for the user.
  • nodal link values can "trick" the recommendation engine 112 into generating an outlying recommendation for the user.
  • a neural net configuration having nodal link strengths strongly geared to specific data such as venue attire, genre and price as well as reviewer data positively identifying venues having these traits may recommend a venue in a neighborhood that is quite different from the neighborhood where the user normally eats dinner.
  • the system 100 may also strongly link user attribute data such as work hours and profession to venues having corresponding business hours and attire such that the recommendation engine 1 12
  • the recommendation engine 1 12 will typically generate a recommendation set having a plurality of accurate recommendations, it is possible due to particular nodal links that the recommendation engine 1 12 may generate an outlying recommendation that does not "resonate" with the previous recommendations served to the user.
  • the recommendation engine 112 generates a recommendation for a venue that is in a neighborhood the user does not typically visit or typically receive recommendations to visit. Referring, for the purposes of this example, solely to the affinity expressed by Reviewer 7, there is a +0.75 collaborative-based link formed between Restaurant 7 and Restaurant 11. Further, based on the venue attributes themselves, there is a +0.25 rating as both Restaurant 7 and Restaurant 11 have the same attire. Additional ratings could be added therebetween as described previously based on similar hours and the fact that the price points of the
  • one exemplary embodiment of the system 100 provides processing for error correction and data verification via the recommendation engine 1 12.
  • the recommendation engine 1 12 can provide recommendations that correlate strongly to the content-based, collaborative- based and content-collaborative based interrelationships and that resonate with the plurality of recommendations that were previously made to the user.
  • the error correction and data verification acts as a guardian against recommendations that, although based on strong nodal links of the neural network topology, do not resonate with recommendations that were previously served to the user and acted upon by the user.
  • the error correction and data verification processing begins, in one embodiment by storing in the data repository 118 recommendations data that was previously generated by the recommendation engine 1 12 and served to the user.
  • the system 100 may designate a minimum number of recommendations that have to be stored before error correction and data verification processing is implemented but may also impose limits on the number of stored recommendations based on storage capacity and processing considerations.
  • recommendations data stored in the data repository 118 can in selected embodiments store not only the recommended venue itself but also the user data, venue data and review data that was considered most pertinent to the recommendations generated by the recommendation engine 112. Therefore, the data repository 1 18 can store a recommended venue in relation to the data values ascribed with the recommended venue itself such as genre, hours of operation, attire, neighborhood and any other value described herein or as would be understood by one of ordinary skill in the art.
  • the data repository 1 18 can also store any other data strongly relied upon by the recommendation engine 1 12 when generating the recommendation such as reviewer information, content-based link values, collaborative-based link values and user attribute data such as age, education and profession.
  • Figure 18 illustrates an exemplary data repository 1 18 storing previous
  • This example is of course non-limiting as the data repository can contain more entries as well as different types of recommendation data previously described herein and as would be recognized by one of ordinary skill in the art.
  • the recommendation engine 1 12 can provide a recommendation set to the user consisting of a plurality of recommended venues, it is assumed for he purposes of the examples provided by Figure 18 that each recommendation set provided to each user contained only one item of recommendation data. As it may be difficult to detect
  • the system 100 in selected embodiments can set a minimum number of recommendation data that is required for each user before the recommendation data can be relied upon for performing error correction and data verification processing. Therefore, the system 100 may not perform error correction and data verification processing until a predetermined threshold quantity of recommendation data has been stored in the data repository 118 for the particular user. This predetermined number relating to initiation of error correction and data verification processing may be manually set by the user via the user interface or automatically set by the system 100.
  • each user is stored in relation with recommendation data that has been previously recommended by the recommendation engine 1 12.
  • the first recommended venue for User 2 contained data such as a price point value of 3, an Italian genre, casual dress attire requirements and location neighborhood 02196 data.
  • the recommendation data stores the reviewers that reviewed the recommended venue (Restaurant 2) and user attribute information such as the age at which the recommendation was made and the number of children the user had at the time the recommendation was made. Therefore, the recommendation data stores values that will change over time such as the number of children and the age of the reviewer and user.
  • venue attributes values such as the price point value and neighborhood and reviewer affinity ratings may change over time.
  • Figure 19 illustrates an example of aggregate repository recommendation data stored in the data repository 118 according to selected embodiments that is generated based on the data repository of previous recommendations illustrated in Figure 18.
  • the system 100 collates the recommendation data for each user to determine statistical values for each item of information stored in the data repository 1 18 relating to previous
  • a recommendation set for User 2 including venues having high price points and/or venues in a neighborhood outside of 02196 may not resonate with the aggregate data stored in the data repository 1 18.
  • the system 100 can determine the aggregate recommendation data based on the previous recommendations stored in the data repository 118 in real time when making a recommendation and performing error correction and data verification.
  • the system 100 can aggregate the previous recommendations at a time when the system 100 is experiencing a lower than normal processing load and store the aggregate data as illustrated in Figure 19. Accordingly, the system 100 has the option of determining the latest aggregate information by aggregating the data at the time of performing error correction and data verification processing or can lower the processing load required for error correction and data processing by aggregating the stored recommendation data at periodic or predetermined intervals.
  • the stored recommendations can be aggregated in a variety of ways. For example, in one embodiment, the system 100 determines a
  • recommendation engine 112 may also limit the error correction and data verification processing to a certain number of recommendations to prevent out-of-date data from affecting resonate recommendation computations.
  • the data repository 1 18 can store a time stamp with each data recommendation entry such that the recommendation engine 1 12 can implement temporal filter values when performing error correction and data verification.
  • the system 100 can therefore adapt over time to the changing affinities of users and reviewers alike. For example, recommendations to a long-time system 100 user may have originally all been tailored to venues at a low price point with casual attire whereas the user is now older and mostly frequents venues at a higher price point with formal attire. However, the introduction of children into the user's lifestyle may then shift recommendations back to a lower price point. Reviewer ratings will most likely also change over time and therefore the recommendation engine 1 12 can reflect only the most recent and accurate ratings when performing error correction and data verification.
  • the previous recommendation data illustrated in Figure 18 and Figure 19 may also be weighted based on affinities explicitly expressed by a user such that the recommendation engine 1 12 provides more emphasis on specific attributes of data when performing error correction and data verification.
  • User 4 may indicate via the user interface that he prefers Japanese and Italian venues and venues in the neighborhood 02163. Therefore, when the recommendation engine 1 12 performs error correction and data verification it will determine whether the current recommendation resonates with the various aggregated datum of previous recommendation data but will also place particular emphasis on verifying that the current recommendation resonates with User 4's affinity for Japanese and Italian venues as well as venues in the neighborhood 02163.
  • Weights may also be provided to the aggregate data of previous recommendations based on the "primary" nodal link strengths of the neural network used by the
  • recommendation engine 1 12 to generate the previous recommendations. For example, based on content-based interrelationships, collaborative-based interrelationships, content- collaborative interrelationships, and higher-order interrelationships, the recommendation engine 112 may generate a recommendation primarily based on genre data and neighborhood data.
  • Figure 18 provides an illustrative example wherein all of the previous
  • the recommendation engine 1 12 may attach weights to these values such that they provide more influence on resonation calculations via the error correction and data verification processing as described above.
  • Figure 20 is a flow chart illustrating error correction and data verification processing according to one embodiment.
  • the process is initiated at S2000 with the recommendation engine 1 12 determining a recommendation set based on the neural network methodology described above. Processing then proceeds to S2002 to perform a comparison of the current recommendation data generated by the recommendation engine 1 12 with the aggregate recommendation data stored in the data repository 118.
  • the recommendation engine 112 can determine whether to initiate error correction and data verification based on the number of recommendations for a particular querying user that are stored in the data repository 1 18.
  • the recommendation engine 1 12 compares the current recommendation to the aggregate recommendation data stored in the data repository 118. In one embodiment, the recommendation engine 1 12 systematically compares each attribute included in the current recommendation data to each corresponding aggregated quantification value of each attribute to determine a resonate value for that attribute. Once each resonance value is determined for each of the attributes corresponding to those contained in the current recommendation, a resonance quantifier is determined based on the plurality of resonance values. If the resonance quantifier is less than a predetermined threshold, then the recommendation engine 1 12 determines that the current recommendation does not "resonate" with previous recommendations at S2004.
  • the recommendation engine 112 confirms that the current recommendation "resonates" with previous recommendations. [0203] If the recommendation engine 112 determines at S2004 that the resonance quantifier does not exceed the predetermined threshold and therefore that the current recommendation does not resonate with previous recommendations to the user, the recommendation engine 1 12 identifies the deficiencies in the current recommendation such that the matrix builder 126 can back propagate these deficiencies into the neural network to establish increased accuracy within the nodal links. For example, with reference to Figure 18 and Figure 19, if the recommendation engine generated a recommendation for a venue in a neighborhood outside 02196, the error correction and data verification processing may indicate this
  • the neural network is updated such that a negative link value is ascribed to the neighborhood identified in the recommendation with respect to the nodal links established for User 2.
  • the matrix builder 126 may ascribe an additional positive link value to the neighborhood 02196 to further ensure that neighborhood 02196 is given increased link strength thereby ensuring increased consideration in any future recommendations provided by the recommendation engine 112.
  • the error correction and data verification processing not only provides an additional filter for accurate recommendations but also acts as a vehicle for driving increased accuracy within the nodal links of the neural network itself.
  • the processing proceeds back to S2000 for the recommendation engine 112 to generate a new recommendation for the user based up the updated neural network.
  • the current recommendation is provided to the user at S2006 and the data repository 1 18 is updated to include an entry for the current recommendation.
  • this entry may include a time stamp indicating the time and date at which the recommendation data was entered into the data repository 1 18.
  • processing proceeds to updating the neural net nodal links at S2010.
  • the matrix builder 126 may update the nodal link strengths of the neural network based on data included in the recommendation data. For example, if the recommendation data for User 2 includes casual attire for the recommended venue, the matrix builder 126 may even out the nodal link strengths with respect to this attribute as User 2 has now been recommended the same amount of venues for both casual and formal attire. Further, this recommendation data "approved" by the error correction and data verification processing may be applied more weight when updating the neural network than
  • recommendation data that was created before error correction and data verification processing was initiated by the recommendation engine 1 12 as it has confirmed resonance with previous recommendations and is therefore more likely to be accurate.
  • a recommendation that is approved by the error correction and data verification processing may also be identified as a recommendation that has been determined to be effective based on the resiliency of the aggregate previous recommendation data.
  • the system 100 may store this recommendation data in the data repository 1 18 with a special label such that the recommendation engine 112 applies more weight to this information when performing error correction and data verification processing.
  • the system 100 may apply a "validation" label to this recommendation data in the data repository 1 18. In doing so, if the recommendation engine 1 12 is using only a predetermined number of previous recommendations, the recommendation engine 1 12 can improve error correction and data verification accuracy by using only "validated" previous recommendations. In other embodiments and if the recommendation engine 1 12 is using more previous recommendations than currently available validated previous
  • the recommendation engine 112 may apply special weight to the validated previous recommendations such that the error correction and data verification processing generates a resonance quantifier that is more strongly influenced by previously validated recommendations .
  • the system 100 must be constantly vigilant with respect to the changing attributes within the recommendation data, particularly the user attribute data. For example, if the user moves to a different part of the country then the matrix builder 126 will update the neural network accordingly thereby lowering the strength of links identifying venues in neighborhoods that are no longer in proximity to the user. Therefore, the nodal link strengths will be reflected in a new recommendation such that any recommendation by the recommendation engine 1 12 will be in neighborhoods in close proximity to the user's new location. However, when comparing a new recommendation to this user, the
  • recommendation engine 112 may identify this recommendation as an outlier as all previous recommendations were in neighbors geographically distant from the user's new location. Accordingly, the recommendation engine 1 12 may assign a label on the neighborhood attribute data within the data repository 118 of previous recommendations thereby identifying certain values of this attribute as data which should not be used when performing error correction and data verification. Therefore, the system 100 provides adaptive functionality to limit error correction and data verification processing to attributes that will not induce the recommendation engine 1 12 to provide erroneous results.
  • Another method for providing enhanced recommendations via error correction and data verification is to dynamically ensure resonance between information, such as review data, from various source sites that are used during harvesting operations.
  • the harvesting of data to create the neural network as previously described herein obtains information from a variety of sources such as web sites.
  • sources such as web sites.
  • the system 100 may not always have an up-to-date capture of information.
  • the system 100 periodically updates the neural network based on information gathered from source sites.
  • the user may perform a search query at a time before an update but after information from the source sites has changed.
  • error correction and data verification further provides the ability to dynamically determine resonance between information contained within the data repository 118 and information obtained from source sites as well as between information from different source sites.
  • the recommendation engine 112 will, just prior to generating a recommendation set, dynamically harvest data items from multiple source sites, such as web sites across the Internet, and resolve any differences between these data items.
  • venue data items from a majority of web sites relating to Restaurant 1 of Figure 4 may include information identifying Restaurant 1 as low cost and casual.
  • the recommendation engine 1 12 can resolve these differences by indicating certain web sites as containing inaccurate information with respect to a venue. Once the outlying information is obtained, the neural network is dynamically updated as previously described herein while excluding the outlying information thereby allowing the recommendation engine 1 12 to provide a more accurate recommendation set based on new overall link strengths of the updated network topology.
  • a sliding scale resonance threshold may be applied to determine at what point information can be deemed accurate as opposed to outlying with respect to other harvested information.
  • the scale may be set by the system 100 or a user such that 75% of the information harvested must conform in order to determine that information not conforming with information in the 75th percentile is outlying information.
  • the system 100 may further adjust the threshold based on the amount of web sites containing information about a certain venue. For example, the more information with respect to the same data items that the system 100 can obtain during harvesting operations, the higher the threshold may be set as there is a large data set from which to draw accurate information.
  • the system 100 may determine that the 45 web sites indicating Restaurant 1 as expensive and formal are outliers and will not take their information into account when updating the neural network.
  • the system 100 may not identify the 450 items of Restaurant 1 venue information as outlying information as there is a larger data set of which 65% is not a high enough resonance threshold.
  • the system 100 may opt to use the information contained within the 650 web sites but provide a negative weighting to this information so that it does not have too much of an effect upon an update of the neural network topology.
  • the system 100 may ignore all of the information and determine that it cannot be resolved and therefore that none of it should be used to update the neural network topology.
  • the neural network topology is updated and the recommendation engine 1 12 provides a recommendation set based on a current real-time snapshot of information contained within the Internet. Accordingly, information provided to the users is as accurate as possible with respect to information harvested from the Internet. Further, this allows the system 100 to determine "trendiness" data among web sites such as certain attribute data which is likely to change rapidly. This provides the system 100 with the ability to identify various types of fickle data and provide appropriate weights when calculating nodal links strengths within the neural network so that the user receives recommendation sets based on the most stable and accurate information harvested by the system 100.
  • error correction and data verification provides the system 100 with a way to avoid outlying recommendations as well as a way to monitor venue, reviewer and user attributes that change over time.
  • users are often inclined to change their interests spontaneously to try something new or simply to see what options the system 100 may produce in response to queries containing a variety of user filters.
  • the user may express an affinity for a particular venue but may want to further limit the search to venues that have particular hours, attire and neighborhood requirements.
  • the recommendation engine 1 12 must generate a plurality of recommendation data having venues with the strongest link strength to the venue provided by the user but which are also limited to the hour, attire and neighborhood requirements.
  • the recommendation engine 1 12 determines a plurality of venue recommendations based on nodal link strengths and then compares the nodal link strength of each recommendation to a recommendation threshold to determine whether or not the venue should be recommended to the user.
  • the recommendation threshold indicates a watershed overall link strength value or in other selected embodiments a percentage identifying the number of recommendations that will be recommended by the
  • the recommendation engine 1 12 may only serve recommended venues having nodal link strengths exceeding the recommendation threshold such that only 3 out of the 10 recommended venues are served to the user.
  • the recommendation engine 1 12 may not recommend any venues if none of the nodal link strengths are greater than the recommendation threshold. In this instance, the user would be served with a useless empty recommendation set thereby lowering user confidence in the system and increasing the likelihood the user will turn to other systems for information.
  • Figure 21 A illustrates an exemplary search according to the above-noted principles by describing the outputs of the recommendation engine 1 12 based on a query for a recommendation for an American restaurant with casual attire and a user affinity for
  • the recommendation engine 1 12 determines the venues having the strongest nodal link strength to Restaurant 5 while also limiting the
  • the recommendation is a blending of at least the content-based link strength 2100, collaborative link strength 2104 and content-collaborative link strength 2108.
  • Each link strength is assigned a distinct weighting factor 2102, 2106 and 21 10.
  • Figure 21 A provides respective values for content-based link strength 2100, collaborative link strength 2104 and content-collaborative link strength 2108. As Restaurant 3 has no content-based
  • the content-collaborative link strength 2108 is exemplary as are the weighting factors 2102, 2106 and 21 10. Based on a first order sum of products, the overall link strength for Restaurant 3 is 0.075.
  • Restaurant 6 has the same attire as Restaurant 5 and therefore has a content-based link strength 2100 value of 0.25 but has a negative collaborative link strength 2104 value of -1.0 based on a strongly opposite affinity expressed by Reviewer 3.
  • the content-collaborative link strength 2108 of Restaurant 6 is exemplary as are the weighting factors 2102, 2106 and 21 10.
  • a first order sum of products produces and overall link strength 21 12 value of -0.1875.
  • values of A-F are assigned, respectively, for content-based link strength, collaborative link strength, content-collaborative link strength and their corresponding weighting factors.
  • Restaurant(s) X have an overall link strength of G.
  • the result of the above-noted query is Restaurant 3, Restaurant 6 and Restaurant(s) X. Therefore, assuming X represents a small number of restaurants having an overall link strength less than Restaurant 3 and Restaurant 6, and based on the filter state implemented by the user via the user interface at the time of the query for recommended venues, the recommendation data set for this filter state is very small. Further, the overall link strengths of Restaurant 3 and Restaurant 6 are low enough that the recommendation engine 1 12 may not recommend them to the user if they do not pass the recommendation threshold. For example, if the recommendation threshold is set at a value of 0.25, neither Restaurant 3 or Restaurant 6 would be recommended by the recommendation engine 1 12 and an empty recommendation set would be provided to the user.
  • the recommendation threshold is effective for reducing a large recommendation data set, it can also act as a barrier for passage of all recommendations when the recommendation set is extremely small and/or has small overall link strength values therein. Therefore, the system 100 must provide a way to avoid serving empty
  • recommendation sets to users when the search returns a limited recommendation set having low overall link strength values In other words, the system 100 must balance the need to provide information to the user while also considering the value or relevance of the information being presented to the user such that user does not lose interest or confidence in the system 100.
  • Geometric contextualization is a mechanism for overcoming the problem of limited recommendation sets by ensuring that at least one recommendation is always provided to the user via the recommendation engine 1 12.
  • contextualization is to adjust the overall link strength values of the recommendation set generated by the recommendation engine 1 12 until at least one of the recommended venues exceeds the recommendation threshold. The recommended venues exceeding the
  • recommendation threshold can then be served to the user or a predefined percentage of recommendations out of the recommendation set that have had their overall link strengths adjusted are served to the user.
  • the overall link strength values of each recommendation are normalized using a normalization factor that is based on various factors until the overall link strength value of at least one recommended venue exceeds the recommendation threshold. Accordingly, in selected embodiments, geometric
  • contextualization is performed every time a recommendation a set is generated by the recommendation engine 1 12 to further redefine recommendation rankings based on a variety of factors to enhance the accuracy of the percentage of recommendations served to the user.
  • One factor that can be used to generate the normalization factor for normalizing the recommendation set is the number of potential recommendations available based on the filter state set by the user at the time of performing the query. For example, if there is a large number of recommendations available based on the filter set and the only issue is that none of the recommendations of the set exceed the recommendation threshold, a minimal
  • the normalization factor may be utilized to normalize the recommendation set such that a limited amount of recommendations exceed the recommendation threshold. Therefore, the recommendation engine 1 12 may generate a normalization factor to ensure that a
  • predetermined number of recommended venues exceed the recommendation threshold. This ensures that the recommendation engine 1 12 can serve the user with at least one
  • the recommendation engine 112 perform geometric contextualization with a low normalization factor for a large recommendation set, only the recommendation values with the largest overall link strength will be provided to the user. If the recommendation set is smaller in size, the recommendation engine 1 12 may need to generate a drastically different normalization factor to ensure that at least one recommended venue will be normalized to a value exceeding the recommendation threshold based on the nodal link strengths of the smaller set of recommended venues.
  • the normalization factor value itself can be set by the recommendation engine 1 12 based on specific calculations with respect to the recommendation set.
  • the recommendation engine 1 12 can analyze the recommendation data set and determine a normalization factor that will ensure that the overall link strength of at least one recommended venue exceeds the recommendation threshold.
  • the system 100 or the user via the user interface may set a specified number of recommendations to receive for each query. Therefore, the recommendation engine 1 12 may calculate a normalization factor that will ensure the overall link strengths of the specified number of recommended venues exceeds the recommendation threshold to ensure the user receives the requisite number of recommendations.
  • the recommendation engine 1 12 may set the
  • the recommendation engine 112 may calculate a normalization factor that ensures at least one recommendation having strong content-based link strength is elevated past the recommendation threshold even if other recommendations having higher overall link strengths exist in the recommendation set.
  • the recommendation engine 1 12 may apply the normalization factor only to those venues in the recommendation set that have a requisite level of content-based link strength.
  • this method may be applied based on collaborative link strength, content-collaborative link strength and/or higher order interrelationships. This provides the system 100 with the ability to elevate those recommendations that have a lower overall link strength but that may prove more effective for the user based on previous user statistics. This enhances the users overall experience with the system 100 and provides enhanced data for merchant vendors.
  • FIG. 21B An example of geometric contextualization using a normalization factor based on the number of potential recommendations is illustrated in Figure 21B with reference to Figure 21 A.
  • the recommendation engine 1 12 has generated Restaurants 3, 6 and Restaurant XI in response to the user query identified for Figure 21 A.
  • a recommendation threshold of 0.25 and an overall link strength value G that is less than 0.25 for Restaurant XI none of the overall link strengths 21 12 exceed the recommendation threshold. Accordingly, the system 100 determines that the recommendation engine 1 12 needs to perform geometric contextualization on the
  • the recommendation engine 1 12 determines that there is a small number of recommendations (3) available and therefore an adequate normalization factor must be calculated to ensure that at least one of the recommended venues exceeds the recommendation threshold once the process of geometric contextualization is finished. Accordingly, assuming a user specified or system 100 specified recommendation limit of two, the recommendation engine 1 12 must calculate a normalization factor such that two of the overall link strengths are elevated above the 0.25 recommendation threshold. Accordingly, a normalization factor of +0.175 is added to the overall link strength 21 12 value of each venue in the recommendation set.
  • Figure 2 IB illustrates the effects of geometric contextualization on the recommendation data illustrated in Figure 21 A as discussed. In Figure 2 IB, due to the effects of normalization, both
  • Restaurant 3 and a Restaurant XI out of the set of recommended venues have the requisite overall link strength of at least 0.25 to ensure they are higher than the recommendation threshold and can therefore be served to the user via the user interface.
  • the recommendation engine 1 12 may generate a normalization factor specific to venues having the highest content-based link strength thereby providing extra emphasis to the overall link strength of Restaurant 6 with respect to the predetermined threshold. Standard normalization factors may then be applied to the remaining venues in the recommendation set. Therefore, if a strong enough normalization factor is applied specifically to Restaurant 6, Restaurant 6 may exceed the recommendation threshold upon completion of geometric contextualization.
  • the recommendation engine 1 12 may determine a normalization factor such that Restaurant 6 still does not exceed the recommendation threshold despite the previous user statistics with respect to the content-based interrelationships. Therefore, the recommendation engine can perform geometric contextualization to avoid empty
  • recommendation sets while taking into account previous user statistics and balancing them against overall link strengths determined from the nodal links of the neural network.
  • the recommendation engine 1 12 may only perform geometric contextualization on recommendations having lower price points thereby elevating recommendations strongly relating to user-specific characteristics. Therefore, although not shown in Figure 2 IB, the recommendation engine 1 12 may only perform geometric contextualization on Restaurant 6 as it has a low price point with respect to Restaurant 3. Accordingly, in this example, even with a negative overall link strength, Restaurant 6 may be elevated above the recommendation threshold such that the user receives a recommendation tailored to his characteristics.
  • the recommendation engine 112 may also perform geometric contextualization based on the aggregate or individual quality of the recommendation data identified in the recommendation set.
  • the quality of the recommendations in the recommendation set can also be determined based no the overall link strength between the recommended venues and venues identified by the user in a search query. Further, in selected embodiments, the quality of the recommendation data is determined by identifying the effectiveness of the
  • the recommendation engine 112 can search each recommendation data item to determine which recommended venues are most closely related to the recommendation data that has previously been determined to be effective or have the strongest overall link strength to venues identified in the search query. Based on this determination, the recommendation engine can then perform geometric contextualization by determining a normalization factor that will elevate the requisite amount of recommendations from the "effective subset" above the recommendation threshold.
  • FIG. 21C An example of geometric contextualization using a normalization factor based on the aggregate or individual quality of the recommendations in the recommendation set is illustrated in Figure 21C with reference to Figure 21 A.
  • the recommendation engine has generated Restaurants 3, 6, and Restaurant XI in response to the user query identified for Figure 21 A.
  • a recommendation threshold of 0.25 and an overall link strength value G that is less than 0.25 for Restaurant XI none of the overall link strengths 2112 exceed the
  • the system 100 determines that the
  • recommendation engine 1 12 needs to perform geometric contextualization on the
  • the recommendation engine 1 12 determines that Restaurant 3 and Restaurant 6 are of higher quality based on the effectiveness of previous recommendations made by the recommendation engine 1 12 that are stored in the data repository 1 18 with a validation label. For example, the recommendation engine 1 12 can determine from data stored in the data repository 118 that User 2 has visited Restaurant 8 numerous times based on financial transactions from Restaurant 8 and further based on geographic habituations with respect to User 2 proximity to the neighborhood 02196. Accordingly, the recommendation engine 1 12 determines a quality factor for
  • the recommendation engine 1 12 may determine the effectiveness of Restaurant 2 based on a multitude of positive review data from User 2 and further determine that User 2 often eats at venues having casual attire and lives in neighborhood 02199 such that a quality factor for Restaurant 3 is calculated based on these considerations. Further, for the purposes of this example, it is assumed that the
  • recommendation engine 1 12 does not calculate Restaurant XI as a high quality
  • recommendation as the recommendation engine 1 12 can not determine many similarities to other venues based on effectiveness data in the data repository 1 18. Therefore, although Restaurant 6 has a low overall link strength 2114, the recommendation engine determines that a normalization factor should be generated based on Restaurant 6 and Restaurant 3 in order to elevate the overall link strength of these restaurants past the recommendation threshold.
  • the recommendation engine 1 12 determines a quality factor of 0.65 for Restaurant 3 as it has multiple similarities to previously determined effective recommendations. Further, the recommendation engine 112 determines a quality factor of 0.55 for Restaurant 6 as it has fewer similarities to previously determined effective recommendations stored in the data repository 1 18. For Restaurant XI, the recommendation engine 112 determined a quality factor of 0.15. At this point, assuming a user specified or system 100 specified recommendation limit of two, the recommendation engine 1 12 must calculate a normalization factor based on the quality factors such that two of the overall link strengths are elevated above the 0.25 recommendation threshold.
  • the recommendation engine 1 12 may also perform geometric contextualization based on the diversity of the recommendations in the recommendation set. For example, assuming the recommendation engine 112 generates six recommendations, only three of these recommendations may be related whereas the other three may be diverse from each other and the three related recommendations. For example, three of the recommendations may relate to restaurants all have the same genre and neighborhood whereas the other three
  • the recommendation engine 1 12 may further compare price points and venue attire to determine similarities between the recommended venues. Accordingly, content-based links, collaborative links and content- collaborative links between the recommended venues are determined by the recommendation engine 1 12 to determine overall link scores therebetween thereby identifying which recommended venues are most closely related and which recommended venues are diverse from each other. The recommendation engine 1 12 may then determine a normalization factor to elevate recommendations that are similar to each other above the recommendation threshold as it is likely that multiple similar recommendations are closer to the affinity of the user as opposed to a variety of potential outlying recommendations have little to no relationship therebetween.
  • FIG. 21 D An example of geometric contextualization using a normalization factor based on the diversity of the recommendations in the recommendation set is illustrated in Figure 21 D with reference to Figure 21 A.
  • the recommendation engine has generated Restaurants 3, 6, and Restaurant XI in response to the user query identified for Figure 21 A.
  • a recommendation threshold 0.25
  • an overall link strength value G that is less than 0.25 for Restaurant XI
  • none of the overall link strengths 21 12 exceed the recommendation threshold. Accordingly, the system 100 determines that the recommendation engine 112 needs to perform geometric contextualization on the recommendation data.
  • the recommendation engine 1 12 determines that Restaurant 6 and
  • Restaurant XI are closely related based on content-based links, collaborative links and content-collaborative links and that Restaurant 3 is quite diverse from both Restaurant 6 and Restaurant XI .
  • the recommendation engine 1 12 can determine from data stored in the data repository 1 18 that Restaurant 6 and Restaurant XI have similar price points, similar neighborhoods, similar review data and similar hours of operation. Accordingly, the recommendation engine 1 12 determines a diversity factor for Restaurant 6 based on similarities between Restaurant 6 and Restaurant 3 and Restaurant XI . Further, the recommendation engine 1 12 repeats this diversity determination for both Restaurants 3 and XI to determine their diversity factor with respect to the other restaurants in the
  • exemplary values of diversity factors are identified in Figure 2 ID with respect to each recommended venue.
  • recommended venues having a lower diversity factor are venues that have more similarity to other venues win the recommendation set whereas recommended venues having higher diversity factors are venues that are not that related to other venues in the recommendation set.
  • Restaurant 6 has the lowest diversity amongst the recommended venues and therefore has a diversity factor of 0.25 whereas Restaurant 3 is the least related amongst the venues and has a diversity factor of 0.75.
  • Geometric contextualization can also be performed with respect to a distance function defined by the user and/or the system 100 and stored as part of the user attribute data illustrated in Figure 6.
  • each user may predefine his own individual distance function identifying geographic preferences with respect to any recommendations made on his behalf.
  • the system 100 may also further redefine this distance function based on the local geography and cultural geography of a given location. For example, the user may live in a city and not have a car such that the system 100 defines the local public transportation boundaries as a distance function for recommendations such that any recommendation served to the user should be within those boundaries.
  • the user may also identify the city limits as their geographic distance function.
  • the system 100 can analyze information from different cities to identify which cities are, for example, walking cities and which cities allow for broader transportation options.
  • the system 100 will define a smaller geographic distance function where as for driving cities, such as Los Angeles, the system 100 will define a larger geographic distance function.
  • a radial distance function is defined for the user such that the recommendation engine 1 12 generates recommendations within the boundaries defined by the user and the system 100 even if these recommendations do not have as high of an overall link strength as other recommended venues in neighborhoods outside the users radial distance parameters. Further, for example, if the recommendation engine 1 12 generated 50 recommendations but only 20 of those were within the distance function defined with respect to that user, the recommendation engine 1 12 may focus only on the 20 geographically appropriate
  • the system 100 may in this instance serve a percentage of those recommendations have the highest overall link strengths that are within the number of recommendations in the radial distance of the user.
  • the system 100 may also provide recommendations based upon a combination of the above-noted geometric contextualization methods. For example, the system 100 may perform geometric contextualization based on the number of potential recommendations, the individual quality of the recommendations, the diversity of the recommendations, the distance function and serve the user with recommendations based on the results of all three geometric contextualization processes.
  • the recommendation engine 1 12 may determine a subset of recommendations within the generated recommendation set that are determined to be higher quality, determine an adequate normalization factor based on the number of recommendations in the subset and then perform geometric contextualization based on the normalization factor to generate the requisite amount of recommendations that are above the recommendation threshold. Further, the recommendation engine 112 may determine a subset of recommendations by determining which recommendations comply with the distance function identified by the user and/or system 100, determine a ranking of these
  • recommendations in terms of quality with respect to overall link strength and effectiveness data and provide a heavy weighting factor to this ranking based on quality factors, determine which of these recommendations have the lowest diversity factor and slightly adjust the ranking to ascend recommendations having lower diversity factors and lower
  • the recommendation engine 1 12 can identify overlapping recommendations based on the various methods and serve these recommendations to the user.
  • the recommendation engine 1 12 may also weigh the various methods of geometric contextualization based on their perceived effectiveness based on the recommendation data set and provide recommendations to the user based on overlap and weighting effects of the different processes.
  • the normalization factor generated by the recommendation engine 1 12 may be calculated based on a combination of data relating to the number of potential recommendations available in the filter state, the aggregate or individual quality of those recommendations, and the diversity of those recommendations. Accordingly, the recommendation engine 1 12 can calculate a normalization factor by using calculated data values based on these factors as inputs. The normalization factor is then applied as described above to elevate the requisite amount of recommendations above the recommendation threshold.
  • the system 100 may require that a certain percentage of recommendations out of the recommendation set be served to the user for each user query. This percentage can change based on factors such as the number of recommendations generated or the number of recommendations generated that have overall link strengths above the predetermined threshold. Accordingly, upon determining a set of recommendations based on overall link strength as previously described herein, the recommendation engine 1 12 may perform geometric contextualization to redefine a ranking of the recommendations based on at least the number of the recommendations, the quality of the recommendations, the diversity of the recommendations, and the distance function in order to provide an enhanced set of recommendations to the user. Upon ranking the recommendations in the recommendation set based on geometric contextualization, the most highly ranked recommendations are selected in descending order until the percentage of required recommendations is met. This set of recommendations is then server by the recommendation engine 1 12 to the user via the user interface.
  • geometric contextualization can be performed only when a predetermined number of recommendations generated by the recommendation engine 112 based on overall link strength do not have overall link strengths above the recommendation threshold. Geometric contextualization then elevates the required amount of recommendations above the recommendation threshold such that the required amount of recommendations can be provided to the user via the user interface.
  • the system 100 may perform geometric contextualization for every search query performed by the user such that recommendations generated by the recommendation engine 112 and provided to the user based on overall link strength are further enhanced and reordered based on at least the number of potential recommendations, the quality of the recommendations, the diversity of the recommendations and the distance function of the particular user or users.
  • the system 100 can serve the recommendation data or datum to the user via the user interface with the caveat that the system had to perform some additional processing based on the filter state to obtain the specified number of recommendations. Therefore, the user can be warned that although they have been provided the requisite number of recommendations that these recommendations did not perfectly match the filter state and should therefore be strongly considered.
  • the system 100 could also provide the user with information based on the type of geometric contextualization performed with respect to the filter state. For example, if geometric contextualization is performed based on the number of potential recommendations and known user characteristics, the user may be informed that a certain venue was selected outside the filter state based on previous user characteristic venue price points.
  • the system 100 could provide the user with a combination of recommendations based on this geometric contextualization method such that the system 100 informs the user that one recommendation is based on elevated overall link strength and the other recommendation is based on previously known user characteristics.
  • the recommendation engine 112 may determine a large set of recommendations based on overall link strength with respect to an affinity of a venue provided by the user but the number of recommendations in this recommendation set will be lowered based upon the user filter state. Therefore, the recommendation engine 112 must determine at S2202 whether geometric contextualization is required based upon the recommendation set. If there is a large number of recommendations in the recommendation set that exceed the recommendation threshold, the recommendation engine 1 12 may determine that geometric contextualization is not required thereby lowering the processing load on the system and providing quicker results to the user. At this point, the
  • recommendation engine 1 12 proceeds to S2210 to provide the one or more recommendations to the user. However, if there a requisite amount of recommendations that exceed the predetermined threshold has not been generated, the recommendation engine 1 12 determines at S2202 that geometric contextualization is required. Further, the system may find a number of recommendations that exceed the recommendation threshold but if this number is lower than a user or system 100 specified number of recommendations required to be presented to the user, the recommendation engine 112 will proceed with geometric contextualization to obtain the requisite amount of recommendations. Further, in other selected embodiments, the recommendation engine 1 12 may always perform geometric contextualization on the recommendation set to further redefine a ranking of recommendations in the recommendation set based on the above-noted input factors such as quantity of recommendations, quality of recommendations, diversity of recommendations and user distance factors.
  • the recommendation engine 112 determines the normalization factor based on the information contained in the recommendation set itself as previously described. Therefore, the recommendation engine 1 12 determines which method or combination of methods for generating a normalization factor will be the most effective and proceeds to generate the normalization factor based on these methods at S2204. The recommendation engine 1 12 then normalizes the overall link strength values identified from the search results to obtain at least one recommendation with an overall link strength value above the recommendation threshold.
  • the recommendation engine 1 12 analyzes at S2208 the normalized recommendation values to ensure that the recommendation set now contains enough recommendations values that exceed the recommendation threshold. If the number of recommendation values exceeding the recommendation threshold is still below the number of recommendations required by the user or system 100 for search results, the recommendation engine 112 repeats steps S2204 to S2208 to determine another appropriate normalization factor and re-normalize the recommendation set. This process is repeated until the requisite number of recommendation values exceeding the recommendation threshold is obtained. Once the recommendation engine 112 determines at S2208 that there is an adequate number of recommendations greater than the recommendation threshold, the recommendation engine 1 12 serves the one or more recommendations to the user via the user interface at S2210. The user can then perform additional searches and/or set a further filter state to further refine the search for additional recommendations.
  • the system 100 in selected embodiments performs the geometric
  • the system 100 can ensure that the recommendation engine 1 12 will always provide at least one recommendation to the user regardless of the filter state. This bolsters user confidence in the system and decreases the likelihood that users migrate to other systems.
  • recommendation engine 1 12 has determined a recommendation set having an adequate number of recommendations, the system 100 may then perform error correction and data verification to further ensure and/or strengthen the accuracy of the recommended venues which may in turn be used to identify reviewers who have submitted review data with respect to the recommended venues and venues in other locations requested by the user.
  • the system 100 can present a user with recommendations based on user input and neural connections created between a variety of nodes via content- based relationships, collaborative relationships and content-collaborative relationships.
  • a user in Boston can get recommendations for other venues in Boston based on overall link strengths and post-recommendation processing performed by the
  • recommendation engine 1 12 An issue arises when a user in one geographical area wants to get recommendations for venues in a geographically distant or diverse geographic location in which the system 100 does not contain much information about user interests. For example, a user in Boston may have an upcoming trip to New York and may query the system 100 for recommendations on places to eat in New York. This request may be difficult if there is an information deficit within the system 100 such that it contains large amounts of information as to which venues the user likes in Boston but not much, if any, information on the likes or dislikes of a user with respect to New York. In other words, neural network connections between the extensive neural network topology of the user in Boston and the limited neural network topology of the user in New York are not well defined. Therefore, the system 100 must use information known about the user in Boston to extrapolate information the recommendation engine 112 can use to generate a set of recommended venues in New York.
  • the system 100 can use information relating to the geometric locale of the user performing the search by taking advantage of a predetermined amount of interconnectivity of venues in the neural network developed at that geometric locale.
  • Figures 7 and 8 represent neural network interconnectivity based on connections formed via content-based and collaborative interrelationships defined based on user data, review data and venue data as previously described. This information is based on
  • the recommendation engine 1 12 can then, at the time of generating a recommendation, use review data relating to the local venues as well as the venues in New York to determine connections to venues in New York that are most closely related to venues in Boston.
  • the recommendation engine 1 12 receives which locale the user would like to obtain recommendations for and polls reviewer information to identify reviewers who have reviewed venues in the locale the user is searching for and the locale the user is located in when performing the search. This reviewer information is obtained from a variety of sources as described above with respect to web crawling and the identification of venue reviews. Once the recommendation engine 1 12 has determined the plurality of reviewers having provided reviews for both locales, the recommendation engine 112 processes the
  • the recommendation engine 112 determines positive or negative affinity connections between a variety of venues within multiple locales based on the review data linking the locales via collaboratively formed interrelationships.
  • the data repository 1 18 contains amplified inter-connections between venues in both locales from which the recommendation engine 112 can draw upon to make
  • the recommendation engine 112 looks for strong overall link strengths between venues in the geographically distance locale and the venue(s) the user expressed an affinity for as part of his search query or venues the user is known to like.
  • the venues in the geographically distant local having the strongest overall link strengths to these venues are then generated by the recommendation engine 112 and served to the user via the user interface. Therefore, the system 100 can provide a user with the ability to identify venues of interest in foreign locales by using review data between locales in which the system 100 contains a highly developed neural network topology with respect to user interests and a foreign domain in which the system 100 does not have much information about user interests by augmenting the neural network interconnect! vity therebetween via correlative review data.
  • Figures 23 and 24 provide an illustrative example of the initial processing of interconnectivity augmentation of determining interconnection data between two
  • the system 100 may only perform interconnectivity augmentation with respect to venues that are closely related to the venue in which the user has expressed an affinity for in his search as determined based on at least the overall link strength or other methods described above. For example, in this embodiment if the user expresses an affinity for an American restaurant having casual attire and a low price point, the recommendation engine 112 will determine a set of venues having a strong overall link strength with respect to this restaurant within Boston and then perform interconnectivity augmentation to determine which of these venues have review data in which the reviewer also provided data for venues in New York.
  • the recommendation engine 112 will identify a plurality of other venues having a strong overall link strength with the previous set of generated venues and the system 100 will again determine if there is enough review data between both locales such that nodal links between both Boston and New York can be updated in a way that allows the recommendation engine 112 to recommend venues in New York with a high level of confidence . This process is repeated until the system 100 determines that a predetermined number of venues in which review data is available for both locales has been reached.
  • Figure 23 provides an illustrative example of a plurality of venues identified by the system 100 in which Reviewers 1-5 have provided review data for both Boston and New York. For illustrative purposes and the ease of explanation, Figure 23 provides three venues in both New York and Boston but it is noted that this is only a non-limiting example as additional restaurants would likely be included when performing interconnectivity augmentation. As seen in Figure 23, Reviewer 1 is an avid reviewer and has provided a plurality of reviews in both Boston and New York and Reviewer 3 is less active and has only provided review data for one restaurant in New York and Boston.
  • Restaurant A and Restaurant F have a strong collaborative interrelationship nodal link value of +1.5 based on strong reviews by Reviewer 1 whereas Restaurant D and Restaurant F have a very low collaborative nodal link value of -1.5 based on opposite affinities expressed by both Reviewer 1 and Reviewer 2.
  • These collaborative venue link values represent interconnections between Restaurants A-C of New York and Restaurants D-F of Boston. Therefore, as previously discussed, through the process of interconnectivity augmentation, the system 100 traces sparse cross connections between venues of different locals (Boston and Yew York) to create "spider webs" of information therebetween. The recommendation engine 1 12 can then navigate links of these spider web based on overall link strengths to determine recommended venues in New York based on the neural network topology interconnections between Boston and New York.
  • Figure 25 presents a connectivity diagram illustrating the spider web generated by the system 100 based upon a user query for a restaurant in New York and the review data obtained for venues in both New York and Boston.
  • Solid connections between the venues represent a positive collaborative link between the venues whereas dotted connections represent a negative collaborative anti-link between the venues.
  • the nodal link 2500 between A and F is a solid line with relative thickness based on the overall collaborative link strength value of +0.75.
  • the nodal anti-link 2502 between D and F is has a relative thickness and is dashed to represent a negative overall collaborative link strength of -1.5.
  • the recommendation engine 112 can determine a variety of recommendations for the user for New York based on the overall collaborative interconnectivity link strengths between the restaurants in Boston and New York.
  • the recommendation engine 1 12 may generate a recommendation containing Restaurant A in New York as Restaurant A is directly linked to Restaurant E via nodal link 2500 and has a positive collaborative nodal link value.
  • the recommendation engine 112 may also recommend Restaurant B as it is linked to
  • the recommendation engine 1 12 may still recommend Restaurant A over Restaurant B even though both Restaurant A and Restaurant B are linked to Restaurant F as Restaurant A has a stronger collaborative nodal link strength with Restaurant F via link 2500.
  • Restaurant B could also be served to the user as an alternative choice.
  • the system 100 will determine the venue having the strongest overall link to the restaurant provided in the search query but which also has ample review data with respect to venues in the foreign local in which the user is seeking recommendations.
  • the recommendation engine 1 12 can the navigate the neural network amplified via interconnectivity augmentation to find a recommendation in New York based on the venue in Boston having the strongest overall link strength value to the venue the user expressed an affinity for in his search query.
  • the interconnectivity augmentation process determines venues having strong overall link strengths with venues the user expresses an affinity for when performing a search query and then determines a plurality of reviewer data with respect to these venues and the location in which the user is requesting recommended venues.
  • a network topology based upon the collaborative values between venues with respect to the review data is generated and it is determined whether there enough information from which the system 100 can make a recommendation to the user. If there is not enough information, the system 100 generates additional local venues with links to the restaurant provided in the search query and the network topology is updated based on review data with respect to the venues and the venues in the foreign local.
  • the recommendation engine 1 12 determines recommended venues in the foreign local by following the strongest overall nodal links in the network topology while starting at the local node expressed in the search query or the local node having the strongest overall link to the venue identified in the user search query. The recommended venues are then served to the user via the user interface. [0251] If the user provides additional filters with the search query in addition to the affinity for a particular venue, the system 100 will take this into account when creating the network topology by harvesting data on the local and foreign venues and identifying which data corresponds to the data within the filter.
  • the system 100 may perform interconnectivity augmentation to recommend venues in a foreign local in which the system 100 has very little information about user interests by taking into account user specific information known to the system 100 in other locals
  • the system 100 may not have much information about what the user likes in New York but may have ample information about what user likes in Boston. Accordingly, user attributes, review data from the user, previous recommendations known to have been effective and the interrelationships formed based on content and reviewer data from the user local can all be used to extrapolate venue "clones" in a foreign local that are similar to or identical to venues known by the system 100 to be well received by the user.
  • nodal doppelgangers can then be incorporated into the neural network topology previously defined as discussed above based on content and collaborative interrelationships within the local area of the user such that the system 100 can follow the nodal links to determine venue clones in a foreign locale that may be of interest to the user. Further, the list of nodal doppelgangers will inherently be cross- connected with a plurality of other venues within the foreign locale such that additional recommendations can be made to the user. Accordingly, alternatively or in addition to review data between two locales, interconnectivity augmentation can also be performed based solely on user interest information from other locales.
  • Figure 26A is a chart illustrating an exemplary sample set of venues within New York, New York that are stored within the data repository 1 18. As with Figure 4, each Restaurant A-E has its own price, genre, hours of operation, attire, and neighborhood.
  • the system 100 contains information, determined via web crawling and web harvesting, about venues in Boston and nodal interrelationships therebetween and knows information about venues in New York but does not have information on nodal links between the venues in Boston and the venues in New York. Therefore, interconnectivity augmentation can be performed utilizing nodal cloning in order to determine intercity nodal relationships between Boston and New York.
  • the system 100 must determine which venues the user is typically interested in Boston.
  • the system 100 can receive as part of the search query for venues in New York, restaurants in Boston that the user likes in which he wishes to find similar restaurants in New York.
  • the system 100 can also determine which venues the user likes based on previous recommendation data that has been determined to be effective via financial transactions of the user, positive review data, GPS data or other data as described previously herein.
  • the system 100 then compiles this list of interests of the user within Boston and compares each venue or piece of interest to known venues in New York to determine nodal doppelgangers within New York that have many of the same features of the venues identified within Boston.
  • Figure 26B is a chart illustrating the results of processing to determine a congruency factor representing a similarity level between the venues of interest from Boston and venues in New York. In Figure 26B, it is assumed for the purposes of this example that both
  • Restaurant 6 and Restaurant 10 were included as part of the search query by the user for restaurants in New York and/or were determined to be venues that were previously recommended and were effective with respect to the user. Accordingly, the system 100 compares each attribute of Restaurant 6 and Restaurant 10 to each attribute of a plurality of identified venues within New York in an attempt to determine one or more venue clones having a high congruence factor with Restaurant 6 and Restaurant 10 of Boston.
  • the congruency factor scores are exemplary and will change based on various venue attributes as well as different weights assigned to various venue attributes. For example, genre may be weighted the highest as a user searching for restaurants in New York who provides Restaurant 6 of Boston as part of the search query will likely identify with New York restaurants that have the same type of food. Further, price may be weighted less than genre but more than attire. These weights can be set automatically by the system 100 or manually by the user performing the search.
  • the congruency score for Restaurant 6 of Boston in comparison to Restaurant C of New York is not 1.0 because it is assumed that there may be other factors taken into consideration in determining how similar Restaurant C is to being a clone of Restaurant 6. These factors include, but are not limited to, hours of operation, review data, user characteristic data and previously defined nodal link
  • the user may also indicate likes and dislikes which will affect the weighting of the various venue attributes. For example, if the user detests dressing up when going out to dinner, the system 100 may apply an extremely high weighting factor to the attire attribute thereby causing restaurants requiring formal attire to have extremely low congruency factors even though they are similar to the identified local restaurant in many other respects.
  • the system 100 updates the neural network topology to form nodal links between the identified venues of interest and the venues identified in the foreign local.
  • the system 100 may link all nodes between the locales regardless of the congruency factor or may link only those nodes having a strong congruency factor therebetween. Accordingly, the system 100 or user may assign a predetermined threshold congruency factor for magnifying nodal interconnectivity between various locales.
  • Figure 27 represents nodal interconnection magnification between Boston and New York based on the plurality of congruency factors determined with respect to Restaurant 6 and Restaurant 10 of Boston, and Restaurants A-E of New York.
  • Figure 27 only illustrates nodal inter-locale augmentation for nodes having a congruency score of at least 0.60 or better.
  • a nodal link 2700 is formed between Restaurant 6 of Boston and Restaurant C of New York as the congruency factor therebetween as determined by interconnectivity augmentation processing is 0.85.
  • nodal links 2702 and 2704 are formed between Restaurant 10 of Boston and
  • nodal link 2504 based on a congruency factor of 0.75 is thicker than nodal link 2502 having a congruency factor of 0.65.
  • nodal link 2500 based on a congruency factor of 0.85 is thicker than both nodal link 2502 and nodal link 2504.
  • Restaurants E, V, W, X, Y and Z are Restaurants in New York that have strong overall link strengths to Restaurants C, D and A as illustrated based on content-based interrelationships, collaborative interrelationships, content- collaborative interrelationships and tiered relationships as described previously herein.
  • the recommendation engine 112 can traverse the links in the updated neural network topology to provide recommendations to the user for venues in New York. For example, as illustrated in Figure 27, for a user expressing an affinity for Restaurant 6, the user will be served with a recommendation for Restaurant C in New York. Similarly, for a user expressing an affinity for Restaurant 10, the user will be served with Restaurant D and Restaurant A with an indication the Restaurant D was the closest venue based on the user's search query. Further, interconnections within the neural network of New York can further be used to provide larger recommendation sets. For example, for a user expressing an affinity for Restaurant 6 in a search query, Restaurant E may be recommended next as having a strong overall link strength to Restaurant C with Restaurant V and W being recommended next as alternative venues based on their overall link strength with respect to Restaurant C.
  • the system 100 will take this into account when creating the network topology by harvesting data on the local and foreign venues and identifying which data corresponds to the data within the filter.
  • the recommendation engine 1 12 may recommend Restaurant E over Restaurant C as the recommendation engine 1 12 is able to traverse the nodal link 2700 to determine the Restaurant C is a good match but further determines based on venues having strong overall link strengths with respect to Restaurant C that Restaurant E is a better choice because it has a medium price point as compared to Restaurant C's low price point. Therefore, venue attributes and user characteristic attributes can also be taking into account by the system 100 when performing interconnectivity augmentation to determine recommendations in locations where the system 100 does not have a lot of information about what the user likes in that particular location.
  • the system 100 may also contain large amounts of information with respect to user interests in locales other than the one in which the user is located that can also be used to perform interconnectivity augmentation based on congruency factors via a determination of nodal doppelgangers.
  • the system 100 may also perform interconnectivity augmentation in the above-noted manner by using recommendations known to be effective in other areas with respect to the user, such as Washington D.C, to further enhance the variety of recommendations provided to the user.
  • congruency factors determined between different locales can be weighted differently based on user time spent in the locales, the number of effective recommendations or the like and then compared to determine a more accurate recommendation set for the user.
  • the system 100 may encounter difficulties performing interconnectivity augmentation between Boston and New York if venue information from New York is not readily available. In such a situation, if the system 100 already contains strong links to another city, such as strong links between Boston and Washington, D.C, and strong links from Washington D.C. to New York, the system 100 may determine recommendations by navigating the nodal network topology from Boston to New York via nodal links provided in Washington D.C.
  • the links may be uni-directional or bi-directional as previously described herein, the nodal links determined via interconnectivity augmentation as illustrated in Figures 25 and 27 are bi-directional to further enhance information available to the system 100 in the event that similar future searches are performed by the same user or other users with similar interests either in Boston or New York.
  • the system may perform interconnectivity augmentation based on both review data between different locations and via a determination of nodal doppelgangers in different locales. Accordingly, the system 100 may update the neural network topology of nodes between different locales based on review data and then may further update this network topology based on nodal link determinations identified via congruency factors.
  • interconnectivity augmentation therefore provides the system 100 with the ability to extrapolate information about foreign systems to generate an updated neural network topology having connections between a locale in which the system has ample information about what the user likes and a local in which the system 100 has very little information about what the user likes.
  • This provides enhanced functionality to the user in that the system 100 acts as a travel companion to provide venues of interest to a user when a user is traveling to various locations. This increases the likelihood that the user will enjoy his experience when traveling and will further enhance the network topology thereby increasing the accuracy of future recommendations to the user.
  • error correction and data verification can be performed to ensure and/or strengthen the accuracy of the recommended venues which may in turn be used to identify reviewers who have submitted review data with respect to the recommended venues and venues in other locations requested by the user.
  • the venues are operated by merchants, or third party vendors, which may comprise merchants such as restaurant owners, airlines, or hotel operators.
  • the system 100 may be configured to provide merchants a visualization of users' behavior. For instance, merchants may be provided access to ant trail data patterns, including in real time. Merchants can "interact" with these patterns and request the system 100 to inject disruptive content such as promotional offers related to a user's present location and expressed preferences.
  • Merchants may also be provided anonymized profiles of the likes and dislikes of their customers (i.e. users who patronize their establishment). This can include reviews provided by reviewers and users who provide feedback (who also constitute reviewers).
  • the system 100 provides an application programming interface (API) operated by the server 102 for allowing merchants to supply data to the system 100 which can be used by the recommendation engine 1 12 to determine recommendation or similarity data. The system 100 then sends this data back to the merchant.
  • API application programming interface
  • Figure 28 illustrates an exemplary interaction between the system 100 and a plurality of merchants/third party vendors 2800, 2802 and 2804 via an API 2801.
  • Figure 28 includes the server-based recommendation generation system 100 hosted on the server 102 as illustrated in Figure 1 and therefore like designations are repeated.
  • the merchant interface 1 16 is illustrated as including the above-noted API 2801.
  • the server 102 is connected to a plurality of merchants 2800, 2802 and 2804 via the network 120. Each merchant can provide the server 102 with a plurality of requests which are received by the API 2801 via the network 120.
  • the requests can include information such as identification information of the merchant, the type of request, the type of information included in the request, the data which the system 100 will process, a request for a quote for processing the request, and temporal information with respect to the request itself.
  • the recommendation engine 112 processes the requests and generates results which are output to the merchants via the API 2801 and network 120.
  • the API 2801 includes a set of programming instructions and standards for accessing the system 100 such that merchants can appropriately format their requests in a manner understood by the system 100 and so the API 2801 can provide responses to the merchants in a manner manageable by their systems.
  • the API 2801 provides programming such that the server 102 and remote applications operated by the merchants 2800, 2802 and 2804 can communicate with each other through a series of calls.
  • web services having a collection of technological standards and protocols, such as extensible markup language (XML) may be provided thereby allowing various parties from different systems to communicate.
  • XML extensible markup language
  • the APT 2801 may be included as part of a software development kit (SDK) along with programming tools thereby providing the merchants 2800, 2802 and 2804 with instructions on how to best interact with the system 100.
  • SDK software development kit
  • Additional technological standards, protocols and programming languages may be included such as simple object access protocol (SOAP) for encoding XML messages so that they can be understood by operating systems over any type of network protocol, and universal description, discovery and integration (UDDI) for allowing the merchants 2800, 2802 and 2804 to list themselves.
  • SOAP simple object access protocol
  • UDDI universal description, discovery and integration
  • Mashups may also be implemented within the system 100 thereby providing functionality from the API 2801 of the system 100 in conjunction with other web applications.
  • Figure 28 illustrates three merchants 2800, 2802 and 2804 providing different requests to the server 102 but one of ordinary skill in the art would clearly recognize that more than three merchants can connect to the server 102.
  • the merchant 2800 has identified a cluster of items of which a customer of the merchant 2800 has expressed a preference as determined by purchase data, shopping habits, and other methods as would be understood by one of ordinary skill in the art.
  • the customer of the merchant 2800 has purchased three bottles of wine (or has three bottles of wine in their shopping cart) and is looking for one more bottle of wine.
  • the merchant 2800 may want to provide the customer with a recommendation of additional wines for purchase and therefore interacts with the server 102 via the request 2806 and API 2801.
  • the request 2806 defined by the API 2801 infrastructure includes a request for the recommendation engine 112 to determine one or more
  • the request 2806 may include identification information of the merchant 2800, information specifying the type of request such as a request for recommendation data, a categorical description of the data, and the data of which the system 100 will determine recommendations.
  • the request 2806 may include the name and address (virtual and real-world) of merchant 2800, a request for recommendations based on the data set provided by the merchant 2800, information specifying that the data set relates to beverages or more specifically alcoholic beverages such as wines, and the list of wines for which the merchant 2800 would like the system 100 to process.
  • This request 2806 may be served to the system 100 at the time of a purchase by the customer or at a later time when the merchant 2800 is attempting to determine advertisement information based on previous customer activity.
  • the system 100 determines the type of request and the type of information included in the request. For example, the system 100 parses the system call from the merchant 2800 to determine that the recommendation engine 1 12 must generate
  • the system 100 may generate an error message to the merchant 2800 or may attempt to determine the type of information.
  • the recommendation engine 1 12 may attempt to determine whether the items within the request 2806 relate to cars, food, video games, or as in this instance, wine based on keywords identified in the request 2806 itself.
  • the recommendation engine 1 12 identifies whether the data repository 128 includes the appropriate neural network topology generated by the matrix builder 126 in which to process the request 2806. Specifically, in selected embodiments the system 100 may generate network topologies in all types of fields and for all types of products in addition to the venues discussed above. Therefore, the data repository 1 18 may already contain a neural network topology for the cluster of items relating to wine contained in the request 2806.
  • system 100 may dynamically generate a new network topology or update a previously existing network topology as previously described herein (via harvesting, creating nodal links, error correction and data verification, interconnectivity augmentation, etc) based on the type of items identified in the request 2806.
  • the recommendation engine 112 generates a
  • the recommendation engine 1 12 generates recommendations based on the methodologies described previously herein such as identifying overall link strength rankings, performing error correction and data verification with respect to source sites, performing geometric contextualization with respect to the generated recommendation set and performing resonance checking of each recommendation in the recommendation set.
  • the server 102 provides the recommendation set including a plurality of recommended wines to the merchant 2800 in a response 2808 via the merchant interface 1 16, API 2801 and network 120.
  • Figure 28 illustrates another example of a request 2810 from merchant 2802 including at least the merchant 2802 identification information, a request that the system 100 provide information as to what items may be similar to the items provided in the request 2810, an identification of the items as beverages and the list of one or more wines.
  • the recommendation engine 1 12 identifies the type or genre of information included in the request 2810 and determines whether the appropriate neural network topology exists for similar items. Specifically, the recommendation engine 1 12 determines a plurality of items that may be similar to the items included in the request 2810 and determines whether an adequate neural network exists for each item.
  • the system 100 may determine similarity to an item in a variety of ways. For example, in selected embodiments, the system 100 determines that bottles of wine fall into a drink category and therefore that only drinks should be contemplated by the system 100 when attempting to determine similarities. This can be accomplished by performing keyword searches with respect to the items included in the requests and/or by referring to a previously defined database updated based on user and vendor requests. Next, additional subcategories are determined until the system 100 identifies a plurality of categories deemed to be most similar to the items included in the request. For example, the system 100 may further identify the wine is a type of alcohol and therefore the system 100 should only search for other alcohols such as beers and liquors.
  • the system 100 can generate a similarity score of various beverages based on nodal link strengths between beverages having similar attributes within the neural network.
  • the merchant 2802 may also provide in the request 2810 similar categories to search based on the items provided by the merchant 2802.
  • the recommendation engine 1 12 generates a recommendation set as previously described herein and provides the recommendation set to the merchant 2802 in a response 2812. Specifically, overall link strengths are calculated by the recommendation engine 1 12 via collaborative-interrelationships data based on reviewer data between wines identified in the request 2810 and items deemed to be similar (such as liquors and beers), content-based interrelationships based on similar attribute data with respect to users who both drink the wines identified in the request 2810 and liquors and beers and wine attribute data such as the type of wine, the alcohol content, the location in which the wine is created, and content- collaborative interrelationships. Further, interconnect!
  • the requests coming from the merchants may also include filters with respect to the items included in the requests.
  • Merchant 2800 may request that the system 100 only return recommendations for wines that were made in or before a certain year.
  • Merchant 2802 may request that recommendations for similar items be restricted to different types of beer rather than also including liquor as a subset.
  • the recommendation engine 112 is able to provide merchants not only with recommendations for the same item or similar items included in requests but is also able to fine tune recommendations specifically tailored towards merchant requirements.
  • requests may include user attribute information from the merchant thereby providing the system 100 with additional information from which to generate a recommendation.
  • the API 2801 further provides the functionality for merchants to communicate a complete index of their items as well as user information with respect to the items to the system 100 with a request that the system 100 create a neural network topology specifically tailored to the communicated index of items. Accordingly, the request can also include item attribute data and item review data.
  • the neural network topology generated by the system 100 can then be used by the recommendation engine 1 12 to provide enhanced
  • This neural network topology can be generated solely based on the merchant index of items or an existing system 100 neural network topology can be updated based on the information contained in the merchant index. Therefore, such a request may contain identification of the merchant, the type of data, the complete index of the merchant's products and a request that the system 100 build personalization maps such as a neural network topology based on the data provided by the merchant. The request may also include user attribute information with respect to these products.
  • request 2814 from merchant 2804 is a request providing the name and address of merchant 2804, an identification of the data as relating to wine, all of the wines sold or made by the merchant 2804 as well as user information with respect to each bottle relating to purchases statistics, likes or dislikes and other affinity data, and a request that the system 100 generate a neural network topology based on this information.
  • the matrix builder 126 generates a neural network having internodal connections between all of the wines identified from the merchant-provided index and the user data provided in the request 2814.
  • the system 100 may further augment the neural network using other information harvested by the system 100 as described previously herein. Accordingly, the request 2810 may also include information identifying whether or not the merchant 2810 wants the system 100 to use information additional to the information provided in the request 2810.
  • the merchant 2804 can then submit further requests to the server 102 via the network 120 and merchant interface 1 16 as previously described herein in order to obtain recommendations or similar items generated by the recommendation engine 112. Further, the merchant 2804 may further request that the server 102 communicate the neural network topology information to the merchant 2804 in response 2816 so that the merchant can use such information internally.
  • the API 2801 may capture this information such that the system 100 may update the neural network topology for further use with the merchant as well as with other users of the system 100. For example, when merchant 2800 sends the request 2806 including the three bottles of wine, the system 100 may determine that the user picked these three wines and that pairing information can be obtained with respect to the user and the wines themselves. Accordingly, this information can be used by the matrix builder 126 to create or update nodal links with respect to data items of this type. Further, the API 2801 can capture user information in the requests thereby mapping user attribute information with specific pairings of items. The system 100 may also capture via the API 2801 the effectiveness of the recommendations provided to the merchants in the system 100 responses. For example, the system 100 may send system call requests via the API 2801 to merchants requesting that the merchants return user
  • the system 100 is able to provide specific merchants with personalization services thereby helping merchants retain customers and increase revenue.
  • Merchants can request recommendation data from the server 102 as well as specific personalization maps with respect to information provided by the merchants relating to the entire catalog of merchant products.
  • the system 100 simultaneously harvests merchant information to increase the accuracy of nodal connections in existing neural network topologies in areas relating to merchant product catalogs. Therefore, the merchants are provided with beneficial personalization services while also further enhancing those services for other users and merchants alike through their interaction with the system 100. Shared Recommendations for Harmonized Group Decision-Making
  • a user's affinity for a particular entity or property may be determined when generating a user personality matrix.
  • Mathematical computations for determining a user's affinity for a particular entity or property may include data mining functions for analyzing previous indications of an affinity for the entity or property.
  • a positive or negative affinity for an entity or property may include an analysis of purchase history, user reviews, interrelationships with users and/or venues, similarities between properties, survey results, and other factors described herein.
  • aspects of the present disclosure may include creating and utilizing a unified taste profile (i.e., a combined personality matrix derived from aggregated user personality matrices) when determining recommendation candidates for a group of users.
  • the recommendation candidates may, e.g., indicate an optimal decision
  • a harmonized group decision-making process may include providing shared recommendation results based on a unified taste profile of multiple users, where the shared recommendations ideally collectively suit the unified taste profile of the group seeking the shared recommendation.
  • a user personality matrix representing an individual user's taste profile may be determined for each user in a group decision-making dynamic, wherein each group member's user personality matrix can be mathematically "merged" to form a unified taste profile corresponding to the group rather than the individual. Accordingly, recommendations based, for example, on interrelational nodal strength characteristics between candidate venues and the unified taste profile may be determined by methods set forth herein.
  • Figure 29 illustrates an exemplary algorithmic flowchart for calculating a user personality matrix.
  • the user personality matrix may represent a user's taste profile and/or a user's affinity for a set of venue properties.
  • venue is used to refer to neural network nodes. It should be understood that the term “venue” is used herein to broadly refer to any entity or item (e.g., a restaurant, location, activity, content, users, reviewers, etc.) that is interrelated in the network with other network nodes.
  • Venue properties included in the user personality matrix may be derived from a user's connection graph, which includes all venues for which a user has previously expressed an affinity.
  • the user personality matrix may be calculated in real-time or saved and modified over time as affinities change and/or new venues are discovered and added to the user's connection graph.
  • the system 100 initially sets all values in the user personality matrix to 0 at step S2900.
  • the system 100 compiles candidate venue properties and property attributes.
  • Candidate venues may be broadly defined as any entity that may be returned as a shared recommendation result.
  • Step S2902 may include acquiring a user's connection graph, extracting candidate venues from the user's connection graph, and dissecting the extracted candidate venues for their properties and property attributes. Exemplary venue properties and property attribute values are shown in the example of Figure 4. Referring now to Figure 4, column 1 in the figure represents twelve restaurant candidate venues that may be extracted from a user's connection graph.
  • the second horizontal column listing categorical descriptors represents a set of venue properties that may be extracted for the 12 restaurant candidates.
  • the remaining portion of Figure 4 represents attributes and corresponding attribute values, which may be represented as labels, codes, numerical values, or other identifiers.
  • the system at step S2904 adjusts the derived property attribute values based, for example, on nodal link strength with respect to the user.
  • nodal link strength with respect to the user may be determined, for example, by analyzing user reviews, frequency of visits, geospatial information, purchase history, second and higher order links with other users, second and higher order links with other attributes, or the like.
  • the processing at step S2904 may result in property attribute values being calculated such that user preferences for a particular attribute and/or and overall affinity for a given property may be discerned.
  • the system 100 determines if more candidate values exist in a user's connection graph and if so, acquires the next candidate venue from the connection graph at step S2908. Otherwise, the system 100 at step S2910 normalizes the attribute values within each property in the user personality matrix based, for example, on a maximum property attribute value for a given property.
  • the processing at step S2910 may result in a numeric representation of a user's relative affinity for a property attribute with respect to all other attributes for that property. For example, the system 100 may determine that a particular user likes Chinese cuisine with an affinity of 0.95 with respect to all other cuisine types (e.g., American, Italian, Mexican, etc.).
  • step S2912 the system 100 may assign property weights based on a user's expressed affinity for a particular property with respect to all other properties in the user personality matrix.
  • step S2910 provides a mathematical representation of user affinity for a particular property attribute with respect to other attributes in the particular property
  • step S2912 may provide a numerical representation indicating, for example, that an entire property field such as cuisine matters to a particular user by a value of 0.8 compared to all other properties (e.g., price, ambience, etc.). Consequently, the system 100 may assign a higher importance weight to the property field of cuisine than it would to other property fields.
  • the system 100 forms the user personality matrix based on the normalized property attribute values and the assigned property weights.
  • a user personality matrix corresponding to a given user is illustrated in Figure 30.
  • Figure 30 illustrates property fields corresponding to restaurants; however, those of ordinary skill should appreciate that the present disclosure may easily be adapted such that user personality matrices including other property fields corresponding to other venue types may easily be determined using the exemplary methods within the scope of the present disclosure.
  • the user personality matrix 3000 includes an area 3002 illustrating various properties of a venue that may be derived, for example, at step S2902 of Figure 29.
  • Area 3004 includes various attributes corresponding to the properties of the area 3002. The property attributes and their corresponding values may be derived, for example, at steps S2902 and S2904 of Figure 29.
  • the user personality matrix 3000 assumes that the attribute values have been normalized, for example, using methods described at least at step S2910 discussed for Figure 29.
  • the attributes and corresponding attribute values illustrated in the area 3004 represent a relative user affinity for attributes within a given property.
  • analysis such as nodal interrelational link strength may indicate that a user has a normalized affinity value of 0.8 for American cuisine relative to other cuisines (i.e., Chinese, Japanese, Italian, and Mexican).
  • Area 3006 includes a plurality of property weights calculated to correspond with the properties shown in the area 3002.
  • the property weights of the area 3006 may be calculated, for example, at step S2912 of Figure 29.
  • the property weights of the area 3006 indicate a relative importance of a property with respect to other properties.
  • acquired user data and corresponding analysis of nodal interrelational link strength may indicate that a user strongly prefers a particular venue property relative to others.
  • the user data and/or nodal interrelational link strength may indicate that a user is largely indifferent to a particular venue property with respect to other properties for the given venue type.
  • Property weight may be determined, for example, by analyzing the attribute values, such as those illustrated in the area 3004. In this case, high variability in attribute value magnitude may indicate a strong preference for a particular property relative to other properties. Conversely, low variability within attribute values may indicate that a user does not place a high importance on that particular property.
  • a user may consistently express an affinity for casual restaurants and rarely express a desire to choose formal or business attire when selecting a restaurant, as indicated by the attribute values corresponding to the attire property shown in the area 3004. Consequently, the system 100 may calculate a high property weight value corresponding to the high importance that the user places on the attire property when selecting a restaurant venue. Similarly, the same user may select venues having a high price attribute at approximately the same frequency at which he or she selects venues having medium and low price attributes. Consequently, the system 100 may calculate a low property weight of 0.2 indicating that the user places a low importance on price when selecting restaurant venues.
  • user personality matrix illustrated in Figure 30 corresponds to a venue type of restaurants
  • user personality matrices corresponding to a plurality of venue types may be calculated such that a single user taste profile is maintained for a variety of different venue types (e.g., favorite movies, favorite restaurants, favorite schools, favorite neighborhoods, etc.).
  • user personality matrices may be calculated such that they are venue type specific, such as the user personality matrix 3000, which corresponds to restaurant venue types.
  • user personality matrices may be stored and adapted over time rather than calculating new user personality matrices for each new shared recommendation query.
  • Figure 31 illustrates a non-limiting example of an algorithmic flowchart for computing a combined personality matrix.
  • a combined personality matrix may represent a unified taste profile for an ensemble of users seeking a shared recommendation.
  • the system 100 at step S3100 acquires user personality matrices N and N+l .
  • the system 100 may set one of the acquired user personality matrices as a "base" matrix to which other user personality matrices can be merged to form the combined user personality matrix.
  • the system 100 compares the acquired user personality matrices and finds matching attributes within matching properties of a given venue. For example, the system 100 may compare two user personality matrices and determine that both matrices include a cuisine property and matching attributes corresponding to Chinese cuisine.
  • the system 100 sums matching attribute values. For example, in a case in which the above-noted users each expressed an affinity for Chinese cuisine based on their matching attributes in their respective user personality matrices, the system 100 may sum their attribute values (e.g., user 1 has an affinity of 0.5 and user 2 has an affinity of 0.7 for Chinese cuisine, resulting in a combined user affinity score of 1.2) to calculate a combined attribute value with which to include in the combined personality matrix.
  • attribute values e.g., user 1 has an affinity of 0.5 and user 2 has an affinity of 0.7 for Chinese cuisine, resulting in a combined user affinity score of 1.2
  • the system 100 compares the user personality matrix N and the user personality matrix N+l to identify non-matching attributes, and appends non-matching attribute values to the base matrix.
  • the user personality matrix N may include an "Ethiopian" attribute in its cuisine type property.
  • the system 100 may determine that the user personality matrix N+l does not include the Ethiopian attribute in its cuisine type property. Consequently, the system 100 may append the attribute value corresponding to the Ethiopian attribute in the user personality matrix N to the base profile at step S3106.
  • step S3108 the system 100 determines if more user personality matrices are available to merge into the combined personality matrix. If more user personality matrices are available, the system 100 at step S31 10 acquires the next user profile (i.e., user profile matrix N+2 in this example) and performs the above-described matrix merging process in an iterative fashion until all user personality matrices for the entire group have been merged.
  • the system 100 at step S31 10 acquires the next user profile (i.e., user profile matrix N+2 in this example) and performs the above-described matrix merging process in an iterative fashion until all user personality matrices for the entire group have been merged.
  • the system 100 at step S31 12 divides the values in the combined personality matrix by the number of users present in the group requesting a shared recommendation. This step results in a set of attribute values representing a unified taste profile for the entire group.
  • the number of users (N) may equal the number of users included (i.e., contributing a user personality matrix) in the shared recommendation processing. In other aspects of the present disclosure, the number of users N may be adjusted such that it does not equal the actual number of users included in the group requesting a shared recommendation. For example, a user's personality matrix may be included when forming the combined
  • the number of users may be adjusted to alter the relative weight of the user personality matrices.
  • connection graph may represent all venues, such as restaurants, for which a user has previously expressed an affinity.
  • processing at step S3114 results in a connection graph corresponding to all venues to which all members in the group requesting shared recommendations have previously expressed an affinity, which can subsequently be used to provide candidate venues from which the recommendation engine can provide a shared recommendation.
  • the recommendation engine may also determine additional candidate venues from which to provide a shared recommendation based, for example, on interrelational nodal link strengths between a venue in the merged connection graph and another "unknown" venue, information of which may be acquired by methods set forth previously (e.g., web crawling, etc.).
  • the system 100 may utilize the aforementioned processes for determining interrelational nodal strength to analyze acquired user personality matrices (e.g., downloaded from a server).
  • Link strengths between the users initiating the requests and users corresponding to the acquired user personality matrices may be analyzed such that shared recommendations can be made as to which partners may wish to also go rock-climbing, as well as the users that the initiators making the request may share common personality traits.
  • Shared recommendation outputs corresponding to suggestions for an activity as well as suggestions for partners to perform an activity with may be presented individually or as a package.
  • the system 100 may perform the aforementioned shared recommendation processes such that a package of multiple activities and multiple partners is presented to a user seeking to participate in an activity in a group setting.
  • aspects of the present disclosure may determine how different user personality matrices match one another.
  • the system 100 may calculate that aspects of two users' personality taste profiles corresponding to their respective user personality matrices correspond (as represented by, e.g., a percentage match). The calculation may be based on, for example, shared nodes that the two users like or dislike, similarities and features of nodes that they like or dislike, and/or nodes that the two users like or dislike that are connected through other common nodes. Aspects of visually representing the degree to which user personalities (or venue features) match are described later at least in the description relating to Figure 39.
  • the user may express certain affinities, for example, when taking trips to certain areas of the country during certain times of year, in which case the user may wish to develop a user personality matrix representing the affinities felt during those time periods, which may represent a particular mood that the user was in at that time. Similar steps may be taken for a plurality of different occasions representing different moods of the user, in which case the plurality of user personality matrices corresponding to the user's different moods may be accumulated (and stored for later use) and blended into a composite user personality matrix representing aspects of the user's various moods.
  • the merged user personality matrices representing different moods of the same person may be weighted towards a particular mood if the user wishes to perform shared recommendation decision-making processes weighted towards the affinities associated with that mood.
  • Figures 32A and 32B provide an illustrative example of merging two individual personality matrices 3200 and 3202 to form a combined personality matrix 3204.
  • the individual personality matrices 3200 and 3202 include a plurality of properties and attributes with corresponding values, similar to those described above with respect to Figure 30.
  • the respective individual personality matrices include attribute values corresponding to each respective user's personal affinity toward those attributes. Since the users may have different affinities for the different attributes, the individual personality matrices 3200 and 3202 reflect varied values for the matching attributes across both matrices.
  • the individual personality matrix 3202 includes attributes "U Street" and "trendy" in the neighborhood and ambience properties, respectively. These property attributes represent non-matching attributes determined, for example, at step 3106 of the algorithmic process shown in Figure 31.
  • matching attribute values in the user personality matrices 3200 and 3202 may be summed to calculate a combined attribute value representing the overall affinity for both combined users for the particular attribute.
  • the summed attribute values corresponding to matching attributes across the matrices may then be normalized to arrive at a combined attribute value to include the combined personality matrix.
  • combined personality matrix 3204 shown in Figure 32B illustrates that because all attribute fields in matrices 3200 and 3202's cuisine property match, the attribute values of user personality matrices 3200 and 3202 in the cuisine property field may be summed and then divided by 2 to arrive at the attribute values shown in the combined personality matrix 3204 cuisine property field.
  • property weights illustrated in Figure 32A for matrices 3200 and 3202 may be summed and divided by the number of users to arrive at a combined property weight value with which to include in the combined personality matrix 3204.
  • the system 100 may append the unmatched attribute field values (i.e., the trendy attribute value of 0.3 and the U Street attribute value of 0.4) when forming the combined personality matrix 3204.
  • the process of appending non-matching attribute field values is illustrated in the fact that the attribute values for the trendy and U Street attribute value fields are the same in the individual personality matrix 3202 and in the calculated combined personality matrix 3204.
  • a set of shared recommendations for venues may be determined for an ensemble of users represented by the combined personality matrix. For example, candidate venues included in a merged connection graph and/or connected to restaurants included in the merged connection graph (e.g., based on
  • interrelational nodal strength may be quantitatively analyzed to determine a degree to which the set of candidate venues corresponds to the unified personality profile represented by the combined personality matrix.
  • each of the candidate venues in the connection graph may be analyzed to determine their respective properties and/or attributes, at which point a value indicating a degree to which the candidates correspond to the combined personality matrix may be calculated and a set of recommendations can be presented to the group of users (e.g., via an interface).
  • Figure 33 illustrates a non-limiting example of an algorithmic flowchart for generating a shared recommendation for a group of users based on a combined personality matrix. It should be appreciated that any and all aspects of descriptions in foregoing sections related to generating
  • the system 100 at step S3300 acquires a set of candidate venues with which to provide a shared recommendation.
  • the candidate venues may be acquired using a merged connection graph.
  • the candidate venues may be acquired by analyzing the merged connection graph to determine restaurants which are not included in the merged connection graph, but have a connection to the venues in the connection graph (e.g., by way of a strong interrelational nodal strength).
  • the system 100 at step S3302 may analyze the candidate venues to determine their various properties and/or attributes. For example, a candidate venue corresponding to a restaurant may be analyzed by the system 100 to determine its properties relating to cuisine type, attire, ambience, etc. After determining the various properties of each of the candidate venues, the associated attributes and attribute values of each property are determined by the system 100.
  • the system 100 at step S3304 may then calculate a candidate venue score based on the combined personality matrix.
  • candidate venues may be scored in relation to the combined personality matrix based on the degree to which the candidate venue
  • the combined personality matrix forms a hypothetical unified individual to which shared recommendations may be made. Nodal link strength between each candidate venue property and/or venue attribute may be calculated for all candidate venue properties, and attributes and an
  • aggregated score for each candidate venue may be calculated by the system 100 at step S3306.
  • the system 100 may filter candidates based on predetermined filter criterion. For example, the system 100 may filter candidates based on the aggregated score calculated at step S3306 being below a predetermined threshold level. Additionally, filters may be set in a case in which the combined personality matrix and/or another received input indicates a strongly positive or negative affinity toward a candidate venue's property and/or attributes. For example, a group of users may request a shared recommendation that is limited to only a certain set of neighborhoods, cuisine types, and price ranges.
  • the system 100 may determine that a candidate venue should be excluded from any shared recommendation due to, e.g., a user represented in the combined personality matrix having a medical condition and/or a religious belief that would automatically exclude such a venue from any actual decision made by the group.
  • candidate venues may be immediately filtered as an input to the recommendation engine to improve processing efficiency. For example, a candidate venue may be precluded from merging to a connection graph in response to receiving an input indicating a particular candidate venue and/or a particular venue type should be excluded from shared recommendations. Further aspects of filtering are described in later sections (at least at Figure 34 and the related discussion thereto).
  • the system 100 at step S3310 prioritizes the unfiltered candidates based on their aggregated score. For example, the system 100 may rank candidate venues from high to low aggregated score. In other aspects of the present disclosure, the system may segregate prioritized candidate values. For example, the venues may be ranked with respect to a given property (e.g., highest scored restaurants in a neighborhood). A candidate list of venues may be generated prior to or after filtering and/or prioritizing the venues, and the candidate list may be received as an input to the recommendation engine 1 12 for generating shared recommendations of venues.
  • a given property e.g., highest scored restaurants in a neighborhood
  • the system 100 at step S3312 may then provide a shared recommendation output.
  • the system 100 outputs a single candidate venue as a shared recommendation that best resonates with the group of users participating in a shared recommendation processing.
  • the system 100 may output a subset of candidate venues that have aggregated scores above a predetermined threshold.
  • subsets of the candidate venues output as shared recommendations may be selected by the users participating in the shared recommendation processing using a voting system.
  • system 100 may utilize user data and/or predetermined inputs indicating that a particular user should have a higher weight when making shared recommendations (further exemplary aspects of weighting shared decision making according to user weights is discussed at least in the discussion relating to Figure 35).
  • the recommendation processing described herein with respect to various link strengths can be used in selected embodiments to provide recommendations to the user based on the final filtered and/or prioritized set or the final set of venues each having an overall score.
  • the processing described herein with respect to determining a set of candidate venues, scoring them based on a combined personality matrix, and identifying a final prioritized and filtered set and overall scores provides the recommendation engine 1 12 with a smaller sample set of venues from which it will make recommendations based on link strength.
  • recommendations are made based on link strengths rather than overall score with respect to weighting values.
  • the recommendation engine 112 will only provide recommendations based on overall link strengths with respect to the venues identified and ranked in the final filter set.
  • the final prioritized and filtered set and/or overall scores of each venue in the final set may therefore, in selected embodiments, be used to identify the final set of venues to which the
  • recommendation engine 1 12 will use to provide recommendations based on overall link strength as previously described herein. Further, based on the final filter set, the
  • recommendation engine 1 12 may provide recommendations out of this set relating to venues of which have the strongest link strength to user attributes.
  • Figure 34 illustrates a non-limiting example of an algorithmic flowchart for filtering candidate venues, such as in the processing related to step S3308 of Figure 33.
  • the system 100 at step S3400 acquires filter conditions with which to use in shared recommendation processing.
  • the filter conditions used in shared recommendation processing are defined by the users participating in such processing.
  • a group of users participating in shared recommendations may define a set of criteria with which to focus the search when providing shared recommendations. That is, the users may define a focus area or search to limited venue properties and/or attributes, such as only searching low cost venues, only searching certain cuisine types, or only searching for venues in certain locations.
  • venue candidates may be explicitly identified for exclusion by the users.
  • a venue which may or may not be included in the merged connection graph may be identified by a user or users such that the identified venue candidate is excluded from being provided as a shared recommendation.
  • user data indicative of previous actions of one or more of the users may be acquired and utilized to generate filter conditions for shared recommendation processing.
  • user data acquired using methods set forth above may indicate that a user in a group has seen a particular movie, in which case that movie may be excluded from being provided as a shared recommendation because the user who has seen the movie is unlikely to want to see the movie again.
  • a shared recommendation interface may provide a filter condition section with which users may select filter conditions when performing shared recommendation searches. For example, a user may indicate a particular allergy to a certain food, in which case properties and/or attributes that are associated with the food allergy would be identified and any venue candidates corresponding to those identified properties and/or attributes would be excluded from shared recommendation processing.
  • the system 100 compares the acquired filter conditions with the set of candidate venues and determines whether attributes and/or properties corresponding to the candidate venues match one or more of the filter conditions.
  • the system 100 at step S3404 adjusts the aggregated score corresponding to the matched candidate venue.
  • the system 100 may add a high magnitude negative value to the aggregated score. Magnitudes of values that may be added to the score should be selected so as to ensure exclusion based on the nature of the calculation/processing.
  • Similar processes can occur at the user personality matrix such that the combined personality matrix is heavily weighted by the user's expressed negative affinity for a particular venue property and/or attribute.
  • the system 100 may identify that the user routinely responds negatively to a particular property and/or attribute based on user data acquired as set forth above. Such analysis may trigger a "negative blocker" that is set in the user personality matrix such that the property and/or attribute to which the user has an expressed negative affinity is excluded from shared recommendation processing.
  • a "flag" may be set in either the user personality matrix or the combined personality matrix (or in another memory area of the system 100) to indicate that a candidate venue should be excluded from shared recommendation processing.
  • the system 100 may set a bit indicating that a particular candidate venue property should be excluded.
  • the system 100 may preclude all filtered candidate venues from being output as a shared recommendation, for example, in a user interface. Such processing in essence results in candidate venues being filtered in
  • candidate venues that do trigger filter conditions may be included in prioritized shared recommendation outputs, but identified as a venue that should likely be excluded as a potential candidate in the decision making process. This allows users participating in shared recommendation processing to make an informed decision as to whether or not the venue should be excluded as a possible decision. For example, in the case in which a user's acquired user data indicates recently viewing a particular movie, users participating in shared recommendation processing in order to determine a movie that all the users in the group would enjoy may receive a prioritized recommendation output that includes the movie recently seen by the user.
  • the movie may be identified (e.g., highlighted or otherwise demarked in a user interface) such that it is easily discernible that the venue (i.e., the movie) should likely be excluded from the decision making process.
  • the venue i.e., the movie
  • the group of users may also appreciate the previously viewed movie being included in possible shared
  • recommendation processing is illustrated in the exemplary algorithmic flowchart of Figure 35. It is noted that the exemplary process illustrated in Figure 35 can be performed before or after merging user personality matrices to form a combined personality matrices. For example, aspects of Figure 35 may be incorporated into step S3310 of Figure 33 and/or into the exemplary process shown in Figure 31.
  • the system 100 at step S3500 acquires the user personality matrices corresponding to all users participating in the shared recommendation decision making process.
  • the system 100 determines user weights
  • the user weights used in shared recommendation processing may be determined as received inputs, for example, from a user interface.
  • the user interface may include features allowing members of the group to indicate a particular occasion corresponding with the group decision.
  • the indicated occasion may, for example, correspond to a user in a group's birthday, in which case the user may be provided with a higher influence user weight (i.e., 3x normal) than would otherwise be afforded that particular user.
  • the user interface may allow for excluding one or more users of the group in the decision-making process, such as when a user may desire to withhold influence from a shared recommendation process so that the other members of the group can happier with the outcome.
  • the system 100 at step S3502 may obtain user data utilizing methods set forth above, in which case the user data may indicate certain features of the users within the group that can be used to calculate user weights. That is, different "strengths of influence" over the group decision can be afforded to particular users based on acquired user data.
  • the system 100 may analyze acquired user data to determine relative relationships within the group, such as family hierarchy, social rank, or other group dynamics such as an individual's propensity to be difficult or otherwise picky when making a decision.
  • the system at step S3504 may adjust values in the combined personality matrix based on the determined user weights. That is, the calculated combined personality matrix may be weighted to more closely resemble one or more user's user personality matrix. In certain aspects of the present disclosure, a weighting factor may be used to weight an individual's user personality matrix during the calculation of the combined personality matrix.
  • values in the user personality matrices may, for example, be multiplied by a weighting factor that is based on the determined user weights such that when the group members' individual user personality matrices are merged (e.g., as in Figure 31), the resultant combined personality matrix is weighted towards the users with the higher weighting factors (similar to calculating a weighted average).
  • negative weighting factors may be used to exclude a user personality matrix from the decision/shared recommendation process. In this case, the number of users assumed when forming/calculating the combined personality matrix may need to be adjusted, such as in the case of step S31 12 of the exemplary processing illustrated in Figure 31.
  • aggregated candidate venue scores may be adjusted based on user weight.
  • system 100 may adjust the aggregated score to weight nodal linkage strengths towards a particular user's user personality matrix.
  • a group of users may combine taste profiles corresponding to their respective user personality matrices, set specific filters within combined taste results based on their current preferences, and obtain a dynamic list of results calculated in real time that fits the taste profile of the entire group within specific categories.
  • Figure 36 provides a non-limiting example of a user interface for performing shared recommendation processing.
  • the exemplary user interface 3600 includes an area 3602, an area 3604, an area 3606, and an area 3608.
  • the area 3602 may be provided such that a user may, e.g., select other users that should be included in a shared recommendation process for a group decision.
  • User personality matrices from the selected users may be used when forming combined personality matrices.
  • the pool of users displayed in the area 3602 may, for example, be derived from a social network, in which case the system 100 may query the social network to determine a set of potential users that may form the inputs of the combined personality matrix.
  • the pool of users displayed in area 3602 may, for example, be derived from a user's contact list stored in a memory.
  • the areas 3604 and 3606 displayed in the user interface 3600 include various attributes that may be selected for a particular property.
  • the attributes correspond to different cuisine type properties (i.e., French, American, Japanese, and Italian cuisines).
  • a user is prompted to select a location property from four attributes, which in this example are neighborhoods in a predetermined location (i.e., Perm Quarter, Dupont Circle, Atlas District, and Chinatown).
  • the properties and/or attributes shown in the areas 3604 and 3606 may, for example, be derived as prioritized properties and/or attributes that a particular user has shown the strongest affinity for, based on derived user data.
  • a user may display the user interface 3600 on their personal mobile device, in which case the system 100 may analyze user data and/or the user's personality matrix in order to display attributes and/or properties that the user has shown the strongest affinity for in the past (in this case cuisine and location).
  • the area 3608 includes various filters that may be applied during shared
  • the exemplary filters shown in the area 3608 may be applied during shared recommendation processing such that candidate venues are filtered from the processing and therefore, would not be displayed as recommendations in response to any shared recommendation request from a user.
  • member 1, member 2, and member 4 may wish to obtain a shared recommendation for lunch.
  • the user may wish to limit the shared recommendation processing such that lunch recommendations are only provided for French and American restaurants in the Perm Quarter and Atlas District neighborhoods. Accordingly, the corresponding attributes of French, American, Perm Quarter, and Atlas District are selected in the areas 3604 and 3606, and the shared
  • the system 100 may carry out shared recommendation processing to form the respective user personality matrices for the plurality of members requesting the shared recommendation, merge the user personality matrices to form a combined personality matrix for the users, and determine candidate venues based on the combined personality matrix while excluding all candidate venues that do not fit the stated criteria selected in the user interface 3600.
  • Figure 37 provides another non-limiting example of a user interface 3700 that may be utilized when performing shared recommendation processing to improve decision making in a group dynamic.
  • the exemplary user interface 3700 includes an input area 3702, which provides a universal search bar to perform a targeted shared recommendation process.
  • the universal search bar of the input area 3702 queries the user with questions of what, where, and with whom a user would like to perform a certain activity. For example, a user may request a shared recommendation to make a decision amongst a first user 1 and a second user 2.
  • the users 1 and 2 may desire a recommendation for pizza and/or sushi restaurants in Capitol Hill.
  • the system 100 may, for example, perform the shared recommendation processing set forth in the above methods, and provide a list of recommendations in the area 3704.
  • the example of Figure 37 illustrates six restaurant recommendations, but it should be appreciated that the present disclosure may be adapted such that any number of restaurant recommendations may be made.
  • the system 100 may provide a single recommendation that best corresponds to the query limitations provided in the area 3702 and the combined personality profile of the user 1 and the user 2.
  • users may then select one or more restaurants that may interest the user (e.g., Restaurant 2 and Restaurant 3 have bolded frames), and in response to the selections the system 100 may, for example, display further information regarding the restaurant, such as menus, hours of operation, reservation availability, etc.
  • aspects of the present disclosure may also allow users to make reservations and invite other users once a decision has been made as to which restaurant will be selected.
  • Figure 38 provides a further non-limiting example of a user interface that may be utilized to perform aspects of the shared recommendation processing set forth by the above-described methods.
  • the figure shows an exemplary user interface 3800, which includes an area 3802 and an area 3804.
  • the members 1 through 4 may, for example, query the system 100 to provide restaurant recommendations with which to make a shared decision.
  • the system 100 may output prioritized recommendations based on processing set forth in methods described above.
  • the area 3804 shown in Figure 38 may be used to provide the highest ranked prioritized restaurants. In this example three restaurants are shown, however it should be appreciated that any number of restaurants may be output as potential recommendations with which to make a group decision.
  • the system 100 may be configured to receive an input from the user interface 3800 corresponding to "votes" for the various restaurants displayed in the area 3804. This feature may allow the members 1 through 4 to vote on the restaurants recommended by the shared recommendation processing described above. Votes for each of the restaurants displayed in the area 3804 may be tallied, and a restaurant decision may be made based on, for example, the restaurant receiving the highest number of votes. User voting may, in certain aspects of the present disclosure, be stored for future recommendations based on selection history.
  • Figure 39 provides another non-limiting example of a user interface that may be utilized for performing the shared recommendation processing set forth in the present disclosure.
  • the exemplary user interface of Figure 39 may provide a visual representation of shared affinities in a network of friends.
  • the exemplary user interface of Figure 39 may provide a visual representation of nodal connections between venues that may be utilized as candidates for performing shared recommendation processing.
  • the exemplary user interface 3900 shown in Figure 39 displays a plurality of nodes 3902 through 3914.
  • the nodes 3902 through 3914 may, in certain embodiments, represent users making a shared recommendation query to the system 100.
  • the nodes 3902 through 3914 may represent candidate venues, venue properties, and/or venue attributes, which may be used in the shared recommendation processing set forth by the present disclosure.
  • the user interface 3900 may represent nodal interrelationships as overlapping nodes, such as in the case of nodes 3902 and 3904. Second and higher order inter-relational relationships may be represented in the user interface 3900, such as in the case in which two nodes do not necessarily overlap with each other but share a common overlapping node (e.g., nodes 3902 and 3904 overlap, and nodes 3902 and 3908 overlap, which may represent a second order connection with nodes 3904 and 3908).
  • nodal size and/or color may be used to distinguish similarities between nodes. For example, stronger shared affinities between users as represented by the combined personality matrix may be represented using bolder colors, for instance. As another example, a stronger affinity may be represented by a larger node size in the user interface 3900.
  • aspects of the present disclosure may be adapted to, for example, select a balanced movie or TV show for a family movie night, search real estate for roommates or newlyweds based on their joint tastes, select a roommate for college students based on traits and tastes, creating travel packages for families or couples, selecting an activity for a group of people from a broad set of categories, selecting a college that will optimize a set of traits fitting with a student's abilities, selecting a specific business/political/military strategy by harmonizing computing interests, selecting areas to explore (e.g., mining, space exploration, etc.), and selecting a group that can work well together based on similar traits of thought patterns and/or decision making styles.
  • Venue data is generated based on information determined by the crawl and parsing module 1 14 as described previously herein.
  • Figure 40 shows an exemplary corresponding matrix of attributes detected by the crawl and parsing module 114 and stored in the data repository 1 18 by the matrix builder 126.
  • each restaurant is in Boston, Mass. and the price varies on a ten point scale.
  • Attire is assigned alphabetic codes (e.g., formal, casual, hipster), although numeric codes are used in certain embodiments. Zip codes are used as neighborhood values in this example.
  • Venue attributes also include genres such as Japanese, Italian, American, French, Western, Chinese, pastries, desserts, and the like.
  • the venue attribute information can also contain coordinate information with respect to the location of each venue.
  • this location data takes the form of latitude and longitude coordinates. This information can be obtained by comparing address information to databases containing corresponding coordinate values and retrieving that information via the crawl and parsing module 1 14. GPS and other types of location services could also be used to generated the appropriate geographic coordinate data. The coordinates can then be used to key certain venues to certain geographic grid areas as described further below with respect to spatial segmentation.
  • User data is generated, in part, based on the venue review data determined via the crawl and parsing module 1 14 as described herein.
  • the crawl and parsing module 114 may have obtained information identifying that the user gave high reviews to certain venues or particular attributes of venues. For example, user affinity data for various restaurants could be obtained based on a user having posted review data or having been geographically present in particular venues for a predetermined amount of time.
  • a user's affinity for particular venue attributes, such as genre, price, attire, hours and neighborhood, may also be determined via the crawl and parsing module 1 14.
  • User information is also generated upon creation of an account or in response to another triggering event such as a request for a new recommendation.
  • the system 100 may require a user to input various data including gender, age, marital status, children ages, children gender, third parties with whom the user is socially networked, hobbies, interests, favorite venue information (in one or more venue categories), and preferred or non-preferred reviewing entities (if any).
  • the user data may be input by each user and/or collected from web data sources in the manner set forth above.
  • the matrix builder 126 then stores the user data in the data repository 1 18 as illustrated in Figure 41.
  • Figure 41 is a chart showing a matrix of user attributes for seven users including personal attributes such as gender, age and the number of children.
  • Personal attributes can also include things such as profession, education, marital status, address and the like.
  • User attributes also include favorite venues and in selected embodiments, each user is asked for favorite venues. In other embodiments, a list of preferred venues in various different venue categories is included in the user profile.
  • the user attributes also include their affinities for certain venue attributes such as price, genre, hours, attire, and neighborhood.
  • Other user attributes can include affinity levels for speed of service, quality of service, accommodations and the like.
  • the matrix builder 126 creates user affinity weighting values based on the interrelationships between the user attribute data and venue attribute data. For example, the system 100 calculates a weight value for certain user attributes such as genre, hours, price and attire and neighborhood. As noted previously herein, this information is derived at least from information received from the user or by reviewing information obtained from the crawl and parse module 114 such as prior restaurants visited, review data from the user, or financial spending habits. Therefore, if the system 100 determines that the user has previously visited or indicated American restaurants as favorable, the system 100 may apply a higher weighting value to this attribute.
  • the user may have a preference for a particular dress attire when visiting restaurants and therefore this information may be given a higher weight.
  • negative weights can be assigned to user attributes deemed by this system 100 to be extremely unfavorable to the user such as a dislike of certain types of food, certain prices and the like.
  • general user weighting data can be derived by the system 100 based on the physical and personal attributes of the user such as age, gender, marital status and the number of kids of the user. For example, the system 100 may apply a higher weighting value to venues having a medium to high price range with a formal dress code for a middle aged married man whereas a younger user may receive higher weightings for lower priced restaurants with a more casual dress code.
  • the weighting values can be any numerical value such as a percentage or value on an overall scale. For example, in selected embodiments, the lowest weighting value is set to a value of zero whereas the highest weighting value is set to a value of one.
  • Figure 42 illustrates a corresponding matrix of weights for various users according to one example.
  • the system 100 has calculated a high weighting value of 0.8 for both Japanese and American restaurants as User 1 has either indicated his preference for these restaurants, he has visited these types of restaurants before or perhaps has provided positive reviews about such genres.
  • the system 100 assigns a high weight to the lower price points and gradually decreases the weighting value as the price goes up.
  • Figure 42 illustrates that the system 100 assigns a high weight value to venues open later than 8:00 PM thereby identifying that this time is usually preferable to the user.
  • the system 100 also calculates that a variety of dress codes are acceptable to the user but at varying weight levels thereby indicating that the user prefers a casual dress code but will accept a formal dress code based on other attributes involved.
  • the neighborhood information indicates that User 1 prefers 02163 which is perhaps a location close to work or home whereas User 1 dislikes neighborhood 02196 which is perhaps a neighborhood having high crime or no public transportation options. In selected embodiments, a negative weighting value could be assigned to neighborhood 02196 to represent a more severe level of dislike for this area.
  • the system 100 has determined that User 2 would only like to receive recommendations for Italian restaurants and prefers eating at times between 5:00 and 6:00 PM. While a lower price point of 3 is preferable to User 2, the user will also accept other price points. Accordingly, the attribute weight values indicate the likes and dislikes of a plurality of users. If the system 100 does not have information with respect to certain attributes, the recommendation engine 1 12 may either ignore recommendations having these attributes or may apply a predetermined
  • the recommendation engine 1 12 may assign a value of 0.0 to signify that the system 100 did not have any data with respect that attribute such that it is likely the user does not have an affinity for that attribute.
  • a nominal predetermined weighting value such as 0.2, may be assigned to indicate that the system 100 may not have enough information but should not fully penalize this attribute with respect to user taste.
  • various factors are involved in determining the user's affinity level for a particular attribute (i.e. review data, user input data, past history data) there may be different levels of weighting for attributes identified in the same category within Figure 41.
  • Figure 41 illustrates that User 1 has a preference for both American and Japanese but Figure 42 illustrates that the system 100 has determined that User 1 prefers Japanese slightly more than American. This could be because the system 100 has determined via the crawl and parsing module 1 14 that User 1 has visited Japanese restaurants more frequently than American ones and/or the user lives closer to Japanese restaurants than American restaurants.
  • FIG. 43 is a flow chart illustrating the process of spatial segmentation according to exemplary embodiments.
  • the server 102 receives geographic data from predetermined locations all around the world (or in space). This information can be manually input by a user or retrieved via the crawl and parsing module 1 14 from generally known and available sources. For example, information may be retrieved from an online database containing geographic coordinate data from all over the world. The system 100 then systematically retrieves this data for processing in order to segment the data into various grids.
  • the system 100 segments the geographic data into various grids have particular global coordinates.
  • the system 100 segments the entirety of the geographic data at one time or systematically divides the geographic data into smaller portions before performing spatial segmentation into specific grids. For example, assuming the system 100 has retrieved geographic data of the entire world, the system 100 may first divide this information into continents, divide the continent information into countries and then divide the country information into states or towns and so forth.
  • the extent of division of the geographic data is based on the degree of granularity at which the system 100 wants to create the grids based on particularities with respect to various locations. For example, the granularity level can be determined based on land area, population density, ethnicity, religion, and other cultural considerations.
  • the system 100 then parcels up the geographic locations into grids having specific longitude and latitude coordinate values.
  • the totality of a particular defined entity space is divided into discrete segments that are functionally independent based on their coordinate values.
  • Figure 44 illustrates an example of spatial segmentation into grids for the state of Massachusetts in the United States.
  • a plurality of grids such as grid 4400 and grid 4402 are formed by the server.
  • the system 100 may start at a particular location within the entity space and trace in a particular direction for a predetermined distance.
  • the grids are formed as squares throughout the entity space.
  • Grid 4400 may be formed by starting in the upper left hand corner of the state and determining lines 4408 and 4410 extending from the point at a ninety degree angle for a particular distance. Once these grid boundaries are determined, enclosure lines 4412 and 4414 can then be formed at right angles from lines 4408 and 4410, respectively, for a corresponding distance to form the grid.
  • the grids are not required to be square shapes and could take any other conventional shape.
  • the system 100 may divide a geographic location by casting parallel latitudinal and longitudinal lines as illustrated in Figure 44 and determining coordinate data for each grid formed based on such a division.
  • the grids may also be formed throughout particular entity spaces based on a partition amount such as a particular amount of coordinate values (i.e. degree areas) or based on distance measurements such as the amount of cross sectional miles or kilometers.
  • a segmentation size of a degree or less is preset for segmenting the grids.
  • the grids could also be formed and shaped based on various geographic particularities over an entity space such as population density, venue density, uninhabited land space, and transportation and transit demographics. Accordingly, not all grids need be the same size and the system may, alternatively or in addition to distance measurements, determine grid sizes based on population density, venue density and transportation and transit demographics. For example, grids in sparsely populated areas of the entity space may be larger than grids in densely populated areas. For instance, although not shown in Figure 44, the city of Boston itself may be separated into a multitude of grids based on the large amount of venues in and around the city.
  • grid data is also determined for neighboring states (not shown) such that points of interest may be identified if a user was close enough to a grid within a neighboring state.
  • the segmentation of geographic data is not limited to areas containing land mass.
  • grid areas such as grid 4404, can be formed over locations containing water. These grids are formed as described above and may contain interest data such as particular spots to fish, whaling locations, diving locations and the like. Accordingly, and as previously described herein, interest data is not limited to venues such as restaurants but can include other types of interest information. This data is processed in a similar fashion as described herein to efficiently provide the user with personalized information based on his geographic location. Alternatively, in other selected embodiments, the system 100 may ignore non-land masses such as oceans, lakes and the like to greatly reduce the amount of area that has to be spatially segmented thereby increasing the efficiency of the spatial segmentation process.
  • Step S4304 the system 100 processes each venue stored in the data repository 1 18 to determine which grid each venue is located within based on the venue location information such as coordinate values.
  • the system 100 has location information identifying the boundaries of each grid.
  • the system 100 then performs comparison matching by identifying the coordinates of each venue and matching that venue with a certain grid and grid key based on the corresponding coordinate values of that grid.
  • the system 100 stores in data repository 1 18 venue information, such as ID or name, in association with a key value identifying the particular grid within which the venue is located.
  • venue information such as ID or name
  • other information with respect to the venue can also be stored in association with the grid key value such as venue attribute data. This information as well as offset information is further described below and illustrated in Figure 45. It should also be noted that venues located on a grid "border" may be identified by the system as being in both grids and will therefore be associated with multiple keys.
  • a reference point is determined for each grid which was generated in Step S4302.
  • the reference point is a geographic location within the grid from which all other item of interest data will be generated (i.e. venue location information).
  • the system 100 may determine reference point 4416 based on reference point 4416s location at a corner of grid 4400.
  • the reference point may be determined based on the starting point at which the grid was formed or may be determined uniformly with respect to the location of reference points in other grids in the entity space. For example, every reference point may be identified as a point in the center of each grid.
  • the coordinate values of this location are identified by the system 100 and stored in data repository 1 18 in correspondence with the Key ID for that particular grid.
  • the system 100 may only store the reference point coordinate values themselves as the keys so that each grid is identified by the reference point coordinate values.
  • the system 100 identifies at Step S4306 all of the items of interest data within the grid and determines offset data for each item of interest. For example and as previously noted, each venue in the grid is associated with the particular key for that grid as well as an offset value based on the reference point previously determined for the grid. In selected embodiments, the offset value is based on a coordinate offset value from the reference point based on the location of the venue within the grid. For example, Figure 44 illustrates a venue 4420 located within grid 4402 having a reference point 4418.
  • the crawl and parse module 1 14 retrieves information identifying venue 4420 and the location of venue 4420, the location of venue 4420 is determined based on offset coordinate values from reference point 4418.
  • reference point 4418 is located at coordinates of (1.1001, 1.1001). Accordingly, if venue 4420 is located at coordinates (1.1005, 1.1005), then the offset value can be determined as (.004, .004) for venue 4420.
  • These coordinates values of venue 4420 are then stored in association with the key ID for grid 4422 and the reference coordinates 4418 of grid 4422.
  • Figure 45 is a chart illustrating keyed segmentation data for the city of Cambridge, MA.
  • the identification of three keys indicates that the system 100 spatially segmented the city of Cambridge into three grids rather than the segmentation being at the higher granularity of an overall "state" level. As described previously herein, this could be for a variety of different reasons but was most likely, in this instance, due to the volume of venues located within the city of Cambridge, MA. As such, the recommendation engine 1 12, when making
  • Figure 45 also illustrates the reference point coordinate data assigned to each key which has been determined and stored in the data repository as described with respect to Steps S4304, S4306 and S4308.
  • a grid assigned key 001 has a reference point coordinate value of (41.75, -71.25) and is associated with venue 003 and venue 005 (i.e. Restaurant 3 and Restaurant 5) illustrated in Figure 40.
  • Restaurant 3 and Restaurant 5 are associated with key 001 because they are geographically located within the grid assigned to key 001 as determined in step S4306. Further, based on the latitude and longitude
  • the offset coordinates for Restaurant 3 are determined by comparing these values to the reference coordinate values of (41.75, - 71.25) to obtain offset data coordinates of (.2230, .1298).
  • the reference point coordinate data for the grid assigned to key 001 Restaurant 3 is
  • the system 100 determines at S4310 whether there are more grids to be processed. If there are more remaining grids, the system 100 loops back to Step S4302 to perform the above-noted processing on any additional grids that have not yet been processed. Accordingly, once this is complete and before a user has even interacted with the system 100 via the user interface 1 10, the system 100 has spatially segmented all geographic data available to the system 100, identified venues or items of interest within each of the grids, and associated this venue information with a grid key and key offset data. At this point, the system 100 proceeds to perform data encoding of the various information to provide more efficiently stored and accessible data for processing by the system 100.
  • this information can be encapsulated in a string but any other data structure could be utilized to encapsulate the information.
  • the data encoding process is done in advance before a user has even interacted with the system 100 via the user interface 110 to request a personalized search.
  • the system 100 may generate all of this information at run time at the time of a request by the user or at predetermined intervals in order to provide up to date information while balancing with processing and storage considerations.
  • Figure 46 illustrates a flow chart describing the data encoding process according to one example.
  • the system 100 obtains from the data repository 118 all of the keyed segmentation data determined from the geo-spatial segmentation processing. This includes, but is not limited to, the data illustrated in Figure 45 such as the key ID identifying each grid, the reference coordinate data for each grid and the venue ID and offset data with respect to the venues within particular grids.
  • Step S4602 obtains from the data repository 1 18 all of the attribute data for each venue that was identified by the crawl and parsing module 1 14. This includes, but is not limited to, all of the attribute data illustrated in Figure 40 such as name, price, genre, and coordinate data.
  • Step S4604 the system 100 encodes some or all of the attribute data for each venue within the data repository 1 18.
  • this data can take the form of a string and includes encoded representations of the attribute data values.
  • the coordinate offset data of each restaurant can be represented as a series of numeric values without intervening decimal points or place holders. Referring to the example above with respect to the offset data determined for Restaurant 3, these coordinate offset values of (.2230, .1298) could be represented simply as 2230 1298.
  • the reference point coordinate information of (41.75, -71.25) can be represented as 4175_-7125 without requiring the decimals or an indication of which value represents an abscissa or ordinate value based on the order of the numbers.
  • This system 100 can store information indicated at what point the decimal value will be applied to the coordinate data. This information will be used to determine which restaurants are located within a reasonable distance from a user located in a particular grid.
  • shorthand versions of important venue designation and attribute data such as ID, price, genre and attire can be used within the string.
  • Numeric information such as price may be represented simply by a alphanumeric value such as 1 -10 wherein 1 signifies a lower price and 10 signifies a higher price.
  • shorthand characters or the first character of a designation type could be used to identify that attribute.
  • various letters from the cuisine designations can be used in the string to represent the venue genre or the first letter could be used.
  • the first letter of the cuisine or genre type may be used to designate the cuisine type such that the letter "p" may designate pastries, the letter "j” may designate Japanese and the letter "w” may represent Western.
  • the style may also be represented by various letters from style designations and in selected embodiments can be represented by the first letter in the style designation.
  • the letter "c” may represent casual
  • the letter "f ' may represent formal
  • the letter "h” may represent hipster.
  • hour of operation or any venue time related attribute information could be represented by the number and a letter for AM or PM.
  • the designation "lOa- ⁇ " or “lOalOp” could be used to designate that a venue is open from 10:00 AM to 10:00 PM. It is noted that any other information, such as rating data and review data, can also be encoded in short hand and stored in association with the venue as described herein.
  • various characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters can be used to separate the information within the string identifying the venue attributes. For example, any characters
  • alphanumeric data separated by underscores may represent that it is a different venue attribute.
  • any other character could also be used to separate the venue attribute data in such a fashion that the system 100 could parse the string and determine the various pieces of attribute data based on the particular character separator.
  • other characters can be used to designate that the venue has a plurality of designations for a particular venue attribute. For example, in selected embodiments, a dash could be used between attributes of the same type to designate that the venue has both characteristics. In other words, the letters A-W could be used to designate that the venue has both an American and Western motif.
  • Position within the string is also extremely important so that the system 100 can effectively and efficiently identify each piece of data when parsing or traversing the string.
  • the order in which the values are encoded is the ID of the restaurant, the price of the restaurant, the genre of the restaurant, the hours of operation, the attire and then the coordinate offset values.
  • the system 100 can use a null value single character place holder such that the system 100 will not mistakenly mix up the order and miscalculate venue attribute information from the string. Accordingly, even with a shorthand representation for various attributes in which these attributes might utilize the same alphanumeric character, the system 100 will be able to identify the specific attribute based on the order.
  • the order in which the attributes are encoded is determined by the system in a variety of ways.
  • the order in which the attributes are encoded within the string may indicate a ranking importance and/or weight of the property values which can be used when personalizing the recommendation described below.
  • the quality of the attribute information may determine the order in which the attributes values are encoded. For example, if the crawl and parse module 114 has determined from a predetermined number of sources, the same information about a venue, such as the genre, the system 100 can identify this attribute value as a quality attribute value have a predetermined quality or reliability level as it has been confirmed from a variety of sources.
  • attribute values that may not have as many confirming sources of information received via the crawl and parsing module 1 14 may not be determined to be as high in quality as the genre. Accordingly, the system 100 can utilize this information such that the attributes are encoded in an order based on their quality level.
  • Figure 47 illustrates an encoding scheme applied by the system 100 according to selected embodiments.
  • This encoding scheme may be stored in the data repository 118.
  • the data repository stores information representing an encoding scheme which identifies position information within a string, the data that is represented at that position in the string, the type of data at that position in the string and corresponding values of the information in the string.
  • This information is used by the system 100 to encode and decode information with respect to venue attributes and location data. For example, in this encoding scheme, position 1 in a string numerically represents the restaurant ID, position two numerically represents the price and provides the system 100 with information such as what various numeric values represent.
  • the system 100 can identify that the value of 1 represents a low priced restaurant whereas the value of 10 represents a high priced restaurant.
  • values with respect to the data can take a variety of different forms based on the type of data. For example, Figure 47 identifies the third position in the string as being represented by genre having a character type and corresponding values for the different characters such as "P" for pizza and "D" for desserts. In selected embodiments, other encoding schemes may be used in combination such as converting every value to a numeric value.
  • the encoded string data is stored at Step S4606 in the data repository 118 in association with the corresponding key data or reference point data.
  • any encoded string data for a venue within a particular grid is stored in association with the key and/or reference point information for that particular grid.
  • Figure 48 illustrates this storage scheme containing the key ID, the reference point coordinate data for each key (i.e. grid designation) and encoded data identifying venues within that particular grid as well as their attribute data.
  • Key 1 represents the first grid created within the city of Cambridge MA having offset coordinate data (as determined above with respect to Step S4306 of Figure 43) and encoded string data for venues within that grid.
  • the grid identified by Key 1 having reference coordinate data also includes encoded string data with respect to Restaurant 4 which has a price point of "3", a "chinese-japanese” cuisine, a casual- family motif and offset coordinates of (.2420, .0005). If, as in selected embodiments, these attributes were encoded in order of quality, it may signify that the system 100 had the best information with respect to price such that this was the first attribute encoded into the string of venue attribute data.
  • the system 100 may also store the encoded data of various venues in association with one or more grid keys and/or corresponding reference point coordinate data in a particular order to designate certain qualities about the encoded data.
  • the order in which the encoded venue data for each venue is stored may indicate a quality level of the venue itself. For example, if the crawl and parsing module 1 14 retrieved information from various sources indicating rating levels of various venues, this information could be used by the system 100 to determine an overall quality level for the venue.
  • the particular quality value for a particular venue may therefore be in selected embodiments encoded with the other attribute data for the venue and can also be used when the system 100 stores the encoded data for each venue in association with corresponding key and/or reference point coordinate data such that venues having a higher quality rating are stored in order based on the ratings.
  • Step S4608 the system determines whether there are additional grids that need to be processed in order to create encoded data for every known venue. If there are additional grids, the system 100 proceeds to create encoded string data for every venue within those remaining grids and store that information in the data repository 1 18 in association with the key and reference point coordinate data. If there are no more grids remaining to be processed, the process terminates.
  • the system 100 may also determine for each a grid, corresponding neighboring grids that should contemplated by the system 100 any time a user is located in a particular grid. For instance, a user in the grid designated by Key 2 may be geographically close enough to the grids represented by Keys 1 and 3 and therefore the system 100 may store Key 2 in association with Keys 1 and 3 to provide for efficient nested retrieval. Alternatively, the system 100 may store in the data repository 1 18 the reference point coordinate values as the key values themselves and therefore would store r_4200_- 07125 in association with r_4175 -07125, r_4225_-07125 and itself. This allows the system to easily locate and query these grids as well any time a query is made with respect to the grid identified by r_4200_-07125.
  • the number of grids to associate with a particular grid can be determined based on a number of different factors.
  • the system 100 may systematically process each grid and for each grid store all neighboring grids in association with that particular grid.
  • the system 100 may also have a predetermined distance amount set such that only neighboring grids within a predetermined coordinate range will be stored in association with each other. Further, the user may manually set in advance the range at which he is willing to travel thereby allowing the system to create grid associations tailored to the individual needs of each user.
  • the user may also indicate particular areas in which he does not want to go to and the system 100 can automatically not include those grid areas in any search thereby further customizing the personalization results while also providing quicker results.
  • the system 100 may have information about the transit options in that area which will affect the distance at which neighboring grids are included within the key set. Further, if the system 100 knows from the user profile that the user does not have a car, the system 100 may limit the geographic boundaries at which neighboring grid data will be included in the key set.
  • the system 100 has retrieved attribute information about the user and a plurality of venues, geo-spatially segmented all of the geographic information available to the system 100 and identified which venues belong to which grids, encoded a plurality of the data and stored this data in corresponding associations in the data repository 1 18. Therefore, the system 100 has determined all of the information necessary for a user to interact with the system 100 via the user interface 110 to receive personalized recommendations for venues within a user locale.
  • Either the system 100 or users 108 may trigger the recommendation engine 112.
  • the users may do so by entering through a web portal via the network 120, client application or electronic message a request that a recommendation be generated based on provided venue attributes such as for example type, geography and/or price.
  • the system 100 may access a user profile to collect the user attribute data identified in Figure 41 from the user profile such as other venues liked, gender, profession, or age.
  • the system 100 may also automatically generate recommendations for inclusion in electronic messages, such as text messages or email messages, sent to targeted users or for presentation on a web portal or client application accessed by users.
  • FIG. 49 is a flow chart illustrating the steps taken by the system 100 to provide personalized recommendations to users 108.
  • the system 100 receives a recommendation request from a user for a personalized recommendation based on a location of the user and/or a predetermined location.
  • the system 100 receives recommendation requirements from the user as part of the request.
  • the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates.
  • the system 100 may automatically provide a request based on information about a location of the user and/or habits of the user.
  • the recommendation engine 1 12 may automatically generate recommendations based on the users location within the new grid and likes and dislikes previously known to the system 100. For further discussions below and as an example, it will be assumed that the user has requested recommendations for an American restaurant having a four point price point located in or around coordinates (42.03, -71.10)
  • the system 100 determines at Step S4902 which grid the user is located in or which grid has location information pertaining to a particular request.
  • the user may provide the system with particular coordinates or the system 100 may determine the location of the user via GPS based on a user's mobile devices and applications.
  • the system 100 uses the coordinates provided by the user and identifies the closest key coordinate data. Based on the example discussed above, the system 100 would determine that the closest reference point coordinate key data is the grid defined by (42.00, - 71.25) or reference point r_4200_-07125.
  • the system 100 may poll the grid data contained within the data repository 1 18 and pick the grid with the smallest offset from the provided location data.
  • the system 100 may reduce the time of such processing by only searching specific locations within the data repository 1 18. For example, if the system 100 knows that the user is located in Boston, MA, United States based on the user profile, the system 100 may only compare the user location data with location data from that particular area. Further, if the user provides location data other than where the user is located, the system 100 may use the coordinates to determine the generalized location in the world and then only seek coordinate reference key data for that particular area in the data repository 1 18.
  • the system 100 retrieves at Step S4904 all of the keys that are linked to that particular key data. For example and as described previously herein with respect to at least Figure 43, each key will often be linked to other neighboring keys. Therefore, the system 100 may easily retrieve the appropriate key set based on the nested key data.
  • the system 100 then retrieves from the data repository 1 18 at Step S4906 all of the encoded venue or item of interest data corresponding to the reference point coordinate key data determined in step S4904. At this point, the system 100 has identified every venue within a reasonable distance from the coordinate data provided by the user in the recommendation request.
  • the system 100 must then filter at Step S4908 this information based on specific request information provided in the recommendation request.
  • the user may request only American restaurants within a particular price range or the system 100, when auto-generating recommendations, may know particular user affinities and therefore filter the data set based on these affinities. Based on the example discussed above, the user only wants recommendations for American restaurants having a price point of four.
  • the system 100 generates a nodal excitation pattern based on the particularities of the specific request for the user. For example, the excitation pattern ([ ⁇ 4]+)_( ⁇ -?A ⁇ - ?)_([ ⁇ _]+)_(.*) may be generated for this particular request by the recommendation engine 1 12.
  • the excitation pattern indicates a value of "4" for the price point and a value "A" for American restaurants in an order in which the encoded data is stored and in a similar fashion in which the encoded data is stored.
  • This pattern is then matched against all of the encoded data patterns that were determined in Step S4906. In this example, there would be matches for Restaurants 1 and 5 based on a match of the nodal excitation pattern with 101_4_A-W_F- R_0123_1699 and 105_4_A-F-h_0950_2475.
  • the recommendation engine 1 12 must then personalize at Step S4910 the recommendation by applying the user attribute weights illustrated in Figure 42 to the venues and venue attributes identified in the final filter set.
  • the system 100 parses or decodes each encoded string in the final filter set to determine the particular venue attributes of the venues in the final filter set. Once these attributes are determined for each venue in the filter set, the recommendation engine 1 12 applies the user attribute weights to the appropriate attributes for each venue. The results for each attribute weighting value are then summed for each venue to provide a total excitation score for each venue in the final filter set. Attributes not having a corresponding attribute weight can be ignored or provided with a general attribute weight value. The venue having the highest score can then be recommended to the user as their personalized recommendation or a ranked listing of the venues can be provided to the user based on score.
  • recommendation engine 112 can also provide a plurality of venues to give the user some choice by always providing a predetermined amount of venues (determined automatically or set manually by the user) to the user. Alternatively, in other selected embodiments only venue scores passing a predetermined threshold value are provided to the user via the user interface 1 10.
  • the recommendation engine 1 12 accesses the information stored in the data repository 118 and illustrated in Figure 40 based on the parsed encoded data in the final filter set for each venue to provide all of the necessary venue information to the user. Therefore, as described further below, the system 100 does not have to have all of the full character object information (i.e. American, Price Point 4) ahead of time to provide personalized recommendations and can therefore operate more efficiently and effectively.
  • the recommendation engine 1 12 has identified two matches and therefore will parse the encoded string data for Restaurant 1 and Restaurant 5 to determine the venue attributes therein. Accordingly, the recommendation engine 1 12 will identify for Restaurant 1 having an encoded pattern of 101_4_A-W_F-R_0123_1699 the following values: 101 , 4, A-W, F-R, 0123, 1699 which signify, as discussed above for selected embodiments, restaurant ID "101,” a price attribute value of "4,” a genre attribute value of "American, Western,” a dress code attribute of "Formal, Romantic” and offset coordinates for the location of Restaurant 1.
  • the recommendation engine 1 12 will parse the following values: 105, 4, A-F, h, 0950, 2475 signifying Restaurant "105,” a price value of "4,” a genre of "American, French,” “hipster” attire, and offset coordinates for the location for the location of the restaurant.
  • the recommendation engine 1 12 applies the user weighting values illustrated in Figure 42 for a particular user based on the venue attributes.
  • the attribute weight value for a price of "4" 0.5
  • the attribute weight value for American 0.7
  • the attribute weight value for French 0.5
  • the system 100 has determined all of the venues in a location near the user, determined which venues best match the encoded values of each venue within the area, filtered the set of venues to a final filter set and determined overall scores for each venue in the filter set.
  • the recommendation engine 1 12 may then provide at step S4912 a variety of outputs to the user such as supplying only Restaurant 1 to the user via user interface 1 10 as it has the highest overall score.
  • the recommendation engine 1 12 may provide both Restaurant 1 and Restaurant 5 but with Restaurant 1 ranked slightly higher than Restaurant 5 based on the overall scores.
  • the recommendation engine 1 12 may set a predetermined recommendation threshold, such as 0.24, and only provide restaurants meeting or exceeding this value. In this case, only Restaurant 1 would be supplied to User 1 via the user interface 1 10. Assuming none of the recommendations are above threshold value, geometric contextualization could be implemented as described herein to resolve this issue.
  • Additional scoring methodologies are considered in selected embodiments such as assigning an additional weighting factor to venues in the final filter set which match venues which have been favorited by users as illustrated in Figure 42.
  • an additional weighting value may be applied to the overall score of 0.24 based on the Restaurant ID value "001 " because Restaurant 1 has been indicated by User 1 as one of his favorite venues.
  • weights can be added based on prior purchase history, prior visit history, how close a restaurant is to the user's current location, home location, or work location, or based on recommendations previously made to the user by the recommendation engine 1 12.
  • the recommendation processing described herein with respect to various link strengths can be used in selected embodiments to provide recommendations to the user based on the final filter set or the final set of venues each having an overall score.
  • the processing described herein with respect to determining a list of venues, encoding them, and identifying a final filter set and overall scores provides the recommendation engine 1 12 with a smaller sample set of venues from which it will make recommendations based on link strength.
  • recommendations are made based on link strengths rather than overall score with respect to weighting values.
  • the recommendation engine 112 will only provide recommendations based on overall link strengths with respect to the venues identified and ranked in the final filter set.
  • the final filter set and/or overall scores of each venue in the final filter set may therefore, in selected embodiments, be used to identify the final set of venues to which the recommendation engine 1 12 will use to provide recommendations based on overall link strength as previously described herein. Further, based on the final filter set, the recommendation engine 1 12 may provide recommendations out of this set relating to venues of which have the strongest link strength to user attributes.
  • the final filter set of venues having overall scores for each venue may be applied to different recommendation systems.
  • the methodology described at least in FIGS. 40-49 generates a final filtered set of candidates based on various factors which can then be used as a data set which is provided to the recommendation engine 1 12 described herein or to other recommendation systems. Those recommendation systems may then determine how to make use of the information to provide the user with various types of information such as rankings.
  • the systems and methodologies described above provide a variety of advantages over current systems and techniques. By efficiently segmenting areas into grids having corresponding key data and storing this information in association with efficiently encoded data, it provides the system 100 with the ability to efficiently and effectively retrieve particular information. Further, the enhanced encoding schemes described herein allow the system to rapidly encode and decode the data while saving on storage space and processing requirements. Under this system, data can be pre-calculated for all users and combinations with minimal memory requirements thereby allowing for faster retrieval and processing of user recommendations. Accordingly, one hit to the data repository 118 can return not only a list of all objects that fall into spatially segmented area but also all of the features of those objects at which point they can be readily operated on to determine personalized
  • the recommendation engine 1 12 is able to more efficiently generate recommendations based on overall link strength with respect to the final filter set. Further, due to the various encoding and storing methodologies, the system 100 can determine from one storage table of information, the attributes of venues, where they are located, which grid they are located in, relative weights of each venue or venue attributes, and the relative quality of the venue.
  • the spatial segmentation further provides the ability for the system 100 to determine objects of interest accurately and efficiently while also allowing the system 100 to easily identify neighboring spatial segments that should be intermingled with each other.
  • the segmentation size allows for decimal offset values thereby requiring only a small storage space and enabling efficient processing to determine key and offset data.
  • segmentation may not be performed by coordinates but rather by "type" of wine (i.e. red, white, rose, etc). Segmentation can then be relied upon to filter various requests by ignoring certain segmented areas such as red wine and white wine when the user request recommendations for a rose.
  • a key would be assigned to each type of wine and then stored in association with all of the identified wines for that type. Attributes of each wine would then be encoded and stored in association with the corresponding key based on the type of wine. Excitation patterns would then be utilized based on the user request to identify a list of particular wines and then the wines identified in that final filter set would be decoded and ranked based on their attributes to identify an overall ranking based on individual scores.
  • Link strengths could also be used as described herein to recommend wines having strong link strengths to those identified by the user or generated based on user attributes.
  • the objects to be retrieval in this example constitute any set of web pages based on objects of interest.
  • the objects may be selected based on category, filters for a particular category and the content sources that are targeted.
  • Content Mode 1 is called “Global Grab.”
  • Global Grab In this mode, the system seeks to identify and retrieve information on every object in a category (e.g., "all restaurants in San Diego").
  • Content Mode 2 Keeping Current, the system seeks to focus the collection on either (i) refreshing stale information on old objects, or (ii) identifying new objects that just arose for old categories.
  • Content Mode 3 known as Intelligent Browsing, the system seeks to have the data search update itself dynamically based on its real-time discoveries, to "zoom in” and focus on specific trends and objects.
  • One type of Global Grab is spidering.
  • the system can also implement paginated searches in which the system actively seeks, for example, page 1 of a term like "Restaurants," then page 2, and so on.
  • a second type of Global Grab is crawling. Sometimes it is desirable not to have to get pages directly from a content site, such as where the site blocks automated indexing. In this case one can replicate the structure of a site from the cache of a search engine, which crawl and cache every page as a "second copy" of the internet.
  • the system uses a search engine to search for the URL of interest. Usually, the URL will be included in the first result, along with a "Cached Page" link to the cached copy of the page. The system can then download the link listed in the "Cached Page," which is the same as the original page. The system can then scan that page for links to other pages on the site, and repeat the process for those pages.
  • a third type of Global Grab involves getting a list of all objects and then finding them within a site. This is a method designed to be more holistic than spidering, to ensure that every single object of a category is retrieved from a given site if available. First, a complete list of target objects is created, such as by crawling an internet directory like
  • the search engine will retrieve pages that match these search query parameters on the target site of interest. Usually one of the first few pages in the results is the correct match. By repeating this search engine and retrieval process for every object in the Internet directory, the system is likely build a complete replica of the target site's data on that category.
  • a fourth type of Global Grab involves third-party crawlers. It is contemplated that third party services will crawl the web and make the results of those crawls available for purchase. In this case, the first step of the global grab methodology is simplified because the system can query the service for every page arising from a certain set of websites. If such third party services also make the pages available for retrieval then the speed of the crawl is increased.
  • the system can discard old data and then run a new global grab.
  • the system can rely on "update notifications" which can be acquired in several forms: (i) some websites focus on these changes, such as “listings of new restaurants” in local papers, (ii) many content provider APIs will notify of openings and closings of sites, (iii) URLs and webpage titles will often receive a "CLOSED" stamp which can be rapidly screened.
  • Each datum collected by the system is tagged with an expiration date, based on the type of the data (events expire immediately, restaurants may need to be refreshed every few months to check for major changes). Data that has expired can have associated pages re-retrieved for freshness. The re-retrieval process is simplified because the URL is already known.
  • Content Mode 3 Intelligent Coordinated Retrieval, involves "eating nodes,” or retrieval computers, that can coordinate their searches based on real-time events to optimize content gathering in response to mass user behavior.
  • the retrieval computers are given "write" access to the retrieval queue. If the retrieval computers identify a trend that is similar to their original target, but stronger, the retrieval computers can recruit other computers to look more deeply at this phenomenon by writing the new target (or a set of targets within a target area) onto the retrieval queue.
  • Retrieval computers can also interact intelligently in the collection process by alerting each others if a lead turns out to be faulty, and is indicative of more faulty leads (for example, if a region of a site is covered with spam or stale data).
  • the retrieval computer(s) can scan the queue and delete similar jobs on the queue so that future computers don't devote resources to exploration of a lower value target area.
  • different search nodes again inform one another about what they learn by virtue of the shared queue to help guide their collective search.
  • the system should ensure that the data on the target site is actually referring to the object of interest. This is especially true when attempting to cross-reference objects across different sites.
  • the system optionally utilizes a "likelihood of match" score to make this determination, taking into account multiple variables. For example, if the system is trying to match a venue on two different sites, the fact that they have the same phone number or address may tend to indicate that they are the same venue.
  • Numeric identifiers on consistent scales are particularly valuable for this purpose, such as phone numbers, UPC symbols, and latitude/longitude.
  • Non-numeric identifiers (strings) such as addresses can also be used, and one can check the similarity of the two sites' addresses by taking a Hamming distance on the characters, or parsing out each one's street number, street name, etc.
  • Data is cross-referenced across multiple sites by using data from one site to choose objects to find on another site, then use the steps discussed above to find new content pages from those objects on a different site.
  • a fleet of retrieval computers may be created by building each from scratch programmatically. Each computer is resurrected from a disk image, such as an Amazon Machine Image (AMI).
  • AMI Amazon Machine Image
  • the AMI is loaded as an elastic computing node on Amazon's EC2 (elastic cloud computing) or other service using standard libraries written in Java.
  • the AMI is armed with everything that the computer will need, including a Java runtime environment, the capacity to communicate with a central version control repository such as Git, etc.
  • the AMI is also armed with a startup script that runs when the EC2 node is born, and receives user parameters passed to the EC2 node at birth.
  • the user parameters to the startup script tell it where to download the latest code instructions for the node, such as the URL of an S3 location, or the URL of a Git repository.
  • the startup script is armed with the credentials to access the latest code instructions, and load the code onto the new EC2 node. Every EC2 node in the fleet downloads similar instructions, so they are all prepped around a common task. These instructions tell it how to connect to the message queue with the URLs to retrieve, and also how to go about the retrieval process. Each one then launches the downloaded code (runs the JAR file, etc) and thus begins working. Finally, each computer in the fleet is assigned its own IP address (via Amazon's Elastic IP system, etc) so that they can be throttled by content sites independently from the other nodes and work in parallel.
  • Tasks are distributed amongst the fleet of retrieval computers by using a list of URLs (usually long, millions) of pages that the system wants to retrieve.
  • This list might be a text file, database table, or other simple serial storage system.
  • the goal is to distribute those URLs among the many computers.
  • This process is best implemented through a queue service that lives independently from all the retrieval computers.
  • Amazon offers the Simple Queuing Service (SQS) in which every URL is stored as a string message on the queue.
  • SQS Simple Queuing Service
  • Each computer in the fleet can query the queue for the next item to be crawled.
  • the queue then assigns the item to a particular retrieval computer, and marks the item as "locked” so that other retrieval computers do not also try to work on the item. Meanwhile, the system monitors whether the retrieval computer completes the task in a timely manner. If the retrieval computer does not check back with the queue to say that the job is done, then the queue restores the item to "unlocked” so that other computers can perform the task. Once a computer checks back with the queue and informs it that the task has been completed the queue removes the item from the queue.
  • a workflow is established that can be shared between an arbitrary number of retrieval computers where they can operate simultaneously to work through a list of retrieval tasks.
  • Pages are retrieved by all computers in the fleet.
  • Each retrieval computer is already armed with a URL to retrieve by taking the message from the messaging queue.
  • the computer executes a function to stream the contents of the remote file (webpage, etc) into memory (in PHP, file_get_contents; in Java, url.openStream( ); etc).
  • the computer then saves this file to the global storage system (see below).
  • rate of repetition it should be noted that no single computer hits a given content source too rapidly. Therefore, each computer is "throttled" to only complete one page request every 0.1-10 seconds.
  • the use of third party crawlers, discussed above, may obviate the need to throttle in this manner. Every page request is checked to determine if it succeeded, and if failure occurs, a longer interval is used before the next attempt.
  • the system can implement different schedules for the interval rollback, such as an exponential rollback.
  • the global storage system may be a distributed storage platform (Amazon S3, etc).
  • Amazon S3 data is stored in buckets that are accessible from any computer as a URL.
  • Each retrieval computer stores the contents of the retrieved file in a repository folder on S3 (or other service) as a file path string which is also URL. The file can thus be retrieved at a later date by entering the storage system URL. Access to these repository folders is private so that they can only be accessed by the system's Content Collection and Content Organization systems.
  • the aim is to take content collected from the Internet and organize it for access through the Interface.
  • the input may be a hard drive directory of the latest set of collected web pages.
  • the output may be the data uploaded to a large-scale (but highly organized) database.
  • the output may be generated by repeating the following process: 1) find a page, 2) parse the page for info, 3) match the page to an object in the database, and 4) update the database.
  • Another computer fleet may be deployed to organize the content.
  • content organization computers may be replicated by building them from scratch programmatically.
  • Each computer is resurrected from a disk image, such as an Amazon Machine Image (AMI).
  • AMI Amazon Machine Image
  • the AMI is loaded as an elastic computing node on Amazon's EC2 (elastic cloud computing) or other service using standard libraries written in Java.
  • the AMI is armed with everything that the computer will need, including a Java runtime environment, the capacity to communicate with a central version control repository such as Git, etc.
  • the AMI is also armed with a startup script that runs when the EC2 node is born, and receives user parameters passed to the EC2 node at birth.
  • the user parameters to the startup script tell it where to download the latest code instructions for the node, such as the URL of an S3 location, or the URL of a Git repository.
  • the startup script is armed with the credentials to access the latest code instructions, and load the code onto the new EC2 node. Every EC2 node in the fleet downloads similar instructions, so they are all prepped around a common task.
  • Every computer in the Content Organization fleet receives 2 pieces of information (which it is programmed to seek out using in its boot instructions): 1) the storage space location of the code instructions to be its brain, 2) the location address of the job queue where it will receive the material to be processed.
  • the system controls the Content Organization fleet by creating and managing the content organization process.
  • the system defines the storage directory of all the pages that need to be organized. The system thus turns this directory into a list of jobs, where each job is a file to be processed.
  • the system then creates a task queue (see below), loads that queue up with the tasks, and sets the properties of the queue to determine the time allotted for task completion before tasks are recalled and given to other computers.
  • the task queue may be implemented using Amazon Simple Queue Service (SQS) or some other service that is external to individual computers.
  • SQL Amazon Simple Queue Service
  • the system loads up the job queue with a list of pages that need to be organized.
  • Each item in the queue is a URL address in global storage space to a page that needs to be organized.
  • the goal is to distribute those URLs among the many computers.
  • the queue allows computers to take URLs, and retains a memory of which URLs still must be organized.
  • Each computer in the fleet can query the queue for the next item to be crawled.
  • the queue then assigns the item to the computer, and marks the item as "locked” so that other computers do not also try to work on the item. Meanwhile, the system monitors the queue to determine whether the computer completes the task in a timely manner.
  • the global storage system for the Content Collection fleet may be a distributed storage platform (Amazon S3, etc.).
  • Amazon S3 data is stored in buckets that are accessible from any computer as a URL.
  • Each retrieval computer stores the contents of the retrieved file in a repository folder on S3 (or other service) as a filepath string which is also URL. The file can thus be retrieved at a later date by entering the storage system URL. Access to these repository folders is restricted so that they can only be accessed by the system's Content Collection and Content Organization systems.
  • the system may utilize the following global structure for document namespaces: date_retrieved/data_format/content_provider/city/category/. For example: 201 1-07- 07/xml/google/boston/restaurants/.
  • the raw data files may not even be organized into this directory structure yet. In this case the crawl results should be sorted into files that are organized according to this structure.
  • the system To sorting raw crawl results, the system first inspects all the files retrieved during Content Collection and sort them according to the objects that they represent. One way to do so is inspect the URL of the crawl.
  • the URL will disclose the content provider, the city/metro area, and category. For sites where this cannot be computed from the URL, the data can be extracted from elsewhere in the file (address field, etc.)
  • the date of the crawl can be retrieved from the stored file's metadata.
  • the crawl result file (or part of the crawl result file) that applies to the extracted object can then be saved in the directory structure described above. In this manner, all of the raw crawl results are placed in an organized directory structure to facilitate the subsequent organization to the database.
  • the queue is loaded by accessing the storage system directory where the sorted documents are located (see above). The system then spiders this directory to uncover the list of all files within that directory and its sub-directories. The system then creates a job queue (described above) to hold the list of files to parse. Next, the system uploads to the queue a list of file locations (URLs to the files), as an array of messages, to the queue. At this point the queue is loaded with a set of files to be parsed and organized.
  • a computer in the fleet Every time a computer in the fleet goes to the queue and retrieves a sorted page to organize, it first analyzes the following information from the URL: the "data format”, which determines how to read the file's data; the "content provider”, which determines which page parser to apply; and the “category”, which determines what type of object to extract.
  • the computer already has in its memory all of the different parsers that it downloaded when it was deployed. The computer picks one out based on the content provider and data format, and runs it on the file. Input is the file itself and the output is a data object in memory with values extracted from the file and stored in fields.
  • the computer Every time a computer parses a file, and stores its data object in memory, the data is next added to the database. First, the computer has to identify the object's location in the database. This is accomplished by selecting the database table (in Amazon, a domain) based on the category of the object, and locating the row of the object by using, in descending order: i) the unique id of the object from the content provider (for example, restaurant id on local.yahoo.com), ii) another unique numerical identifier, such as the phone number, and iii) name, address, and latitude/longitude fuzzy matching. If the determined entry does not already exist, the computer creates a new row. The computer then runs an update on that row, updating every attribute (field) in a single database hit for efficiency. This is repeated for every sorted page that the computers come across in the queue, until all of the sorted pages have been organized into the database.
  • the database table in Amazon, a domain
  • the system personalizes the content by generating a neural network architecture that connects objects in the world as nodes within a network.
  • the system activates a subset of the nodes based on what is known about the user's affinities. The activations are followed through the network to deduce what else the user will like.
  • the neural network may be implemented as follows. Connections TO a node a stored as a list of ⁇ Nl, Wl , N2, W2, ... ⁇ where the connected nodes N are paired with their weights W. This list is saved in the database in the same row as the other properties of the node.
  • a list of connections FROM the node can also be stored.
  • Subsets of nodes to be activated are identified by user-provided data regarding likes and dislikes. Users may be required to answer regarding their "favorites" in different categories. Users may also provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or -10 to 10).
  • the system assembles a list of "positive activation nodes” and assign an activation level, which were either favorites (e.g., 10H activation) or feedback-driven (e.g., 1-1 OH activation). Similarly, the system assembles a list of "negative activation nodes” and assigns an activation level (e.g., -1H to -10H).
  • Connections are established by, for every node in the user's list, accessing in the database the set of common co-occurrences with that object on the web. The system retrieves this list of objects and builds connections from our node to those objects with five positive synapses each.
  • Connections also may be based on feature similarity. For every node in the user's list, the system identifies nodes with similar properties. For the category to be matched, the system takes the most salient properties (e.g., for a restaurant, price, cuisine and ambience) and searches the database for other restaurants that match that feature set. Each match generates two positive synapses.
  • feature similarity For every node in the user's list, the system identifies nodes with similar properties. For the category to be matched, the system takes the most salient properties (e.g., for a restaurant, price, cuisine and ambience) and searches the database for other restaurants that match that feature set. Each match generates two positive synapses.
  • Connections also may be established based on cross-visitation. For every node in the user's list, the system identifies nodes that have been cross- visited by other users. These users can be users of the system (e.g., users of a subscription service associated with the system) or activity elsewhere on the Internet about which the system has data. This may be accomplished by indexing the reviews and responses to all nodes. The system identifies strong responses to the node of interest, identifies the users that furnished those responses, and identifies other nodes to which those users had similarly strong responses. The system can connect those nodes to our node of interest, with one positive synapse for every similar response.
  • Negative synapses can facilitate the recommendation process by factoring in what the user does not like and the things that are not like things that the user does like. Both of these associates involve negative synapses, which add richness to the representation. For example, the system can identify strong responses to the node of interest, identify users that made those responses, and identify other nodes to which those users had opposite strong responses.
  • the system can identify nodes that the user did not like, identify other people who did not like that node, identify nodes that those people did like and positively link those nodes to our user's preferences.
  • the network may exhibit "runaway connectivity" where something gets more connected, which then gives it an advantage in getting further connected (e.g., more cooccurrences) which in turn tends to generate even further connections. Therefore the system may normalize connectivity by inspecting the list of existing connections to a node, determining their total value (e.g., # connections N.times. average weight W), and in the event that total value exceeds some threshold, divide all of the connection weights by a constant value to bring them back into range. This may be repeated for all nodes. Normalization alternatively can be accomplished by dividing based on the N*W term going TO the node, dividing based on the N*W term coming FROM the node, dividing by the total N*W term across the network. The implementation for this may involve reading the list of node weights in the database, performing the normalization on those weights, and writing the new weights back to the database.
  • # connections N.times. average weight W e.g., # connections N.times. average weight W
  • Connections from node to node can be constantly analyzed, updated and consolidated to take into account patterns that emerge between nodes. As a simple example, if A forms a strong link to B, and A forms a strong link to C, then a connection can be consolidated linking B and C. Such patterns can be searched for using specialized scripts that check the database entries for such patterns, and then write back consolidation changes to the affected nodes' lists.
  • connection strength is therefore the inverse of the resistance to the propagation of the activation through the network.
  • the total list of nodes that was effectively activated by this process can then be stored in a list that is linked to the user in the database, for retrieval with a single database call whereupon the list can be cross-referenced against a set of presented results.
  • different sub-lists can be stored for different categories, or different presentation scenarios, caching the results for fast personalization.
  • the user interface may comprise i) a set of HTML files that define the look and feel of the web interface, with design elements styled using cascading style sheets (CSS), iii) a server-side set of scripts that dynamically generate those HTML files using a backend scripting language (PHP, etc) running on a web server (Apache, etc.), iii) a client-side set of scripts and interface libraries that allows rich user interaction within the browser (Javascript, j Query, etc.), and iv) a backend database that provides the data to the web application
  • the functionality of the user interface includes permitting the user to create an account and log in using secure credentials that are verified against an encrypted user table in our backend database.
  • the interface also allows a user to browse objects and see whether they are recommended or not.
  • the interface allows a user to filter those objects by city, by category, and then by a host of properties pertinent to those categories.
  • the user can enter feedback on their recommendations by clicking on thumbs up/thumbs down or other feedback mechanisms.
  • the interface allows a user to drag and drop recommendations onto a "being considered” area where they can be compared across different parameters using sortable headers, etc.
  • the interface allows a user to drag an object onto their calendar in order to "action" it by going to the object at a certain time.
  • the interface allows a user to build events, such as "My New York City Trip" where the user can create a group of restaurants, hotels, and other opportunities that have been recommended.
  • the user can enter notes about their recommendations to remind themselves of various impressions, for example.
  • the user can print out a copy of itineraries for their events, or email those itineraries to themselves.
  • Their calendar is also synchronized with the global calendar on their smart phones, etc.
  • the user can share their recommendations with others, or build events and share those with others.
  • the interface may be delivered via a scalable cloud architecture.
  • Web servers run as Linux CPU nodes on Amazon's elastic cloud computing (EC2) system.
  • Web servers receive independent IP addresses using Elastic IP or other IP address mediators.
  • Web servers are monitored for load, and users are dynamically distributed among the servers. Excessive user load trips a threshold which leads to the creation of more EC2 nodes. When user load drops too low, that trips a threshold which leads to the delete of EC2 nodes to save cost.
  • a list of all recommended objects is pre-computed for the user.
  • the system simply checks to IDs of those objects prior to presentation to see whether the objects appear on the recommended list or not.
  • the personalization is computed in real time with no pre-cached list of recommended objects. In this example, as objects were going to be presented through the interface, they are run through the personalization engine at that moment to compute if they are recommended or not.
  • the server and/or client device are implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
  • the apparatus is optionally implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by a programmable processor; and method steps are performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output.
  • the described features are optionally implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device.
  • a computer program is a set of instructions that are optionally used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result.
  • a computer program is optionally written in any form of programming language, including compiled or interpreted languages, and it is deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer.
  • a processor will receive instructions and data from a read-only memory or a random access memory or both.
  • the essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data.
  • a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto- optical disks; and optical disks.
  • Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor memory devices such as EPROM, EEPROM, and flash memory devices
  • magnetic disks such as internal hard disks and removable disks
  • magneto-optical disks and CD-ROM and DVD-ROM disks.
  • the processor and the memory are optionally supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
  • ASICs application-specific integrated circuits
  • a computer having a display device such as an LCD (liquid crystal display) monitor or screen for displaying information to the user and, in the case of a desktop computer, a keyboard and a pointing device such as a mouse or a trackball by which the user provides input to the computer.
  • a display device such as an LCD (liquid crystal display) monitor or screen for displaying information to the user and, in the case of a desktop computer, a keyboard and a pointing device such as a mouse or a trackball by which the user provides input to the computer.
  • the client device is a smart phone such as that described in U.S. Pat. No. 7,966,578, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Translating Displayed Content,” assigned to Apple, Inc., which is incorporated herein by reference.
  • the server functionality described above is optionally implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser; or any combination of them.
  • the components of the system are connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.
  • the computer system optionally includes clients and servers.
  • a client and server are generally remote from each other and typically interact through a network, such as the described one.
  • the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • a processing circuit also includes devices such as an application specific integrated circuit (ASIC) and conventional circuit components arranged to perform the recited functions.
  • ASIC application specific integrated circuit
  • the functions and features described herein may also be executed by various distributed components of a system.
  • one or more processors may execute these system functions, wherein the processors are distributed across multiple components communicating in a network.
  • the distributed components may include one or more client and/or server machines, in addition to various human interface and/or communication devices (e.g., display monitors, smart phones, tablets, personal digital assistants (PDAs)).
  • the network may be a private network, such as a LAN or WAN, or may be a public network, such as the Internet. Input to the system may be received via direct user input and/or received remotely either in real-time or as a batch process. Additionally, some implementations may be performed on modules or hardware not identical to those described. Accordingly, other implementations are within the scope that may be claimed.
  • Non-limiting examples for the above-noted embodiments include ad serving, customer relationship management, fraud detection, matchmaking, real estate, predicting political affiliations, vacation recommendations, educational/professional recommendations, health care provider recommendations, disease diagnosis, babysitter recommendations, employment recommendations, supply chain recommendations and business consulting / knowledge management.

Abstract

In selected embodiments a recommendation generator builds a network of interrelationships between venues, reviewers and users based on their attributes and reviewer and user reviews of the venues which are enhanced by dynamic resonance between source sites. The recommendation engine in certain embodiments determines recommended venues based on user attributes and venue preferences by performing geometric contextualization on generated recommendation sets and determining recommendation resonance with past recommendations. Remote businesses may also link with the recommendation generator to receive recommendations custom-tailored to their business. In selected embodiments, interconnectivity augmentation provides for enhanced neural network topology and recommendations for foreign locales. Various user interfaces are also contemplated thereby providing users with a view of the neural network topology as well as the ability to collaboratively determine meeting places.

Description

6
TITLE
SYSTEMS AND METHODS FOR PROVIDING ENHANCED NEURAL NETWORK GENESIS AND RECOMMENDATIONS TO ONE OR MORE USERS
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is related to U.S. application Serial No. 13/416,945, filed on March 9, 2012, and U.S. application Serial No. 13/247,289, filed September 28, 2011, which is now U.S. Patent No. 8,170,971 issued May 1, 2012, the entire contents of each of which are incorporated herein by reference. This application claims priority to U.S. application Serial No. 13/669,150, filed on November 5, 2012, U.S. application Serial No. 13/842,165, filed on March 15, 2013, and U.S. application Serial No. 13/842,665, filed on March 15, 2013, the entire contents of each of which is incorporated by reference.
BACKGROUND
[0002] Search engines may output lists of hyperlinks for web pages that include information of interest. Some search engines base the determination of corresponding hyperlinks on a search query entered by the user. The goal of the search engine is to return links for high quality, relevant sites based on the search query. Most commonly, search engines accomplish this by matching the terms in the search query to a database of stored web pages or web page content. Web pages that include the terms in the search query are considered "hits" and are included in the list of hyperlinks presented to the user.
[0003] To increase efficacy of the search, a search engine may rank the list of hits or hyperlinks according to the relevance or quality. For example, the search engine may assign a grade or rank to each hit, and the score may be assigned to correspond to the relevance or importance of the web page. Conventional methods of determining importance or relevance are based on the content of each web page including the link structure of the web page.
[0004] Many conventional search engines utilize an indexing system for identifying web pages available on the Internet. The indexing system identifies words in the pages and creates an index of those words. The system responds to user queries by analyzing the index and identifying the pages that are most relevant to the users query.
[0005] The relevance ranking or determination can be executed in various ways. The citation of one site or page by other sites or pages is sometimes used as one measure of relevance. Web page metadata is also sometimes used in a determination of relevance. [0006] Neural networks have also been used in the field of Internet searching. It is assumed, for purposes of this description, that the reader is familiar with how neural networks operate. A neural network can consist of three basic aspects—a neuron or node, definitions of how the neurons or nodes are interconnected or related to each other, and the manner in which that topology is updated over time.
[0007] Further, some systems have used the explicit stated interests of one person to construct recommendations for another. For example, Person A may be connected with Person B by way of a social networking interface. The social networking interface may allow users to indicate a preference for certain consumer goods, movies, music, television shows, venues, and the like. In this case, the social network may provide recommendations to Person A based on the stated preferences of Person B. That is, Person B's preferences are directly mapped to Person B.
[0008] A recent system even suggests making "joint recommendations" in US 7,756,753. However, this system only analyzes specific items in one user's list (e.g., shopping cart, etc) to offer those items or related items to another user. That is, recommendations are provided to individual users based on purchase history similarities with other users.
[0009] Additionally, systems are available for providing recommendations based on personality traits. For example, online dating services may develop a personal profile for a user, and provide recommendations on potential partners based on personality metrics indicating a likely favorable match. Again, these systems merely provide individualized recommendations for partners; however, such systems fail to provide harmonized
recommendations based on characteristics of a group of individuals.
[0010] Further, a shift in consumer technology from desktop computing to mobile applications has led to a pronounced emphasis on computation and interfaces that incorporate a user's location. By utilizing geographic location information with respect to users, systems can provide particular information of interest arising out of that geographic location. For example, upon detecting that a user has entered a new city or neighborhood, a mobile application may provide local restaurants or shopping areas of interest to the user in that area.
[0011] Whether processing data based on geographical considerations or different data types, in order to provide this information or recommendations in an accurate and effective manner, systems must have increasingly immense computational resources and storage capacity to process the large volume of available data. This leads to increased costs to maintain and upgrade existing systems in order to continuously provide effective information to users in a timely manner. Further, current systems cannot pre-calculate the required information for holistic searching due to the variety and immense number of combinations. Therefore, a need exists for a system and associated methodology that provide timely and accurate
recommendations without requiring extensive and expensive computational resources.
SUMMARY OF ILLUSTRATIVE EMBODIMENTS
[0012] In selected embodiments a recommendation generator builds a network of interrelationships between venues, reviewers and users based on their attributes and reviewer and user reviews of the venues which are enhanced by dynamic resonance between source sites. The recommendation engine in certain embodiments determines recommended venues based on user attributes and venue preferences by performing geometric contextualization on generated recommendation sets and determining recommendation resonance with past recommendations. Remote businesses may also link with the recommendation generator to receive recommendations custom-tailored to their business. In selected embodiments, interconnectivity augmentation provides for enhanced neural network topology and recommendations for foreign locales. Various user interfaces are also contemplated thereby providing users with a view of the neural network topology as well as the ability to collaboratively determine meeting places.
[0013] In certain implementations, a system may receive attribute data corresponding to attributes of a plurality of users and to one or more venues for which the plurality of users has an affinity. A user personality matrix may be calculated for one or more of the plurality of users based on interrelational nodal link strengths between the one or more users and the venues. The user personality matrices may be merged to calculate a combined personality matrix representing a unified taste profile for the one or more users. A candidate list of venues having the highest link strength with the combined personality matrix may be determined. One or more recommended venues from the candidate list of venues that have the strongest links to the combined personality matrix may be determined, and
recommendation data corresponding to the recommended venues may be output.
[0014] In certain implementations, data is spatially segmented into a variety of grids having particular keyed location data. Items of interest located within the boundaries of each grid are identified and stored in association with the grid information. Data with respect to attributes of items of interest is encoded and stored in association with corresponding grid data. The system will identify a grid or grids based on a recommendation request or based on the user data and will generate a list of items of interest in that grid and neighboring grids. This information is filtered based on the particularities of the user request to form a final filter set. The encoded information is then parsed to determine venue attributes of the final filter set. User attribute weights are then applied to the final filter set to determine an overall score for each item of interest. Items of interest are provided as recommendations to the user based on the overall scores.
[0015] The foregoing general description and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure, and are not restrictive.
The details of one or more implementations are set forth in the accompanying drawing and description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] A more complete appreciation of this disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:
[0017] Figure 1 A is a block diagram of an environment for developing and utilizing a network of interrelated nodes;
[0018] Figure IB is a diagram of a process flow executed by an exemplary content collection system;
[0019] Figure 1C is a diagram of a process flow executed by an exemplary content organization system;
[0020] Figure 2 is a diagram showing the interrelationships between venues, reviewers and users;
[0021] Figure 3 is chart including reviewer ratings according to one example;
[0022] Figure 4 is a chart including venue attributes according to one example;
[0023] Figure 5 is a chart including reviewer attributes according to one example;
[0024] Figure 6 is a chart including user attributes according to one example;
[0025] Figure 7A and 7B show a matrix of content-based venue links according to one example;
[0026] Figures 8A and 8B show a matrix of collaborative venue link according to one example;
[0027] Figure 9 is a chart illustrating a recommendation generation according to one example;
[0028] Figure 10 is a chart illustrating a connection grown according to one example; [0029] Figure 1 1 is a chart illustrating pre-normalization matrix data according to a second example;
[0030] Figure 12 is a chart illustrating post-normalization matrix data according to a second example;
[0031] Figure 13 is a chart illustrating connection creep according to a second example;
[0032] Figure 14 is an exemplary user interface;
[0033] Figure 15 illustrates a topographical world view user interface displaying the neural network topology according to one example.
[0034] Figure 16 illustrates a topographical local view user interface displaying the neural network topology according to one example.
[0035] Figure 17 illustrates a collaborative decision making user interface according to one example.
[0036] Figure 18 is a chart illustrating the data repository of previous recommendations served to users according to one example.
[0037] Figure 19 is a chart illustrating aggregate data repository recommendation data according to one example.
[0038] Figure 20 is a flow chart illustrating error correction and data verification processing according to one example.
[0039] Figures 21 A-21D illustrate recommendation generation and recommended data values after geometric contextualization according to one example.
[0040] Figure 22 is a flow chart illustrating geometric contextualization processing according to one example.
[0041] Figure 23 is a chart illustrating reviewer ratings between different locales according to one example.
[0042] Figure 24 shows a matrix of collaborative venue links based on the reviewer ratings illustrated in Figure 23 according to one example.
[0043] Figure 25 illustrates inter nodal connections after interconnectivity augmentation processing according to one example.
[0044] Figure 26A is a chart illustrating venue attributes according to one example.
[0045] Figure 26B is a chart illustrating congruency factors determined via interconnectivity augmentation according to one example.
[0046] Figure 27 illustrates inter nodal connections after interconnectivity augmentation processing according to one example. [0047] Figure 28 illustrates an exemplary interaction via the system API between the server and a plurality of merchants.
[0048] Figure 29 is an exemplary algorithmic flow chart for calculating a user personality matrix according to one example;
[0049] Figure 30 is an exemplary user personality matrix according to one example;
[0050] Figure 31 is an exemplary algorithmic flow chart for calculating a combined personality matrix according to one example;
[0051] Figures 32A and 32B are illustrative examples of calculating a combined personality matrix according to one example;
[0052] Figure 33 is an exemplary algorithmic flowchart for determining shared
recommendations according to one example;
[0053] Figure 34 is an exemplary algorithmic flowchart for filtering candidate venues according to one example;
[0054] Figure 35 is an exemplary algorithmic flowchart for applying user weights to shared recommendations according to one example; and
[0055] Figure 36 illustrates an exemplary user interface according to one example;
[0056] Figure 37 illustrates an exemplary user interface according to one example;
[0057] Figure 38 illustrates an exemplary user interface according to one example;
[0058] Figure 39 illustrates an exemplary user interface according to one example;
[0059] Figure 40 is chart including venue attributes according to one example;
[0060] Figure 41 is a chart including user attributes according to one example;
[0061] Figure 42 is a chart illustrating user attribute weight data according to one example;
[0062] Figure 43 is a flow chart illustrating geospatial segmentation according to one example;
[0063] Figure 44 is a diagram of a geospatially segmented geographic location according to one example;
[0064] Figure 45 is a chart including keyed segmentation data according to one example;
[0065] Figure 46 is a flow chart illustrating data encoding according to one example;
[0066] Figure 47 is a chart including encoding parameters according to one example;
[0067] Figure 48 is a chart including encoded data according to one example; and
[0068] Figure 49 is a flow chart illustrating the process of providing personalized recommendations according to one example.
[0069] Like reference symbols in various drawing indicate like elements. DETAILED DESCRIPTION
Overview of Selected Embodiments
[0070] Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views.
[0071] In certain implementations a recommendation engine may generate recommendations based on attributes and data associated with venues, users, reviewers and reviews. The system may harvest reviews generated by various reviewing entities parse those reviews into an organized database of review data. That data may include attributes of the venue (such as a restaurant) and the rating or assessment provided by the reviewer. The system may also gather or generate data concerning the attributes of reviewer, such as gender, age, profession, marital status, review frequency and review accuracy. The system, in one implementation, also gathers data concerning the attributes of user, such as gender, age, profession, marital status, and affinity (whether positive or negative) for certain venues.
[0072] The exemplary system may generate a neural network of interrelationships based on venue attributes and reviewer attributes. For instance, venues may be linked by common features such as price, genre, attire, location, or affinity expressed by the same reviewer. Reviewers may be linked by personal characteristics or common affinities for certain venues. Reviewers and venues may be linked by common attributes of reviewers with a given affinity for a specific venue or common venue attributes for venues liked by a given reviewer.
[0073] The system may create interrelationships between and amongst venues and reviewers of different species. For instance, interrelated venues may include restaurants, theaters, events and institutions. Interrelated reviewers may include periodicals and individual reviewers.
[0074] Each link may incrementally strengthen or weaken the overall interrelationship between two venues, a venue and a reviewer, or two reviewers. Each link may affect neighboring links, either by causing the neighboring links to strengthen or weaken based on the magnitude of the origin link. When two reference nodes (e.g. venues) are each connected to a common node (e.g., a venue), the system can generate an additional link or
interrelationship between the two reference nodes.
[0075] The interrelationships can be broadly categorized as collaborative and content-based. Collaborative relationships are a function of affinities expressed by a given reviewer. Stated another way, collaborative links are usually between things a given user likes, often irrespective of why the user likes them. Content-based relationships are a function of the features held in common among venues in a given subset. Stated another way, content-based links are usually between things within a group which have common features. Hybrids of these approaches may also be used, for example, a link may identify venues among those liked by a given reviewer which have features in common.
[0076] The neural network of interrelationships grows dynamically as further review, reviewer and venue data is added. The system may continuously analyze the data to add positive or negative collaborative links, content links, or content-collaborative links. The system may create new derivative links, normalize the data to adjust for data skew, and adjust links based on neighboring link values.
[0077] In various implementations the system may generate recommendations based on user attributes and data associated with a recommendation request. The system may provide a plurality of recommendations based overall link strengths that factor in collaborative and content-based interrelationships. The recommendations may include venues complementary to that specifically requested, for instance, in response to a user request for a restaurant recommendation the system may generate a theater or night club recommendation as well.
[0078] In certain aspects of the present disclosure, personalization profiles may be determined concurrently for a plurality of users for the purpose of providing "shared recommendations." Shared recommendation generation may include defining a "user personality matrix" defining features of each user in the plurality of users (i.e., the group), generating a combined personality matrix defining features of the group, and determining a set of shared recommendations based on the combined personality matrix.
[0079] In certain aspects of the present disclosure, a user's affinity for a particular entity or property (i.e., a feature of a person, place, thing, etc.) may be determined when generating a user personality matrix. Mathematical computations for determining a user's affinity for a particular entity or property may include data mining functions for analyzing previous indications of an affinity for the entity or property. As a non-limiting example, a positive or negative affinity for an entity or property may include an analysis of purchase history, user reviews, interrelationships with users and/or venues, similarities between properties, survey results, and other factors described herein. It should also be appreciated that corollary principles of utilizing a user or group of users' affinities apply when determining shared recommendations based on a combined personality matrix. That is, in addition to analyzing a user's affinity for a particular entity when determining an individual's taste profile (i.e., a user personality matrix), aspects of the present disclosure may include creating and utilizing a unified taste profile (i.e., a combined personality matrix derived from aggregated user personality matrices) when determining recommendation candidates for a group of users. In this case, the recommendation candidates may, e.g., indicate an optimal decision
recommendation, based on the unified taste profile represented by the combined personality matrix.
[0080] In certain implementations a recommendation engine may generate recommendations based on attributes and data associated with venues, users, and reviews. The system harvests this information from throughout the Internet and stores it in a data repository. In certain implementations, geographic data is spatially segmented into a variety of grids having particular keyed location data. Each grid can be associated with other neighboring grids. Further, items of interest located within the geographic boundaries of each grid are identified and stored in association with the grid location information. Data with respect to venue attributes is encoded and stored in association with corresponding grid location data.
[0081] In certain implementations, users of the system will request recommendations or the system will automatically provide recommendations based on the grid data and encoded data. The system will identify a location of the request or the user and generate a list of items of interest in that location and neighboring locations. This information is then filtered based on the particularities of the user request to form a final filter set. User attribute weights determined from user affinity data are then applied to the final filter set to determine an overall score for each item of interest. Items of interest having an overall score above a predetermined threshold are then provided as recommendations to the user.
Exemplary System Architecture
[0082] Figure 1A illustrates an exemplary network architecture for a server-based recommendation generation system 100. It will be understood that some or all of the functionality described herein may be relocated to a client device application (such as a smart phone application) based on the client device's communication, data storage, and
computational capabilities.
[0083] The server 102 may host a plurality of engines and modules. In this example, the user interface module 110 resides on the server 102 and serves web pages and/or suitable content to a client side application. The crawl and parsing module 1 14 executes the web crawling and source data collection operations described below. The recommendation engine 1 12 accesses the matrices of interrelationships and/or combined personality profile matrices to generate recommendations according to the techniques described herein. The merchant interface provides the functionality described below concerning venue operators' interaction with the server and accessing projections and reports generated thereby. [0084] The data repository 118 stores the matrices of interrelationships. The repository includes a matrix builder 126 that builds data structures reflecting nodal interrelationships based on review data 122, which is collected from review sites 106 by the crawl and parsing module 114. The matrix builder 126 also incorporates at least venue, reviewer, and user data 124 collected from users 108, venues 104, and other web pages (by the crawl and parsing module 114).
[0085] In certain embodiments, the network 120 includes the Internet or World-Wide Web. The network may also comprise proprietary and semi-propriety networks such as cellular data networks, intranets, VPNs, or extranets.
[0086] Those skilled in the art will understand that the techniques described herein may be implemented in various system and database topologies consistent with various
computational methodologies. Topologies and methodologies suitable for aspects of various embodiments are described in K. R. Nichols, A Reconfigurable Computing Architecture for Implementing Artificial Neural Networks on FPGA, Master's Thesis, The University of Guelph, December 2003; F. Rosenblati, The Perception: A Probabilistic Model For
Information Storage And Organization In The Brain, Psychol, Rev., 65(6):386-408, 1958; K. Steinbuch and U. A. W. Piske; Learning Matrices and their Applications. IEEE Trans.
Electron. Computers; 12:846-862, 1963; J. A Bamden, High-level Reasoning, Computational Challenges for Connectionism, and the Conposit solution. Appl. Intell., 5(2): 103-135, April 1995; B. Denby, P. Garda, B. Granado, C. Kiesling, J.-c. Prevotet and A. Wassatch, Fast Triggering in High Energy Physics Experiments Using Hardware Neural Networks, IEEE Trans. On Neural Networks, 14(5): 1010-1027, September 2003; R. O. Duda, P. E. Hart, and D. G. Stork. Pattern Classification. John Wiley & Sons, New York, 2nd edition, 2001 ; H. Eichenbaum, The Cognitive Neuroscience of Memory: An Introduction, Oxford University Press, New York, 2002; K. Fukushima, Cognitron: A Self-Organizing Multilayered Neural Network, Bioi. Cybern, 20(3-4): 127-136, 5 Nov. 1975; K. Fukushima and S. Miyake. A Self-Organizing Neural Network With A Function Of Associative Memory: Feedback Type Cognitron, Bioi. Cybern., 28(4):201-208, 3 Mar. 1978; J. M. Fuster. Cortex and Mind:
Unifying Cognition. Oxford University Press, New York, 2002; R. Gadea, J. Cerda, F.
Ballesterand A. Mocholi, Artificial Neural Network Implementation On A Single FPGA Of A Pipelined On-Line Backpropagation, ISSS 2000, Madrid, Spain, September 2000; S.
Grossberg, Adaptive Pattern Classification And Universal Recoding: I. Parallel Development And Coding Of Neural Feature Detectors. Bioi. Cybern., 23(3): 121-134, 30 Jul. 1976; S. Grossberg, Adaptive Pattern Classification And Universal Recoding: II. Feedback, Expectation, Olfaction, Illusions, Bioi. Cybern., 23(4): 187-202, 30 Aug. 1976; S. Haykin. Neural Networks: A Comprehensive Foundation. Prentice Hall, Upper Saddle River, N.J., 2nd edition, 1999; R. Hecht-Nielsen, Neurocomputing, Addison Wesley, Reading, Mass., 1989; R. Hecht-Nielsen, A Theory Of Thalamocortex, in R. Hecht-Nielsen and T. McKenna, editors, Computational Models for Neuroscience: Human Cortical Information; S. Y. Kung, M. W. and S. H. Lin., Biometric Authentication: A Machine Learning Approach. Prentice Hall PTR, Upper Saddle River, N.J., 2005; B. Widrow and M. Kamenetsky, On The
Efficiency Of Adaptive Algorithms, In S. Haykin and B. Widrow, editors, Least-Mean- Square Adaptive Filters, John Wiley & Sons, New York, 2003; B. Widrow and M.
Kamenetsky, Statistical Efficiency Of Adaptive Algorithms, Neural Netw., 16(5-6):735-744, June July 2003; B. Widrow and M. A. Lehr, 30 Years Of Adaptive Neural Networks:
Perception, Madaline, and backpropagation, Proc. IEEE, 78(9):1415-1442, September 1990; U.S. Pat. No. 7,840,569, entitled "Enterprise relevancy ranking using a neural network," which is incorporated herein by reference; U.S. Pat. No. 7,895, 140, entitled "Neural Network Learning Device, Method, And Program," which is incorporated herein by reference; and U.S. Pat. No. 7,979,370, entitled "Neural Network For Electronic Search Applications," which is incorporated herein by reference.
Node/V enue Types
[0087] The nodes in the neural network in one implementation are venues such as restaurants, theaters, night clubs, hotels, concerts and other events. However, due to the flexibility of the systems and methodologies described herein they may be applied in a variety of other manners. Nodes in the network may be sub-venue items such as specific menu items or specific rooms inside a hotel. The nodes may also be style consumables such as clothing, furniture, or wine. The nodes may also be content such as music, books, magazines, TV shows, or movies. The nodes are optionally set to be services such as mechanics, barbers, transportation, doctors, dentists, landscape architects, interior designers, or nanny services. In other implementations the nodes may be neighborhoods or cities in which to live, real estate to purchase/rent, colleges to apply to, careers that are a good fit, or grocery stores. In still other applications the nodes may be associated with social aspects such as friends and activities the user or group of users might like. The nodes in other embodiments may be medical conditions or treatments. In other implementations, the nodes may be business, political, and military strategies, which may included simulated outcomes. [0088] The techniques described herein may also be used for fraud detection by providing predictions of what a user or group of users is unlikely to do, which in turn is more likely to be associated with fraudulent use of a credit card (for instance). The techniques may also be used for marketing/co-branding opportunities by predicting brand affinity even across disparate categories. The techniques may also be applied to actuarial/risk assessment applications by analyzing co-occurrences between a user's fine-scale likes and dislikes, which can be utilized as indicators of risk. The techniques may also be used to predict financial market behavior or trends by aggregating markets into "group users" and predicting behavior of that group user as described hereinbelow. In a similar vein, predictions on mass human behavior can be achieved with respect to geographic movement (migratory patterns) and thereby census and demographic projections over time may be generated for use by retailers, real estate developers, and others. Moreover, the techniques may be used to gauge affinity for certain types of media (such a television shows) or media channels (cable or web).
[0089] As will be appreciated from the following description, in each such implementation the nodal attributes, reviewer attributes, and the corresponding interrelationships will be selected to correspond in part to the factors that are causally associated with a user or group of users' preferences for certain nodes. For instance, in a system designed to provide career suggestions the nodal attributes may includes skills associated with each profession and user attributes may include aptitude scores or survey questionnaire results.
[0090] Hereinbelow the system 100 is described in connection with exemplary systems in which the nodes are venues such as restaurants, hotels, or theaters. For convenience the term "venue" is used to refer to neural network nodes. It should be understood that the term "venue" in the following sections is used broadly to refer to any entity or item that is interrelated in the network with other network nodes such as users and/or reviewers.
Identification of Venue Reviews
[0091] A user's or reviewer's affinity (again, positive or negative) for a venue may be derived from both evaluations and assessments of venues, such as reviews or ratings, and implicit data sources, such as ant trails. Individuals may publish ratings on social web pages, review forums and websites or blogs. Ratings may also be published by votes placed via "Like" or "Digg" buttons disposed on various websites. As one example, user reviews of restaurants can be found at menuism.com, dine.com, opentable.com, google.com,
reviewsahoy.com, and realeats.com. An individual's affinity for certain venues can also be discerned from their spending habits or purchase history, data of which can be gleaned from financial transaction records such as credit card statements. An individual's web browsing history or ant trail can also provide insight into affinities for certain venues, as discerned from cookies or the various reviews an individual generates across multiple forums, including but not limited to websites associated with each venue. An individual's website navigation bookmarks and browsing history also reflect browsing behavior and may likewise be mined for source data. The geographic position of an individual over time, such as information derived from cellular GPS data, can likewise be correlated with venues and thereby generate data reflective of venue affinity. This approach may provide dwell time data as well, which can be used to sort or arrange the data. Magazine subscription information may also be used as an indicator of an individual's affinity for given venues (as that term is broadly used herein). An individual's professional licenses can also be used as data sources for determining an affinity for venues, including but not limited to organizations.
[0092] The foregoing sources of data concerning venue affinity can be prioritized based on factors germane to the strength of the correlation between the data and the affinity of interest. Data or sites that refer to a greater number of venues might be more probative since such sites are more likely to compare, contrast or rank venues. Similarly, sites that specify a greater number of properties, such as in structured fields, for each venue or reviewer tend to be more effective or probative. Sites with a greater number of reviews per venue and/or reviews per reviewer are, on balance, to include more reliable affinity. The inclusion of "related items," "also viewed," or "people who purchased this also purchased" fields or boxes can also be considered as indicators that the site's data will be strongly correlated to actual affinities. In a similar vein, a site's inclusion of geographically proximate recommendations,
recommendations based on social networking, and recommendations based of
complementary venues (e.g. hotel and restaurant) may be indicative of more reliable data. The behavior of the more effective or accurate reviewers also can be analyzed to differentiate various data sources, for example, by determining where those reviewers tend to post reviews. The existence of grouping structures, such as data structures associated with a plurality of socially networked individuals, can also be used as a metric to grade or rate the potential value of the site's data. Blogs may also be crawled to determine which reviews or ratings sites are the most commonly referenced.
[0093] In one embodiment, numeric values are associated with some or all of the foregoing variables and weights are assigned to each variable based on the system designer's estimation of the relative strength of correlation between the variable and the predictive value of the review data on the site. For instance, the density of the best reviewers on a site may be weighted more heavily than the number of venues referenced on a site. The resulted weighted numerical grades can be used to prioritize harvesting operations.
Harvesting Venue Reviews and Reviewer Data
[0094] The reviews may be harvested using web crawling techniques such as those described in US 6,631,369, entitled "Method and System for Incremental Web Crawling," and assigned to IBM Corporation, which is incorporated herein by reference. According to that technique, in an initial crawl, the crawler creates a first full index for the document store after which incremental crawls are executed.
[0095] Alternatively or in addition, the system 100 may target cached web pages served by commercial search engines. A suitable protocol for rebuilding content sites from search engine caches is as follows. First, a complete venue listing for a category by crawling a directory such as a Yellow Pages or other suitable directory. For each item in the directory, the system 100 runs a series of search queries in various search engines, each query restricted to results for the content site of interest, such as dine.com. The search results are parsed and the URLs for the relevant cached pages are retrieved. The cached pages are then retrieved and in a repository, after which they are parsed based on the name, city, phone number, and other data fields associated with a venue of interest. In this manner the cached review page for the venue of interest may be identified. This process is optionally repeated across search engines and across multiple venues, targeting the sites prioritized as set forth in the preceding section, to collect the desired array of source data.
[0096] The data may optionally be validated by checking parsed venue or reviewer content for blank fields. Venue or reviewer content may also be checked against unique
identification information (a venue phone number or a reviewer email address or screen name) to ensure sure that it corresponds to the target venue or reviewer.
[0097] After validation, the pages may be parsed to extract the data of interest. Parser code may be used to segregate out the structured fields of interest, the reviews, and other information of interest as described above. The extracted data may be uploaded to database tables or files to be analyzed for computing personalization. Techniques such as those taught in US 7,788,293, entitled "Generating Structured Information," assigned to Google Inc., the contents of which are herein incorporated by reference, may be used for this purpose.
[0098] The same approaches can be used to harvest data concerning reviewers or users (discussed in more detail below). The data is preferentially in a structured format on a public site and is predictive of personality and affinities. The data sources may be prioritized or ranked as set forth in the preceding section, such as according to the number of reviews given by the reviewer, the citation of a reviewer's reviews on other sites and the alignment of a reviewer's reviews with overall ratings generated by the system 100 (as discussed below) and third party review sites from which data is harvested. The reviewer data is then selectively crawled and parsed as explained above.
[0099] The crawl and parser module 114 may be configured to coordinate the crawling and digestion of certain web or network nodes. Due to practical limitations, the entire World Wide Web cannot be crawled and parsed simultaneously. The crawling and parsing process may be coordinated across different content- gathering computers or agents. Multiple remote crawling engines (at remote network nodes) may be deployed, each of which can check data sources (such as web pages or cached web pages) for the properties described above and recruit crawling and parsing nodes in the event rich data sources are located. The remote crawling nodes can coordinate their crawling based on real-time breaking news events, or optimize content gathering in response to shifts in mass user behavior as reflected in the data matrices described herein.
[00100] Examples of content collection and content organization systems and process flows are shown in Figure IB and 1C. Figure IB illustrates the process executed by the content collection system, which may include the crawl and parsing module 114. At step 150 the crawl and parsing module 114 identifies subject matter targets, such as rock-climbing, are needed in the neural network. The targets may also take the form of specific URLs or collections thereof. At step 1 2 the module 1 14 identifies the current content, in the form of previously collected web pages (or representations thereof), that already resides within the system's storage network. At step 154 the content collector, which in one embodiment takes the form of a persistent system network node, determines from a comparison and analysis of the two inputs which subject matter or URLs are to be gathered by the module 114. The content collector verifies the addresses and content of the target sites containing the subject matter which is to be collected and creates a queue of items to be crawled and parsed by the module 114. As an example, the distributed queue's first entry might be [Boston, restaurants, google.com, 'all'], which corresponds to a request that the crawler nodes collect all cached pages associated with google. corn's reviews of any Boston area restaurant. The content collector may also dynamically allocate certain queue items to specific crawling nodes based on their relative priority (160). At step 162 the content collection engine, which includes a distributed array of crawler nodes, receives or access the distributed queue and dynamically assigned collection commands from the content collector. The content collection engine, under the control of crawl and parsing module 114, collects cached web pages as discussed above. The output is a library of cached web content which is parsed according to the methods described herein.
[00101] Figure 1C shows an exemplary process executed by the content organizer, which may comprise the matrix builder 116. A set of cached pages to organize is obtaining as an input at step 170. At step 174 the content organizer receives or accesses the library of cached pages to be parsed and added to the network. The content organizer may be a persistent system network node in various embodiments. The content organization engine (see step 182) may include a distributed array of parsing nodes that access a distributed queue of parsing assignments and receive assignments which are dynamically assigned, optionally to specific crawling nodes or crawling nodes having certain attributes such as bandwidth or throughput. The content organization engine also accesses an array of site-specific parsers that are specially designed to parse data as it is presented on certain sites. For instance, because google.com may present its hotel data in a format different than restaurants, a parser engine specific to Google's hotel pages is presented to the content organization engine for use in parsing corresponding cached web pages. Other examples, as shown in Figure 1C, include a parser specific to facebook.com's venue or event pages. This architecture may facilitate modification of parser engines as sites alter the manner in which they present data. For example, local.yahoo.com may alter the data format of its hotel pages, in response to which a single parser engine can be updated. The output of the content organization engine (182) is used by the matrix builder 1 14 to create additional nodes and matrices of interrelationships as described herein. The resulting matrices and databases of web content are presented for simultaneous access by multiple instances of web servers which present the user interface described below or which communicate with mobile device client applications as discussed herein.
Collection of User Data
[00102] Upon creation of an account or in response to another triggering event such as a request for a new recommendation, the system 100 may require a user to input various data including gender, age, marital status, children ages, children gender, third parties with whom the user is socially networked, hobbies, interests, favorite venue information (in one or more venue categories), preferred or non-preferred reviewing entities (if any). [00103] The user is then asked to list favorite or preferred venues. As an example, the user may list favorite restaurants, movies, or activities. The system 100 may asks for alternative favorites in the event a venue is not included within the neural network.
[00104] The system 100 optionally may crawl the web for additional information concerning the user and then parse and validate the data according to the methods described above. This supplemental data may be added to the user's profile, data from which will be used in various operations as set forth below.
Creating Nodal Interrelationships
[00105] The following provides an exemplary description of aspects of creating nodal interrelationships. For the purposes of the present disclosure, it should be appreciated that these aspects may be applicable to forming nodal interrelationships as part of determining an individual user's personality matrix, as well as a group of users' combined personality matrix. Therefore, for simplicity the term "user" hereinafter may represent an individual user or a unified set of users represented by a combined personality matrix.
[00106] Nodes in the data network may represent venues, venue properties, users, user properties, reviewers, reviewer properties, and the like. Links represent relations between those nodes. The number of links between two items might therefore grow as data on two items grows. The strength of each link denotes the affinity between the two connected items, such as similarity of star rating (in a review of a venue), number of attributes held in common. Links can be either positive or negative in sign.
[00107] Links can be associated to designate affinity between and amongst, venues, properties of venues, users, reviewers, content sources, or any combination thereof. For instance, as shown in Figure 2, two venues 200, 210 may be interrelated in that they have several attributes 201, 211 in common, namely that they are both Italian restaurants in the same neighborhood. Reviewers 220, 230 are related in that they likewise have multiple attributed in common. Users 240, 250 are likewise interrelated by shared attributes.
Reviewer 220 is interrelated with both venues 200 and 210 in that Reviewer delivered a review to both venues and that in turn creates an additional relationship between venues 200 and 210 (namely, they were reviewed by the same reviewer. User 250 is related to both Reviewers 220 and 230 via shared attributes and User 240 is related only to Reviewer 220 via the shared attributes. Reviewers 220 and 230 are thus interrelated also in that they share attributes of user 240. User 240 is also directly linked to venue 200 by virtue of the fact that the user has expressed an affinity for that specific venue. Reviewers 220 and 230 thus have a second order relationship with venue 200 through user 240.
[00108] This data architecture permits links, or interrelationships, to be adjusted
independently from one another. Links touching the same node can be adjusted for one partner node but not others. Links on the same node can be "scaled" together to maintain relative values of each of their partners while changing the overall drive/influence to that node.
[00109] In selected embodiments, subtractive or "anti-related" links can weaken
relationships from one node onto another. Subtractive nodes also can be added to the network to normalize the total positive timbre of local nodes where the average link values are too strongly positive. Subtractive nodes also can serve to mediate competition between nodes to influence one another, as the strength of the link dictates the effect one node will have on the other. Subtractive nodes can help sharpen, or focus, the positive influence cast by a given node.
[00110] Links can in various implementations be sorted according to priority of influence over (or strength of link to) their downstream node. Links may interact and influence one another, where the addition of one changes the strength or presence of another, in a manner that is restricted or targeted to other links on the same node.
[00111] Links from reviewer nodes can be normalized based on how positive or negative they are. In other words, if a given reviewer is an "easy grader" his or her reviews may be lessened in magnitude to normalize the reviews to a statistic goal or mean. Links from reviewer nodes may also be normalized to lessen the influence of those links where, for instance, a reviewer has an extraordinarily high number of reviews (each of which creates a link) and thus that single reviewer's opinion would unduly influence the data network if not scaled appropriately. Conversely, the strength of a reviewer link make by scaled upwards based on measured or perceived effectiveness or accuracy of the reviewer. This may be executed, for instance, through rankings or ratings of reviewers or statistical feedback whereby accuracy or predictiveness of reviewers is measured.
[00112] Weighting or normalization may also be used to alter a link's strength based on the number of attributes in held in common. For instance, the system 100 may be configured to give each additional link of a given type a linearly or exponentially decreasing affect, such as where a substantial number of interrelated reviewers given a venue a similar review. Links between nodes that are hyper-connected may be likewise be scaled downward to reduce the effect that one of the two nodes has on the extended network. The converse-giving cumulative links escalating effect or increasing link strength for under-connected nodes—may also be implemented with the opposite effects.
[00113] Links may also be weighted based on the predictiveness of the reviewer. For instance, reviewers may be graded based on number of reviews, number of citations on other web sites, or ratings of reviewers on third party sites crawled by the system. The links created based on each reviewer's reviews may accordingly be scaled linearly or non-linearly according to the relative grade of the reviewer. Reviews provided by more highly rated reviewers may be assigned correspondingly higher values or strengths.
[00114] Reviewers may be weighted on a user-specific basis as well. For example, the neural network of links may be re-weighted based on the fact that the user requesting a recommendation, or a "unified user" represented by a combined personality matrix, has affinities or attributes held in common with certain reviewers. Conversely, certain reviewers with which a user and/or a unified user has indicated a negative association may result in re- weighting to correspond with the negative association. Reviewers' ratings may be correspondingly weighted more heavily or more lightly in correspondence to the link between the user and the various reviewers.
[00115] Reviewers may optionally be pruned from the network if they have below a threshold level of relevance as measured by a corresponding grade or effectiveness. As noted elsewhere herein, the grades of reviewers may be based on ratings of reviewers at third party sites and/or feedback of users of the system 100 concerning agreement or disagreement with recommendations which were calculated in part based on a given reviewer's review. If a reviewer is pruned from the system the remaining reviewer's weightings may be adjusted upwards to maintain normalization.
[00116] Similarly, aspects of the present disclosure may allow for indicating certain "filters" related to affinities or attributes other than reviewers, which can be utilized to screen against candidate recommendations. Screening candidate recommendations may, e.g., include re- weighting link strength or eliminating a link altogether.
[00117] The links in the neural network may be bidirectional (as shown in the figures) or unidirectional. In certain circumstances, the predictiveness of a link may be asymmetrical or unidirectional. For example, it may be the case that almost everyone who likes restaurant A likes restaurant B, but very few who like restaurant B also like restaurant A. In that case, the links associated with affinity for restaurant A may unidirectionally point to (i.e., be linked to) restaurant B, but the converse would not be true (i.e., node B would not have a positive link to restaurant A based on this data point). For simplicity of illustration, the figures address the simpler scenario wherein all data points are symmetrical, but in various implementations some or all of the links may be unidirectional or have asymmetric strengths (such as +1.5 in one direction and +0.5 or -0.5 in the other direction).
[00118] The neural network may be refined based on an active feedback loop concerning the effectiveness of the recommendations provided by the system 100. Links can be refined (in either direction) based on feedback for how effective the recommendation was. One measure of the effectiveness of the recommendation is whether funds were spent by the user based on the recommendation, which in turn might be measured via data provided by partners such as financial transaction card issuers. Another measure may be feedback provided by the user in response to a query or survey concerning the recommendation or venue in question. Yet another measure of recommendation effectiveness is a user's browsing behavior and the fact that the user left a positive review for the recommended venue on a third party site (which can be collected and parsed as set forth above). Still another technique to assess effectiveness of a recommendation is geographic dwell time at a physical location associated with a venue, as measured by mobile device GPS data, for instance.
[00119] It should be noted that not only first order connections are updated based on feedback. Rather, in various implementations second and higher order connections are optionally updated based on feedback. For instance, when a reviewer's ranking or grade is updated, the second order connection between two restaurants which are both liked by the reviewer may be updated or correspondingly modified as well. Mismatch between the recommendation and the user's evaluation can drive a reduction or weakening of the links between the associated nodes such that the converse could also be executed. In response to positive feedback between a reviewer node's recommendation, the links between that node and neighboring nodes may be strengthened. Similarly, links created by the reviewer's reviews may be assigned a greater strength.
[00120] The nodal structure facilitates computations and scaling of the network. As will be seen, the nodal network may create a natural look-up table that is convenient to search and operate over. The nodal structure with inter-node links of varying types provides a convenient way to update the structure as new pieces of information are added, and in certain embodiments this may be executed without losing the original information as in traditional databases that represent affinity as single number weights between items. The data in various embodiments may be represented as either an indexed rows of databases, linked lists, or distributed files. [00121] The matrix of interrelationships or links can be broadly categorized as content-based interrelationships, collaborative interrelationships, and content-collaborative
interrelationships. The first type, content-based links, are in certain embodiments premised on venue attributes for multiple venues reviewed by same reviewer. The content-based links establish interrelationships between venues based on shared attributes. The strength of the link (or anti-link) may be dependent on the number of things held in common, comparative ratings, and other factors as described herein.
[00122] Collaborative venue interrelationships associate venues that are liked by the same reviewer, often without any dependency or relation to the reason(s) why the reviewer likes the venue. The strength of the link (or anti-link) may be dependent on reviewer rating, proximity on same list, and other factors described herein. Collaborative links arise when two venues co-occur, for example, in the same person's list of favorite or preferred venues, on the same "top 10" or other grouping lists on ranking or recommendation sites, or on the same search engine search results page. Proximity within the list may be used as a variable to control link strength. Ant trails may also be used to create collaborative links by tracking people's surfing behavior and linking venues a given user often visits, independent of spiderwebbing. In this way, restaurant A may be deemed interrelated to museum B if many tracked users visit both of those sites. The user's dwell time at each site or the fact that a user left a rating or review may also factor into whether a link is created. In certain embodiments, this tracking is accomplished without the use of cookies, rather by collecting from the web data concerning the user's activities on rating and review sites according to the techniques described elsewhere herein.
[00123] Content-collaborative interrelationships or links may arise from common (or anti- common) reviewer attributes for reviewers who liked (or disliked) the same venue. The venue attributes may be analyzed for common or anti-common features, and links may be established between either a specific venue and reviewer attributes or between venue attributes and reviewer attributes. The strength of the link may depend on the incidence of an attribute among reviewers giving a venue a certain grade, or similar comparative ratings.
[00124] The exemplary architecture illustrated in Figures 3-12 facilitates in certain embodiments dynamic updating and adapting of the network. For example, when a new restaurant or review is added to the network, those nodes each create first, second and higher order links which are added to the network. The affected links can be updated by a relatively computationally simple (and non-resource intensive) addition or other arithmetic operation and the neural network need not be substantially entirely recalculated or reformed. Generating Recommendations
[00125] Either the system or users may trigger the recommendation engine. The users may do so by entering through a web portal, client application, or electronic message a request that a shared recommendation be generated based on provided venue attributes such as type, geography, or price. The system 100 may access user profiles to collect data for each user in a group requesting a shared recommendation. Exemplary user data collected by the system 100 includes other venues liked, gender, profession, age, location, pricing preferences, cuisine preferences, entertainment content preferences (e.g., favorite movies, music, books, etc.), preferred venue features, allergies, preferred modes of transportation, relative weight in shared decision making, schedule/calendar information, style preferences, and any other user information set forth herein. As will be described in further detail in later paragraphs, user data collected by the system 100 may be utilized to form a user personality matrix and combined personality matrices with which to determine shared recommendations.
[00126] The system 100 may also automatically generate recommendations for inclusion in electronic messages, such as text messages, or email messages, sent to targeted users or for presentation on a web portal or client application accessed by users. The system 100 may also include features for determining available times for a show, reservation, appointment, etc. Accordingly, the system 100 may control an interface for scheduling an event and/or purchasing tickets for shared recommendation results.
[00127] The recommendation engine may responsively identify venues with strongest links according to the following protocols in selected embodiments. Based on the identified "liked venue(s)" the system 100 may identify the top N venues that have strongest link value to that the identified venue and which have the specified venue attributes. Alternatively or in addition, based on highest rated venue(s) having specified attributes, the system 100 may identify the top N venues that have strongest link value to that the identified venue. Still another alternative which can be used alone or in combination with the foregoing is to, based on the highest rates venue(s) having specified attributes and being recommended by friends or selected reviewers, identify the top N venues that have strongest link value to that the identified venue. The recommendation engine may also generate recommendations based on the user attributes, for instance by identifying the top N venues that have strongest link to attributes of the user personality matrix and the combined personality matrix. Further, in selected embodiments a recommendation threshold at which the nodal link strengths have to cross may be implemented such that the recommendation engine will not recommend venues with link strengths below the recommendation threshold.
[0124] In certain embodiments, a plurality of these techniques are used and resulting venue recommendations are weighted based on empirical observations concerning the
predictiveness or accuracy of each protocol. The weight factors may be simple coefficients or first, second, or higher order equations.
[0125] In the case of recommendations provided for a group of users, these same techniques may be used but with the modification that the user attributes are selected to match the group, either by direct user input or by arithmetic blending or averaging the user attribute values to arrive at a composite group user profile.
[0126] Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data. As described more fully below, the system 100 may send an electronic message or alert either including a recommendation based in part on the location and/or time or prompting a user to access an interface to receive the recommendation. For instance, if one or more users is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular combined personality matrix, the system 100 may generate an electronic alert to the one or more users including the recommendation, a hyperlink to the system 100 web portal, or a link to activate a client recommendation application that can launch a user interface, such as the exemplary interfaces described herein.
[0127] Alerts or recommendations may be accompanied by, and be generated based on, promotional offers related to the venues. For instance, an electronic notification may contain a recommendation along with a promotional discount offer for the related potential booking or reservation. Recommendations presented in the interface (or via electronic messages) may also be selected based in part on promotional status. That is to say, the recommendation engine may strengthen links nodes associated with promotional offers and thus the engine will factor in promotional offers when determining nodes to recommend (i.e. those most strongly linked to nodes associated with the user or a recommendation request).
[0128] Users' feedback concerning recommended venues and the associated "take rates" may likewise be factored in by the recommendation engine. For example, the link strengths may be increased for venues for which users more frequently make reservations based on the recommendations, consistent with the techniques taught herein.
Example [0129] Figures 3-12 illustrate one simplified implementation of the recommendation engine described herein. Those skilled in the art will understand that this example can be extended to incorporate any or all of the additional features described herein. Selected of these substitutions and extensions will be mentioned below and those explanations are not intended to be limiting.
[0130] Figure 3 shows an exemplary matrix of reviewer ratings. Reviewer 1 has provided reviews for nine out of the twelve restaurants, the ratings spanning from one star to five, five being the highest. Reviewers 2-7 have likewise each provided ratings for a different subset of the twelve restaurants. In other embodiments the venues could be venues of different types, such as four restaurants, four night clubs, and four theaters. The ratings may use a wider numerical or alphabetic scale, and integer or non-integer values.
[0131] Figure 4 shows the corresponding matrix of attributes for the venues of Figure 3. In this example, each restaurant is in Boston, MA and the price varies on a ten point scale.
Attire is assigned alphabetic codes (formal and casual), although numeric codes may be used in certain embodiments. Zip codes may be used as neighborhood values in this example, although neighborhood values may be determined based on GPS position location
information, or another predefined system indicating geographical boundaries. The hours of operation may be assigned a code selected from a predetermined library of operational hours and in other embodiments the hours of operation is provided various fields, one for each day of the week.
[0132] Figure 5 shows the reviewer attributes for the Reviewers 1-7 of Figure 3. In this example, reviewer attributes are limited to gender, age, profession, education, marital status, number of children, number of reviews, and review accuracy. The codes may be selected from predetermined libraries. The number of reviews is based on the data collected as described above. The review accuracy may be calculated based on the feedback control data as discussed above. Alternatively, a composite reviewer grade may be used, which optionally factors in number of reviews, citations of reviews on other sites, number sites hosting reviews, and/or consistency of recommendation with positive user feedback.
[0133] Figure 6 is a chart showing an array of user attributes for seven users. The
methodology is similar to that set forth above for reviewers, but additional or different data fields are used for the users. In this embodiment, each user is asked for four favorite venues. In other embodiments, a list of preferred venues in various different venue categories may be included in the user profile. This user data, as noted above, may be input by each user and/or collected from web data sources in the manner set forth above. Additionally, as will be discussed in further detail in later sections, the user data may be used to form user personality matrices and combined personality matrices for shared recommendations.
[0134] Figures 7A and 7B illustrate an array of content-based venue links based on the venue attributes of Figure 4. Referring to Figure 7A, Restaurant 4 has one link with
Restaurant 2 associated with common attire. The value of the link, +0.25, is less than the other links such that it has a lesser impact on the recommendation, as will be seen. In other words, the link is relatively weak. Restaurant 4 has three links with Restaurant 1 , +1.25 associated with the common neighborhood, +1 based on the common genre and +0.25 based on the same attire. The net value of the content-based links between links Restaurant 4 and Restaurant 1 is +2.50. The exemplary matrix of Figures 7A and 7B could optionally include links associated with a plurality of additional venue attributes and could also include anti- links (or negative links) associated with anti-common properties, as will be illustrated in connection with Figure 8.
[0135] Figures 8A and 8B show a matrix of collaborative venue links based on the reviews set forth in Figure 3. Taking as an example the association between Restaurant 7 and Restaurant 3, there is a +1 link associated with the fact that Reviewer 2 rated both of these restaurants as four star. Restaurants 6 and 7 are given a stronger positive link based on common positive reviews because Reviewer 3 rated both restaurants as five star. Returning to the link between Restaurant 7 and 3, an anti-link of -0.75 is assigned based on the opposite affinity for these restaurants expressed by Reviewer 1 (who gave the Restaurant 3 four stars and Restaurant 7 one star). A higher negative magnitude could be used where a review rated restaurants in a more strongly opposite manner (i.e. one star and five star), as shown in the link between Restaurant 1 1 and Restaurant 5 where a -1.00 anti-link is shown based on the one star/five star ratings of Reviewer 5. As noted above, a greater array of different links could be assigned based on commonalities or anti-commonalities ~ these are merely representative.
[0136] A matrix of content-collaborative interrelationships (not shown) may reflect links arising from common or anti-common features between each venue and each reviewer. For example, reviewers may have a characteristic called "genre affinity," and a link of predetermined strength may be created when a genre affinity matches the venue genre.
Additionally, the content-collaborative matrix may show links between affinity for a venue and reviewer attributes. In that example, common attributes among reviewers who rated a venue highly may be linked to the venue. For instance, reviewers aged 31-35 may disproportionately rate a venue poorly, in which case an anti-link may be created between the venue and the reviewer attribute "age 31-35."
[0137] Figure 9 shows illustrative exemplary outputs of the recommendation engine based on a query for a recommendation for an American restaurant and a user affinity for
Restaurant 7, which may be indicated by an aggregated user taste profile represented by a combined personality matrix. In other embodiments more inputs may be used, such as venue attributes and other preferred venues. In this example, the recommendation is a blending of the content-based link strength 901 , collaborative link strength 903, and content-collaborative link strength 905. Each link strength is assigned a distinct weighting factor 902, 904, 906, although in other embodiments the blending equation may be a second order or higher order equation rather than a first order sum of products. The values 910-914 derive from the fact that Restaurant 3 and Restaurant 7 have no link shown in Figure 7. The same is true for Restaurants 6/7, while Restaurants 9/7 and 12/7 show a +0.25 link. Similarly, the matrix in Figure 9 shows the cumulative link strengths 915-918 for restaurant links 3/7, 6/7, 9/7 and 12/7, respectively. The content-collaborative link strength are based on the content- collaborative link matrix (not shown). The weighting factors 902, 904, 906 are constant but may be set to vary according to the predictiveness or accuracy of each type of link (based on feedback control as discussed above). The resulting recommendation values 920-923 reflect the overall link strength 907 between each restaurant and restaurant 7, as shown above.
[0138] Second order relationships could also be included in the link matrices used to calculate overall link strength. For example, Restaurant 8 is liked by both Reviewer 4 and Reviewer 5. Those reviewers, in turn, both like Restaurant 5. Restaurant 5 could be assigned a direct +0.25 link to Restaurant 8 based on this second order relationship. That link could operate in the matrix independently of the nodes associated with Reviewer 4 or Reviewer 5.
[0139] An alternative form of a second order relationship is shown in Figure 10. Figure 10 illustrates second order links arising from collaborative venue links. As shown in Figure 8, Restaurant 8 is positively linked to both Restaurant 3 and Restaurant 5, so a +0.25 link is created directly between Restaurants 3 and 5. Restaurants 12 and 7 are both negatively linked to Restaurant 8 so a +0.15 link is created to reflect the belief that this anti-link is weaker than the positive link previously mentioned. In a similar vein, an even weaker second order link is established between Restaurants 1 1 and 12 because while both are negatively linked to Restaurant 8 the links are substantially different in magnitude. [0140] These second order relationships can be added directly to the related matrices or otherwise computationally combined when calculating overall link strength between two nodes.
[0141] Figure 1 1 shows an exemplary set of arbitrary link values in a more complex system that factors in a wider variety of links (such as second order links) across the same nodes. It can be seen that the values are strongly positive and few values are negative. This can be observed where the data has a skew associated with reviewer tendency to give generous ratings, for instance. If the data of Figure 11 is content based, it may have a skew different than parallel matrices for collaborative links or content-collaborative links. Accordingly, it may be useful to normalize the data of Figure 1 1 to facilitate computational combination with links in the other matrices.
[0142] Figure 12 shows the data after an exemplary normalization operation. In this example, a constant value of five was subtracted from all data points. In other embodiments, the value subtracted may be selected such that the data set hits a common or desired mean or median. In other embodiments normalization may be accomplished by multiplication or division. For example, a certain percentage may be subtracted like a tax from affected links by multiplying the link strengths by (1 -X), wherein X is a tax rate from 0 to 1. The tax rates in this approach may be progressive to accommodate the tendency of users and reviewers to aggregate toward a small number of more popular venues, which as discussed herein can cause those venues to cast too large a shadow or have an undue influence on the remainder of the neural network.
[0143] It should be noted that normalization can occur at local level or at the network level. At the local level, all links connected to a certain nodes may be normalized or all links coming to or going from a certain node may be normalized (recalling that links may be unidirectional or asymmetric). Alternatively, normalization may occur at the data matrix level. For example, content-based link matrices may be normalized or other data subsets of network may be normalized.
[0144] Figure 13 shows another form of higher order connection, referred hereinafter as connection creep. In this example the link between Restaurant 10 and Restaurant 1 in Figure 12 is considered too high in that it might have an undue influence on the connected nodes. Accordingly, a link strength value of 1.5 is subtracted from link 10/1 and 0.5 is added to the less strongly positive links 10/2, 10/7 and 10/8. No portion of link 10/1 's strength is reassigned to link 10/9 because it is already above a predetermined threshold above which links are not to have connection creep bonuses added or above which no higher order links should be added.
Interface
[0145] Figure 14 illustrates an exemplary user interface for deployment at a web portal or client device such as a desktop computer, smart phone, tablet PC, automotive multimedia interface, or other mobile computing device. The server or local application provides an evolving personalized brand logo and personalized audio soundtrack to match the displayed itinerary. The sound track may persist and "travel" with the user as he or she navigates different functionalities or pages through the interface. The interface is also designed to provide bio-visual data feedback to the user. The system permits users to state their goals and intentions based on the feedback they have received from the system.
[0146] Figure 14 is an overview page that provides users with an immediate perspective on options, a space for collection/comparison/pre-screening/deliberation, and the ability to immediately act. Specifically, the overview page has three distinct sections and
functionalities. The interface of Figure 14 may be provided as an interface for initiating shared recommendation requests and/or viewing results and taking corresponding actions.
[0147] First, at the recommendation panel 1410, a plurality of recommendations is presented. In preferred embodiments, there are five recommendations provided as shown in Figure 14. In other embodiments, two to seven, three to six, four to six, four to eight, four to nine, or two to ten recommendations are provided. The number of recommendations may be on a per- venue basis so that five recommendations are provided for restaurants and a like number of hotels are recommended. Alternatively, a lesser number of complementary venue (e.g. hotel) recommendations are provided.
[0148] Second, the collection and comparison panel 1420 provides a place to compare and contrast recommendations of interest. The panel provides venue genre or type, the venue name, geographic area, and price. The panel also provides buttons to book a reservation or check availabilities or rates for the various venues. Buttons for adding the event to a calendar are optionally provided adjacent each venue. Also provided are status identifiers indicating the current state of activities and/or bookings for each venue. Optionally, buttons may be provided to launch a window or image that depicts the venue on a map.
[0149] Third, the calendar panel (not shown) may feed or import a view of the user's personal calendar and provide interactivity for immediate assessment of the user's schedule and available times. The calendar permits import of the user's other appointments and export of the calendar items to any third party calendar systems such as Outlook, Google, and iCal.
[0150] These three panels are arranged down the page so that decision-making flows down the page from menu of options (top), to deliberation and comparison (middle), to arriving at a decision, and finally to scheduling/booking/publishing/sharing/taking action (bottom). This arrangement may in certain embodiments facilitate decision-making.
[0151] A user can directly book a recommendation at any of these three stages, or add to calendar at either of the first two stages. This arrangement may in certain embodiments enhance the likelihood that a user makes reservation or booking based on the
recommendations .
[0152] Additional optional functionalities (not shown) include a transportation reservation interface. For example, the interface may present a transportation button that launches an booking or reservation portal which communicates with a third party transportation provider, such as a taxi service, and makes a reservation corresponding to a restaurant or other reservation. The interface may also permit the arrangement of transportation services between and amongst a plurality of other recommended events spanning one or more days.
[0153] In similar vein, booking functionality may be provided for a variety of
complementary venues, services, or activities. Examples include hotel rooms, airline reservations, movie tickets, theatre tickets, museum tickets, music tickets, sporting events, product delivery (such as flowers or flowers), rental car services, car share services, public transportation services, restaurant takeout/delivery services, parking services, real estate services, or moving services (such as inter-city packing and transportation services).
[0154] The interface may selectively suggest alternative actions or venues based on a first booked venue or action. For instance, the booking of a restaurant reservation may prompt the generation of night club or theater recommendations. As another example, the booking of a real estate tour through a real estate agency may prompt a recommendation for moving services. Subsequent bookings may in turn generate additional recommendations
complementary to the most recent booking, the earlier booking, or both.
[0155] These follow-on recommendations may be filtered and selected according to the techniques set forth above. In particular, the recommendations may be a function of the user's profile, attributes, venue preferences, past booking behavior and/or previous feedback concerning certain venues. For instance, the recommendations may be filtered as set forth above according to the user's most recent reservations and the user's expressed preferences for given venues that are linked to potential secondary or tertiary recommendations. [0156] Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data. The system 100 may send an electronic message or alert either including a recommendation based in part on the location and/or time or prompting the user to access an interface to receive the recommendation. For instance, if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user the system 100 may generate an electronic alert to the user including the recommendation, a hyperlink to the system web portal, or a link to activate a client recommendation application that can launch an interface such as those described herein.
[0157] Alerts or recommendations may be accompanied by, and be generated based on, promotional offers related to the venues. For instance, an electronic notification may contain a recommendation along with a promotional discount offer for the related potential booking or reservation. Recommendations presented in the interface (or via electronic messages) may also be selected based in part on promotional status. That is to say, the recommendation engine may strengthen linked nodes associated with promotional offers and thus the recommendation engine may factor in promotional offers when determining nodes to recommend (i.e. those most strongly linked to nodes associated with the user or a
recommendation request).
[0158] Users' feedback concerning recommended venues and the associated "take rates" may likewise be factored in by the recommendation engine. For example, the link strengths may be increased for venues for which users more frequently make reservations based on the recommendations, consistent with the techniques taught herein.
[0159] Users may be provided a profile page or "my account" page that provides analytics on that data and any other data collected or contributed to provide perspective and insight into behavior. The page provides a feedback mechanisms to the user that is "habit honing" in that analytics on self activity is provided in a visual format. For example, the page may present graphical trends of actions within customizable goal categories such as health (gym, yoga), family (museums, travel, dining), and errands (dentist, mechanic, groceries). Based on user defined goals, the overview page suggestions can be featured to highlight relevant activities to fill existing calendar time-slots.
[0160] The interface may also provide other prompts to facilitate actions and hone habits. For example, the interface may provide cues and triggers embedded in mobile device applications to cue initiation of plans and transitions between scheduled events. For instance, the mobile client application may trigger chimes upon next scheduled event, music to reduce anxiety surrounding errands, tailored music transitions upon the occurrence of the next scheduled event, or visual (blinking LED) cues upon next scheduled events.
Bio-Visual Personalized Feedback
[0161] The user interface described above presents a plurality of recommendations to the user based on a user search query thereby allowing a user to pick various venues and/or add them to a calendar. However, based on this view, a user may not fully grasp the
interrelationships between the venues that led the recommendation engine 112 to recommend the venues in the first place. Further, as long as the recommendation engine 1 12 is providing recommendations to the user, the user may not have as much of an incentive to provide more information to the system 100 thereby enabling an enhanced neural network topology that will provide better recommendation results.
[0162] To ensure a better user understanding of the nodal links between venues within the neural network topology and to provide motivation for users to input more information into the system 100, an additional bio-visual personalized feedback interface is provided to users of the system 100. Through the bio-visual feedback user interface, the user is able to view an overall network topology of various nodes within the system 100 and the interconnections therebetween thereby allowing users to grasp the nodal link strengths and relationships between venues.
[0163] The bio-visual feedback interface is a two-dimensional interface that provides an overhead aerial "bird's eye" view of the network topology presented topographically in an easy to understand manner. For instance, at the highest level, a topographical view of the system may depict clusters of nodes in various regions with some node clusters being venues of interest to the user based on previous recommendations and/or nodal interrelationships having strong overall link values and other cluster areas may include nodes known to have low overall link scores or, in other words, nodes that would be bad recommendations to the user. To enhance the understand of the user, nodal clusters having nodes that would be strong recommendations for a user or nodes that have previously determined to have been effective to the user can be displayed in hot colors, such as red or orange, whereas other nodal clusters having poor recommendation choices can be displayed in cold colors, such as blue or purple. Nodal links may or may not be provided at this level to give the user an understanding of how various nodes are linked to each other.
[0164] The topographical view of the nodes can further be enhanced via contour mapping features. Accordingly, certain areas of the clusters which include strong nodal links therein can be presented in an "elevated" contour with a different color mapping than venues with lesser overall link strengths positioned in lower elevations. Further, nodes having antilinks with other nodes may be positioned farther apart in the aerial view and have dotted links to indicate the negative link strength therebetween. Further, nodes that do not have links to other nodes may be placed apart from the nodal clusters to represent their independence from the other nodes of the neural network.
[0165] Figure 15 illustrates an exemplary bio-visual personalized feedback user interface using a topographical contour mapping system based on a user search query for Restaurant 7. As illustrated in Figure 15, the neural network topology, or neural network "world" view 1500, includes nodes representing Restaurants 1-3, 7-11 and Restaurants X and Y.
Restaurants 1-3 and 7-11 are the same Restaurants illustrated in Figure 4 and therefore have the same venue attributes, content-based relationships, collaborative relationships and content-collaborative relationships as described above with respect to at least Figures 5-9. Accordingly, the links shown between the nodes are in accordance with the content-based venue links and collaborative venue links identified in Figures 7 and 8. Restaurants X and Y represent two venues that are not linked to any other venues within the neural network. In selected embodiments, the world view 1500 represents the "highest" aerial view the user can obtain via the bio-visual feedback user interface.
[0166] As described above, Restaurants 1-3 and 10 represent a cluster of venues having strong overall link strengths with Restaurant 7 and as such may be represented using hot colors. Restaurant 7 itself may be indicated in a neutral color to identify that it is the restaurant expressed in the search query by the user. Further, Restaurant 7 could be displayed larger than the other nodes in the topology depicted in Figure 15 to identify it as a restaurant that was part of a search query. Restaurants 8, 9 and 11 may be depicted in cold colors as they have low recommendation values based on low overall link strengths with respect to Restaurant 7. Further, as illustrated in Figure 15, the links between Restaurant 7 and
Restaurants 8, 9 and 11 are dashed as they represent anti-links having negative overall link strengths.
[0167] Figure 15 further includes elevated contour zones 1501 , 1502, 1504 and 1506. These topographical contours represent elevated nodal areas containing nodes having strong overall link strengths with a node or nodes included in a search query. Accordingly, contour zone 1501 includes Restaurant 7 and Restaurant 1 and is depicted as having the highest elevation as Restaurant 1 has strong content-based and collaborative venue link strength. Further, contour zone 1502 has a median elevation and includes Restaurant 10 which has a higher overall link strength with Restaurant 7 than Restaurants 2 and 3 but has a lower overall link strength than Restaurant 1. As Restaurants 2 and 3 have the lowest overall link strengths with Restaurant 7 when compared to Restaurant 1 and Restaurant 10, they are depicted at the lowest elevation or "ground" level. Therefore, contour zones 1501 and 1505 provide the user with an easy-to-understand view of restaurants that would be good recommendations with respect to Restaurant 7. On the hand, contour zone 1504 and 1506 represent elevations containing nodes that would be bad recommendations as contour zone 1504 and 1506 contain nodes having lower overall link strengths with respect to Restaurant 7. For instance, contour zone 1506 includes Restaurant 9 and Restaurant 1 1 which have comparable negative overall link strength values with respect to Restaurant 7 but that are elevated higher than Restaurant 8 as Restaurant 8 has a lower negative overall link strength value with respect to Restaurant 7. Accordingly, alternatively from the depiction of Restaurants 2 and 3, the lowest elevation or ground level may be depicted via a contour zone.
[0168] The system 100, as illustrated in Figure 15, can also display links to nodes in other locales. For example, in selected embodiments, the world view 1500 may include different locales such as New York and Boston. As such, link 1508 identifies a connection between Restaurant 7 of Boston and Restaurant Z of New York. The link between different locales may be represented in various manners such as a squiggly line in order to indicate to the user that the link represents a connection to a different area. Further, as the line is solid and not dashed it represents a positive overall link strength between Restaurant 7 and Restaurant Z as described above. While not shown, New York will likely have its own neural network topology with corresponding contours and internodal connections. Accordingly, the bio- visual personalized feedback user interface provides the user with the ability to quickly identify restaurants in different locales that may be strongly connected to known restaurants in the user's location. In other words, if the user is planning on traveling to New York he can "virtually travel" over transit link 1508 to determine restaurants in New York that he may want to visit based on their relationship with Restaurant 7.
[0169] To further aid the understanding of the user upon a close or cursory inspection of the bio-visual feedback user interface, the contour zones may also be colored using hot or cold colors based on overall link strength with respect to a designated restaurant. The more information the system 100 contains, the more detailed and comprehensive contour map can be provided to the user. Accordingly, by interacting with the bio-visual feedback user interface, the user is motivated to provide more information to the system in order to discover new avenues of connectability with respect to the nodes of the neural network topology. This in turn enables the system 100 to provide more accurate information to the user for future recommendation requests.
[0170] In addition to viewing network topology via the bio-visual feedback user interface, the user may interact with the nodes in order to redefine and redisplay the neural network image. For instance, world view 1500 identifies the neural network topology with respect to Restaurant 7 but the user may designate, via a mouse, speech or other input device, another node in which to view the network topology. The system 100 will then recalculate the overall link strengths as previously described herein and will redisplay the world view 1500 based on the newly designated node. Therefore, the bio-visual feedback user interface allows the user to easily grasp interconnections between a variety of different nodes and to realize an expansion of internodal links based on input provided by the user.
[0171] While Figure 15 illustrates a world view 1500 representation, the system 100 also allows the user to zoom into lower levels of "aerial coverage". Accordingly, if there are too many connections between nodes in various clusters, the user may not be able to fully grasp specific connections between specific nodes. Therefore, the user can zoom in on a particular portion of the world view 1500 to see more granular arrangements of nodes and connections therebetween. The user may zoom in by clicking a magnification button (not shown), by right clicking a specific node which pops up a dropdown menu having an option to zoom in with respect to that node, by speech, touch or any other method as would be understood by one of ordinary skill in the art.
[0172] Figure 16 represents a local view 1600 of the world view 1500 of Figure 15 based upon a command from the user to zoom in with respect to Restaurant 1. In other words, the local view 1500 illustrated in Figure 15 depicts nodal connections based on Restaurant 1. In selected embodiments, the system, whether in the world view 1500 or local view 1600, may center on the screen whichever node has been selected by the user. Figure 16 is intended to be exemplary and therefore only a handful of the connections are illustrated for the ease of explanation. Accordingly, Restaurant 1 has a variety of connections with Restaurants 2, 3, 7, 9 and 10 and the user is able to grasp a better understanding of these connections as compared with the world view 2500. For instance, different link strengths are represented by different link thicknesses and anti-links are represented by dashed lines. The user can further designate particular lines themselves and the system 100 will display the overall link strength values for that particular connection.
[0173] As illustrated in Figure 16, link 1602 connecting Restaurants 1 and 7 has the thickest line as compared to other connections as they share the same neighborhood and genre and both received highly positive reviews from Reviewer 2. Link 1606 connecting Restaurant 1 and Restaurant 2 has a small line thickness as they only share the same attire and do not share any positive review data. Link 1604 connecting Restaurant 1 and Restaurant 9 is dashed as they share a negative overall link strength due to an opposite affinity expressed by Reviewer 2. However, the link 1604 is not that thick as the overall link strength value, while negative, is close to zero.
[0174] In the local view 1600, the links may be depicted in different colors to identify which links have strong or small overall link strengths with respect to a designated node. For instance, link 1602 may appear to be bright red due to a strong overall link strength between Restaurant 7 and Restaurant 1 and link 1604 may appear blue based on a low overall link strength value between Restaurant 1 and Restaurant 9. Alternatively, the user may request link colors solely based on the designated node such that link 1606 would be assigned a "hotter" color than link 1602 because it is a direct link with Restaurant 1. Further, links having a stronger overall link strength with respect to a designated node may appear closer to the designated node than other links. For instance, Restaurant 7 is closer in proximity to Restaurant 1 than Restaurant 3 as Restaurant 3 has a lower overall link strength with
Restaurant 1 as compared to the overall link strength value between Restaurant 7 and Restaurant 1. In addition to or alternatively, other indications may be used to designate link strengths such as making nodal appearances larger than others if they have a strong overall link strength with respect to a designated node.
[0175] Therefore, both the world view 2500 depicted in Figure 25 and the local view depicted in Figure 16 provide an easy-to -understand view of the neural network topology thereby providing the user with insight into potential recommendations while also providing an incentive to present more information to the system to bolster internodal links. While the nodes illustrated in Figure 15 and Figure 16 are represented by the number of the restaurant, other depictions are contemplated such as thumbnail pictures, logos and/or names of the restaurants. Further, the system in selected embodiments may display a three-dimensional view of the neural network topology thereby giving the user a real-world impression of the internodal connections. For example, in a three-dimensional system, connections with strong overall link strengths may represent highways whereas connections with low overall links strengths may be represented as dirt roads. In addition to or alternatively, venues that are located close to each other which are thereby in "walking distance" may represent strong overall link connections as opposed to venues that appear far off in the horizon. Collaborative Decision Making
[0176] Group events can often cause problems between individuals in the group because it may be hard for everyone to come to agreement on particular topics. For instance, a group of friends that are also users of the system 100 may have plans to go out to dinner but may be unsure of which restaurant to go to or may be unable to come to an agreement with respect to a restaurant. As such, each user may have his own opinion of where the group should go based on recommendations provided by the system 100. Therefore, in addition to providing users with a variety of ways in which to view recommendation data and nodal connections between various venues, the system 100 also provides user interfaces enabling a group of users to collaboratively select venues.
[0177] Initially, the system 100 performs a group search using information provided by members of the group. Specifically, the members of the group may submit a venue choice and a list of requirements to the system 100 in which they want the search query to adhere to when determining recommended venues. As such, some members may specify the genre whereas other members may request a low price point. The recommendation engine 1 12 will then perform a search for each particular member based on their individual requests and recommendations are generated by the recommendation engine 1 12 as previously described herein such that each member has their own recommendation set.
[0178] Once the recommendation engine 112 has generated the various recommendation sets for each member of the group, the collaborative decision making user interface depicts each group member in a different row with recommendations for each corresponding member appearing in a column beneath that member. The system 100 also highlights one of the recommended venues for each member that represents the strongest overall link strength based on the venue provided by the user and the filter state input as part of the search query. The highlighted venue may be displayed in a certain color, have a varied border as compared to other recommendations, may be displayed larger than the other recommendations or may be displayed in a particular order with respect to the position of the member information.
[0179] The recommendation engine 112 will also determine, based on the information included the search queries by each member, a recommended group venue having the greatest average affinity with respect to the recommendations identified for each member. The recommendation engine may also use attribute information to prevent clashes between members of the group. For example, the system may not recommend a steakhouse as a group venue when one or more of the members of the group are known vegetarians. Further, for example, if a majority of group members dislike seafood, the recommendation engine may avoid generating a seafood restaurant as a group recommendation regardless of how close other calculations come with respect to other attributes such as price and attire. Accordingly, to generate a group recommendation, the recommendation engine 1 12 takes into account at least the nodal interrelationships between venues identified by the group members and user attribute data.
[0180] Once the recommendation engine 1 12 determines the group recommendation, the system 100 highlights the group recommendation if it already appears in the user interface and/or displays the recommended venue separately for the members of the group to see. In selected embodiments, each member of the group will have the ability to vote on the recommended venue or to select a different venue from the options listed on the display screen. The recommendation engine 112 will then continuously recalculate a recommended group venue or venues having the strongest overall affinity based on the recommendations provided by recommendation engine 112 or those voted on by the members. To prevent an endless recommendation cycle, each member may be limited to a certain number of votes and/or a time limit, such as a certain time before the planned event, may be prescribed to ensure a limited voting period.
[0181] Figure 17 illustrates an exemplary collaborative decision making user interface, or group interface. In Figure 17, Members 1-4 represent a group of users of the system 100 who are planning to meet for dinner on October 8, 2012, at 5:00 PM. In selected embodiments, one user may setup the meeting time of an event and can send invites to other users of the system 100. If these users accept the invite, the system 100 will indicate that they are part of a group. Once the group is formed, the users may each provide a venue and other filter parameters to have the recommendation engine 112 provide a recommendation set for each user. In other embodiments, the recommendation set of a founder of the group may hold more weight or may be the only recommendation set provided to the group members.
[0182] Once the recommendations have been determined by the recommendation engine 112 for each user, the system 100 displays these recommendations as illustrated in Figure 17 such that each user is shown along with their corresponding recommendations. Within each column containing the recommendation set for each user, a recommended venue (1706, 1708, 1710 and 1714) having the strongest overall link strength with a venue provided by the user as part of the search query is highlighted. Some users may have more recommended venues in their recommendation set based on the development of the neural network with respect to the particulars of the search query made by that user. For example, Member 4 only was provided three recommendations by the recommendation engine 112. Once the individual recommendations are generated, the system 100 then calculates a group recommendation having the greatest average affinity based on the recommendations identified by the recommendation engine 112 and presents the venue as a current group recommendation 1700. The previous group recommendation 1702 may also be provided to illustrate to the members of the group that the venue has changed.
[0183] The collaborative user interface also identifies the last time at which the group recommendation was changed as well as the last vote for a venue and who placed that vote. Further, a deadline for submitted votes can be set by the group founder and/or voted upon by group members and is displayed to inform group members of the last time at which a vote may be cast. Accordingly, as the meeting time is set to 5:00 PM on October 8, 2012, the group members must submit their final votes, if any, by October 8, 2012, at 12:00 PM. As such, the initial group recommendation is dynamic and can change up to the deadline by receiving different votes and recalculating the group recommendation based on overall link strengths and user attribute data with respect to the newly voted venue and previously identified venues for particular group members. In other selected embodiments, the group founder may prevent voting thereby locking the group recommendation calculated by the system 100.
[0184] In the exemplary user interface illustrated in Figure 17, the system 100 calculated Restaurant 7 as being the best group recommendation 1700 based on the individual recommendations generated for each user by the recommendation engine 1 12.
Recommendation 1704 is highlighted to indicate that Member 4 changed his choice for a venue from Restaurant 1 to Restaurant 1 1 by voting for Restaurant 11. This change may have been made from the original recommendation made by the system 100 or a from a previous vote cast by Member 4. For the purposes of this example, it is assumed that the recommendation engine 112 originally generated Recommendation 1704 and based on this recommendation in conjunction with the Recommendations 1706, 1708 and 1710 for
Members 1-3, the system 100 originally generated the group recommendation 1702 of
Restaurant 4. However, as explained further below, the recommendation engine 112 recalculated a group recommendation of Restaurant 7 based upon the vote for
recommendation 1714 by Member 4. In other selected embodiments, recommended venues other than those highlighted within the user interface are used by the system 100 to calculate a group recommendation 1700.
[0185] Group recommendations are based, in part, on recommended venue attributes such as those illustrated in Figure 4. For instance, Recommendations 1706 and 1708 have the same genre but have different price points than Recommendation 1710 and Recommendation 1704 with Restaurant 7 being expensive and Restaurants 1 and 12 being inexpensive. However, as Recommendations 1710 and 1704 have different genres, the Japanese genre of
Recommendations 1706 and 1708 is the dominant genre. Accordingly, as the predominant genre was Japanese but the price points were opposite, the system 100 originally generated the group recommendation 1702 of Restaurant 4 having the same Japanese genre but a medium price point. However, when Member 4 decided to vote for Recommendation 1714, the system 100 recalculated the group recommendation and recommended the current group recommendation 1700 of Restaurant 7. For instance, Recommendation 1714 has a high price point and therefore only one recommendation, Recommendation 12, has a low price point. Further, as Recommendation 1710 and Recommendation 1714 have different genres, the Japanese genre of Recommendations 1706 and 1708 is still predominate. Accordingly, the system calculated Restaurant 7 as the group recommendation as it has the predominate genre and a high price point. Of course, these examples are for the sake of illustration and user attributes, other venue attributes, and link strengths based on the neural network topology between the various recommendations can all be used by the system 100 to calculate a group recommendation 1700.
[0186] The collaborative user interface illustrated in Figure 17 is exemplary and as such can be displayed in a variety of ways. Members of a group may be listed in columns with corresponding recommendations being listed in rows adjacent to the group members.
Members may customize images representing their virtual user identity within the system 100. Thumbnail images, logos, or videos may be used in addition to or alternatively to the textual display of the restaurant in the recommendation slots. The strongest recommendations, such as 1706, 1708, 1710 and 1714 illustrated in Figure 17, may be highlighted, may appear larger than other recommendations, and/or may contain animations or audio representations of the recommended venue itself. Further, video streams of group members themselves may be depicted in the collaborative user interface via an imaging device to virtually interact with each other when determining meeting times, discussing group recommendations, or taking votes. Further, a group member may vote on recommendations listed for the group member or any other group member as well as for venues not illustrated in the collaborative user interface.
[0187] The collaborative user interface illustrated in Figure 17 thereby presents users with the option of having the system 100 generate a group recommendation when members are having a hard time determining a venue amongst themselves. The group recommendations further provide the user with the comfort of knowing that the group recommendation is not only based on strong links to the interests of the user but also to other members of the group thereby increasing the likelihood of a speedy resolution when determining venues amongst large groups. Further, in selected embodiments, the system 100 may incorporate votes may by users into the data repository 1 18 such that the system 100 may further update the neural network topology and enhance future recommendations. Additionally, the system 100 may in real time repopulate the recommendations within the collaborative user interface based on updated nodal links between venues with respect to votes cast by one member or other group members.
[0188] The interfaces described herein may be presented, as noted, through a variety of devices. Still additional devices are contemplated, including television screens, third party websites (through partnerships), in-store kiosks, or personal keychains or dongles.
Error Correction and Data Verification
[0189] In selected embodiments, the recommendation engine 1 12 generates
recommendations for venues based on a variety of information such as user data, venue data and reviewer data. More specifically, the user data, venue data and reviewer data are combined as previously described herein to form link matrices the strength of which can be used to generate the recommendations for the user. However, while recommendations based on link strengths between nodes of the neural network provide a strong gauge as to the accuracy of the generated recommendations, it is possible that nodal link values can "trick" the recommendation engine 112 into generating an outlying recommendation for the user. For instance, a neural net configuration having nodal link strengths strongly geared to specific data such as venue attire, genre and price as well as reviewer data positively identifying venues having these traits may recommend a venue in a neighborhood that is quite different from the neighborhood where the user normally eats dinner. The system 100 may also strongly link user attribute data such as work hours and profession to venues having corresponding business hours and attire such that the recommendation engine 1 12
recommends an exorbitant venue that is drastically outside the price range of venues the user typically frequents based on past recommendations. Therefore, while the recommendation engine 1 12 will typically generate a recommendation set having a plurality of accurate recommendations, it is possible due to particular nodal links that the recommendation engine 1 12 may generate an outlying recommendation that does not "resonate" with the previous recommendations served to the user. [0190] Referring back to Figures 3-8, an illustrative example of this effect is provided wherein the recommendation engine 112 generates a recommendation for a venue that is in a neighborhood the user does not typically visit or typically receive recommendations to visit. Referring, for the purposes of this example, solely to the affinity expressed by Reviewer 7, there is a +0.75 collaborative-based link formed between Restaurant 7 and Restaurant 11. Further, based on the venue attributes themselves, there is a +0.25 rating as both Restaurant 7 and Restaurant 11 have the same attire. Additional ratings could be added therebetween as described previously based on similar hours and the fact that the price points of the
Restaurant 7 and Restaurant 1 1 are similar. Therefore, the nodal link strength between Restaurant 7 and Restaurant 11 would be quite strong upon the formation of link matrices by the Matrix Builder 126 such that the recommendation engine 1 12 may generate a
recommendation for Restaurant 7 in response to receiving a query of Restaurant 1 1 by the user via the user interface. However, assuming for the purposes of this example that previous recommendations to this user were typically in neighborhood 02196 and/or rarely, if ever, involved Japanese food, the recommendation engine 1 12 would be providing a
recommendation of Restaurant 7 that clearly does not resonate with recommendations previously made to the user.
[0191] To prevent the risk of an erroneous recommendation, one exemplary embodiment of the system 100 provides processing for error correction and data verification via the recommendation engine 1 12. Through this improved processing, the recommendation engine 1 12 can provide recommendations that correlate strongly to the content-based, collaborative- based and content-collaborative based interrelationships and that resonate with the plurality of recommendations that were previously made to the user. Accordingly, the error correction and data verification acts as a guardian against recommendations that, although based on strong nodal links of the neural network topology, do not resonate with recommendations that were previously served to the user and acted upon by the user.
[0192] The error correction and data verification processing begins, in one embodiment by storing in the data repository 118 recommendations data that was previously generated by the recommendation engine 1 12 and served to the user. The system 100 may designate a minimum number of recommendations that have to be stored before error correction and data verification processing is implemented but may also impose limits on the number of stored recommendations based on storage capacity and processing considerations. The
recommendations data stored in the data repository 118 can in selected embodiments store not only the recommended venue itself but also the user data, venue data and review data that was considered most pertinent to the recommendations generated by the recommendation engine 112. Therefore, the data repository 1 18 can store a recommended venue in relation to the data values ascribed with the recommended venue itself such as genre, hours of operation, attire, neighborhood and any other value described herein or as would be understood by one of ordinary skill in the art. The data repository 1 18 can also store any other data strongly relied upon by the recommendation engine 1 12 when generating the recommendation such as reviewer information, content-based link values, collaborative-based link values and user attribute data such as age, education and profession.
[0193] Figure 18 illustrates an exemplary data repository 1 18 storing previous
recommendation data for Users 2, User 4 and User 7. This example is of course non-limiting as the data repository can contain more entries as well as different types of recommendation data previously described herein and as would be recognized by one of ordinary skill in the art. Further, although the recommendation engine 1 12 can provide a recommendation set to the user consisting of a plurality of recommended venues, it is assumed for he purposes of the examples provided by Figure 18 that each recommendation set provided to each user contained only one item of recommendation data. As it may be difficult to detect
recommendation resonate outliers with a limited amount of prior recommendations, the system 100 in selected embodiments can set a minimum number of recommendation data that is required for each user before the recommendation data can be relied upon for performing error correction and data verification processing. Therefore, the system 100 may not perform error correction and data verification processing until a predetermined threshold quantity of recommendation data has been stored in the data repository 118 for the particular user. This predetermined number relating to initiation of error correction and data verification processing may be manually set by the user via the user interface or automatically set by the system 100.
[0194] In Figure 18, each user is stored in relation with recommendation data that has been previously recommended by the recommendation engine 1 12. For example, the first recommended venue for User 2 contained data such as a price point value of 3, an Italian genre, casual dress attire requirements and location neighborhood 02196 data. Further, the recommendation data stores the reviewers that reviewed the recommended venue (Restaurant 2) and user attribute information such as the age at which the recommendation was made and the number of children the user had at the time the recommendation was made. Therefore, the recommendation data stores values that will change over time such as the number of children and the age of the reviewer and user. Although not illustrated, it is further expected that venue attributes values such as the price point value and neighborhood and reviewer affinity ratings may change over time.
[0195] Figure 19 illustrates an example of aggregate repository recommendation data stored in the data repository 118 according to selected embodiments that is generated based on the data repository of previous recommendations illustrated in Figure 18. In one embodiment, the system 100 collates the recommendation data for each user to determine statistical values for each item of information stored in the data repository 1 18 relating to previous
recommendations. For example, it can be seen that User 2 has received three
recommendations all of which were Italian Venues. Further, the aggregate data indicates that the recommended venues to User 2 were often at the lower price point range as User 2 received two recommendations at a price point of three and one recommendation at a price point value of two. Further, Figure 18 illustrates that User 2 has always received
recommendations for neighborhood 02196. Therefore, as discussed previously and explained further below, a recommendation set for User 2 including venues having high price points and/or venues in a neighborhood outside of 02196 may not resonate with the aggregate data stored in the data repository 1 18.
[0196] The system 100 can determine the aggregate recommendation data based on the previous recommendations stored in the data repository 118 in real time when making a recommendation and performing error correction and data verification. In other selected embodiments, the system 100 can aggregate the previous recommendations at a time when the system 100 is experiencing a lower than normal processing load and store the aggregate data as illustrated in Figure 19. Accordingly, the system 100 has the option of determining the latest aggregate information by aggregating the data at the time of performing error correction and data verification processing or can lower the processing load required for error correction and data processing by aggregating the stored recommendation data at periodic or predetermined intervals.
[0197] Whether the aggregated data is collated simultaneously with the issuance of a recommendation or at a previous time, the stored recommendations can be aggregated in a variety of ways. For example, in one embodiment, the system 100 determines a
quantification value for each attribute of the recommendation data which can then be used in the error correction and data verification processing. An illustration of this methodology is shown in Figure 19 wherein quantification values for the price of the various venues previously recommended to User 2 are stored separately such that a price point of "3" was provided twice by the recommendation engine 1 12 and a price point of "2" was provided only once by the recommendation engine 112. As the data collected from venues, reviewers and users is likely to change over time, the aggregated data can also be collated based on running averages. Figure 19 provides an example of this type of collation wherein the ages of the reviewer has changed based on the time at which previous recommendations have been made and therefore an average age value is provided in the aggregate data. The
recommendation engine 112 may also limit the error correction and data verification processing to a certain number of recommendations to prevent out-of-date data from affecting resonate recommendation computations. As such, in selected embodiments, the data repository 1 18 can store a time stamp with each data recommendation entry such that the recommendation engine 1 12 can implement temporal filter values when performing error correction and data verification.
[0198] The system 100 can therefore adapt over time to the changing affinities of users and reviewers alike. For example, recommendations to a long-time system 100 user may have originally all been tailored to venues at a low price point with casual attire whereas the user is now older and mostly frequents venues at a higher price point with formal attire. However, the introduction of children into the user's lifestyle may then shift recommendations back to a lower price point. Reviewer ratings will most likely also change over time and therefore the recommendation engine 1 12 can reflect only the most recent and accurate ratings when performing error correction and data verification.
[0199] The previous recommendation data illustrated in Figure 18 and Figure 19 may also be weighted based on affinities explicitly expressed by a user such that the recommendation engine 1 12 provides more emphasis on specific attributes of data when performing error correction and data verification. For example, User 4 may indicate via the user interface that he prefers Japanese and Italian venues and venues in the neighborhood 02163. Therefore, when the recommendation engine 1 12 performs error correction and data verification it will determine whether the current recommendation resonates with the various aggregated datum of previous recommendation data but will also place particular emphasis on verifying that the current recommendation resonates with User 4's affinity for Japanese and Italian venues as well as venues in the neighborhood 02163. It is likely that the recommendations will already be tailored somewhat towards these feature sets based on the nodal links formed by the matrix builder 126 based on user-expressed affinity but the error correction and data verification processing provides an extra filter of protection to ensure a more accurate recommendation to the user. [0200] Weights may also be provided to the aggregate data of previous recommendations based on the "primary" nodal link strengths of the neural network used by the
recommendation engine 1 12 to generate the previous recommendations. For example, based on content-based interrelationships, collaborative-based interrelationships, content- collaborative interrelationships, and higher-order interrelationships, the recommendation engine 112 may generate a recommendation primarily based on genre data and neighborhood data. Figure 18 provides an illustrative example wherein all of the previous
recommendations to the User 2 have been for an Italian venue within the neighborhood 02196. Therefore, the recommendation engine 1 12 may attach weights to these values such that they provide more influence on resonation calculations via the error correction and data verification processing as described above.
[0201] Figure 20 is a flow chart illustrating error correction and data verification processing according to one embodiment. The process is initiated at S2000 with the recommendation engine 1 12 determining a recommendation set based on the neural network methodology described above. Processing then proceeds to S2002 to perform a comparison of the current recommendation data generated by the recommendation engine 1 12 with the aggregate recommendation data stored in the data repository 118. Although not illustrated in Figure 20 but as previously discussed, the recommendation engine 112 can determine whether to initiate error correction and data verification based on the number of recommendations for a particular querying user that are stored in the data repository 1 18.
[0202] Assuming the recommendation engine 1 12 has access to the requisite amount of aggregate recommendation data, the recommendation engine 1 12 compares the current recommendation to the aggregate recommendation data stored in the data repository 118. In one embodiment, the recommendation engine 1 12 systematically compares each attribute included in the current recommendation data to each corresponding aggregated quantification value of each attribute to determine a resonate value for that attribute. Once each resonance value is determined for each of the attributes corresponding to those contained in the current recommendation, a resonance quantifier is determined based on the plurality of resonance values. If the resonance quantifier is less than a predetermined threshold, then the recommendation engine 1 12 determines that the current recommendation does not "resonate" with previous recommendations at S2004. Accordingly, at S2004, if the resonant quantifier is greater than a predetermined threshold, the recommendation engine 112 confirms that the current recommendation "resonates" with previous recommendations. [0203] If the recommendation engine 112 determines at S2004 that the resonance quantifier does not exceed the predetermined threshold and therefore that the current recommendation does not resonate with previous recommendations to the user, the recommendation engine 1 12 identifies the deficiencies in the current recommendation such that the matrix builder 126 can back propagate these deficiencies into the neural network to establish increased accuracy within the nodal links. For example, with reference to Figure 18 and Figure 19, if the recommendation engine generated a recommendation for a venue in a neighborhood outside 02196, the error correction and data verification processing may indicate this
recommendation as an outlier based on previous recommendations for User 2 that were all within the neighborhood 02196. Accordingly, at S2012, the neural network is updated such that a negative link value is ascribed to the neighborhood identified in the recommendation with respect to the nodal links established for User 2. Alternatively, or in addition, the matrix builder 126 may ascribe an additional positive link value to the neighborhood 02196 to further ensure that neighborhood 02196 is given increased link strength thereby ensuring increased consideration in any future recommendations provided by the recommendation engine 112. Accordingly, the error correction and data verification processing not only provides an additional filter for accurate recommendations but also acts as a vehicle for driving increased accuracy within the nodal links of the neural network itself. After updating the neural network at S2012, the processing proceeds back to S2000 for the recommendation engine 112 to generate a new recommendation for the user based up the updated neural network.
[0204] Referring back to Figure 20, once it is determined that the current recommendation resonates with previous recommendations at S2004, the current recommendation is provided to the user at S2006 and the data repository 1 18 is updated to include an entry for the current recommendation. As noted above, this entry may include a time stamp indicating the time and date at which the recommendation data was entered into the data repository 1 18.
[0205] After updating the data repository 1 18 with the current recommendation, processing proceeds to updating the neural net nodal links at S2010. As the system 100 has determined that the recommendation data generated by the recommendation engine 1 12 resonates with previous recommendations, the matrix builder 126 may update the nodal link strengths of the neural network based on data included in the recommendation data. For example, if the recommendation data for User 2 includes casual attire for the recommended venue, the matrix builder 126 may even out the nodal link strengths with respect to this attribute as User 2 has now been recommended the same amount of venues for both casual and formal attire. Further, this recommendation data "approved" by the error correction and data verification processing may be applied more weight when updating the neural network than
recommendation data that was created before error correction and data verification processing was initiated by the recommendation engine 1 12 as it has confirmed resonance with previous recommendations and is therefore more likely to be accurate.
[0206] Further, in addition to the methods of refining the neural network based on the effectiveness of recommendations as determined by the system 100, a recommendation that is approved by the error correction and data verification processing may also be identified as a recommendation that has been determined to be effective based on the resiliency of the aggregate previous recommendation data. Further, in selected embodiments, when the system 100 determines the effectiveness of the recommendation data as describe herein based on financial data, feedback data, web browsing data, geographic data or the like, the system 100 may store this recommendation data in the data repository 1 18 with a special label such that the recommendation engine 112 applies more weight to this information when performing error correction and data verification processing. For example, in referring to Figure 18, if the system 100 determines the effectiveness of recommendation #2 by receiving financial information that User 2 visited the venue, by receiving user feedback from User 2 that he liked the venue, by determining that User 2 spends a lot of time on the venue website, or by determining that User 2 spends a lot of time in a geographic location proximate to the recommended venue, the system 100 may apply a "validation" label to this recommendation data in the data repository 1 18. In doing so, if the recommendation engine 1 12 is using only a predetermined number of previous recommendations, the recommendation engine 1 12 can improve error correction and data verification accuracy by using only "validated" previous recommendations. In other embodiments and if the recommendation engine 1 12 is using more previous recommendations than currently available validated previous
recommendations, the recommendation engine 112 may apply special weight to the validated previous recommendations such that the error correction and data verification processing generates a resonance quantifier that is more strongly influenced by previously validated recommendations .
[0207] While error correction and data verification provides enhanced accuracy with respect to recommendations to the user, the system 100 must be constantly vigilant with respect to the changing attributes within the recommendation data, particularly the user attribute data. For example, if the user moves to a different part of the country then the matrix builder 126 will update the neural network accordingly thereby lowering the strength of links identifying venues in neighborhoods that are no longer in proximity to the user. Therefore, the nodal link strengths will be reflected in a new recommendation such that any recommendation by the recommendation engine 1 12 will be in neighborhoods in close proximity to the user's new location. However, when comparing a new recommendation to this user, the
recommendation engine 112 may identify this recommendation as an outlier as all previous recommendations were in neighbors geographically distant from the user's new location. Accordingly, the recommendation engine 1 12 may assign a label on the neighborhood attribute data within the data repository 118 of previous recommendations thereby identifying certain values of this attribute as data which should not be used when performing error correction and data verification. Therefore, the system 100 provides adaptive functionality to limit error correction and data verification processing to attributes that will not induce the recommendation engine 1 12 to provide erroneous results.
[0208] Another method for providing enhanced recommendations via error correction and data verification is to dynamically ensure resonance between information, such as review data, from various source sites that are used during harvesting operations. For example, the harvesting of data to create the neural network as previously described herein obtains information from a variety of sources such as web sites. However, as web sites are constantly changing, as well as user review data and venue data contained therein, the system 100 may not always have an up-to-date capture of information. As described previously, the system 100 periodically updates the neural network based on information gathered from source sites. However, the user may perform a search query at a time before an update but after information from the source sites has changed. Accordingly, nodal link strengths of the neural network topology, while providing a strong representation of links between different venues, may not be optimized as they were determined based on information that was "out of date". Therefore, error correction and data verification further provides the ability to dynamically determine resonance between information contained within the data repository 118 and information obtained from source sites as well as between information from different source sites.
[0209] Specifically, in selected embodiments, the recommendation engine 112 will, just prior to generating a recommendation set, dynamically harvest data items from multiple source sites, such as web sites across the Internet, and resolve any differences between these data items. For example, venue data items from a majority of web sites relating to Restaurant 1 of Figure 4 may include information identifying Restaurant 1 as low cost and casual.
However, it is possible that other websites may mistakenly indicate Restaurant 1 as expensive and requiring formal attire. Therefore, the recommendation engine 1 12 can resolve these differences by indicating certain web sites as containing inaccurate information with respect to a venue. Once the outlying information is obtained, the neural network is dynamically updated as previously described herein while excluding the outlying information thereby allowing the recommendation engine 1 12 to provide a more accurate recommendation set based on new overall link strengths of the updated network topology.
[0210] In selected embodiments, a sliding scale resonance threshold may be applied to determine at what point information can be deemed accurate as opposed to outlying with respect to other harvested information. For example, the scale may be set by the system 100 or a user such that 75% of the information harvested must conform in order to determine that information not conforming with information in the 75th percentile is outlying information. The system 100 may further adjust the threshold based on the amount of web sites containing information about a certain venue. For example, the more information with respect to the same data items that the system 100 can obtain during harvesting operations, the higher the threshold may be set as there is a large data set from which to draw accurate information. Accordingly, if the system 100 harvests information from 100 sites of which 65 indicate Restaurant 1 as low cost and casual and 45 indicate that Restaurant 1 is expensive and formal, the system 100 may determine that the 45 web sites indicating Restaurant 1 as expensive and formal are outliers and will not take their information into account when updating the neural network. However, if the system 100 harvests information from 1000 sites of which 650 indicate Restaurant 1 as low cost and casual and 450 indicate Restaurant 1 as expensive and formal, the system 100 may not identify the 450 items of Restaurant 1 venue information as outlying information as there is a larger data set of which 65% is not a high enough resonance threshold. In this instance, the system 100 may opt to use the information contained within the 650 web sites but provide a negative weighting to this information so that it does not have too much of an effect upon an update of the neural network topology. Alternatively, the system 100 may ignore all of the information and determine that it cannot be resolved and therefore that none of it should be used to update the neural network topology.
[0211] Once error correction and data verification has been dynamically performed at the time of a user query, the neural network topology is updated and the recommendation engine 1 12 provides a recommendation set based on a current real-time snapshot of information contained within the Internet. Accordingly, information provided to the users is as accurate as possible with respect to information harvested from the Internet. Further, this allows the system 100 to determine "trendiness" data among web sites such as certain attribute data which is likely to change rapidly. This provides the system 100 with the ability to identify various types of fickle data and provide appropriate weights when calculating nodal links strengths within the neural network so that the user receives recommendation sets based on the most stable and accurate information harvested by the system 100.
Geometric Contextualization
[0212] As discussed above, error correction and data verification provides the system 100 with a way to avoid outlying recommendations as well as a way to monitor venue, reviewer and user attributes that change over time. However, in addition to these gradual characteristic changes over time, users are often inclined to change their interests spontaneously to try something new or simply to see what options the system 100 may produce in response to queries containing a variety of user filters. For example, the user may express an affinity for a particular venue but may want to further limit the search to venues that have particular hours, attire and neighborhood requirements. Accordingly, in selected embodiments, the recommendation engine 1 12 must generate a plurality of recommendation data having venues with the strongest link strength to the venue provided by the user but which are also limited to the hour, attire and neighborhood requirements. Of course, the more filters the user provides with a search query, the harder it is for the recommendation engine 1 12 to generate a good recommendation that meets all of the requirements of a user. For example, if a user queries the system 100 for recommendations within the state of Massachusetts, the recommendation engine 1 12 may not recommend certain venues from Salisbury, MA based on weak nodal link strengths even though they are located in the state of Massachusetts. As such, in selected embodiments, the recommendation engine 1 12 determines a plurality of venue recommendations based on nodal link strengths and then compares the nodal link strength of each recommendation to a recommendation threshold to determine whether or not the venue should be recommended to the user. The recommendation threshold indicates a watershed overall link strength value or in other selected embodiments a percentage identifying the number of recommendations that will be recommended by the
recommendation engine 1 12 to the user out of the recommendation set. Accordingly, for example, if in response to a particular user query the recommendation engine 1 12 generates ten venues based on the above-described data interrelationships, the recommendation engine 112 may only serve recommended venues having nodal link strengths exceeding the recommendation threshold such that only 3 out of the 10 recommended venues are served to the user. [0213] However, if the user then performs the same query but limits the geographic limitations of the search to Salisbury, Massachusetts, or a neighborhood of Salisbury, MA, and the recommendation engine 1 12 only determines a few recommended venues based on the nodal link strengths, the recommendation engine 1 12 may not recommend any venues if none of the nodal link strengths are greater than the recommendation threshold. In this instance, the user would be served with a useless empty recommendation set thereby lowering user confidence in the system and increasing the likelihood the user will turn to other systems for information.
[0214] Figure 21 A illustrates an exemplary search according to the above-noted principles by describing the outputs of the recommendation engine 1 12 based on a query for a recommendation for an American restaurant with casual attire and a user affinity for
Restaurant 5. Based on this query, the recommendation engine 1 12 determines the venues having the strongest nodal link strength to Restaurant 5 while also limiting the
recommendation set having these strong nodal link strengths solely to American restaurants with casual attire. This example is limited to two restaurants based on the data set illustrated in Figure 4, but it is assumed that other restaurants may exist which are listed as Restaurants X. For the foregoing examples, the value X may represent a small number of restaurants or a large number of restaurants. In this example, as with Figure 9, the recommendation is a blending of at least the content-based link strength 2100, collaborative link strength 2104 and content-collaborative link strength 2108. Each link strength is assigned a distinct weighting factor 2102, 2106 and 21 10. By referring to Figures 4, 7, and 8, Figure 21 A provides respective values for content-based link strength 2100, collaborative link strength 2104 and content-collaborative link strength 2108. As Restaurant 3 has no content-based
interrelationships or collaborative interrelationships with Restaurant 5, the content-based link strength 2100 and collaborative link strength 2104 is zero. The content-collaborative link strength 2108 is exemplary as are the weighting factors 2102, 2106 and 21 10. Based on a first order sum of products, the overall link strength for Restaurant 3 is 0.075. Restaurant 6 has the same attire as Restaurant 5 and therefore has a content-based link strength 2100 value of 0.25 but has a negative collaborative link strength 2104 value of -1.0 based on a strongly opposite affinity expressed by Reviewer 3. As with Restaurant 3, the content-collaborative link strength 2108 of Restaurant 6 is exemplary as are the weighting factors 2102, 2106 and 21 10. Accordingly, in this example, a first order sum of products produces and overall link strength 21 12 value of -0.1875. For the other Restaurant(s) X, values of A-F are assigned, respectively, for content-based link strength, collaborative link strength, content-collaborative link strength and their corresponding weighting factors. Further, Restaurant(s) X have an overall link strength of G.
[0215] As illustrated in Figure 21 A and described above, the result of the above-noted query is Restaurant 3, Restaurant 6 and Restaurant(s) X. Therefore, assuming X represents a small number of restaurants having an overall link strength less than Restaurant 3 and Restaurant 6, and based on the filter state implemented by the user via the user interface at the time of the query for recommended venues, the recommendation data set for this filter state is very small. Further, the overall link strengths of Restaurant 3 and Restaurant 6 are low enough that the recommendation engine 1 12 may not recommend them to the user if they do not pass the recommendation threshold. For example, if the recommendation threshold is set at a value of 0.25, neither Restaurant 3 or Restaurant 6 would be recommended by the recommendation engine 1 12 and an empty recommendation set would be provided to the user. Accordingly, as noted above, while the recommendation threshold is effective for reducing a large recommendation data set, it can also act as a barrier for passage of all recommendations when the recommendation set is extremely small and/or has small overall link strength values therein. Therefore, the system 100 must provide a way to avoid serving empty
recommendation sets to users when the search returns a limited recommendation set having low overall link strength values. In other words, the system 100 must balance the need to provide information to the user while also considering the value or relevance of the information being presented to the user such that user does not lose interest or confidence in the system 100.
[0216] Geometric contextualization is a mechanism for overcoming the problem of limited recommendation sets by ensuring that at least one recommendation is always provided to the user via the recommendation engine 1 12. One method of performing geometric
contextualization is to adjust the overall link strength values of the recommendation set generated by the recommendation engine 1 12 until at least one of the recommended venues exceeds the recommendation threshold. The recommended venues exceeding the
recommendation threshold can then be served to the user or a predefined percentage of recommendations out of the recommendation set that have had their overall link strengths adjusted are served to the user. In this embodiment, the overall link strength values of each recommendation are normalized using a normalization factor that is based on various factors until the overall link strength value of at least one recommended venue exceeds the recommendation threshold. Accordingly, in selected embodiments, geometric
contextualization is performed every time a recommendation a set is generated by the recommendation engine 1 12 to further redefine recommendation rankings based on a variety of factors to enhance the accuracy of the percentage of recommendations served to the user.
[0217] One factor that can be used to generate the normalization factor for normalizing the recommendation set is the number of potential recommendations available based on the filter state set by the user at the time of performing the query. For example, if there is a large number of recommendations available based on the filter set and the only issue is that none of the recommendations of the set exceed the recommendation threshold, a minimal
normalization factor may be utilized to normalize the recommendation set such that a limited amount of recommendations exceed the recommendation threshold. Therefore, the recommendation engine 1 12 may generate a normalization factor to ensure that a
predetermined number of recommended venues exceed the recommendation threshold. This ensures that the recommendation engine 1 12 can serve the user with at least one
recommendation but increases the chance that the recommendations provided are the "best" recommendations out of the group based on the overall link strength values. In other words, by having the recommendation engine 112 perform geometric contextualization with a low normalization factor for a large recommendation set, only the recommendation values with the largest overall link strength will be provided to the user. If the recommendation set is smaller in size, the recommendation engine 1 12 may need to generate a drastically different normalization factor to ensure that at least one recommended venue will be normalized to a value exceeding the recommendation threshold based on the nodal link strengths of the smaller set of recommended venues.
[0218] In selected embodiments for performing geometric contextualization based on the number of recommendations available in the filter state, the normalization factor value itself can be set by the recommendation engine 1 12 based on specific calculations with respect to the recommendation set. For example, the recommendation engine 1 12 can analyze the recommendation data set and determine a normalization factor that will ensure that the overall link strength of at least one recommended venue exceeds the recommendation threshold. Further, the system 100 or the user via the user interface may set a specified number of recommendations to receive for each query. Therefore, the recommendation engine 1 12 may calculate a normalization factor that will ensure the overall link strengths of the specified number of recommended venues exceeds the recommendation threshold to ensure the user receives the requisite number of recommendations.
[0219] In addition or alternatively, the recommendation engine 1 12 may set the
normalization factor based on user statistics known to the system 100 relating to venue attributes, user attributes, reviewer attributes, ordered relationships, content-based interrelationships, collaborative based interrelationships and/or content-collaborative interrelationships. These statistics are determined as described above with respect to determining the effectiveness of recommendations. For example, if past recommendations of the user indicate that recommendations based on content-based link strength are more effective than recommendations based on collaborative links strength, the recommendation engine 112 may calculate a normalization factor that ensures at least one recommendation having strong content-based link strength is elevated past the recommendation threshold even if other recommendations having higher overall link strengths exist in the recommendation set. In this instance, the recommendation engine 1 12 may apply the normalization factor only to those venues in the recommendation set that have a requisite level of content-based link strength. Of course, this method may be applied based on collaborative link strength, content-collaborative link strength and/or higher order interrelationships. This provides the system 100 with the ability to elevate those recommendations that have a lower overall link strength but that may prove more effective for the user based on previous user statistics. This enhances the users overall experience with the system 100 and provides enhanced data for merchant vendors.
[0220] An example of geometric contextualization using a normalization factor based on the number of potential recommendations is illustrated in Figure 21B with reference to Figure 21 A. In this example, it is assumed that the recommendation engine 1 12 has generated Restaurants 3, 6 and Restaurant XI in response to the user query identified for Figure 21 A. In this example, assuming a recommendation threshold of 0.25 and an overall link strength value G that is less than 0.25 for Restaurant XI , none of the overall link strengths 21 12 exceed the recommendation threshold. Accordingly, the system 100 determines that the recommendation engine 1 12 needs to perform geometric contextualization on the
recommendation data. When performing geometric contextualization, the recommendation engine 1 12 determines that there is a small number of recommendations (3) available and therefore an adequate normalization factor must be calculated to ensure that at least one of the recommended venues exceeds the recommendation threshold once the process of geometric contextualization is finished. Accordingly, assuming a user specified or system 100 specified recommendation limit of two, the recommendation engine 1 12 must calculate a normalization factor such that two of the overall link strengths are elevated above the 0.25 recommendation threshold. Accordingly, a normalization factor of +0.175 is added to the overall link strength 21 12 value of each venue in the recommendation set. Figure 2 IB illustrates the effects of geometric contextualization on the recommendation data illustrated in Figure 21 A as discussed. In Figure 2 IB, due to the effects of normalization, both
Restaurant 3 and a Restaurant XI out of the set of recommended venues have the requisite overall link strength of at least 0.25 to ensure they are higher than the recommendation threshold and can therefore be served to the user via the user interface.
[0221] However, in other selected embodiments and as previously discussed, if the system 100 determines statistically that content-based interrelationships have often proven to be the most successful factor in determining the effectiveness of the recommendation, the recommendation engine 1 12 may generate a normalization factor specific to venues having the highest content-based link strength thereby providing extra emphasis to the overall link strength of Restaurant 6 with respect to the predetermined threshold. Standard normalization factors may then be applied to the remaining venues in the recommendation set. Therefore, if a strong enough normalization factor is applied specifically to Restaurant 6, Restaurant 6 may exceed the recommendation threshold upon completion of geometric contextualization.
However, as Restaurant 6 has such a low overall link strength with respect to Restaurant 3 and Restaurant XI, the recommendation engine 1 12 may determine a normalization factor such that Restaurant 6 still does not exceed the recommendation threshold despite the previous user statistics with respect to the content-based interrelationships. Therefore, the recommendation engine can perform geometric contextualization to avoid empty
recommendation sets while taking into account previous user statistics and balancing them against overall link strengths determined from the nodal links of the neural network.
[0222] Further, if, for example, the system 100 contains data strongly correlating a low venue price point to the effectiveness of the recommendation, the recommendation engine 1 12 may only perform geometric contextualization on recommendations having lower price points thereby elevating recommendations strongly relating to user-specific characteristics. Therefore, although not shown in Figure 2 IB, the recommendation engine 1 12 may only perform geometric contextualization on Restaurant 6 as it has a low price point with respect to Restaurant 3. Accordingly, in this example, even with a negative overall link strength, Restaurant 6 may be elevated above the recommendation threshold such that the user receives a recommendation tailored to his characteristics.
[0223] The recommendation engine 112 may also perform geometric contextualization based on the aggregate or individual quality of the recommendation data identified in the recommendation set. The quality of the recommendations in the recommendation set can also be determined based no the overall link strength between the recommended venues and venues identified by the user in a search query. Further, in selected embodiments, the quality of the recommendation data is determined by identifying the effectiveness of the
recommendation based on previous recommendation stored in the data repository 1 18. As described above, certain prior recommendations may have a validation label if the recommendations have been determined effective based on user reviews, user financial data, user geographic data or other information as previously described herein. Further, the quality of the recommendation data can be determined based on the recommendation effectiveness data previously described herein with respect to identifying user financial transactions at the recommended venue, habitual user proximity to the venue and so forth. Accordingly, assuming the recommendation engine 112 generates a recommendation set having data for five recommendations that are all below the recommendation threshold, the recommendation engine 1 12 can search each recommendation data item to determine which recommended venues are most closely related to the recommendation data that has previously been determined to be effective or have the strongest overall link strength to venues identified in the search query. Based on this determination, the recommendation engine can then perform geometric contextualization by determining a normalization factor that will elevate the requisite amount of recommendations from the "effective subset" above the recommendation threshold.
[0224] An example of geometric contextualization using a normalization factor based on the aggregate or individual quality of the recommendations in the recommendation set is illustrated in Figure 21C with reference to Figure 21 A. In this example, as with the previous example, it is assumed that the recommendation engine has generated Restaurants 3, 6, and Restaurant XI in response to the user query identified for Figure 21 A. In this example, assuming a recommendation threshold of 0.25 and an overall link strength value G that is less than 0.25 for Restaurant XI, none of the overall link strengths 2112 exceed the
recommendation threshold. Accordingly, the system 100 determines that the
recommendation engine 1 12 needs to perform geometric contextualization on the
recommendation data. When performing geometric contextualization, the recommendation engine 1 12 determines that Restaurant 3 and Restaurant 6 are of higher quality based on the effectiveness of previous recommendations made by the recommendation engine 1 12 that are stored in the data repository 1 18 with a validation label. For example, the recommendation engine 1 12 can determine from data stored in the data repository 118 that User 2 has visited Restaurant 8 numerous times based on financial transactions from Restaurant 8 and further based on geographic habituations with respect to User 2 proximity to the neighborhood 02196. Accordingly, the recommendation engine 1 12 determines a quality factor for
Restaurant 6 based on similarities between Restaurant 6 and Restaurant 8 such as having an identical price-point as Restaurant 8. Further, the recommendation engine 1 12 may determine the effectiveness of Restaurant 2 based on a multitude of positive review data from User 2 and further determine that User 2 often eats at venues having casual attire and lives in neighborhood 02199 such that a quality factor for Restaurant 3 is calculated based on these considerations. Further, for the purposes of this example, it is assumed that the
recommendation engine 1 12 does not calculate Restaurant XI as a high quality
recommendation as the recommendation engine 1 12 can not determine many similarities to other venues based on effectiveness data in the data repository 1 18. Therefore, although Restaurant 6 has a low overall link strength 2114, the recommendation engine determines that a normalization factor should be generated based on Restaurant 6 and Restaurant 3 in order to elevate the overall link strength of these restaurants past the recommendation threshold.
[0225] In the example illustrated in Figure 21C, the recommendation engine 1 12 determines a quality factor of 0.65 for Restaurant 3 as it has multiple similarities to previously determined effective recommendations. Further, the recommendation engine 112 determines a quality factor of 0.55 for Restaurant 6 as it has fewer similarities to previously determined effective recommendations stored in the data repository 1 18. For Restaurant XI, the recommendation engine 112 determined a quality factor of 0.15. At this point, assuming a user specified or system 100 specified recommendation limit of two, the recommendation engine 1 12 must calculate a normalization factor based on the quality factors such that two of the overall link strengths are elevated above the 0.25 recommendation threshold.
Accordingly, exemplary values of overall link strengths are illustrated in Figure 21 C based on normalization based on the quality factors such that Restaurant 3 and Restaurant 6 are both above the recommendation threshold. Therefore, even with a low overall link strength, Restaurant 6 is still recommended in this example as two recommendations were required to be provided to User 2 and Restaurant XI had an extremely low quality factor.
[0226] The recommendation engine 1 12 may also perform geometric contextualization based on the diversity of the recommendations in the recommendation set. For example, assuming the recommendation engine 112 generates six recommendations, only three of these recommendations may be related whereas the other three may be diverse from each other and the three related recommendations. For example, three of the recommendations may relate to restaurants all have the same genre and neighborhood whereas the other three
recommendations have different genres and neighborhoods. The recommendation engine 1 12 may further compare price points and venue attire to determine similarities between the recommended venues. Accordingly, content-based links, collaborative links and content- collaborative links between the recommended venues are determined by the recommendation engine 1 12 to determine overall link scores therebetween thereby identifying which recommended venues are most closely related and which recommended venues are diverse from each other. The recommendation engine 1 12 may then determine a normalization factor to elevate recommendations that are similar to each other above the recommendation threshold as it is likely that multiple similar recommendations are closer to the affinity of the user as opposed to a variety of potential outlying recommendations have little to no relationship therebetween.
[0227] An example of geometric contextualization using a normalization factor based on the diversity of the recommendations in the recommendation set is illustrated in Figure 21 D with reference to Figure 21 A. In this example, as with the previous examples, it is assumed that the recommendation engine has generated Restaurants 3, 6, and Restaurant XI in response to the user query identified for Figure 21 A. In this example, assuming a recommendation threshold of 0.25 and an overall link strength value G that is less than 0.25 for Restaurant XI , none of the overall link strengths 21 12 exceed the recommendation threshold. Accordingly, the system 100 determines that the recommendation engine 112 needs to perform geometric contextualization on the recommendation data. When performing geometric
contextualization, the recommendation engine 1 12 determines that Restaurant 6 and
Restaurant XI are closely related based on content-based links, collaborative links and content-collaborative links and that Restaurant 3 is quite diverse from both Restaurant 6 and Restaurant XI . For example, the recommendation engine 1 12 can determine from data stored in the data repository 1 18 that Restaurant 6 and Restaurant XI have similar price points, similar neighborhoods, similar review data and similar hours of operation. Accordingly, the recommendation engine 1 12 determines a diversity factor for Restaurant 6 based on similarities between Restaurant 6 and Restaurant 3 and Restaurant XI . Further, the recommendation engine 1 12 repeats this diversity determination for both Restaurants 3 and XI to determine their diversity factor with respect to the other restaurants in the
recommendation set illustrated in Figure 2 ID. Based on these determinations, exemplary values of diversity factors are identified in Figure 2 ID with respect to each recommended venue. According to this example, recommended venues having a lower diversity factor are venues that have more similarity to other venues win the recommendation set whereas recommended venues having higher diversity factors are venues that are not that related to other venues in the recommendation set. For example, Restaurant 6 has the lowest diversity amongst the recommended venues and therefore has a diversity factor of 0.25 whereas Restaurant 3 is the least related amongst the venues and has a diversity factor of 0.75.
Accordingly, exemplary values of overall link strengths are illustrated in Figure 21D based on a normalization factor generated based on the diversity factors such that Restaurant 6 and Restaurant XI are both above the recommendation threshold.
[0228] Geometric contextualization can also be performed with respect to a distance function defined by the user and/or the system 100 and stored as part of the user attribute data illustrated in Figure 6. For example, each user may predefine his own individual distance function identifying geographic preferences with respect to any recommendations made on his behalf. The system 100 may also further redefine this distance function based on the local geography and cultural geography of a given location. For example, the user may live in a city and not have a car such that the system 100 defines the local public transportation boundaries as a distance function for recommendations such that any recommendation served to the user should be within those boundaries. The user may also identify the city limits as their geographic distance function. Further, the system 100 can analyze information from different cities to identify which cities are, for example, walking cities and which cities allow for broader transportation options. As such, for walking cities, the system 100 will define a smaller geographic distance function where as for driving cities, such as Los Angeles, the system 100 will define a larger geographic distance function. Accordingly, in selected embodiments, a radial distance function is defined for the user such that the recommendation engine 1 12 generates recommendations within the boundaries defined by the user and the system 100 even if these recommendations do not have as high of an overall link strength as other recommended venues in neighborhoods outside the users radial distance parameters. Further, for example, if the recommendation engine 1 12 generated 50 recommendations but only 20 of those were within the distance function defined with respect to that user, the recommendation engine 1 12 may focus only on the 20 geographically appropriate
recommendations and then serve a recommendation set based on those that have overall link strengths above the recommendation threshold. In other selected embodiments, the system 100 may in this instance serve a percentage of those recommendations have the highest overall link strengths that are within the number of recommendations in the radial distance of the user.
[0229] The system 100 may also provide recommendations based upon a combination of the above-noted geometric contextualization methods. For example, the system 100 may perform geometric contextualization based on the number of potential recommendations, the individual quality of the recommendations, the diversity of the recommendations, the distance function and serve the user with recommendations based on the results of all three geometric contextualization processes. The recommendation engine 1 12 may determine a subset of recommendations within the generated recommendation set that are determined to be higher quality, determine an adequate normalization factor based on the number of recommendations in the subset and then perform geometric contextualization based on the normalization factor to generate the requisite amount of recommendations that are above the recommendation threshold. Further, the recommendation engine 112 may determine a subset of recommendations by determining which recommendations comply with the distance function identified by the user and/or system 100, determine a ranking of these
recommendations in terms of quality with respect to overall link strength and effectiveness data and provide a heavy weighting factor to this ranking based on quality factors, determine which of these recommendations have the lowest diversity factor and slightly adjust the ranking to ascend recommendations having lower diversity factors and lower
recommendations having high diversity factors, and then identify the number of potential recommendations to identify a percentage of recommendations that should be served to the user based on overall link strengths. In selected embodiments, the recommendation engine 1 12 can identify overlapping recommendations based on the various methods and serve these recommendations to the user. The recommendation engine 1 12 may also weigh the various methods of geometric contextualization based on their perceived effectiveness based on the recommendation data set and provide recommendations to the user based on overlap and weighting effects of the different processes.
[0230] Further, in selected embodiments, the normalization factor generated by the recommendation engine 1 12 may be calculated based on a combination of data relating to the number of potential recommendations available in the filter state, the aggregate or individual quality of those recommendations, and the diversity of those recommendations. Accordingly, the recommendation engine 1 12 can calculate a normalization factor by using calculated data values based on these factors as inputs. The normalization factor is then applied as described above to elevate the requisite amount of recommendations above the recommendation threshold.
[0231] As discussed previously herein, in other selected embodiments or in combination with the above described geometric contextualization methods, the system 100 may require that a certain percentage of recommendations out of the recommendation set be served to the user for each user query. This percentage can change based on factors such as the number of recommendations generated or the number of recommendations generated that have overall link strengths above the predetermined threshold. Accordingly, upon determining a set of recommendations based on overall link strength as previously described herein, the recommendation engine 1 12 may perform geometric contextualization to redefine a ranking of the recommendations based on at least the number of the recommendations, the quality of the recommendations, the diversity of the recommendations, and the distance function in order to provide an enhanced set of recommendations to the user. Upon ranking the recommendations in the recommendation set based on geometric contextualization, the most highly ranked recommendations are selected in descending order until the percentage of required recommendations is met. This set of recommendations is then server by the recommendation engine 1 12 to the user via the user interface.
[0232] In selected embodiments, and to lower processing requirements on the system, geometric contextualization can be performed only when a predetermined number of recommendations generated by the recommendation engine 112 based on overall link strength do not have overall link strengths above the recommendation threshold. Geometric contextualization then elevates the required amount of recommendations above the recommendation threshold such that the required amount of recommendations can be provided to the user via the user interface. However, in other selected embodiments, the system 100 may perform geometric contextualization for every search query performed by the user such that recommendations generated by the recommendation engine 112 and provided to the user based on overall link strength are further enhanced and reordered based on at least the number of potential recommendations, the quality of the recommendations, the diversity of the recommendations and the distance function of the particular user or users.
[0233] Regardless of how geometric contextualization is performed, the system 100 can serve the recommendation data or datum to the user via the user interface with the caveat that the system had to perform some additional processing based on the filter state to obtain the specified number of recommendations. Therefore, the user can be warned that although they have been provided the requisite number of recommendations that these recommendations did not perfectly match the filter state and should therefore be strongly considered. The system 100 could also provide the user with information based on the type of geometric contextualization performed with respect to the filter state. For example, if geometric contextualization is performed based on the number of potential recommendations and known user characteristics, the user may be informed that a certain venue was selected outside the filter state based on previous user characteristic venue price points. Alternatively, the system 100 could provide the user with a combination of recommendations based on this geometric contextualization method such that the system 100 informs the user that one recommendation is based on elevated overall link strength and the other recommendation is based on previously known user characteristics.
[0234] A description of the geometric contextualization according to selected embodiments is illustrated in Figure 22. First, the recommendation engine 1 12 calculates the
recommendation set at S2200 based on the filter state provided by the user at the time of the query. Accordingly, the recommendation engine 112 may determine a large set of recommendations based on overall link strength with respect to an affinity of a venue provided by the user but the number of recommendations in this recommendation set will be lowered based upon the user filter state. Therefore, the recommendation engine 112 must determine at S2202 whether geometric contextualization is required based upon the recommendation set. If there is a large number of recommendations in the recommendation set that exceed the recommendation threshold, the recommendation engine 1 12 may determine that geometric contextualization is not required thereby lowering the processing load on the system and providing quicker results to the user. At this point, the
recommendation engine 1 12 proceeds to S2210 to provide the one or more recommendations to the user. However, if there a requisite amount of recommendations that exceed the predetermined threshold has not been generated, the recommendation engine 1 12 determines at S2202 that geometric contextualization is required. Further, the system may find a number of recommendations that exceed the recommendation threshold but if this number is lower than a user or system 100 specified number of recommendations required to be presented to the user, the recommendation engine 112 will proceed with geometric contextualization to obtain the requisite amount of recommendations. Further, in other selected embodiments, the recommendation engine 1 12 may always perform geometric contextualization on the recommendation set to further redefine a ranking of recommendations in the recommendation set based on the above-noted input factors such as quantity of recommendations, quality of recommendations, diversity of recommendations and user distance factors.
[0235] Upon determining that geometric contextualization is required, the recommendation engine 112 determines the normalization factor based on the information contained in the recommendation set itself as previously described. Therefore, the recommendation engine 1 12 determines which method or combination of methods for generating a normalization factor will be the most effective and proceeds to generate the normalization factor based on these methods at S2204. The recommendation engine 1 12 then normalizes the overall link strength values identified from the search results to obtain at least one recommendation with an overall link strength value above the recommendation threshold.
[0236] Once the recommendations have been normalized, the recommendation engine 1 12 analyzes at S2208 the normalized recommendation values to ensure that the recommendation set now contains enough recommendations values that exceed the recommendation threshold. If the number of recommendation values exceeding the recommendation threshold is still below the number of recommendations required by the user or system 100 for search results, the recommendation engine 112 repeats steps S2204 to S2208 to determine another appropriate normalization factor and re-normalize the recommendation set. This process is repeated until the requisite number of recommendation values exceeding the recommendation threshold is obtained. Once the recommendation engine 112 determines at S2208 that there is an adequate number of recommendations greater than the recommendation threshold, the recommendation engine 1 12 serves the one or more recommendations to the user via the user interface at S2210. The user can then perform additional searches and/or set a further filter state to further refine the search for additional recommendations.
[0237] As calculating what recommendations the recommendation engine 112 will generate for each possible filter state provided by a user ahead of time is extremely difficult and time consuming, the system 100 in selected embodiments performs the geometric
contextualization in "real-time" to provide enhanced recommendation accuracy at the time of a search. Accordingly, via geometric contextualization processing, the system 100 can ensure that the recommendation engine 1 12 will always provide at least one recommendation to the user regardless of the filter state. This bolsters user confidence in the system and decreases the likelihood that users migrate to other systems.
[0238] Further, once geometric contextualization has been performed and the
recommendation engine 1 12 has determined a recommendation set having an adequate number of recommendations, the system 100 may then perform error correction and data verification to further ensure and/or strengthen the accuracy of the recommended venues which may in turn be used to identify reviewers who have submitted review data with respect to the recommended venues and venues in other locations requested by the user.
Interconnectivity Augmentation
[0239] As previously described, the system 100 can present a user with recommendations based on user input and neural connections created between a variety of nodes via content- based relationships, collaborative relationships and content-collaborative relationships.
Therefore, a user in Boston can get recommendations for other venues in Boston based on overall link strengths and post-recommendation processing performed by the
recommendation engine 1 12. However, an issue arises when a user in one geographical area wants to get recommendations for venues in a geographically distant or diverse geographic location in which the system 100 does not contain much information about user interests. For example, a user in Boston may have an upcoming trip to New York and may query the system 100 for recommendations on places to eat in New York. This request may be difficult if there is an information deficit within the system 100 such that it contains large amounts of information as to which venues the user likes in Boston but not much, if any, information on the likes or dislikes of a user with respect to New York. In other words, neural network connections between the extensive neural network topology of the user in Boston and the limited neural network topology of the user in New York are not well defined. Therefore, the system 100 must use information known about the user in Boston to extrapolate information the recommendation engine 112 can use to generate a set of recommended venues in New York.
[0240] In one embodiment, the system 100 can use information relating to the geometric locale of the user performing the search by taking advantage of a predetermined amount of interconnectivity of venues in the neural network developed at that geometric locale. For example, Figures 7 and 8 represent neural network interconnectivity based on connections formed via content-based and collaborative interrelationships defined based on user data, review data and venue data as previously described. This information is based on
Restaurants 1-12 that are located in Boston, Massachusetts. Therefore, the system 100 already has at its disposal a variety of interconnectivity information with respect to the user and venues in the state of Massachusetts. The recommendation engine 1 12 can then, at the time of generating a recommendation, use review data relating to the local venues as well as the venues in New York to determine connections to venues in New York that are most closely related to venues in Boston.
[0241] First, the recommendation engine 1 12 receives which locale the user would like to obtain recommendations for and polls reviewer information to identify reviewers who have reviewed venues in the locale the user is searching for and the locale the user is located in when performing the search. This reviewer information is obtained from a variety of sources as described above with respect to web crawling and the identification of venue reviews. Once the recommendation engine 1 12 has determined the plurality of reviewers having provided reviews for both locales, the recommendation engine 112 processes the
geometrically interconnected review data to form collaborative interrelationships values such that the system 100 can augment the neural network based on the collaborative nodal link values between the two locales. Accordingly, the recommendation engine 112 determines positive or negative affinity connections between a variety of venues within multiple locales based on the review data linking the locales via collaboratively formed interrelationships. At this point, the data repository 1 18 contains amplified inter-connections between venues in both locales from which the recommendation engine 112 can draw upon to make
recommendations for the user.
[0242] To determine which venues from the geographically distance locale to recommend to the user, the recommendation engine 112 looks for strong overall link strengths between venues in the geographically distance locale and the venue(s) the user expressed an affinity for as part of his search query or venues the user is known to like. The venues in the geographically distant local having the strongest overall link strengths to these venues are then generated by the recommendation engine 112 and served to the user via the user interface. Therefore, the system 100 can provide a user with the ability to identify venues of interest in foreign locales by using review data between locales in which the system 100 contains a highly developed neural network topology with respect to user interests and a foreign domain in which the system 100 does not have much information about user interests by augmenting the neural network interconnect! vity therebetween via correlative review data.
[0243] Figures 23 and 24 provide an illustrative example of the initial processing of interconnectivity augmentation of determining interconnection data between two
geographically diverse locals in response for a user query for a venue in New York based on an affinity for a venue in Boston. For the purposes of this example, it is assumed that the user lives in Boston and would like to determine a venue of interest for his upcoming trip to New York. Assuming the system 100 contains a well-developed neural network topology for users' interests in Boston but contains little information on users interests in New York, the system 100 must augment the existing neural network established based on interrelationships developed in Boston to include additional links to venues located in New York. Accordingly, in selected embodiments, all of the review data in which reviewers have provided reviews for both Boston and New York venues is identified and is used to determine collaborative relationships values between the venues in both cities. This information can then be used to update interconnectivity between the neural network topology in both Boston and New York thereby allowing the system to follow links from Boston to New York to recommend venues to the user.
[0244] To increase efficiency and decrease processing demands, in selected embodiments the system 100 may only perform interconnectivity augmentation with respect to venues that are closely related to the venue in which the user has expressed an affinity for in his search as determined based on at least the overall link strength or other methods described above. For example, in this embodiment if the user expresses an affinity for an American restaurant having casual attire and a low price point, the recommendation engine 112 will determine a set of venues having a strong overall link strength with respect to this restaurant within Boston and then perform interconnectivity augmentation to determine which of these venues have review data in which the reviewer also provided data for venues in New York. If there is not enough review data to determine ample interconnectivity information between the generated venues in both locales, the recommendation engine 112 will identify a plurality of other venues having a strong overall link strength with the previous set of generated venues and the system 100 will again determine if there is enough review data between both locales such that nodal links between both Boston and New York can be updated in a way that allows the recommendation engine 112 to recommend venues in New York with a high level of confidence . This process is repeated until the system 100 determines that a predetermined number of venues in which review data is available for both locales has been reached.
[0245] Figure 23 provides an illustrative example of a plurality of venues identified by the system 100 in which Reviewers 1-5 have provided review data for both Boston and New York. For illustrative purposes and the ease of explanation, Figure 23 provides three venues in both New York and Boston but it is noted that this is only a non-limiting example as additional restaurants would likely be included when performing interconnectivity augmentation. As seen in Figure 23, Reviewer 1 is an avid reviewer and has provided a plurality of reviews in both Boston and New York and Reviewer 3 is less active and has only provided review data for one restaurant in New York and Boston. For the purposes of this example, it is assumed that Restaurant D is the actual venue the user expressed an affinity for when performing a search for restaurants in New York, Restaurant E is a restaurant having a strong overall link strength to Restaurant D, and Restaurant F is a restaurant having a low overall link strength to Restaurant D. Assuming that an adequate number of venues having reviews in both Boston and New York have been identified by the system 100, collaborative based link strengths are determined based on the review data. [0246] Figure 24 illustrates the collaborative based links strengths between Restaurants A-F based on the reviewer ratings illustrated in Figure 23. Accordingly, Restaurant A and Restaurant F have a strong collaborative interrelationship nodal link value of +1.5 based on strong reviews by Reviewer 1 whereas Restaurant D and Restaurant F have a very low collaborative nodal link value of -1.5 based on opposite affinities expressed by both Reviewer 1 and Reviewer 2. These collaborative venue link values represent interconnections between Restaurants A-C of New York and Restaurants D-F of Boston. Therefore, as previously discussed, through the process of interconnectivity augmentation, the system 100 traces sparse cross connections between venues of different locals (Boston and Yew York) to create "spider webs" of information therebetween. The recommendation engine 1 12 can then navigate links of these spider web based on overall link strengths to determine recommended venues in New York based on the neural network topology interconnections between Boston and New York.
[0247] Figure 25 presents a connectivity diagram illustrating the spider web generated by the system 100 based upon a user query for a restaurant in New York and the review data obtained for venues in both New York and Boston. Solid connections between the venues represent a positive collaborative link between the venues whereas dotted connections represent a negative collaborative anti-link between the venues. Further, the thicker the line illustrated in Figure 24, the stronger the value (either negative or positive) for that particular nodal link. For example, the nodal link 2500 between A and F is a solid line with relative thickness based on the overall collaborative link strength value of +0.75. Further, the nodal anti-link 2502 between D and F is has a relative thickness and is dashed to represent a negative overall collaborative link strength of -1.5. Based upon these links created by the system 100, the recommendation engine 112 can determine a variety of recommendations for the user for New York based on the overall collaborative interconnectivity link strengths between the restaurants in Boston and New York.
[0248] For example, as it is assumed that Restaurant E is the actual restaurant in Boston the user expressed an affinity for in his search query, the recommendation engine 1 12 may generate a recommendation containing Restaurant A in New York as Restaurant A is directly linked to Restaurant E via nodal link 2500 and has a positive collaborative nodal link value. The recommendation engine 112 may also recommend Restaurant B as it is linked to
Restaurant E via Restaurant A (nodal link 2504) and has a strong nodal link strength with Restaurant A. As Restaurant C does not have any collaborative connections to Restaurant E or Restaurant A, the recommendation engine 112 would likely ignore this node when presenting New York venue recommendations to the user.
[0249] Assuming the user expressed an affinity for Restaurant F in his search query for recommended venues in New York and the network topology was defined by the system 100 based on reviewer data as illustrated in Figure 23, the recommendation engine 1 12 may still recommend Restaurant A over Restaurant B even though both Restaurant A and Restaurant B are linked to Restaurant F as Restaurant A has a stronger collaborative nodal link strength with Restaurant F via link 2500. However, Restaurant B could also be served to the user as an alternative choice. However, if the restaurant for which the user has expressed an affinity for in the search query is not included in the network topology data because there was not enough reviewer information relating to that restaurant, the system 100 will determine the venue having the strongest overall link to the restaurant provided in the search query but which also has ample review data with respect to venues in the foreign local in which the user is seeking recommendations. The recommendation engine 1 12 can the navigate the neural network amplified via interconnectivity augmentation to find a recommendation in New York based on the venue in Boston having the strongest overall link strength value to the venue the user expressed an affinity for in his search query.
[0250] Accordingly, the interconnectivity augmentation process determines venues having strong overall link strengths with venues the user expresses an affinity for when performing a search query and then determines a plurality of reviewer data with respect to these venues and the location in which the user is requesting recommended venues. A network topology based upon the collaborative values between venues with respect to the review data is generated and it is determined whether there enough information from which the system 100 can make a recommendation to the user. If there is not enough information, the system 100 generates additional local venues with links to the restaurant provided in the search query and the network topology is updated based on review data with respect to the venues and the venues in the foreign local. Once there is a predetermined amount of collaborative link strength data between the plurality of venues both within the locale of the user and the foreign local, the recommendation engine 1 12 determines recommended venues in the foreign local by following the strongest overall nodal links in the network topology while starting at the local node expressed in the search query or the local node having the strongest overall link to the venue identified in the user search query. The recommended venues are then served to the user via the user interface. [0251] If the user provides additional filters with the search query in addition to the affinity for a particular venue, the system 100 will take this into account when creating the network topology by harvesting data on the local and foreign venues and identifying which data corresponds to the data within the filter. For example, if the Boston user is a New England Patriots fan and is looking to watch the Monday night game in New York while avoiding heckling from New York Giants fans who mistakenly believe Eli Manning is better than Tom Brady, the user may indicate that he would like a restaurant identified as Patriots friendly. Accordingly, based on the example illustrated in Figure 25 in which the user expressed an affinity for Restaurant E in Boston as part of his search query, if Restaurant A is a Giants friendly venue and Restaurant B is a Patriots friendly venue, the recommendation engine 1 12 will recommend Restaurant B over Restaurant A even though Restaurant A has a stronger overall collaborative link value to Restaurant E based on the reviewer data therebetween. Further, the user may have kids and will therefore want a venue that is friendly to children. Therefore, venue attributes and user characteristic attributes can also be taking into account by the system 100 when performing interconnectivity augmentation to determine
recommendations in locations where the system 100 does not have a lot of information about what the user likes in that particular location.
[0252] In other selected embodiments, the system 100 may perform interconnectivity augmentation to recommend venues in a foreign local in which the system 100 has very little information about user interests by taking into account user specific information known to the system 100 in other locals As with the examples discussed above, the system 100 may not have much information about what the user likes in New York but may have ample information about what user likes in Boston. Accordingly, user attributes, review data from the user, previous recommendations known to have been effective and the interrelationships formed based on content and reviewer data from the user local can all be used to extrapolate venue "clones" in a foreign local that are similar to or identical to venues known by the system 100 to be well received by the user. These nodal doppelgangers can then be incorporated into the neural network topology previously defined as discussed above based on content and collaborative interrelationships within the local area of the user such that the system 100 can follow the nodal links to determine venue clones in a foreign locale that may be of interest to the user. Further, the list of nodal doppelgangers will inherently be cross- connected with a plurality of other venues within the foreign locale such that additional recommendations can be made to the user. Accordingly, alternatively or in addition to review data between two locales, interconnectivity augmentation can also be performed based solely on user interest information from other locales.
[0253] Figure 26A is a chart illustrating an exemplary sample set of venues within New York, New York that are stored within the data repository 1 18. As with Figure 4, each Restaurant A-E has its own price, genre, hours of operation, attire, and neighborhood.
Accordingly, as described previously with respect to Figure 4-12 and Figure 23, the system 100 contains information, determined via web crawling and web harvesting, about venues in Boston and nodal interrelationships therebetween and knows information about venues in New York but does not have information on nodal links between the venues in Boston and the venues in New York. Therefore, interconnectivity augmentation can be performed utilizing nodal cloning in order to determine intercity nodal relationships between Boston and New York.
[0254] Assuming the user is located in Boston and has performed a search query for venues in New York, the system 100 must determine which venues the user is typically interested in Boston. The system 100 can receive as part of the search query for venues in New York, restaurants in Boston that the user likes in which he wishes to find similar restaurants in New York. The system 100 can also determine which venues the user likes based on previous recommendation data that has been determined to be effective via financial transactions of the user, positive review data, GPS data or other data as described previously herein. The system 100 then compiles this list of interests of the user within Boston and compares each venue or piece of interest to known venues in New York to determine nodal doppelgangers within New York that have many of the same features of the venues identified within Boston.
[0255] Figure 26B is a chart illustrating the results of processing to determine a congruency factor representing a similarity level between the venues of interest from Boston and venues in New York. In Figure 26B, it is assumed for the purposes of this example that both
Restaurant 6 and Restaurant 10 were included as part of the search query by the user for restaurants in New York and/or were determined to be venues that were previously recommended and were effective with respect to the user. Accordingly, the system 100 compares each attribute of Restaurant 6 and Restaurant 10 to each attribute of a plurality of identified venues within New York in an attempt to determine one or more venue clones having a high congruence factor with Restaurant 6 and Restaurant 10 of Boston.
[0256] Based on these comparisons, Restaurant C of New York has the highest congruency factor with respect to Restaurant 6 as the price is the same as Restaurant 6, the genre is the same as Restaurant 6 and the attire is the same as Restaurant 6. Conversely, Restaurant D has the lowest congruency factor with respect to Restaurant 6 as the price point is extremely high, the genre is different and the attire is different. With respect to Restaurant 10 of Boston, Restaurant D has the highest congruency factor as the price point is similar, the genre is the same and the attire requirements are the same. Accordingly, by determining the congruency factors, the system 100 can identify venues in a foreign local that have the features similar to user-provided venue filters and/or venues which have been determined to be effective for the user in the past.
[0257] The congruency factor scores are exemplary and will change based on various venue attributes as well as different weights assigned to various venue attributes. For example, genre may be weighted the highest as a user searching for restaurants in New York who provides Restaurant 6 of Boston as part of the search query will likely identify with New York restaurants that have the same type of food. Further, price may be weighted less than genre but more than attire. These weights can be set automatically by the system 100 or manually by the user performing the search. The congruency score for Restaurant 6 of Boston in comparison to Restaurant C of New York is not 1.0 because it is assumed that there may be other factors taken into consideration in determining how similar Restaurant C is to being a clone of Restaurant 6. These factors include, but are not limited to, hours of operation, review data, user characteristic data and previously defined nodal link
interrelationship information between Restaurant 6 and other restaurants in Boston or New York. The user may also indicate likes and dislikes which will affect the weighting of the various venue attributes. For example, if the user detests dressing up when going out to dinner, the system 100 may apply an extremely high weighting factor to the attire attribute thereby causing restaurants requiring formal attire to have extremely low congruency factors even though they are similar to the identified local restaurant in many other respects.
[0258] Once the system has determined the plurality of congruency scores with respect to the restaurants of interest identified based on the venues provided in the search query or those known by the system 100 to be effective, the system 100 updates the neural network topology to form nodal links between the identified venues of interest and the venues identified in the foreign local. In selected embodiments, the system 100 may link all nodes between the locales regardless of the congruency factor or may link only those nodes having a strong congruency factor therebetween. Accordingly, the system 100 or user may assign a predetermined threshold congruency factor for magnifying nodal interconnectivity between various locales. [0259] Figure 27 represents nodal interconnection magnification between Boston and New York based on the plurality of congruency factors determined with respect to Restaurant 6 and Restaurant 10 of Boston, and Restaurants A-E of New York. For the purposes of this example, Figure 27 only illustrates nodal inter-locale augmentation for nodes having a congruency score of at least 0.60 or better. As illustrated in Figure 27, a nodal link 2700 is formed between Restaurant 6 of Boston and Restaurant C of New York as the congruency factor therebetween as determined by interconnectivity augmentation processing is 0.85. Further, nodal links 2702 and 2704 are formed between Restaurant 10 of Boston and
Restaurants A and D of New York as Restaurant 10 and Restaurant A have a congruency factor of 0.65 and Restaurant 10 and Restaurant D have a congruency factor of 0.75. The difference in thickness of the nodal link represents the strength of the congruency factor such that the thicker the nodal link the more similar the venues are to each other. Accordingly, nodal link 2504 based on a congruency factor of 0.75 is thicker than nodal link 2502 having a congruency factor of 0.65. Further, nodal link 2500 based on a congruency factor of 0.85 is thicker than both nodal link 2502 and nodal link 2504. Restaurants E, V, W, X, Y and Z are Restaurants in New York that have strong overall link strengths to Restaurants C, D and A as illustrated based on content-based interrelationships, collaborative interrelationships, content- collaborative interrelationships and tiered relationships as described previously herein.
[0260] Based on the amplified neural network formed between Boston and New York formed as a result of the interconnectivity augmentation performed in response to a search query for a venue in New York based on an affinity for Restaurant 6 and/or Restaurant 10 of Boston, the recommendation engine 112 can traverse the links in the updated neural network topology to provide recommendations to the user for venues in New York. For example, as illustrated in Figure 27, for a user expressing an affinity for Restaurant 6, the user will be served with a recommendation for Restaurant C in New York. Similarly, for a user expressing an affinity for Restaurant 10, the user will be served with Restaurant D and Restaurant A with an indication the Restaurant D was the closest venue based on the user's search query. Further, interconnections within the neural network of New York can further be used to provide larger recommendation sets. For example, for a user expressing an affinity for Restaurant 6 in a search query, Restaurant E may be recommended next as having a strong overall link strength to Restaurant C with Restaurant V and W being recommended next as alternative venues based on their overall link strength with respect to Restaurant C.
[0261] As described previously, if the user provides additional filters with the search query in addition to the affinity for a particular venue, the system 100 will take this into account when creating the network topology by harvesting data on the local and foreign venues and identifying which data corresponds to the data within the filter. For example, if the user performs a search query by expressing an affinity for Restaurant 6 but also provides a filter that requires a medium price point for recommended venues, the recommendation engine 1 12 may recommend Restaurant E over Restaurant C as the recommendation engine 1 12 is able to traverse the nodal link 2700 to determine the Restaurant C is a good match but further determines based on venues having strong overall link strengths with respect to Restaurant C that Restaurant E is a better choice because it has a medium price point as compared to Restaurant C's low price point. Therefore, venue attributes and user characteristic attributes can also be taking into account by the system 100 when performing interconnectivity augmentation to determine recommendations in locations where the system 100 does not have a lot of information about what the user likes in that particular location.
[0262] It should be noted that the system 100 may also contain large amounts of information with respect to user interests in locales other than the one in which the user is located that can also be used to perform interconnectivity augmentation based on congruency factors via a determination of nodal doppelgangers. In other words, when a user from Boston is looking for venues of interest in New York, the system 100 may also perform interconnectivity augmentation in the above-noted manner by using recommendations known to be effective in other areas with respect to the user, such as Washington D.C, to further enhance the variety of recommendations provided to the user. Further, congruency factors determined between different locales can be weighted differently based on user time spent in the locales, the number of effective recommendations or the like and then compared to determine a more accurate recommendation set for the user. Additionally, the system 100 may encounter difficulties performing interconnectivity augmentation between Boston and New York if venue information from New York is not readily available. In such a situation, if the system 100 already contains strong links to another city, such as strong links between Boston and Washington, D.C, and strong links from Washington D.C. to New York, the system 100 may determine recommendations by navigating the nodal network topology from Boston to New York via nodal links provided in Washington D.C.
[0263] Although the links may be uni-directional or bi-directional as previously described herein, the nodal links determined via interconnectivity augmentation as illustrated in Figures 25 and 27 are bi-directional to further enhance information available to the system 100 in the event that similar future searches are performed by the same user or other users with similar interests either in Boston or New York. [0264] As note above, the system may perform interconnectivity augmentation based on both review data between different locations and via a determination of nodal doppelgangers in different locales. Accordingly, the system 100 may update the neural network topology of nodes between different locales based on review data and then may further update this network topology based on nodal link determinations identified via congruency factors. As such, interconnectivity augmentation therefore provides the system 100 with the ability to extrapolate information about foreign systems to generate an updated neural network topology having connections between a locale in which the system has ample information about what the user likes and a local in which the system 100 has very little information about what the user likes. This provides enhanced functionality to the user in that the system 100 acts as a travel companion to provide venues of interest to a user when a user is traveling to various locations. This increases the likelihood that the user will enjoy his experience when traveling and will further enhance the network topology thereby increasing the accuracy of future recommendations to the user.
[0265] Further, error correction and data verification can be performed to ensure and/or strengthen the accuracy of the recommended venues which may in turn be used to identify reviewers who have submitted review data with respect to the recommended venues and venues in other locations requested by the user.
Merchant Interface
[0266] The venues are operated by merchants, or third party vendors, which may comprise merchants such as restaurant owners, airlines, or hotel operators. The system 100 may be configured to provide merchants a visualization of users' behavior. For instance, merchants may be provided access to ant trail data patterns, including in real time. Merchants can "interact" with these patterns and request the system 100 to inject disruptive content such as promotional offers related to a user's present location and expressed preferences.
[0267] Merchants may also be provided anonymized profiles of the likes and dislikes of their customers (i.e. users who patronize their establishment). This can include reviews provided by reviewers and users who provide feedback (who also constitute reviewers).
[0268] Additionally, it is anticipated that merchants will likely wish to provide
personalization services to their customers to ensure customer retention while increasing revenue. For example, merchants selling products either online or in the brick-and-mortar world may want to identify recommendations for their customers based on at least previous purchases by the customer, customer attribute data, review data, data about the product itself and the accompanying neural network topology generated based such information. However, it is unlikely that merchants will have this functionality to provide users, much less the ability to provide these types of services on the scale and accuracy of the system 100. Accordingly, the system 100 provides an application programming interface (API) operated by the server 102 for allowing merchants to supply data to the system 100 which can be used by the recommendation engine 1 12 to determine recommendation or similarity data. The system 100 then sends this data back to the merchant.
[0269] Figure 28 illustrates an exemplary interaction between the system 100 and a plurality of merchants/third party vendors 2800, 2802 and 2804 via an API 2801. Figure 28 includes the server-based recommendation generation system 100 hosted on the server 102 as illustrated in Figure 1 and therefore like designations are repeated. Further, the merchant interface 1 16 is illustrated as including the above-noted API 2801. As illustrated in Figure 28, the server 102 is connected to a plurality of merchants 2800, 2802 and 2804 via the network 120. Each merchant can provide the server 102 with a plurality of requests which are received by the API 2801 via the network 120. The requests can include information such as identification information of the merchant, the type of request, the type of information included in the request, the data which the system 100 will process, a request for a quote for processing the request, and temporal information with respect to the request itself. In response to receiving requests from the merchants, the recommendation engine 112 processes the requests and generates results which are output to the merchants via the API 2801 and network 120.
[0270] In selected embodiments, the API 2801 includes a set of programming instructions and standards for accessing the system 100 such that merchants can appropriately format their requests in a manner understood by the system 100 and so the API 2801 can provide responses to the merchants in a manner manageable by their systems. In other words, the API 2801 provides programming such that the server 102 and remote applications operated by the merchants 2800, 2802 and 2804 can communicate with each other through a series of calls. For example, web services having a collection of technological standards and protocols, such as extensible markup language (XML) may be provided thereby allowing various parties from different systems to communicate. The APT 2801 may be included as part of a software development kit (SDK) along with programming tools thereby providing the merchants 2800, 2802 and 2804 with instructions on how to best interact with the system 100. Additional technological standards, protocols and programming languages may be included such as simple object access protocol (SOAP) for encoding XML messages so that they can be understood by operating systems over any type of network protocol, and universal description, discovery and integration (UDDI) for allowing the merchants 2800, 2802 and 2804 to list themselves. Mashups may also be implemented within the system 100 thereby providing functionality from the API 2801 of the system 100 in conjunction with other web applications.
[0271] For the ease of explanation, Figure 28 illustrates three merchants 2800, 2802 and 2804 providing different requests to the server 102 but one of ordinary skill in the art would clearly recognize that more than three merchants can connect to the server 102. In Figure 28, it is assumed that the merchant 2800 has identified a cluster of items of which a customer of the merchant 2800 has expressed a preference as determined by purchase data, shopping habits, and other methods as would be understood by one of ordinary skill in the art. For the purposes of this example, it is assumed that the customer of the merchant 2800 has purchased three bottles of wine (or has three bottles of wine in their shopping cart) and is looking for one more bottle of wine. The merchant 2800 may want to provide the customer with a recommendation of additional wines for purchase and therefore interacts with the server 102 via the request 2806 and API 2801. The request 2806 defined by the API 2801 infrastructure includes a request for the recommendation engine 112 to determine one or more
recommended items that the user may like based on the cluster of items included in the request 2806. The request 2806 may include identification information of the merchant 2800, information specifying the type of request such as a request for recommendation data, a categorical description of the data, and the data of which the system 100 will determine recommendations. For example, the request 2806 may include the name and address (virtual and real-world) of merchant 2800, a request for recommendations based on the data set provided by the merchant 2800, information specifying that the data set relates to beverages or more specifically alcoholic beverages such as wines, and the list of wines for which the merchant 2800 would like the system 100 to process. This request 2806 may be served to the system 100 at the time of a purchase by the customer or at a later time when the merchant 2800 is attempting to determine advertisement information based on previous customer activity.
[0272] Once the request 2806 is received by the API 2801 via the merchant interface 1 16 and network 120, the system 100 determines the type of request and the type of information included in the request. For example, the system 100 parses the system call from the merchant 2800 to determine that the recommendation engine 1 12 must generate
recommendations as described above based on the list of wines provided in the request 2806. If the type or genre of information is not included in the request, the system 100 may generate an error message to the merchant 2800 or may attempt to determine the type of information. For example, the recommendation engine 1 12 may attempt to determine whether the items within the request 2806 relate to cars, food, video games, or as in this instance, wine based on keywords identified in the request 2806 itself.
[0273] Once the recommendation engine 1 12 has determined the type of request and what type of information is included in the request, the recommendation engine 1 12 identifies whether the data repository 128 includes the appropriate neural network topology generated by the matrix builder 126 in which to process the request 2806. Specifically, in selected embodiments the system 100 may generate network topologies in all types of fields and for all types of products in addition to the venues discussed above. Therefore, the data repository 1 18 may already contain a neural network topology for the cluster of items relating to wine contained in the request 2806. In other embodiments, the system 100 may dynamically generate a new network topology or update a previously existing network topology as previously described herein (via harvesting, creating nodal links, error correction and data verification, interconnectivity augmentation, etc) based on the type of items identified in the request 2806.
[0274] Once the system 100 has determined that a suitable neural network topology exists for which to process the request 2806, the recommendation engine 112 generates a
recommendation set for the merchant 2800 of items that users may like based on the cluster of items provided in the request 2806. Specifically, the recommendation engine 1 12 generates recommendations based on the methodologies described previously herein such as identifying overall link strength rankings, performing error correction and data verification with respect to source sites, performing geometric contextualization with respect to the generated recommendation set and performing resonance checking of each recommendation in the recommendation set. Once the final recommendation set is generated by the
recommendation engine 112, the server 102 provides the recommendation set including a plurality of recommended wines to the merchant 2800 in a response 2808 via the merchant interface 1 16, API 2801 and network 120.
[0275] Figure 28 illustrates another example of a request 2810 from merchant 2802 including at least the merchant 2802 identification information, a request that the system 100 provide information as to what items may be similar to the items provided in the request 2810, an identification of the items as beverages and the list of one or more wines. For example, assuming that the data items included in the request 2810 again include three bottles of wine, the merchant 2802 requests information as to what other drinks may be similar to the bottles of wine such as other wines, champagne or liquor, that the user may like based on a similarity to the wine bottles included in the request 2810. In this instance, the recommendation engine 1 12 identifies the type or genre of information included in the request 2810 and determines whether the appropriate neural network topology exists for similar items. Specifically, the recommendation engine 1 12 determines a plurality of items that may be similar to the items included in the request 2810 and determines whether an adequate neural network exists for each item.
[0276] The system 100 may determine similarity to an item in a variety of ways. For example, in selected embodiments, the system 100 determines that bottles of wine fall into a drink category and therefore that only drinks should be contemplated by the system 100 when attempting to determine similarities. This can be accomplished by performing keyword searches with respect to the items included in the requests and/or by referring to a previously defined database updated based on user and vendor requests. Next, additional subcategories are determined until the system 100 identifies a plurality of categories deemed to be most similar to the items included in the request. For example, the system 100 may further identify the wine is a type of alcohol and therefore the system 100 should only search for other alcohols such as beers and liquors. Accordingly, the system 100 can generate a similarity score of various beverages based on nodal link strengths between beverages having similar attributes within the neural network. In other selected embodiments, the merchant 2802 may also provide in the request 2810 similar categories to search based on the items provided by the merchant 2802.
[0277] Once a list of items deemed to be similar to those listed in the request 2810 has been determined, the recommendation engine 1 12 generates a recommendation set as previously described herein and provides the recommendation set to the merchant 2802 in a response 2812. Specifically, overall link strengths are calculated by the recommendation engine 1 12 via collaborative-interrelationships data based on reviewer data between wines identified in the request 2810 and items deemed to be similar (such as liquors and beers), content-based interrelationships based on similar attribute data with respect to users who both drink the wines identified in the request 2810 and liquors and beers and wine attribute data such as the type of wine, the alcohol content, the location in which the wine is created, and content- collaborative interrelationships. Further, interconnect! vity augmentation may be performed to bolster the neural network connectivity as well as geometric contextualization and error correction and data verification to enhance recommendation accuracy. [0278] As described previously above, the requests coming from the merchants may also include filters with respect to the items included in the requests. For example, Merchant 2800 may request that the system 100 only return recommendations for wines that were made in or before a certain year. Merchant 2802 may request that recommendations for similar items be restricted to different types of beer rather than also including liquor as a subset. Accordingly, the recommendation engine 112 is able to provide merchants not only with recommendations for the same item or similar items included in requests but is also able to fine tune recommendations specifically tailored towards merchant requirements. Further, requests may include user attribute information from the merchant thereby providing the system 100 with additional information from which to generate a recommendation.
[0279] The API 2801 further provides the functionality for merchants to communicate a complete index of their items as well as user information with respect to the items to the system 100 with a request that the system 100 create a neural network topology specifically tailored to the communicated index of items. Accordingly, the request can also include item attribute data and item review data. The neural network topology generated by the system 100 can then be used by the recommendation engine 1 12 to provide enhanced
recommendations that are finely tuned to the enriched data provided by the merchant. This neural network topology can be generated solely based on the merchant index of items or an existing system 100 neural network topology can be updated based on the information contained in the merchant index. Therefore, such a request may contain identification of the merchant, the type of data, the complete index of the merchant's products and a request that the system 100 build personalization maps such as a neural network topology based on the data provided by the merchant. The request may also include user attribute information with respect to these products. For example, request 2814 from merchant 2804 is a request providing the name and address of merchant 2804, an identification of the data as relating to wine, all of the wines sold or made by the merchant 2804 as well as user information with respect to each bottle relating to purchases statistics, likes or dislikes and other affinity data, and a request that the system 100 generate a neural network topology based on this information.
[0280] Once the request is received by the merchant interface 1 16 via the API 1801, the matrix builder 126 generates a neural network having internodal connections between all of the wines identified from the merchant-provided index and the user data provided in the request 2814. The system 100 may further augment the neural network using other information harvested by the system 100 as described previously herein. Accordingly, the request 2810 may also include information identifying whether or not the merchant 2810 wants the system 100 to use information additional to the information provided in the request 2810.
[0281] Once the neural network is generated by the system 100, the merchant 2804 can then submit further requests to the server 102 via the network 120 and merchant interface 1 16 as previously described herein in order to obtain recommendations or similar items generated by the recommendation engine 112. Further, the merchant 2804 may further request that the server 102 communicate the neural network topology information to the merchant 2804 in response 2816 so that the merchant can use such information internally.
[0282] Based on the information provided in the requests from the merchants, the API 2801 may capture this information such that the system 100 may update the neural network topology for further use with the merchant as well as with other users of the system 100. For example, when merchant 2800 sends the request 2806 including the three bottles of wine, the system 100 may determine that the user picked these three wines and that pairing information can be obtained with respect to the user and the wines themselves. Accordingly, this information can be used by the matrix builder 126 to create or update nodal links with respect to data items of this type. Further, the API 2801 can capture user information in the requests thereby mapping user attribute information with specific pairings of items. The system 100 may also capture via the API 2801 the effectiveness of the recommendations provided to the merchants in the system 100 responses. For example, the system 100 may send system call requests via the API 2801 to merchants requesting that the merchants return user
effectiveness data with respect to recommended items such as increased revenue based on certain recommendations and/or whether certain customers of the merchants have purchased items based on the recommendations served by the recommendation engine 1 12.
[0283] Accordingly, via the API 2801 the system 100 is able to provide specific merchants with personalization services thereby helping merchants retain customers and increase revenue. Merchants can request recommendation data from the server 102 as well as specific personalization maps with respect to information provided by the merchants relating to the entire catalog of merchant products. Further, while providing these services to the merchants, the system 100 simultaneously harvests merchant information to increase the accuracy of nodal connections in existing neural network topologies in areas relating to merchant product catalogs. Therefore, the merchants are provided with beneficial personalization services while also further enhancing those services for other users and merchants alike through their interaction with the system 100. Shared Recommendations for Harmonized Group Decision-Making
[0284] In certain aspects of the present disclosure, a user's affinity for a particular entity or property (i.e., a feature of a person, place, thing, etc.) may be determined when generating a user personality matrix. Mathematical computations for determining a user's affinity for a particular entity or property may include data mining functions for analyzing previous indications of an affinity for the entity or property. As a non-limiting example, a positive or negative affinity for an entity or property may include an analysis of purchase history, user reviews, interrelationships with users and/or venues, similarities between properties, survey results, and other factors described herein. It should also be appreciated that corollary principles of utilizing a user or group of users' affinities apply when determining shared recommendations based on a combined personality matrix. That is, in addition to analyzing a user's affinity for a particular entity when determining an individual's taste profile (i.e., a user personality matrix), aspects of the present disclosure may include creating and utilizing a unified taste profile (i.e., a combined personality matrix derived from aggregated user personality matrices) when determining recommendation candidates for a group of users. In this case, the recommendation candidates may, e.g., indicate an optimal decision
recommendation, based on the unified taste profile represented by the combined personality matrix.
[0285] A harmonized group decision-making process may include providing shared recommendation results based on a unified taste profile of multiple users, where the shared recommendations ideally collectively suit the unified taste profile of the group seeking the shared recommendation. In certain aspects of the present disclosure, a user personality matrix representing an individual user's taste profile may be determined for each user in a group decision-making dynamic, wherein each group member's user personality matrix can be mathematically "merged" to form a unified taste profile corresponding to the group rather than the individual. Accordingly, recommendations based, for example, on interrelational nodal strength characteristics between candidate venues and the unified taste profile may be determined by methods set forth herein.
[0286] Figure 29 illustrates an exemplary algorithmic flowchart for calculating a user personality matrix. As discussed previously, the user personality matrix may represent a user's taste profile and/or a user's affinity for a set of venue properties. As previously noted, for convenience the term "venue" is used to refer to neural network nodes. It should be understood that the term "venue" is used herein to broadly refer to any entity or item (e.g., a restaurant, location, activity, content, users, reviewers, etc.) that is interrelated in the network with other network nodes. Venue properties included in the user personality matrix may be derived from a user's connection graph, which includes all venues for which a user has previously expressed an affinity. The user personality matrix may be calculated in real-time or saved and modified over time as affinities change and/or new venues are discovered and added to the user's connection graph.
[0287] Referring now to Figure 29, the system 100 initially sets all values in the user personality matrix to 0 at step S2900. At step S2902, the system 100 compiles candidate venue properties and property attributes. Candidate venues may be broadly defined as any entity that may be returned as a shared recommendation result. Step S2902 may include acquiring a user's connection graph, extracting candidate venues from the user's connection graph, and dissecting the extracted candidate venues for their properties and property attributes. Exemplary venue properties and property attribute values are shown in the example of Figure 4. Referring now to Figure 4, column 1 in the figure represents twelve restaurant candidate venues that may be extracted from a user's connection graph. The second horizontal column listing categorical descriptors (city, state, etc.) represents a set of venue properties that may be extracted for the 12 restaurant candidates. The remaining portion of Figure 4 represents attributes and corresponding attribute values, which may be represented as labels, codes, numerical values, or other identifiers.
[0288] Turning back to Figure 29, the system at step S2904 adjusts the derived property attribute values based, for example, on nodal link strength with respect to the user. As discussed previously, nodal link strength with respect to the user may be determined, for example, by analyzing user reviews, frequency of visits, geospatial information, purchase history, second and higher order links with other users, second and higher order links with other attributes, or the like. The processing at step S2904 may result in property attribute values being calculated such that user preferences for a particular attribute and/or and overall affinity for a given property may be discerned.
[0289] Next, at step S2906 the system 100 determines if more candidate values exist in a user's connection graph and if so, acquires the next candidate venue from the connection graph at step S2908. Otherwise, the system 100 at step S2910 normalizes the attribute values within each property in the user personality matrix based, for example, on a maximum property attribute value for a given property. The processing at step S2910 may result in a numeric representation of a user's relative affinity for a property attribute with respect to all other attributes for that property. For example, the system 100 may determine that a particular user likes Chinese cuisine with an affinity of 0.95 with respect to all other cuisine types (e.g., American, Italian, Mexican, etc.).
[0290] Next, at step S2912 the system 100 may assign property weights based on a user's expressed affinity for a particular property with respect to all other properties in the user personality matrix. Whereas step S2910 provides a mathematical representation of user affinity for a particular property attribute with respect to other attributes in the particular property, step S2912 may provide a numerical representation indicating, for example, that an entire property field such as cuisine matters to a particular user by a value of 0.8 compared to all other properties (e.g., price, ambience, etc.). Consequently, the system 100 may assign a higher importance weight to the property field of cuisine than it would to other property fields.
[0291] Next, at step S2914 the system 100 forms the user personality matrix based on the normalized property attribute values and the assigned property weights. For illustration purposes, a non-limiting example of a user personality matrix corresponding to a given user is illustrated in Figure 30. For simplicity, Figure 30 illustrates property fields corresponding to restaurants; however, those of ordinary skill should appreciate that the present disclosure may easily be adapted such that user personality matrices including other property fields corresponding to other venue types may easily be determined using the exemplary methods within the scope of the present disclosure.
[0292] Referring now to Figure 30, an exemplary user personality matrix 3000 is shown. Initially, it is noted that the format presented with respect to the user personality matrix 3000 of Figure 30 is provided merely for illustration purposes and those of ordinary skill will appreciate that other formats may be used, such as those that may be easily adapted such that mathematical computations may be performed using, for example, processing circuitry. The user personality matrix 3000 includes an area 3002 illustrating various properties of a venue that may be derived, for example, at step S2902 of Figure 29. Area 3004 includes various attributes corresponding to the properties of the area 3002. The property attributes and their corresponding values may be derived, for example, at steps S2902 and S2904 of Figure 29. Additionally, the user personality matrix 3000 assumes that the attribute values have been normalized, for example, using methods described at least at step S2910 discussed for Figure 29. The attributes and corresponding attribute values illustrated in the area 3004 represent a relative user affinity for attributes within a given property. In this example, analysis such as nodal interrelational link strength may indicate that a user has a normalized affinity value of 0.8 for American cuisine relative to other cuisines (i.e., Chinese, Japanese, Italian, and Mexican). Area 3006 includes a plurality of property weights calculated to correspond with the properties shown in the area 3002. The property weights of the area 3006 may be calculated, for example, at step S2912 of Figure 29. The property weights of the area 3006 indicate a relative importance of a property with respect to other properties. That is, acquired user data and corresponding analysis of nodal interrelational link strength may indicate that a user strongly prefers a particular venue property relative to others. Similarly, the user data and/or nodal interrelational link strength may indicate that a user is largely indifferent to a particular venue property with respect to other properties for the given venue type. Property weight may be determined, for example, by analyzing the attribute values, such as those illustrated in the area 3004. In this case, high variability in attribute value magnitude may indicate a strong preference for a particular property relative to other properties. Conversely, low variability within attribute values may indicate that a user does not place a high importance on that particular property. For example, a user may consistently express an affinity for casual restaurants and rarely express a desire to choose formal or business attire when selecting a restaurant, as indicated by the attribute values corresponding to the attire property shown in the area 3004. Consequently, the system 100 may calculate a high property weight value corresponding to the high importance that the user places on the attire property when selecting a restaurant venue. Similarly, the same user may select venues having a high price attribute at approximately the same frequency at which he or she selects venues having medium and low price attributes. Consequently, the system 100 may calculate a low property weight of 0.2 indicating that the user places a low importance on price when selecting restaurant venues.
[0293] It is noted that while the user personality matrix illustrated in Figure 30 corresponds to a venue type of restaurants, in certain aspects of the present disclosure user personality matrices corresponding to a plurality of venue types may be calculated such that a single user taste profile is maintained for a variety of different venue types (e.g., favorite movies, favorite restaurants, favorite schools, favorite neighborhoods, etc.). In other aspects of the present disclosure, user personality matrices may be calculated such that they are venue type specific, such as the user personality matrix 3000, which corresponds to restaurant venue types. Additionally, user personality matrices may be stored and adapted over time rather than calculating new user personality matrices for each new shared recommendation query.
[0294] Next, Figure 31 illustrates a non-limiting example of an algorithmic flowchart for computing a combined personality matrix. As discussed previously, a combined personality matrix may represent a unified taste profile for an ensemble of users seeking a shared recommendation. Referring now to the figure, the system 100 at step S3100 acquires user personality matrices N and N+l . In certain aspects of the present disclosure, the system 100 may set one of the acquired user personality matrices as a "base" matrix to which other user personality matrices can be merged to form the combined user personality matrix.
[0295] At step S3102, the system 100 compares the acquired user personality matrices and finds matching attributes within matching properties of a given venue. For example, the system 100 may compare two user personality matrices and determine that both matrices include a cuisine property and matching attributes corresponding to Chinese cuisine.
[0296] At step S3104, the system 100 sums matching attribute values. For example, in a case in which the above-noted users each expressed an affinity for Chinese cuisine based on their matching attributes in their respective user personality matrices, the system 100 may sum their attribute values (e.g., user 1 has an affinity of 0.5 and user 2 has an affinity of 0.7 for Chinese cuisine, resulting in a combined user affinity score of 1.2) to calculate a combined attribute value with which to include in the combined personality matrix.
[0297] At step S3106, the system 100 compares the user personality matrix N and the user personality matrix N+l to identify non-matching attributes, and appends non-matching attribute values to the base matrix. For example, the user personality matrix N may include an "Ethiopian" attribute in its cuisine type property. The system 100 may determine that the user personality matrix N+l does not include the Ethiopian attribute in its cuisine type property. Consequently, the system 100 may append the attribute value corresponding to the Ethiopian attribute in the user personality matrix N to the base profile at step S3106.
[0298] Next, at step S3108 the system 100 determines if more user personality matrices are available to merge into the combined personality matrix. If more user personality matrices are available, the system 100 at step S31 10 acquires the next user profile (i.e., user profile matrix N+2 in this example) and performs the above-described matrix merging process in an iterative fashion until all user personality matrices for the entire group have been merged.
[0299] After aggregating the attribute values as described above, the system 100 at step S31 12 divides the values in the combined personality matrix by the number of users present in the group requesting a shared recommendation. This step results in a set of attribute values representing a unified taste profile for the entire group. In certain aspects of the present disclosure, the number of users (N) may equal the number of users included (i.e., contributing a user personality matrix) in the shared recommendation processing. In other aspects of the present disclosure, the number of users N may be adjusted such that it does not equal the actual number of users included in the group requesting a shared recommendation. For example, a user's personality matrix may be included when forming the combined
personality matrix; however, the number of users may be adjusted to alter the relative weight of the user personality matrices.
[0300] At step S31 14, the system 100 merges the connection graphs for all users from which a user personality matrix was derived. As discussed above, the connection graph may represent all venues, such as restaurants, for which a user has previously expressed an affinity. Thus, the processing at step S3114 results in a connection graph corresponding to all venues to which all members in the group requesting shared recommendations have previously expressed an affinity, which can subsequently be used to provide candidate venues from which the recommendation engine can provide a shared recommendation. In certain aspects of the present disclosure, the recommendation engine may also determine additional candidate venues from which to provide a shared recommendation based, for example, on interrelational nodal link strengths between a venue in the merged connection graph and another "unknown" venue, information of which may be acquired by methods set forth previously (e.g., web crawling, etc.).
[0301] While the example discussed with respect to Figure 31 may represent a case in which a fixed set of users seeks to make a shared decision using the shared recommendation process described herein, it should be appreciated that aspects of the present disclosure may be adapted such that recommendations for partners to participate in a given activity may also be recommended. For example, a group of users may seek an ideal location to go rock-climbing, and also request the system 100 provide recommendations as to other partners with which to go rock-climbing with. In this case, the system 100 may perform processing in accordance with methods set forth above to determine interrelational nodal strengths between the users making the request and the potential venues with which the users might wish to go rock- climbing. In addition, the system 100 may utilize the aforementioned processes for determining interrelational nodal strength to analyze acquired user personality matrices (e.g., downloaded from a server). Link strengths between the users initiating the requests and users corresponding to the acquired user personality matrices may be analyzed such that shared recommendations can be made as to which partners may wish to also go rock-climbing, as well as the users that the initiators making the request may share common personality traits. Shared recommendation outputs corresponding to suggestions for an activity as well as suggestions for partners to perform an activity with may be presented individually or as a package. For example, the system 100 may perform the aforementioned shared recommendation processes such that a package of multiple activities and multiple partners is presented to a user seeking to participate in an activity in a group setting.
[0302] In a similar vein, certain aspects of the present disclosure may determine how different user personality matrices match one another. For example, the system 100 may calculate that aspects of two users' personality taste profiles corresponding to their respective user personality matrices correspond (as represented by, e.g., a percentage match). The calculation may be based on, for example, shared nodes that the two users like or dislike, similarities and features of nodes that they like or dislike, and/or nodes that the two users like or dislike that are connected through other common nodes. Aspects of visually representing the degree to which user personalities (or venue features) match are described later at least in the description relating to Figure 39.
[0303] Moreover, while the example described with respect to Figure 31 is drawn to the case in which a plurality of user personality matrices corresponding to distinct users are merged to form a combined personality matrix, it should be appreciated that aspects of the present disclosure may be adapted such that a plurality of user personality matrices corresponding to a single user may be merged to form a combined personality matrix representing multiple "moods" of the individual user. For example, a user may express particular affinities for venues based on, for example, the time of year, the location, the time of day, the group of people with whom the person is with at the present time, or the like. Specifically, the user may express certain affinities, for example, when taking trips to certain areas of the country during certain times of year, in which case the user may wish to develop a user personality matrix representing the affinities felt during those time periods, which may represent a particular mood that the user was in at that time. Similar steps may be taken for a plurality of different occasions representing different moods of the user, in which case the plurality of user personality matrices corresponding to the user's different moods may be accumulated (and stored for later use) and blended into a composite user personality matrix representing aspects of the user's various moods. The merged user personality matrices representing different moods of the same person may be weighted towards a particular mood if the user wishes to perform shared recommendation decision-making processes weighted towards the affinities associated with that mood.
[0304] Next, Figures 32A and 32B provide an illustrative example of merging two individual personality matrices 3200 and 3202 to form a combined personality matrix 3204. Turning first to Figure 32A, the individual personality matrices 3200 and 3202 include a plurality of properties and attributes with corresponding values, similar to those described above with respect to Figure 30. Of note, the respective individual personality matrices include attribute values corresponding to each respective user's personal affinity toward those attributes. Since the users may have different affinities for the different attributes, the individual personality matrices 3200 and 3202 reflect varied values for the matching attributes across both matrices. Additionally, the individual personality matrix 3202 includes attributes "U Street" and "trendy" in the neighborhood and ambience properties, respectively. These property attributes represent non-matching attributes determined, for example, at step 3106 of the algorithmic process shown in Figure 31.
[0305] As discussed above with respect to Figure 31, matching attribute values in the user personality matrices 3200 and 3202 may be summed to calculate a combined attribute value representing the overall affinity for both combined users for the particular attribute. The summed attribute values corresponding to matching attributes across the matrices may then be normalized to arrive at a combined attribute value to include the combined personality matrix. Taking the cuisine property as exemplary, combined personality matrix 3204 shown in Figure 32B illustrates that because all attribute fields in matrices 3200 and 3202's cuisine property match, the attribute values of user personality matrices 3200 and 3202 in the cuisine property field may be summed and then divided by 2 to arrive at the attribute values shown in the combined personality matrix 3204 cuisine property field. Similarly, property weights illustrated in Figure 32A for matrices 3200 and 3202 may be summed and divided by the number of users to arrive at a combined property weight value with which to include in the combined personality matrix 3204. Regarding the unmatched attribute fields discussed above for Figure 32A, the system 100 may append the unmatched attribute field values (i.e., the trendy attribute value of 0.3 and the U Street attribute value of 0.4) when forming the combined personality matrix 3204. The process of appending non-matching attribute field values is illustrated in the fact that the attribute values for the trendy and U Street attribute value fields are the same in the individual personality matrix 3202 and in the calculated combined personality matrix 3204.
[0306] After calculating a combined personality matrix, a set of shared recommendations for venues may be determined for an ensemble of users represented by the combined personality matrix. For example, candidate venues included in a merged connection graph and/or connected to restaurants included in the merged connection graph (e.g., based on
interrelational nodal strength) may be quantitatively analyzed to determine a degree to which the set of candidate venues corresponds to the unified personality profile represented by the combined personality matrix. For example, each of the candidate venues in the connection graph may be analyzed to determine their respective properties and/or attributes, at which point a value indicating a degree to which the candidates correspond to the combined personality matrix may be calculated and a set of recommendations can be presented to the group of users (e.g., via an interface). In addition to the discussion of aspects of generating recommendations based on, for example, interrelational nodal strength, Figure 33 illustrates a non-limiting example of an algorithmic flowchart for generating a shared recommendation for a group of users based on a combined personality matrix. It should be appreciated that any and all aspects of descriptions in foregoing sections related to generating
recommendations based on user data may be incorporated into the example of Figure 33.
[0307] Turning to Figure 33, the system 100 at step S3300 acquires a set of candidate venues with which to provide a shared recommendation. As a non-limiting example, the candidate venues may be acquired using a merged connection graph. In addition, the candidate venues may be acquired by analyzing the merged connection graph to determine restaurants which are not included in the merged connection graph, but have a connection to the venues in the connection graph (e.g., by way of a strong interrelational nodal strength).
[0308] The system 100 at step S3302 may analyze the candidate venues to determine their various properties and/or attributes. For example, a candidate venue corresponding to a restaurant may be analyzed by the system 100 to determine its properties relating to cuisine type, attire, ambience, etc. After determining the various properties of each of the candidate venues, the associated attributes and attribute values of each property are determined by the system 100.
[0309] Once the properties and associated attributes are determined by the system 100, the system 100 at step S3304 may then calculate a candidate venue score based on the combined personality matrix. As a non-limiting example, candidate venues may be scored in relation to the combined personality matrix based on the degree to which the candidate venue
"resonates" with the unified user profile represented by the combined personality matrix. Similar to the above-described case in which a venue recommendation is provided to an individual user based on interrelational links between the user and the venue, the combined personality matrix forms a hypothetical unified individual to which shared recommendations may be made. Nodal link strength between each candidate venue property and/or venue attribute may be calculated for all candidate venue properties, and attributes and an
aggregated score for each candidate venue may be calculated by the system 100 at step S3306.
[0310] At step S3308, the system 100 may filter candidates based on predetermined filter criterion. For example, the system 100 may filter candidates based on the aggregated score calculated at step S3306 being below a predetermined threshold level. Additionally, filters may be set in a case in which the combined personality matrix and/or another received input indicates a strongly positive or negative affinity toward a candidate venue's property and/or attributes. For example, a group of users may request a shared recommendation that is limited to only a certain set of neighborhoods, cuisine types, and price ranges. In other aspects of the present disclosure, the system 100 may determine that a candidate venue should be excluded from any shared recommendation due to, e.g., a user represented in the combined personality matrix having a medical condition and/or a religious belief that would automatically exclude such a venue from any actual decision made by the group. In certain aspects of the present disclosure, candidate venues may be immediately filtered as an input to the recommendation engine to improve processing efficiency. For example, a candidate venue may be precluded from merging to a connection graph in response to receiving an input indicating a particular candidate venue and/or a particular venue type should be excluded from shared recommendations. Further aspects of filtering are described in later sections (at least at Figure 34 and the related discussion thereto).
[0311] After calculating an aggregated score for each candidate venue and filtering out unwanted candidate venues from the shared recommendation process, the system 100 at step S3310 prioritizes the unfiltered candidates based on their aggregated score. For example, the system 100 may rank candidate venues from high to low aggregated score. In other aspects of the present disclosure, the system may segregate prioritized candidate values. For example, the venues may be ranked with respect to a given property (e.g., highest scored restaurants in a neighborhood). A candidate list of venues may be generated prior to or after filtering and/or prioritizing the venues, and the candidate list may be received as an input to the recommendation engine 1 12 for generating shared recommendations of venues.
[0312] After prioritizing the unfiltered candidate venues, the system 100 at step S3312 may then provide a shared recommendation output. In certain aspects of the present disclosure, the system 100 outputs a single candidate venue as a shared recommendation that best resonates with the group of users participating in a shared recommendation processing. In another aspect of the present disclosure, the system 100 may output a subset of candidate venues that have aggregated scores above a predetermined threshold. In further aspects of the present disclosure, subsets of the candidate venues output as shared recommendations may be selected by the users participating in the shared recommendation processing using a voting system. In further aspects of the present disclosure, the system 100 may utilize user data and/or predetermined inputs indicating that a particular user should have a higher weight when making shared recommendations (further exemplary aspects of weighting shared decision making according to user weights is discussed at least in the discussion relating to Figure 35).
[0313] In combination with, or alternatively, with respect to the recommendation processing described above calculating overall scores and outputting prioritized shared venue recommendations, the recommendation processing described herein with respect to various link strengths can be used in selected embodiments to provide recommendations to the user based on the final filtered and/or prioritized set or the final set of venues each having an overall score. As such and in selected embodiments, the processing described herein with respect to determining a set of candidate venues, scoring them based on a combined personality matrix, and identifying a final prioritized and filtered set and overall scores, provides the recommendation engine 1 12 with a smaller sample set of venues from which it will make recommendations based on link strength. In this embodiment, recommendations are made based on link strengths rather than overall score with respect to weighting values. Accordingly, if a user requests a search by providing a venue to which he has an affinity, the recommendation engine 112 will only provide recommendations based on overall link strengths with respect to the venues identified and ranked in the final filter set. The final prioritized and filtered set and/or overall scores of each venue in the final set may therefore, in selected embodiments, be used to identify the final set of venues to which the
recommendation engine 1 12 will use to provide recommendations based on overall link strength as previously described herein. Further, based on the final filter set, the
recommendation engine 1 12 may provide recommendations out of this set relating to venues of which have the strongest link strength to user attributes.
[0314] Next, Figure 34 illustrates a non-limiting example of an algorithmic flowchart for filtering candidate venues, such as in the processing related to step S3308 of Figure 33. Referring now to Figure 34, the system 100 at step S3400 acquires filter conditions with which to use in shared recommendation processing. In certain aspects of the present disclosure, the filter conditions used in shared recommendation processing are defined by the users participating in such processing. For example, a group of users participating in shared recommendations may define a set of criteria with which to focus the search when providing shared recommendations. That is, the users may define a focus area or search to limited venue properties and/or attributes, such as only searching low cost venues, only searching certain cuisine types, or only searching for venues in certain locations. In other aspects of the present disclosure, venue candidates may be explicitly identified for exclusion by the users. For example, a venue which may or may not be included in the merged connection graph may be identified by a user or users such that the identified venue candidate is excluded from being provided as a shared recommendation. In other aspects of the present disclosure, user data indicative of previous actions of one or more of the users may be acquired and utilized to generate filter conditions for shared recommendation processing. For example, user data acquired using methods set forth above may indicate that a user in a group has seen a particular movie, in which case that movie may be excluded from being provided as a shared recommendation because the user who has seen the movie is unlikely to want to see the movie again. Similarly, user data that is acquired and/or inputs received, for example, in a shared recommendation interface may eliminate certain properties and/or attributes from shared recommendation processing. For example, a shared recommendation interface may provide a filter condition section with which users may select filter conditions when performing shared recommendation searches. For example, a user may indicate a particular allergy to a certain food, in which case properties and/or attributes that are associated with the food allergy would be identified and any venue candidates corresponding to those identified properties and/or attributes would be excluded from shared recommendation processing.
[0315] Next, at step S3402 the system 100 compares the acquired filter conditions with the set of candidate venues and determines whether attributes and/or properties corresponding to the candidate venues match one or more of the filter conditions. In the case in which an attribute or property of a candidate venue matches a filter condition, the system 100 at step S3404 adjusts the aggregated score corresponding to the matched candidate venue. As a non- limiting example of adjusting the aggregated score of the candidate venue, the system 100 may add a high magnitude negative value to the aggregated score. Magnitudes of values that may be added to the score should be selected so as to ensure exclusion based on the nature of the calculation/processing. Alternatively or in addition to adjusting the aggregated score of a candidate venue, similar processes can occur at the user personality matrix such that the combined personality matrix is heavily weighted by the user's expressed negative affinity for a particular venue property and/or attribute. For example, when calculating a user's personality matrix, the system 100 may identify that the user routinely responds negatively to a particular property and/or attribute based on user data acquired as set forth above. Such analysis may trigger a "negative blocker" that is set in the user personality matrix such that the property and/or attribute to which the user has an expressed negative affinity is excluded from shared recommendation processing. Alternatively, or in addition to the processing described with respect to step S3404, a "flag" may be set in either the user personality matrix or the combined personality matrix (or in another memory area of the system 100) to indicate that a candidate venue should be excluded from shared recommendation processing. For example, the system 100 may set a bit indicating that a particular candidate venue property should be excluded.
[0316] In certain aspects of the present disclosure, the system 100 may preclude all filtered candidate venues from being output as a shared recommendation, for example, in a user interface. Such processing in essence results in candidate venues being filtered in
background processing such that the users participating in shared recommendation process are unaware that the candidate venue was filtered. In other aspects of the present disclosure, candidate venues that do trigger filter conditions may be included in prioritized shared recommendation outputs, but identified as a venue that should likely be excluded as a potential candidate in the decision making process. This allows users participating in shared recommendation processing to make an informed decision as to whether or not the venue should be excluded as a possible decision. For example, in the case in which a user's acquired user data indicates recently viewing a particular movie, users participating in shared recommendation processing in order to determine a movie that all the users in the group would enjoy may receive a prioritized recommendation output that includes the movie recently seen by the user. The movie may be identified (e.g., highlighted or otherwise demarked in a user interface) such that it is easily discernible that the venue (i.e., the movie) should likely be excluded from the decision making process. However, in the case in which the user highly enjoyed the movie and would like to see the movie again, the group of users may also appreciate the previously viewed movie being included in possible shared
recommendations for decision making.
[0317] Next, aspects of utilizing user influence weights when executing shared
recommendation processing is illustrated in the exemplary algorithmic flowchart of Figure 35. It is noted that the exemplary process illustrated in Figure 35 can be performed before or after merging user personality matrices to form a combined personality matrices. For example, aspects of Figure 35 may be incorporated into step S3310 of Figure 33 and/or into the exemplary process shown in Figure 31.
[0318] Referring now to the figure, the system 100 at step S3500 acquires the user personality matrices corresponding to all users participating in the shared recommendation decision making process. At step S3502, the system 100 determines user weights
corresponding to each of the users in the group. In certain aspects of the present disclosure, the user weights used in shared recommendation processing may be determined as received inputs, for example, from a user interface. For example, the user interface may include features allowing members of the group to indicate a particular occasion corresponding with the group decision. The indicated occasion may, for example, correspond to a user in a group's birthday, in which case the user may be provided with a higher influence user weight (i.e., 3x normal) than would otherwise be afforded that particular user. Additionally, the user interface may allow for excluding one or more users of the group in the decision-making process, such as when a user may desire to withhold influence from a shared recommendation process so that the other members of the group can happier with the outcome. In other aspects of the present disclosure, the system 100 at step S3502 may obtain user data utilizing methods set forth above, in which case the user data may indicate certain features of the users within the group that can be used to calculate user weights. That is, different "strengths of influence" over the group decision can be afforded to particular users based on acquired user data. As a non-limiting example of features which may be used to assign strengths of influence over a group decision, the system 100 may analyze acquired user data to determine relative relationships within the group, such as family hierarchy, social rank, or other group dynamics such as an individual's propensity to be difficult or otherwise picky when making a decision.
[0319] After determining user influence weights at step S3502, the system at step S3504 may adjust values in the combined personality matrix based on the determined user weights. That is, the calculated combined personality matrix may be weighted to more closely resemble one or more user's user personality matrix. In certain aspects of the present disclosure, a weighting factor may be used to weight an individual's user personality matrix during the calculation of the combined personality matrix. In this case, values in the user personality matrices may, for example, be multiplied by a weighting factor that is based on the determined user weights such that when the group members' individual user personality matrices are merged (e.g., as in Figure 31), the resultant combined personality matrix is weighted towards the users with the higher weighting factors (similar to calculating a weighted average). Similarly, negative weighting factors may be used to exclude a user personality matrix from the decision/shared recommendation process. In this case, the number of users assumed when forming/calculating the combined personality matrix may need to be adjusted, such as in the case of step S31 12 of the exemplary processing illustrated in Figure 31. Alternatively or in addition to adjusting values within the combined personality matrix to account for user weights in a decision-making process, aggregated candidate venue scores, such as those calculated at step S3306 of Figure 33, may be adjusted based on user weight. For example, system 100 may adjust the aggregated score to weight nodal linkage strengths towards a particular user's user personality matrix.
Exemplary User Interfaces
[0320] Aspects of shared recommendation processing discussed in the foregoing sections naturally lend themselves to real-time computations for determining a set of shared
recommendations given a set of restrictions across multiple users. For example, a group of users may combine taste profiles corresponding to their respective user personality matrices, set specific filters within combined taste results based on their current preferences, and obtain a dynamic list of results calculated in real time that fits the taste profile of the entire group within specific categories.
[0321] Figure 36 provides a non-limiting example of a user interface for performing shared recommendation processing. Turning to the figure, the exemplary user interface 3600 includes an area 3602, an area 3604, an area 3606, and an area 3608. The area 3602 may be provided such that a user may, e.g., select other users that should be included in a shared recommendation process for a group decision. User personality matrices from the selected users may be used when forming combined personality matrices. In certain aspects of the present disclosure, the pool of users displayed in the area 3602 may, for example, be derived from a social network, in which case the system 100 may query the social network to determine a set of potential users that may form the inputs of the combined personality matrix. In other aspects of the present disclosure, the pool of users displayed in area 3602 may, for example, be derived from a user's contact list stored in a memory.
[0322] The areas 3604 and 3606 displayed in the user interface 3600 include various attributes that may be selected for a particular property. In the case of the area 3604, the attributes correspond to different cuisine type properties (i.e., French, American, Japanese, and Italian cuisines). In the case of the area 3606, a user is prompted to select a location property from four attributes, which in this example are neighborhoods in a predetermined location (i.e., Perm Quarter, Dupont Circle, Atlas District, and Chinatown). In certain aspects of the present disclosure, the properties and/or attributes shown in the areas 3604 and 3606 may, for example, be derived as prioritized properties and/or attributes that a particular user has shown the strongest affinity for, based on derived user data. For example, a user may display the user interface 3600 on their personal mobile device, in which case the system 100 may analyze user data and/or the user's personality matrix in order to display attributes and/or properties that the user has shown the strongest affinity for in the past (in this case cuisine and location).
[0323] The area 3608 includes various filters that may be applied during shared
recommendation and/or decision making processing. As discussed previously, the exemplary filters shown in the area 3608 may be applied during shared recommendation processing such that candidate venues are filtered from the processing and therefore, would not be displayed as recommendations in response to any shared recommendation request from a user. As a non-limiting example of Figure 36, member 1, member 2, and member 4 may wish to obtain a shared recommendation for lunch. After selecting the members in the area 3602, the user may wish to limit the shared recommendation processing such that lunch recommendations are only provided for French and American restaurants in the Perm Quarter and Atlas District neighborhoods. Accordingly, the corresponding attributes of French, American, Perm Quarter, and Atlas District are selected in the areas 3604 and 3606, and the shared
recommendation processing proceeds under these limitations. The user may select additional filters in the area 3608, such as limiting the price of the American and French restaurants in the given neighborhoods to only moderately or low priced restaurants. In response to receiving this request for a shared recommendation given the aforementioned limitations, the system 100 may carry out shared recommendation processing to form the respective user personality matrices for the plurality of members requesting the shared recommendation, merge the user personality matrices to form a combined personality matrix for the users, and determine candidate venues based on the combined personality matrix while excluding all candidate venues that do not fit the stated criteria selected in the user interface 3600.
[0324] Next, Figure 37 provides another non-limiting example of a user interface 3700 that may be utilized when performing shared recommendation processing to improve decision making in a group dynamic. The exemplary user interface 3700 includes an input area 3702, which provides a universal search bar to perform a targeted shared recommendation process. In the example of Figure 37, the universal search bar of the input area 3702 queries the user with questions of what, where, and with whom a user would like to perform a certain activity. For example, a user may request a shared recommendation to make a decision amongst a first user 1 and a second user 2. The users 1 and 2 may desire a recommendation for pizza and/or sushi restaurants in Capitol Hill. In response to receiving the request for the restaurants, the system 100 may, for example, perform the shared recommendation processing set forth in the above methods, and provide a list of recommendations in the area 3704. The example of Figure 37 illustrates six restaurant recommendations, but it should be appreciated that the present disclosure may be adapted such that any number of restaurant recommendations may be made. For example, the system 100 may provide a single recommendation that best corresponds to the query limitations provided in the area 3702 and the combined personality profile of the user 1 and the user 2. Once the list of prioritized shared recommendations are displayed in the area 3704, users may then select one or more restaurants that may interest the user (e.g., Restaurant 2 and Restaurant 3 have bolded frames), and in response to the selections the system 100 may, for example, display further information regarding the restaurant, such as menus, hours of operation, reservation availability, etc. Aspects of the present disclosure may also allow users to make reservations and invite other users once a decision has been made as to which restaurant will be selected.
[0325] Next, Figure 38 provides a further non-limiting example of a user interface that may be utilized to perform aspects of the shared recommendation processing set forth by the above-described methods. The figure shows an exemplary user interface 3800, which includes an area 3802 and an area 3804. In this example, the members 1 through 4 may, for example, query the system 100 to provide restaurant recommendations with which to make a shared decision. In response to the query for a shared recommendation for restaurants, the system 100 may output prioritized recommendations based on processing set forth in methods described above. The area 3804 shown in Figure 38 may be used to provide the highest ranked prioritized restaurants. In this example three restaurants are shown, however it should be appreciated that any number of restaurants may be output as potential recommendations with which to make a group decision. The system 100 may be configured to receive an input from the user interface 3800 corresponding to "votes" for the various restaurants displayed in the area 3804. This feature may allow the members 1 through 4 to vote on the restaurants recommended by the shared recommendation processing described above. Votes for each of the restaurants displayed in the area 3804 may be tallied, and a restaurant decision may be made based on, for example, the restaurant receiving the highest number of votes. User voting may, in certain aspects of the present disclosure, be stored for future recommendations based on selection history.
[0326] Next, Figure 39 provides another non-limiting example of a user interface that may be utilized for performing the shared recommendation processing set forth in the present disclosure. In certain aspects of the present disclosure, the exemplary user interface of Figure 39 may provide a visual representation of shared affinities in a network of friends. In other aspects of the present disclosure, the exemplary user interface of Figure 39 may provide a visual representation of nodal connections between venues that may be utilized as candidates for performing shared recommendation processing. The exemplary user interface 3900 shown in Figure 39 displays a plurality of nodes 3902 through 3914. The nodes 3902 through 3914 may, in certain embodiments, represent users making a shared recommendation query to the system 100. In other aspects of the present disclosure, the nodes 3902 through 3914 may represent candidate venues, venue properties, and/or venue attributes, which may be used in the shared recommendation processing set forth by the present disclosure. The user interface 3900 may represent nodal interrelationships as overlapping nodes, such as in the case of nodes 3902 and 3904. Second and higher order inter-relational relationships may be represented in the user interface 3900, such as in the case in which two nodes do not necessarily overlap with each other but share a common overlapping node (e.g., nodes 3902 and 3904 overlap, and nodes 3902 and 3908 overlap, which may represent a second order connection with nodes 3904 and 3908). In other aspects of the present disclosure, nodal size and/or color may be used to distinguish similarities between nodes. For example, stronger shared affinities between users as represented by the combined personality matrix may be represented using bolder colors, for instance. As another example, a stronger affinity may be represented by a larger node size in the user interface 3900.
[0327] While the foregoing examples illustrate a case in which a group of users desires a shared recommendation to pick an ideal restaurant for that group of people, it should be appreciated that the present disclosure is not limited to selecting restaurant venues. As will be appreciated by one of ordinary skill, aspects of the present disclosure may easily be adapted such that other venue selections and/or shared decisions can be made. Specific examples of adapting aspects of the present disclosure to perform shared recommendation processing on non-restaurant venues include selecting clothing options based on a user personality matrix corresponding to a celebrity where the recommendations are still partially fitting with the taste of the user making the query. Further, aspects of the present disclosure may be adapted to, for example, select a balanced movie or TV show for a family movie night, search real estate for roommates or newlyweds based on their joint tastes, select a roommate for college students based on traits and tastes, creating travel packages for families or couples, selecting an activity for a group of people from a broad set of categories, selecting a college that will optimize a set of traits fitting with a student's abilities, selecting a specific business/political/military strategy by harmonizing computing interests, selecting areas to explore (e.g., mining, space exploration, etc.), and selecting a group that can work well together based on similar traits of thought patterns and/or decision making styles. Further Discussion of Collection of Venue and User Data According to Selected
Embodiments
[00328] Venue data is generated based on information determined by the crawl and parsing module 1 14 as described previously herein. For example, Figure 40 shows an exemplary corresponding matrix of attributes detected by the crawl and parsing module 114 and stored in the data repository 1 18 by the matrix builder 126. In this example each restaurant is in Boston, Mass. and the price varies on a ten point scale. Attire is assigned alphabetic codes (e.g., formal, casual, hipster), although numeric codes are used in certain embodiments. Zip codes are used as neighborhood values in this example. Venue attributes also include genres such as Japanese, Italian, American, French, Western, Chinese, pastries, desserts, and the like.
[00329] In addition to location information such as city, state country and the like, the venue attribute information can also contain coordinate information with respect to the location of each venue. In selected embodiments, this location data takes the form of latitude and longitude coordinates. This information can be obtained by comparing address information to databases containing corresponding coordinate values and retrieving that information via the crawl and parsing module 1 14. GPS and other types of location services could also be used to generated the appropriate geographic coordinate data. The coordinates can then be used to key certain venues to certain geographic grid areas as described further below with respect to spatial segmentation.
[00330] User data is generated, in part, based on the venue review data determined via the crawl and parsing module 1 14 as described herein. The crawl and parsing module 114 may have obtained information identifying that the user gave high reviews to certain venues or particular attributes of venues. For example, user affinity data for various restaurants could be obtained based on a user having posted review data or having been geographically present in particular venues for a predetermined amount of time. A user's affinity for particular venue attributes, such as genre, price, attire, hours and neighborhood, may also be determined via the crawl and parsing module 1 14.
[00331] User information is also generated upon creation of an account or in response to another triggering event such as a request for a new recommendation. The system 100 may require a user to input various data including gender, age, marital status, children ages, children gender, third parties with whom the user is socially networked, hobbies, interests, favorite venue information (in one or more venue categories), and preferred or non-preferred reviewing entities (if any). [00332] Accordingly, the user data may be input by each user and/or collected from web data sources in the manner set forth above. The matrix builder 126 then stores the user data in the data repository 1 18 as illustrated in Figure 41. Figure 41 is a chart showing a matrix of user attributes for seven users including personal attributes such as gender, age and the number of children. Personal attributes (not shown) can also include things such as profession, education, marital status, address and the like. User attributes also include favorite venues and in selected embodiments, each user is asked for favorite venues. In other embodiments, a list of preferred venues in various different venue categories is included in the user profile. As illustrated in Figure 41 , the user attributes also include their affinities for certain venue attributes such as price, genre, hours, attire, and neighborhood. Other user attributes (not shown) can include affinity levels for speed of service, quality of service, accommodations and the like.
[00333] Once all of this information is received by the server 102 via at least the user interface 110 and crawl and parsing module 1 14, the matrix builder 126 creates user affinity weighting values based on the interrelationships between the user attribute data and venue attribute data. For example, the system 100 calculates a weight value for certain user attributes such as genre, hours, price and attire and neighborhood. As noted previously herein, this information is derived at least from information received from the user or by reviewing information obtained from the crawl and parse module 114 such as prior restaurants visited, review data from the user, or financial spending habits. Therefore, if the system 100 determines that the user has previously visited or indicated American restaurants as favorable, the system 100 may apply a higher weighting value to this attribute. Similarly, the user may have a preference for a particular dress attire when visiting restaurants and therefore this information may be given a higher weight. In selected embodiments, negative weights can be assigned to user attributes deemed by this system 100 to be extremely unfavorable to the user such as a dislike of certain types of food, certain prices and the like. Additionally, general user weighting data can be derived by the system 100 based on the physical and personal attributes of the user such as age, gender, marital status and the number of kids of the user. For example, the system 100 may apply a higher weighting value to venues having a medium to high price range with a formal dress code for a middle aged married man whereas a younger user may receive higher weightings for lower priced restaurants with a more casual dress code.
[00334] The weighting values can be any numerical value such as a percentage or value on an overall scale. For example, in selected embodiments, the lowest weighting value is set to a value of zero whereas the highest weighting value is set to a value of one. Figure 42, with respect to Figure 41, illustrates a corresponding matrix of weights for various users according to one example. In Figure 42 and with respect to User 1, the system 100 has calculated a high weighting value of 0.8 for both Japanese and American restaurants as User 1 has either indicated his preference for these restaurants, he has visited these types of restaurants before or perhaps has provided positive reviews about such genres. As User 1 prefers a lower price point, the system 100 assigns a high weight to the lower price points and gradually decreases the weighting value as the price goes up. Further, Figure 42 illustrates that the system 100 assigns a high weight value to venues open later than 8:00 PM thereby identifying that this time is usually preferable to the user. The system 100 also calculates that a variety of dress codes are acceptable to the user but at varying weight levels thereby indicating that the user prefers a casual dress code but will accept a formal dress code based on other attributes involved. The neighborhood information indicates that User 1 prefers 02163 which is perhaps a location close to work or home whereas User 1 dislikes neighborhood 02196 which is perhaps a neighborhood having high crime or no public transportation options. In selected embodiments, a negative weighting value could be assigned to neighborhood 02196 to represent a more severe level of dislike for this area.
Various weight options are available as illustrated in Figure 42. For example, the system 100 has determined that User 2 would only like to receive recommendations for Italian restaurants and prefers eating at times between 5:00 and 6:00 PM. While a lower price point of 3 is preferable to User 2, the user will also accept other price points. Accordingly, the attribute weight values indicate the likes and dislikes of a plurality of users. If the system 100 does not have information with respect to certain attributes, the recommendation engine 1 12 may either ignore recommendations having these attributes or may apply a predetermined
"general" weighting value. For example, the recommendation engine 1 12 may assign a value of 0.0 to signify that the system 100 did not have any data with respect that attribute such that it is likely the user does not have an affinity for that attribute. Also, depending on the data available to the recommendation engine 112, a nominal predetermined weighting value, such as 0.2, may be assigned to indicate that the system 100 may not have enough information but should not fully penalize this attribute with respect to user taste. Further, as various factors are involved in determining the user's affinity level for a particular attribute (i.e. review data, user input data, past history data) there may be different levels of weighting for attributes identified in the same category within Figure 41. For example, Figure 41 illustrates that User 1 has a preference for both American and Japanese but Figure 42 illustrates that the system 100 has determined that User 1 prefers Japanese slightly more than American. This could be because the system 100 has determined via the crawl and parsing module 1 14 that User 1 has visited Japanese restaurants more frequently than American ones and/or the user lives closer to Japanese restaurants than American restaurants.
Spatial Segmentation
[00335] As previously described herein and with the propagation of mobile devices, it is has become increasingly common in industry to provide users with information on the go based on their location. In order to effectively provide these services, systems must have access to a multitude of information, such as venues, coupons and activities within the geographic location of particular users. For instance, if a user has just disembarked from the subway in Cambridge, MA, the system must have access to information within that specific geographic area in order to provide the user with recommendations in that area. Further, the system must efficiently determine, store and process this information in order to provide the best results to users in a timely manner.
[00336] In order to obtain and store information in different geographic areas, the server 102 performs spatial segmentation on various geographic locations. Figure 43 is a flow chart illustrating the process of spatial segmentation according to exemplary embodiments.
Initially, at Step S4300, the server 102 receives geographic data from predetermined locations all around the world (or in space). This information can be manually input by a user or retrieved via the crawl and parsing module 1 14 from generally known and available sources. For example, information may be retrieved from an online database containing geographic coordinate data from all over the world. The system 100 then systematically retrieves this data for processing in order to segment the data into various grids.
[00337] At Step S4302, the system 100 segments the geographic data into various grids have particular global coordinates. In selected embodiments, the system 100 segments the entirety of the geographic data at one time or systematically divides the geographic data into smaller portions before performing spatial segmentation into specific grids. For example, assuming the system 100 has retrieved geographic data of the entire world, the system 100 may first divide this information into continents, divide the continent information into countries and then divide the country information into states or towns and so forth. The extent of division of the geographic data is based on the degree of granularity at which the system 100 wants to create the grids based on particularities with respect to various locations. For example, the granularity level can be determined based on land area, population density, ethnicity, religion, and other cultural considerations.
[00338] Regardless of how the geographic data is divided, the system 100 then parcels up the geographic locations into grids having specific longitude and latitude coordinate values. In other words, the totality of a particular defined entity space is divided into discrete segments that are functionally independent based on their coordinate values. Figure 44 illustrates an example of spatial segmentation into grids for the state of Massachusetts in the United States. In Figure 44, a plurality of grids, such as grid 4400 and grid 4402 are formed by the server.
[00339] In order to form the grids, the system 100 may start at a particular location within the entity space and trace in a particular direction for a predetermined distance. For example, in selected embodiments and as illustrated in Figure 44, the grids are formed as squares throughout the entity space. Grid 4400 may be formed by starting in the upper left hand corner of the state and determining lines 4408 and 4410 extending from the point at a ninety degree angle for a particular distance. Once these grid boundaries are determined, enclosure lines 4412 and 4414 can then be formed at right angles from lines 4408 and 4410, respectively, for a corresponding distance to form the grid. However, it is understood that the grids are not required to be square shapes and could take any other conventional shape. In other selected embodiments, the system 100 may divide a geographic location by casting parallel latitudinal and longitudinal lines as illustrated in Figure 44 and determining coordinate data for each grid formed based on such a division. The grids may also be formed throughout particular entity spaces based on a partition amount such as a particular amount of coordinate values (i.e. degree areas) or based on distance measurements such as the amount of cross sectional miles or kilometers.
[00340] In selected embodiments, a segmentation size of a degree or less is preset for segmenting the grids. The grids could also be formed and shaped based on various geographic particularities over an entity space such as population density, venue density, uninhabited land space, and transportation and transit demographics. Accordingly, not all grids need be the same size and the system may, alternatively or in addition to distance measurements, determine grid sizes based on population density, venue density and transportation and transit demographics. For example, grids in sparsely populated areas of the entity space may be larger than grids in densely populated areas. For instance, although not shown in Figure 44, the city of Boston itself may be separated into a multitude of grids based on the large amount of venues in and around the city. As described further below, this will ensure that an appropriate amount of venues or items of interest are processed by the system 100 when receiving requests from a user based on the user's location. Further, as described further herein and although not illustrated in Figure 44, grid data is also determined for neighboring states (not shown) such that points of interest may be identified if a user was close enough to a grid within a neighboring state.
[00341] The segmentation of geographic data is not limited to areas containing land mass. For instance, grid areas, such as grid 4404, can be formed over locations containing water. These grids are formed as described above and may contain interest data such as particular spots to fish, whaling locations, diving locations and the like. Accordingly, and as previously described herein, interest data is not limited to venues such as restaurants but can include other types of interest information. This data is processed in a similar fashion as described herein to efficiently provide the user with personalized information based on his geographic location. Alternatively, in other selected embodiments, the system 100 may ignore non-land masses such as oceans, lakes and the like to greatly reduce the amount of area that has to be spatially segmented thereby increasing the efficiency of the spatial segmentation process.
[00342] Referring back to Figure 43, after the system 100 has segmented the entity space into various grids, "keys" are assigned to each grid. Items of interest and reference points are then determined at Step S4304 for each grid. Accordingly, the system 100 processes each venue stored in the data repository 1 18 to determine which grid each venue is located within based on the venue location information such as coordinate values. In other words, based on the processing performed in Step S4302, the system 100 has location information identifying the boundaries of each grid. The system 100 then performs comparison matching by identifying the coordinates of each venue and matching that venue with a certain grid and grid key based on the corresponding coordinate values of that grid. Once the system 100 identifies a particular grid for a venue, the system 100 stores in data repository 1 18 venue information, such as ID or name, in association with a key value identifying the particular grid within which the venue is located. In selected embodiments, other information with respect to the venue can also be stored in association with the grid key value such as venue attribute data. This information as well as offset information is further described below and illustrated in Figure 45. It should also be noted that venues located on a grid "border" may be identified by the system as being in both grids and will therefore be associated with multiple keys.
[00343] Once the items of interest or venues have been identified and stored in
correspondence with their particular grid keys, a reference point is determined for each grid which was generated in Step S4302. The reference point is a geographic location within the grid from which all other item of interest data will be generated (i.e. venue location information). For example, the system 100 may determine reference point 4416 based on reference point 4416s location at a corner of grid 4400. Alternatively, in other selected embodiments, the reference point may be determined based on the starting point at which the grid was formed or may be determined uniformly with respect to the location of reference points in other grids in the entity space. For example, every reference point may be identified as a point in the center of each grid. Once the reference point is determined, the coordinate values of this location are identified by the system 100 and stored in data repository 1 18 in correspondence with the Key ID for that particular grid. In selected embodiments, the system 100 may only store the reference point coordinate values themselves as the keys so that each grid is identified by the reference point coordinate values.
[00344] Once a reference point is determined for a "keyed" grid, the system 100 identifies at Step S4306 all of the items of interest data within the grid and determines offset data for each item of interest. For example and as previously noted, each venue in the grid is associated with the particular key for that grid as well as an offset value based on the reference point previously determined for the grid. In selected embodiments, the offset value is based on a coordinate offset value from the reference point based on the location of the venue within the grid. For example, Figure 44 illustrates a venue 4420 located within grid 4402 having a reference point 4418. Once the crawl and parse module 1 14 retrieves information identifying venue 4420 and the location of venue 4420, the location of venue 4420 is determined based on offset coordinate values from reference point 4418. To illustrate how the system 100 determines the offset values for venue 4420, it will be assumed, for the sake of example, that reference point 4418 is located at coordinates of (1.1001, 1.1001). Accordingly, if venue 4420 is located at coordinates (1.1005, 1.1005), then the offset value can be determined as (.004, .004) for venue 4420. These coordinates values of venue 4420 are then stored in association with the key ID for grid 4422 and the reference coordinates 4418 of grid 4422.
[00345] Referring back to Figure 43, once all of the offset data for each item of interest in a particular grid is identified, the offset data and corresponding venue ID information are stored in the data repository 1 18 at step S4308 in association with the particular key ID and reference point data. As an example and according to an exemplary embodiment, Figure 45 is a chart illustrating keyed segmentation data for the city of Cambridge, MA. The identification of three keys indicates that the system 100 spatially segmented the city of Cambridge into three grids rather than the segmentation being at the higher granularity of an overall "state" level. As described previously herein, this could be for a variety of different reasons but was most likely, in this instance, due to the volume of venues located within the city of Cambridge, MA. As such, the recommendation engine 1 12, when making
recommendations for someone in Cambridge, MA, would only want to look within smaller gridded areas to ensure that the system doesn't needlessly process locations that are far away and most likely outside the interest area of the user.
[00346] Figure 45 also illustrates the reference point coordinate data assigned to each key which has been determined and stored in the data repository as described with respect to Steps S4304, S4306 and S4308. In this example, a grid assigned key 001 has a reference point coordinate value of (41.75, -71.25) and is associated with venue 003 and venue 005 (i.e. Restaurant 3 and Restaurant 5) illustrated in Figure 40. Restaurant 3 and Restaurant 5 are associated with key 001 because they are geographically located within the grid assigned to key 001 as determined in step S4306. Further, based on the latitude and longitude
coordinates of Restaurant 3 being (41.973, -71.1213), the offset coordinates for Restaurant 3 are determined by comparing these values to the reference coordinate values of (41.75, - 71.25) to obtain offset data coordinates of (.2230, .1298). In other words, with respect to the reference point coordinate data for the grid assigned to key 001 , Restaurant 3 is
geographically at a location offset from the reference point of the grid by a value of .2230 degrees in the longitude and .1298 degrees in the latitude within the city of Cambridge, MA.
[00347] Once all of the venues have been identified within a grid, a reference point has been determined for the grid and venue offset data within that grid has been determined, and all of the information is stored in association, the system 100 determines at S4310 whether there are more grids to be processed. If there are more remaining grids, the system 100 loops back to Step S4302 to perform the above-noted processing on any additional grids that have not yet been processed. Accordingly, once this is complete and before a user has even interacted with the system 100 via the user interface 1 10, the system 100 has spatially segmented all geographic data available to the system 100, identified venues or items of interest within each of the grids, and associated this venue information with a grid key and key offset data. At this point, the system 100 proceeds to perform data encoding of the various information to provide more efficiently stored and accessible data for processing by the system 100.
Data Encoding [00348] Once the system 100 has obtained all of the information with respect to venue offset values, venue attributes and corresponding key data and reference point data, the system 100 performs encoding processing to generate a compilation of this information. This process encapsulates not only just ID data with respect to various stored items but also all other relevant information needed for the recommendation engine 1 12 to provide
personalized recommendations to the user based on the user's location, attributes, and search filter requirements. In selected embodiments, this information can be encapsulated in a string but any other data structure could be utilized to encapsulate the information. As with the spatial segmentation processing, the data encoding process is done in advance before a user has even interacted with the system 100 via the user interface 110 to request a personalized search. However, in addition to or alternatively, the system 100 may generate all of this information at run time at the time of a request by the user or at predetermined intervals in order to provide up to date information while balancing with processing and storage considerations.
[00349] Figure 46 illustrates a flow chart describing the data encoding process according to one example. At Step S4600, the system 100 obtains from the data repository 118 all of the keyed segmentation data determined from the geo-spatial segmentation processing. This includes, but is not limited to, the data illustrated in Figure 45 such as the key ID identifying each grid, the reference coordinate data for each grid and the venue ID and offset data with respect to the venues within particular grids.
[00350] The system 100 then at Step S4602 obtains from the data repository 1 18 all of the attribute data for each venue that was identified by the crawl and parsing module 1 14. This includes, but is not limited to, all of the attribute data illustrated in Figure 40 such as name, price, genre, and coordinate data.
[00351] Data processing then proceeds to Step S4604 at which point the system 100 encodes some or all of the attribute data for each venue within the data repository 1 18. In selected embodiments and as noted above, this data can take the form of a string and includes encoded representations of the attribute data values. For example, the coordinate offset data of each restaurant can be represented as a series of numeric values without intervening decimal points or place holders. Referring to the example above with respect to the offset data determined for Restaurant 3, these coordinate offset values of (.2230, .1298) could be represented simply as 2230 1298. Further, the reference point coordinate information of (41.75, -71.25) can be represented as 4175_-7125 without requiring the decimals or an indication of which value represents an abscissa or ordinate value based on the order of the numbers. This system 100 can store information indicated at what point the decimal value will be applied to the coordinate data. This information will be used to determine which restaurants are located within a reasonable distance from a user located in a particular grid.
[00352] Further, shorthand versions of important venue designation and attribute data, such as ID, price, genre and attire can be used within the string. Numeric information, such as price may be represented simply by a alphanumeric value such as 1 -10 wherein 1 signifies a lower price and 10 signifies a higher price. Further, in selected embodiments, shorthand characters or the first character of a designation type could be used to identify that attribute. For example, various letters from the cuisine designations can be used in the string to represent the venue genre or the first letter could be used. For example, the first letter of the cuisine or genre type may be used to designate the cuisine type such that the letter "p" may designate pastries, the letter "j" may designate Japanese and the letter "w" may represent Western. The style may also be represented by various letters from style designations and in selected embodiments can be represented by the first letter in the style designation. For example, the letter "c" may represent casual, the letter "f ' may represent formal and the letter "h" may represent hipster. In selected embodiments, hour of operation or any venue time related attribute information could be represented by the number and a letter for AM or PM. For example, the designation "lOa-ΙΟρ" or "lOalOp" could be used to designate that a venue is open from 10:00 AM to 10:00 PM. It is noted that any other information, such as rating data and review data, can also be encoded in short hand and stored in association with the venue as described herein.
[00353] In selected embodiments, various characters can be used to separate the information within the string identifying the venue attributes. For example, any
alphanumeric data separated by underscores may represent that it is a different venue attribute. However, any other character could also be used to separate the venue attribute data in such a fashion that the system 100 could parse the string and determine the various pieces of attribute data based on the particular character separator. Further, other characters can be used to designate that the venue has a plurality of designations for a particular venue attribute. For example, in selected embodiments, a dash could be used between attributes of the same type to designate that the venue has both characteristics. In other words, the letters A-W could be used to designate that the venue has both an American and Western motif.
[00354] Position within the string is also extremely important so that the system 100 can effectively and efficiently identify each piece of data when parsing or traversing the string. For example, in selected embodiments, the order in which the values are encoded is the ID of the restaurant, the price of the restaurant, the genre of the restaurant, the hours of operation, the attire and then the coordinate offset values. However, any order could be used. In the event that the data repository 118 does not contain certain attribute information about a particular venue, the system 100 can use a null value single character place holder such that the system 100 will not mistakenly mix up the order and miscalculate venue attribute information from the string. Accordingly, even with a shorthand representation for various attributes in which these attributes might utilize the same alphanumeric character, the system 100 will be able to identify the specific attribute based on the order.
[00355] The order in which the attributes are encoded is determined by the system in a variety of ways. In selected embodiments, the order in which the attributes are encoded within the string may indicate a ranking importance and/or weight of the property values which can be used when personalizing the recommendation described below. For instance, in selected embodiments, the quality of the attribute information may determine the order in which the attributes values are encoded. For example, if the crawl and parse module 114 has determined from a predetermined number of sources, the same information about a venue, such as the genre, the system 100 can identify this attribute value as a quality attribute value have a predetermined quality or reliability level as it has been confirmed from a variety of sources. Other attribute values that may not have as many confirming sources of information received via the crawl and parsing module 1 14 may not be determined to be as high in quality as the genre. Accordingly, the system 100 can utilize this information such that the attributes are encoded in an order based on their quality level.
[00356] Figure 47 illustrates an encoding scheme applied by the system 100 according to selected embodiments. This encoding scheme may be stored in the data repository 118. As illustrated in Figure 47, the data repository stores information representing an encoding scheme which identifies position information within a string, the data that is represented at that position in the string, the type of data at that position in the string and corresponding values of the information in the string. This information is used by the system 100 to encode and decode information with respect to venue attributes and location data. For example, in this encoding scheme, position 1 in a string numerically represents the restaurant ID, position two numerically represents the price and provides the system 100 with information such as what various numeric values represent. Therefore, the system 100 can identify that the value of 1 represents a low priced restaurant whereas the value of 10 represents a high priced restaurant. Further, values with respect to the data can take a variety of different forms based on the type of data. For example, Figure 47 identifies the third position in the string as being represented by genre having a character type and corresponding values for the different characters such as "P" for pizza and "D" for desserts. In selected embodiments, other encoding schemes may be used in combination such as converting every value to a numeric value.
[00357] Once the encoded string data is generated for each venue of each grid known to the system 100, the encoded string data is stored at Step S4606 in the data repository 118 in association with the corresponding key data or reference point data. For example, any encoded string data for a venue within a particular grid is stored in association with the key and/or reference point information for that particular grid. Figure 48 illustrates this storage scheme containing the key ID, the reference point coordinate data for each key (i.e. grid designation) and encoded data identifying venues within that particular grid as well as their attribute data. As illustrated in Figure 48, Key 1 represents the first grid created within the city of Cambridge MA having offset coordinate data (as determined above with respect to Step S4306 of Figure 43) and encoded string data for venues within that grid. In this example, and as described previously and illustrated in Figure 45, both Restaurants 3 and 4 were located within the grid identified by Key 1. Therefore, the encoded data for Restaurant 3 is represented as an encoded item of data containing 003_2_p_c_2230_1298 or when parsed "003" = Restaurant ID, "2" = a price point of two, "p" = pasteries, "c" = casual attire, and "2230 and 1298" = coordinate offset data determined previously during spatial segmentation as (.2230, .1298). As illustrated in Figure 48, the grid identified by Key 1 having reference coordinate data (41.75, -71.125) also includes encoded string data with respect to Restaurant 4 which has a price point of "3", a "chinese-japanese" cuisine, a casual- family motif and offset coordinates of (.2420, .0005). If, as in selected embodiments, these attributes were encoded in order of quality, it may signify that the system 100 had the best information with respect to price such that this was the first attribute encoded into the string of venue attribute data.
[00358] The system 100 may also store the encoded data of various venues in association with one or more grid keys and/or corresponding reference point coordinate data in a particular order to designate certain qualities about the encoded data. For instance, in selected embodiments, the order in which the encoded venue data for each venue is stored may indicate a quality level of the venue itself. For example, if the crawl and parsing module 1 14 retrieved information from various sources indicating rating levels of various venues, this information could be used by the system 100 to determine an overall quality level for the venue. The particular quality value for a particular venue may therefore be in selected embodiments encoded with the other attribute data for the venue and can also be used when the system 100 stores the encoded data for each venue in association with corresponding key and/or reference point coordinate data such that venues having a higher quality rating are stored in order based on the ratings.
[00359] Referring back to Figure 46, at Step S4608, the system determines whether there are additional grids that need to be processed in order to create encoded data for every known venue. If there are additional grids, the system 100 proceeds to create encoded string data for every venue within those remaining grids and store that information in the data repository 1 18 in association with the key and reference point coordinate data. If there are no more grids remaining to be processed, the process terminates.
[00360] In selected embodiments, the system 100 may also determine for each a grid, corresponding neighboring grids that should contemplated by the system 100 any time a user is located in a particular grid. For instance, a user in the grid designated by Key 2 may be geographically close enough to the grids represented by Keys 1 and 3 and therefore the system 100 may store Key 2 in association with Keys 1 and 3 to provide for efficient nested retrieval. Alternatively, the system 100 may store in the data repository 1 18 the reference point coordinate values as the key values themselves and therefore would store r_4200_- 07125 in association with r_4175 -07125, r_4225_-07125 and itself. This allows the system to easily locate and query these grids as well any time a query is made with respect to the grid identified by r_4200_-07125.
[00361] The number of grids to associate with a particular grid can be determined based on a number of different factors. The system 100 may systematically process each grid and for each grid store all neighboring grids in association with that particular grid. The system 100 may also have a predetermined distance amount set such that only neighboring grids within a predetermined coordinate range will be stored in association with each other. Further, the user may manually set in advance the range at which he is willing to travel thereby allowing the system to create grid associations tailored to the individual needs of each user. The user may also indicate particular areas in which he does not want to go to and the system 100 can automatically not include those grid areas in any search thereby further customizing the personalization results while also providing quicker results. Additionally, the system 100 may have information about the transit options in that area which will affect the distance at which neighboring grids are included within the key set. Further, if the system 100 knows from the user profile that the user does not have a car, the system 100 may limit the geographic boundaries at which neighboring grid data will be included in the key set.
I l l [00362] At this point, the system 100 has retrieved attribute information about the user and a plurality of venues, geo-spatially segmented all of the geographic information available to the system 100 and identified which venues belong to which grids, encoded a plurality of the data and stored this data in corresponding associations in the data repository 1 18. Therefore, the system 100 has determined all of the information necessary for a user to interact with the system 100 via the user interface 110 to receive personalized recommendations for venues within a user locale.
Recommendation Processing
[00363] Either the system 100 or users 108 may trigger the recommendation engine 112. The users may do so by entering through a web portal via the network 120, client application or electronic message a request that a recommendation be generated based on provided venue attributes such as for example type, geography and/or price. The system 100 may access a user profile to collect the user attribute data identified in Figure 41 from the user profile such as other venues liked, gender, profession, or age. The system 100 may also automatically generate recommendations for inclusion in electronic messages, such as text messages or email messages, sent to targeted users or for presentation on a web portal or client application accessed by users.
[00364] Figure 49 is a flow chart illustrating the steps taken by the system 100 to provide personalized recommendations to users 108. Initially, at Step S4900, the system 100 receives a recommendation request from a user for a personalized recommendation based on a location of the user and/or a predetermined location. When requesting a personalized recommendation, the system 100 receives recommendation requirements from the user as part of the request. Specifically, the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates. Alternatively, the system 100 may automatically provide a request based on information about a location of the user and/or habits of the user. For example, if the system 100 determines that the user crosses into a different grid, the recommendation engine 1 12 may automatically generate recommendations based on the users location within the new grid and likes and dislikes previously known to the system 100. For further discussions below and as an example, it will be assumed that the user has requested recommendations for an American restaurant having a four point price point located in or around coordinates (42.03, -71.10)
[00365] Once the system 100 has received the request or has decided to automatically provide a recommendation to the user, the system 100 determines at Step S4902 which grid the user is located in or which grid has location information pertaining to a particular request. As noted herein, the user may provide the system with particular coordinates or the system 100 may determine the location of the user via GPS based on a user's mobile devices and applications. To determine the grid the user is located in or of which the user has request information for, the system 100 uses the coordinates provided by the user and identifies the closest key coordinate data. Based on the example discussed above, the system 100 would determine that the closest reference point coordinate key data is the grid defined by (42.00, - 71.25) or reference point r_4200_-07125. In order to determine the closest grid, the system 100 may poll the grid data contained within the data repository 1 18 and pick the grid with the smallest offset from the provided location data. The system 100 may reduce the time of such processing by only searching specific locations within the data repository 1 18. For example, if the system 100 knows that the user is located in Boston, MA, United States based on the user profile, the system 100 may only compare the user location data with location data from that particular area. Further, if the user provides location data other than where the user is located, the system 100 may use the coordinates to determine the generalized location in the world and then only seek coordinate reference key data for that particular area in the data repository 1 18.
[00366] Once the system 100 has determined the closest key data for the user location data, the system 100 retrieves at Step S4904 all of the keys that are linked to that particular key data. For example and as described previously herein with respect to at least Figure 43, each key will often be linked to other neighboring keys. Therefore, the system 100 may easily retrieve the appropriate key set based on the nested key data. The system 100 then retrieves from the data repository 1 18 at Step S4906 all of the encoded venue or item of interest data corresponding to the reference point coordinate key data determined in step S4904. At this point, the system 100 has identified every venue within a reasonable distance from the coordinate data provided by the user in the recommendation request.
[00367] The system 100 must then filter at Step S4908 this information based on specific request information provided in the recommendation request. For example, the user may request only American restaurants within a particular price range or the system 100, when auto-generating recommendations, may know particular user affinities and therefore filter the data set based on these affinities. Based on the example discussed above, the user only wants recommendations for American restaurants having a price point of four. To accomplish this feature, the system 100 generates a nodal excitation pattern based on the particularities of the specific request for the user. For example, the excitation pattern ([\\4]+)_(\\-?A\\- ?)_([Λ_]+)_(.*) may be generated for this particular request by the recommendation engine 1 12. The excitation pattern indicates a value of "4" for the price point and a value "A" for American restaurants in an order in which the encoded data is stored and in a similar fashion in which the encoded data is stored. This pattern is then matched against all of the encoded data patterns that were determined in Step S4906. In this example, there would be matches for Restaurants 1 and 5 based on a match of the nodal excitation pattern with 101_4_A-W_F- R_0123_1699 and 105_4_A-F-h_0950_2475.
[00368] Once the final filtered set is determined by the recommendation engine 112 as described in Step S4908, the recommendation engine 1 12 must then personalize at Step S4910 the recommendation by applying the user attribute weights illustrated in Figure 42 to the venues and venue attributes identified in the final filter set. In order to apply the user attribute weights, the system 100 parses or decodes each encoded string in the final filter set to determine the particular venue attributes of the venues in the final filter set. Once these attributes are determined for each venue in the filter set, the recommendation engine 1 12 applies the user attribute weights to the appropriate attributes for each venue. The results for each attribute weighting value are then summed for each venue to provide a total excitation score for each venue in the final filter set. Attributes not having a corresponding attribute weight can be ignored or provided with a general attribute weight value. The venue having the highest score can then be recommended to the user as their personalized recommendation or a ranked listing of the venues can be provided to the user based on score. The
recommendation engine 112 can also provide a plurality of venues to give the user some choice by always providing a predetermined amount of venues (determined automatically or set manually by the user) to the user. Alternatively, in other selected embodiments only venue scores passing a predetermined threshold value are provided to the user via the user interface 1 10. Once the recommendation engine 1 12 has determined which recommendations will be provided to the user, the recommendation engine 1 12 accesses the information stored in the data repository 118 and illustrated in Figure 40 based on the parsed encoded data in the final filter set for each venue to provide all of the necessary venue information to the user. Therefore, as described further below, the system 100 does not have to have all of the full character object information (i.e. American, Price Point 4) ahead of time to provide personalized recommendations and can therefore operate more efficiently and effectively.
[00369] With respect to the example identified above of a user request for
recommendations for an American restaurant at a price point of four dollars and located near (42.03, -71.10), the recommendation engine 1 12 has identified two matches and therefore will parse the encoded string data for Restaurant 1 and Restaurant 5 to determine the venue attributes therein. Accordingly, the recommendation engine 1 12 will identify for Restaurant 1 having an encoded pattern of 101_4_A-W_F-R_0123_1699 the following values: 101 , 4, A-W, F-R, 0123, 1699 which signify, as discussed above for selected embodiments, restaurant ID "101," a price attribute value of "4," a genre attribute value of "American, Western," a dress code attribute of "Formal, Romantic" and offset coordinates for the location of Restaurant 1. For Restaurant 5 having an encoded pattern of 105_4_A-F- h_0950_2475 the recommendation engine 1 12 will parse the following values: 105, 4, A-F, h, 0950, 2475 signifying Restaurant "105," a price value of "4," a genre of "American, French," "hipster" attire, and offset coordinates for the location for the location of the restaurant.
[00370] Having parsed out the various attributes from the encoded data for Restaurants 1 and 5, the recommendation engine 1 12 applies the user weighting values illustrated in Figure 42 for a particular user based on the venue attributes. For example, assuming User 1 made the request, for Restaurant 1 the attribute weight value for a price value of "4" is 0.5, the attribute weight value for American is 0.7, the attribute weight value for French = 0.5, and the attribute weight value for a Formal dress code is 0.5. As there is no weighted attribute value for User 1 for romantic dress codes, the recommendation in selected embodiments may assign a value of 0.0 or a predetermined weighting value such as 0.2. Assuming a value of 0.2 is supplied for romantic dress code, an overall score for Restaurant 1 is (0.5 + 0.7 + 0.5 + 0.5 + 0.2) = 0.24.
[00371] With respect to Restaurant 5, the recommendation engine 1 12 applies the user weighting values illustrated in Figure 42 for a particular user based on the venue attributes. With respect to User 1, the attribute weight value for a price of "4" = 0.5, the attribute weight value for American = 0.7, the attribute weight value for French = 0.5, and the attribute weight value for hipster attire = 0.7. Accordingly, an overall score for Restaurant 5 is (0.5 + 0.7 + 0.5 + 0.6) = 0.23.
[00372] At this point, the system 100 has determined all of the venues in a location near the user, determined which venues best match the encoded values of each venue within the area, filtered the set of venues to a final filter set and determined overall scores for each venue in the filter set. The recommendation engine 1 12 may then provide at step S4912 a variety of outputs to the user such as supplying only Restaurant 1 to the user via user interface 1 10 as it has the highest overall score. In other selected embodiments, the recommendation engine 1 12 may provide both Restaurant 1 and Restaurant 5 but with Restaurant 1 ranked slightly higher than Restaurant 5 based on the overall scores. In selected embodiments, the recommendation engine 1 12 may set a predetermined recommendation threshold, such as 0.24, and only provide restaurants meeting or exceeding this value. In this case, only Restaurant 1 would be supplied to User 1 via the user interface 1 10. Assuming none of the recommendations are above threshold value, geometric contextualization could be implemented as described herein to resolve this issue.
[00373] Additional scoring methodologies are considered in selected embodiments such as assigning an additional weighting factor to venues in the final filter set which match venues which have been favorited by users as illustrated in Figure 42. With respect to the example above in relation to User 1 , an additional weighting value may be applied to the overall score of 0.24 based on the Restaurant ID value "001 " because Restaurant 1 has been indicated by User 1 as one of his favorite venues. Additionally, weights can be added based on prior purchase history, prior visit history, how close a restaurant is to the user's current location, home location, or work location, or based on recommendations previously made to the user by the recommendation engine 1 12.
[00374] In combination with, or alternatively, with respect to the recommendation processing described above (S4912) relating to the overall scores, the recommendation processing described herein with respect to various link strengths can be used in selected embodiments to provide recommendations to the user based on the final filter set or the final set of venues each having an overall score. As such and in selected embodiments, the processing described herein with respect to determining a list of venues, encoding them, and identifying a final filter set and overall scores, provides the recommendation engine 1 12 with a smaller sample set of venues from which it will make recommendations based on link strength. In this embodiment, recommendations are made based on link strengths rather than overall score with respect to weighting values. Accordingly, if a user requests a search by providing a venue to which he has an affinity, the recommendation engine 112 will only provide recommendations based on overall link strengths with respect to the venues identified and ranked in the final filter set. The final filter set and/or overall scores of each venue in the final filter set may therefore, in selected embodiments, be used to identify the final set of venues to which the recommendation engine 1 12 will use to provide recommendations based on overall link strength as previously described herein. Further, based on the final filter set, the recommendation engine 1 12 may provide recommendations out of this set relating to venues of which have the strongest link strength to user attributes.
[00375] Alternatively, the final filter set of venues having overall scores for each venue may be applied to different recommendation systems. In other words, the methodology described at least in FIGS. 40-49 generates a final filtered set of candidates based on various factors which can then be used as a data set which is provided to the recommendation engine 1 12 described herein or to other recommendation systems. Those recommendation systems may then determine how to make use of the information to provide the user with various types of information such as rankings.
[00376] The systems and methodologies described above provide a variety of advantages over current systems and techniques. By efficiently segmenting areas into grids having corresponding key data and storing this information in association with efficiently encoded data, it provides the system 100 with the ability to efficiently and effectively retrieve particular information. Further, the enhanced encoding schemes described herein allow the system to rapidly encode and decode the data while saving on storage space and processing requirements. Under this system, data can be pre-calculated for all users and combinations with minimal memory requirements thereby allowing for faster retrieval and processing of user recommendations. Accordingly, one hit to the data repository 118 can return not only a list of all objects that fall into spatially segmented area but also all of the features of those objects at which point they can be readily operated on to determine personalized
recommendations. This does not require the system to retrieve the full data objects such as restaurant name, genre, attire, etc as the encoded information is all that is required. Further, as the final filter set provides a reduced amount of venues which are relevant to the user, the recommendation engine 1 12 is able to more efficiently generate recommendations based on overall link strength with respect to the final filter set. Further, due to the various encoding and storing methodologies, the system 100 can determine from one storage table of information, the attributes of venues, where they are located, which grid they are located in, relative weights of each venue or venue attributes, and the relative quality of the venue.
[00377] The spatial segmentation further provides the ability for the system 100 to determine objects of interest accurately and efficiently while also allowing the system 100 to easily identify neighboring spatial segments that should be intermingled with each other. The segmentation size allows for decimal offset values thereby requiring only a small storage space and enabling efficient processing to determine key and offset data.
[0378] As previously described herein, it is noted that the techniques described herein are not limited to geographic data and may also be used for determining recommendations in other spaces. For example, the processing described herein could be applied to
recommendations for a particular wine. In this case, segmentation may not be performed by coordinates but rather by "type" of wine (i.e. red, white, rose, etc). Segmentation can then be relied upon to filter various requests by ignoring certain segmented areas such as red wine and white wine when the user request recommendations for a rose. In this instance, a key would be assigned to each type of wine and then stored in association with all of the identified wines for that type. Attributes of each wine would then be encoded and stored in association with the corresponding key based on the type of wine. Excitation patterns would then be utilized based on the user request to identify a list of particular wines and then the wines identified in that final filter set would be decoded and ranked based on their attributes to identify an overall ranking based on individual scores. Link strengths could also be used as described herein to recommend wines having strong link strengths to those identified by the user or generated based on user attributes. By segmenting the keys based on this principle of axis and consideration for category, efficient access to relevant recommendations indexed by key can be provided.
Illustrative Implementation
[0379] One illustrative system implementation consistent with the foregoing teachings is discussed below. The discussion is generally organized into four sections: content collection, content organization, personalization and user interface.
[0380] The purpose of the Content Collection system is to perform 3 steps:
1) identify "objects" (venues, events, and other instances of interest to the user),
2) find/match electronic pages with deep information on those objects (object characteristics, reviews, associations with other objects), and
3) retrieve pages into the storage system.
[0381] The objects to be retrieval in this example constitute any set of web pages based on objects of interest. The objects may be selected based on category, filters for a particular category and the content sources that are targeted.
[0382] This type of retrieval can in turn be broken up into several Content Modes. Content Mode 1 is called "Global Grab." In this mode, the system seeks to identify and retrieve information on every object in a category (e.g., "all restaurants in San Diego"). In Content Mode 2, Keeping Current, the system seeks to focus the collection on either (i) refreshing stale information on old objects, or (ii) identifying new objects that just arose for old categories. In Content Mode 3, known as Intelligent Browsing, the system seeks to have the data search update itself dynamically based on its real-time discoveries, to "zoom in" and focus on specific trends and objects. [0383] One type of Global Grab is spidering. This is a conventional method used by Internet search engines according to which the system downloads the page of a content provider's site, scans that page for links to other pages on the site, and then downloads those pages. By repeating this process an entire site can be covered. The system can also implement paginated searches in which the system actively seeks, for example, page 1 of a term like "Restaurants," then page 2, and so on.
[0384] A second type of Global Grab is crawling. Sometimes it is desirable not to have to get pages directly from a content site, such as where the site blocks automated indexing. In this case one can replicate the structure of a site from the cache of a search engine, which crawl and cache every page as a "second copy" of the internet. Here, the system uses a search engine to search for the URL of interest. Usually, the URL will be included in the first result, along with a "Cached Page" link to the cached copy of the page. The system can then download the link listed in the "Cached Page," which is the same as the original page. The system can then scan that page for links to other pages on the site, and repeat the process for those pages.
[0385] A third type of Global Grab involves getting a list of all objects and then finding them within a site. This is a method designed to be more holistic than spidering, to ensure that every single object of a category is retrieved from a given site if available. First, a complete list of target objects is created, such as by crawling an internet directory like
Yellowpages.com for "restaurants in San Diego." Then the system will have the complete list of objects for which data is desired. The next step is to search for each of these objects in turn in a search engine, restricting the search to the pages from the target website. Different combinations of data extracted from the internet directory can be used to seed the search query, and usually the business name, metro name, and phone number are useful ways to lock onto the object on the target site.
[0386] The search engine will retrieve pages that match these search query parameters on the target site of interest. Usually one of the first few pages in the results is the correct match. By repeating this search engine and retrieval process for every object in the Internet directory, the system is likely build a complete replica of the target site's data on that category.
[0387] A fourth type of Global Grab involves third-party crawlers. It is contemplated that third party services will crawl the web and make the results of those crawls available for purchase. In this case, the first step of the global grab methodology is simplified because the system can query the service for every page arising from a certain set of websites. If such third party services also make the pages available for retrieval then the speed of the crawl is increased.
[0388] Turning to Content Mode 2, Keeping Current, it is assumed that the system has completed a global grab and has data on all objects for a given category. The task then becomes staying current, or up to date, with the objects as their data changes. New objects can be introduced, such as when restaurants open. Old objects can become outdated, such as when restaurants close. Data on objects can change, such as when the hours of operation or menu items change. New and old objects can be identified by doing a crawl on global directories (which is fast) and then focusing in on any changes to the list of objects.
Alternatively, the system can discard old data and then run a new global grab. Finally, the system can rely on "update notifications" which can be acquired in several forms: (i) some websites focus on these changes, such as "listings of new restaurants" in local papers, (ii) many content provider APIs will notify of openings and closings of sites, (iii) URLs and webpage titles will often receive a "CLOSED" stamp which can be rapidly screened. Each datum collected by the system is tagged with an expiration date, based on the type of the data (events expire immediately, restaurants may need to be refreshed every few months to check for major changes). Data that has expired can have associated pages re-retrieved for freshness. The re-retrieval process is simplified because the URL is already known.
[0389] Content Mode 3, Intelligent Coordinated Retrieval, involves "eating nodes," or retrieval computers, that can coordinate their searches based on real-time events to optimize content gathering in response to mass user behavior. In this implementation the retrieval computers are given "write" access to the retrieval queue. If the retrieval computers identify a trend that is similar to their original target, but stronger, the retrieval computers can recruit other computers to look more deeply at this phenomenon by writing the new target (or a set of targets within a target area) onto the retrieval queue. Retrieval computers can also interact intelligently in the collection process by alerting each others if a lead turns out to be faulty, and is indicative of more faulty leads (for example, if a region of a site is covered with spam or stale data). In this case, the retrieval computer(s) can scan the queue and delete similar jobs on the queue so that future computers don't devote resources to exploration of a lower value target area. In this way, different search nodes again inform one another about what they learn by virtue of the shared queue to help guide their collective search.
[0390] Turning next to matching objects to content pages, whenever the system is gathering data from target websites on an object of interest, the system should ensure that the data on the target site is actually referring to the object of interest. This is especially true when attempting to cross-reference objects across different sites. The system optionally utilizes a "likelihood of match" score to make this determination, taking into account multiple variables. For example, if the system is trying to match a venue on two different sites, the fact that they have the same phone number or address may tend to indicate that they are the same venue. Numeric identifiers on consistent scales are particularly valuable for this purpose, such as phone numbers, UPC symbols, and latitude/longitude. Non-numeric identifiers (strings) such as addresses can also be used, and one can check the similarity of the two sites' addresses by taking a Hamming distance on the characters, or parsing out each one's street number, street name, etc.
[0391] Data is cross-referenced across multiple sites by using data from one site to choose objects to find on another site, then use the steps discussed above to find new content pages from those objects on a different site.
[0392] A fleet of retrieval computers may be created by building each from scratch programmatically. Each computer is resurrected from a disk image, such as an Amazon Machine Image (AMI). The AMI is loaded as an elastic computing node on Amazon's EC2 (elastic cloud computing) or other service using standard libraries written in Java. The AMI is armed with everything that the computer will need, including a Java runtime environment, the capacity to communicate with a central version control repository such as Git, etc. The AMI is also armed with a startup script that runs when the EC2 node is born, and receives user parameters passed to the EC2 node at birth. The user parameters to the startup script tell it where to download the latest code instructions for the node, such as the URL of an S3 location, or the URL of a Git repository. The startup script is armed with the credentials to access the latest code instructions, and load the code onto the new EC2 node. Every EC2 node in the fleet downloads similar instructions, so they are all prepped around a common task. These instructions tell it how to connect to the message queue with the URLs to retrieve, and also how to go about the retrieval process. Each one then launches the downloaded code (runs the JAR file, etc) and thus begins working. Finally, each computer in the fleet is assigned its own IP address (via Amazon's Elastic IP system, etc) so that they can be throttled by content sites independently from the other nodes and work in parallel.
[0393] Tasks are distributed amongst the fleet of retrieval computers by using a list of URLs (usually long, millions) of pages that the system wants to retrieve. This list might be a text file, database table, or other simple serial storage system. The goal is to distribute those URLs among the many computers. This process is best implemented through a queue service that lives independently from all the retrieval computers. As an example, Amazon offers the Simple Queuing Service (SQS) in which every URL is stored as a string message on the queue. Thus, the queue retains a memory of which URLs still are to be crawled. Each computer in the fleet can query the queue for the next item to be crawled. The queue then assigns the item to a particular retrieval computer, and marks the item as "locked" so that other retrieval computers do not also try to work on the item. Meanwhile, the system monitors whether the retrieval computer completes the task in a timely manner. If the retrieval computer does not check back with the queue to say that the job is done, then the queue restores the item to "unlocked" so that other computers can perform the task. Once a computer checks back with the queue and informs it that the task has been completed the queue removes the item from the queue. Thus, a workflow is established that can be shared between an arbitrary number of retrieval computers where they can operate simultaneously to work through a list of retrieval tasks.
[0394] Pages are retrieved by all computers in the fleet. Each retrieval computer is already armed with a URL to retrieve by taking the message from the messaging queue. The computer then executes a function to stream the contents of the remote file (webpage, etc) into memory (in PHP, file_get_contents; in Java, url.openStream( ); etc). The computer then saves this file to the global storage system (see below). With respect to rate of repetition, it should be noted that no single computer hits a given content source too rapidly. Therefore, each computer is "throttled" to only complete one page request every 0.1-10 seconds. The use of third party crawlers, discussed above, may obviate the need to throttle in this manner. Every page request is checked to determine if it succeeded, and if failure occurs, a longer interval is used before the next attempt. The system can implement different schedules for the interval rollback, such as an exponential rollback.
[0395] The global storage system may be a distributed storage platform (Amazon S3, etc). In the case of Amazon S3, data is stored in buckets that are accessible from any computer as a URL. Each retrieval computer stores the contents of the retrieved file in a repository folder on S3 (or other service) as a file path string which is also URL. The file can thus be retrieved at a later date by entering the storage system URL. Access to these repository folders is private so that they can only be accessed by the system's Content Collection and Content Organization systems.
[0396] Turning now to content organization, the aim is to take content collected from the Internet and organize it for access through the Interface. The input may be a hard drive directory of the latest set of collected web pages. The output may be the data uploaded to a large-scale (but highly organized) database. The output may be generated by repeating the following process: 1) find a page, 2) parse the page for info, 3) match the page to an object in the database, and 4) update the database.
[0397] Another computer fleet may be deployed to organize the content. As noted above in the case of retrieval computers, content organization computers may be replicated by building them from scratch programmatically. Each computer is resurrected from a disk image, such as an Amazon Machine Image (AMI). The AMI is loaded as an elastic computing node on Amazon's EC2 (elastic cloud computing) or other service using standard libraries written in Java. The AMI is armed with everything that the computer will need, including a Java runtime environment, the capacity to communicate with a central version control repository such as Git, etc. The AMI is also armed with a startup script that runs when the EC2 node is born, and receives user parameters passed to the EC2 node at birth. The user parameters to the startup script tell it where to download the latest code instructions for the node, such as the URL of an S3 location, or the URL of a Git repository. The startup script is armed with the credentials to access the latest code instructions, and load the code onto the new EC2 node. Every EC2 node in the fleet downloads similar instructions, so they are all prepped around a common task.
[0398] Every computer in the Content Organization fleet receives 2 pieces of information (which it is programmed to seek out using in its boot instructions): 1) the storage space location of the code instructions to be its brain, 2) the location address of the job queue where it will receive the material to be processed. The system controls the Content Organization fleet by creating and managing the content organization process. The system defines the storage directory of all the pages that need to be organized. The system thus turns this directory into a list of jobs, where each job is a file to be processed. The system then creates a task queue (see below), loads that queue up with the tasks, and sets the properties of the queue to determine the time allotted for task completion before tasks are recalled and given to other computers.
[0399] The task queue may be implemented using Amazon Simple Queue Service (SQS) or some other service that is external to individual computers. The system loads up the job queue with a list of pages that need to be organized. Each item in the queue is a URL address in global storage space to a page that needs to be organized. The goal is to distribute those URLs among the many computers. The queue allows computers to take URLs, and retains a memory of which URLs still must be organized. Each computer in the fleet can query the queue for the next item to be crawled. The queue then assigns the item to the computer, and marks the item as "locked" so that other computers do not also try to work on the item. Meanwhile, the system monitors the queue to determine whether the computer completes the task in a timely manner. If the computer does not indicate to the queue that the task is done within the allotted time the queue restores the item to "unlocked" so that other computers can take the task. Once a computer checks back with the queue to say that it has completed the task, the queue removes the task from the queue. Thus, a workflow is established that can be shared between an arbitrary number of computers where they can operate simultaneously to work through a list of retrieval tasks.
[0400] The global storage system for the Content Collection fleet may be a distributed storage platform (Amazon S3, etc.). In the case of Amazon S3, data is stored in buckets that are accessible from any computer as a URL. Each retrieval computer stores the contents of the retrieved file in a repository folder on S3 (or other service) as a filepath string which is also URL. The file can thus be retrieved at a later date by entering the storage system URL. Access to these repository folders is restricted so that they can only be accessed by the system's Content Collection and Content Organization systems.
[0401] The system may utilize the following global structure for document namespaces: date_retrieved/data_format/content_provider/city/category/. For example: 201 1-07- 07/xml/google/boston/restaurants/. However, depending on the source of the crawl, the raw data files may not even be organized into this directory structure yet. In this case the crawl results should be sorted into files that are organized according to this structure.
[0402] To sorting raw crawl results, the system first inspects all the files retrieved during Content Collection and sort them according to the objects that they represent. One way to do so is inspect the URL of the crawl. The URL will disclose the content provider, the city/metro area, and category. For sites where this cannot be computed from the URL, the data can be extracted from elsewhere in the file (address field, etc.) The date of the crawl can be retrieved from the stored file's metadata. The crawl result file (or part of the crawl result file) that applies to the extracted object can then be saved in the directory structure described above. In this manner, all of the raw crawl results are placed in an organized directory structure to facilitate the subsequent organization to the database.
[0403] The queue is loaded by accessing the storage system directory where the sorted documents are located (see above). The system then spiders this directory to uncover the list of all files within that directory and its sub-directories. The system then creates a job queue (described above) to hold the list of files to parse. Next, the system uploads to the queue a list of file locations (URLs to the files), as an array of messages, to the queue. At this point the queue is loaded with a set of files to be parsed and organized. [0404] Every time a computer in the fleet goes to the queue and retrieves a sorted page to organize, it first analyzes the following information from the URL: the "data format", which determines how to read the file's data; the "content provider", which determines which page parser to apply; and the "category", which determines what type of object to extract. The computer already has in its memory all of the different parsers that it downloaded when it was deployed. The computer picks one out based on the content provider and data format, and runs it on the file. Input is the file itself and the output is a data object in memory with values extracted from the file and stored in fields.
[0405] Every time a computer parses a file, and stores its data object in memory, the data is next added to the database. First, the computer has to identify the object's location in the database. This is accomplished by selecting the database table (in Amazon, a domain) based on the category of the object, and locating the row of the object by using, in descending order: i) the unique id of the object from the content provider (for example, restaurant id on local.yahoo.com), ii) another unique numerical identifier, such as the phone number, and iii) name, address, and latitude/longitude fuzzy matching. If the determined entry does not already exist, the computer creates a new row. The computer then runs an update on that row, updating every attribute (field) in a single database hit for efficiency. This is repeated for every sorted page that the computers come across in the queue, until all of the sorted pages have been organized into the database.
[0406] Next, the system personalizes the content by generating a neural network architecture that connects objects in the world as nodes within a network. The system activates a subset of the nodes based on what is known about the user's affinities. The activations are followed through the network to deduce what else the user will like.
[0407] The neural network may be implemented as follows. Connections TO a node a stored as a list of {Nl, Wl , N2, W2, ... } where the connected nodes N are paired with their weights W. This list is saved in the database in the same row as the other properties of the node.
Optionally, a list of connections FROM the node can also be stored. Subsets of nodes to be activated are identified by user-provided data regarding likes and dislikes. Users may be required to answer regarding their "favorites" in different categories. Users may also provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or -10 to 10). The system assembles a list of "positive activation nodes" and assign an activation level, which were either favorites (e.g., 10H activation) or feedback-driven (e.g., 1-1 OH activation). Similarly, the system assembles a list of "negative activation nodes" and assigns an activation level (e.g., -1H to -10H).
[0408] Connections are established by, for every node in the user's list, accessing in the database the set of common co-occurrences with that object on the web. The system retrieves this list of objects and builds connections from our node to those objects with five positive synapses each.
[0409] Connections also may be based on feature similarity. For every node in the user's list, the system identifies nodes with similar properties. For the category to be matched, the system takes the most salient properties (e.g., for a restaurant, price, cuisine and ambiance) and searches the database for other restaurants that match that feature set. Each match generates two positive synapses.
[0410] Connections also may be established based on cross-visitation. For every node in the user's list, the system identifies nodes that have been cross- visited by other users. These users can be users of the system (e.g., users of a subscription service associated with the system) or activity elsewhere on the Internet about which the system has data. This may be accomplished by indexing the reviews and responses to all nodes. The system identifies strong responses to the node of interest, identifies the users that furnished those responses, and identifies other nodes to which those users had similarly strong responses. The system can connect those nodes to our node of interest, with one positive synapse for every similar response.
[0411] Negative synapses can facilitate the recommendation process by factoring in what the user does not like and the things that are not like things that the user does like. Both of these associates involve negative synapses, which add richness to the representation. For example, the system can identify strong responses to the node of interest, identify users that made those responses, and identify other nodes to which those users had opposite strong responses.
Alternatively, the system can identify nodes that the user did not like, identify other people who did not like that node, identify nodes that those people did like and positively link those nodes to our user's preferences.
[0412] Sometimes the network may exhibit "runaway connectivity" where something gets more connected, which then gives it an advantage in getting further connected (e.g., more cooccurrences) which in turn tends to generate even further connections. Therefore the system may normalize connectivity by inspecting the list of existing connections to a node, determining their total value (e.g., # connections N.times. average weight W), and in the event that total value exceeds some threshold, divide all of the connection weights by a constant value to bring them back into range. This may be repeated for all nodes. Normalization alternatively can be accomplished by dividing based on the N*W term going TO the node, dividing based on the N*W term coming FROM the node, dividing by the total N*W term across the network. The implementation for this may involve reading the list of node weights in the database, performing the normalization on those weights, and writing the new weights back to the database.
[0413] The addition of a new synapse connecting nodes can also immediately impact other connections. Upon adding the connection to the list, the other connections to that node can be "taxed" by an amount equal to the inverse of their proportion of the new connection's strength—that is, adding a +1 synapse then taxes the other 10 synapses already on that node by 1/10=0.1. When synapses become so weak that they are below a certain threshold (either through interaction taxing or through normalization), then they are removed (deleted from the list).
[0414] Connections from node to node can be constantly analyzed, updated and consolidated to take into account patterns that emerge between nodes. As a simple example, if A forms a strong link to B, and A forms a strong link to C, then a connection can be consolidated linking B and C. Such patterns can be searched for using specialized scripts that check the database entries for such patterns, and then write back consolidation changes to the affected nodes' lists.
[0415] The result of all of these processes is a rich information base that accurately links a huge variety of nodes to a user's established nodes of interest, with a significant dynamic range, and with substantial retrieval efficiency.
[0416] To retrieve the list of nodes related to a user, the system need only then "activate" the user's established nodes, and follow their connections to retrieve more nodes that if connected sufficiently strongly will also activate, and depending on the initial activation strength follow those connections to further nodes until the activation peters out with each connection hop depending on the connection strength. The connection strength is therefore the inverse of the resistance to the propagation of the activation through the network.
[0417] The total list of nodes that was effectively activated by this process (recommendation set) can then be stored in a list that is linked to the user in the database, for retrieval with a single database call whereupon the list can be cross-referenced against a set of presented results. Optionally, different sub-lists can be stored for different categories, or different presentation scenarios, caching the results for fast personalization. [0418] The user interface may comprise i) a set of HTML files that define the look and feel of the web interface, with design elements styled using cascading style sheets (CSS), iii) a server-side set of scripts that dynamically generate those HTML files using a backend scripting language (PHP, etc) running on a web server (Apache, etc.), iii) a client-side set of scripts and interface libraries that allows rich user interaction within the browser (Javascript, j Query, etc.), and iv) a backend database that provides the data to the web application
(Amazon SimpleDB, etc.).
[0419] The functionality of the user interface includes permitting the user to create an account and log in using secure credentials that are verified against an encrypted user table in our backend database. The interface also allows a user to browse objects and see whether they are recommended or not. The interface allows a user to filter those objects by city, by category, and then by a host of properties pertinent to those categories. The user can enter feedback on their recommendations by clicking on thumbs up/thumbs down or other feedback mechanisms. The interface allows a user to drag and drop recommendations onto a "being considered" area where they can be compared across different parameters using sortable headers, etc. The interface allows a user to drag an object onto their calendar in order to "action" it by going to the object at a certain time. The interface allows a user to build events, such as "My New York City Trip" where the user can create a group of restaurants, hotels, and other opportunities that have been recommended. The user can enter notes about their recommendations to remind themselves of various impressions, for example. The user can print out a copy of itineraries for their events, or email those itineraries to themselves. Their calendar is also synchronized with the global calendar on their smart phones, etc. The user can share their recommendations with others, or build events and share those with others.
[0420] The interface may be delivered via a scalable cloud architecture. Web servers run as Linux CPU nodes on Amazon's elastic cloud computing (EC2) system. Web servers receive independent IP addresses using Elastic IP or other IP address mediators. Web servers are monitored for load, and users are dynamically distributed among the servers. Excessive user load trips a threshold which leads to the creation of more EC2 nodes. When user load drops too low, that trips a threshold which leads to the delete of EC2 nodes to save cost.
[0421] A list of all recommended objects is pre-computed for the user. When the user requests objects via the interface, the system simply checks to IDs of those objects prior to presentation to see whether the objects appear on the recommended list or not. In another iteration, the personalization is computed in real time with no pre-cached list of recommended objects. In this example, as objects were going to be presented through the interface, they are run through the personalization engine at that moment to compute if they are recommended or not.
[0422] In some examples, the server and/or client device (e.g. desktop computer or smart phone) are implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus is optionally implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by a programmable processor; and method steps are performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features are optionally implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that are optionally used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program is optionally written in any form of programming language, including compiled or interpreted languages, and it is deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0423] Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto- optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory are optionally supplemented by, or incorporated in, ASICs (application-specific integrated circuits). [0424] To provide for interaction with a user, the features in some instances are implemented on a computer having a display device such as an LCD (liquid crystal display) monitor or screen for displaying information to the user and, in the case of a desktop computer, a keyboard and a pointing device such as a mouse or a trackball by which the user provides input to the computer.
[0425] In various implementations, the client device is a smart phone such as that described in U.S. Pat. No. 7,966,578, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Translating Displayed Content," assigned to Apple, Inc., which is incorporated herein by reference.
[0426] The server functionality described above is optionally implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser; or any combination of them. The components of the system are connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.
[0427] The computer system optionally includes clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
[0428] Obviously, numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein. For example, advantageous results may be achieved if the steps of the disclosed techniques were performed in a different sequence, if components in the disclosed systems were combined in a different manner, or if the components were replaced or supplemented by other components. The functions, processes and algorithms described herein may be performed in hardware or software executed by hardware, including computer processors and/or programmable processing circuits configured to execute program code and/or computer instructions to execute the functions, processes and algorithms described herein. A processing circuit includes a programmed processor, as a processor includes circuitry. A processing circuit also includes devices such as an application specific integrated circuit (ASIC) and conventional circuit components arranged to perform the recited functions. [0429] The functions and features described herein may also be executed by various distributed components of a system. For example, one or more processors may execute these system functions, wherein the processors are distributed across multiple components communicating in a network. The distributed components may include one or more client and/or server machines, in addition to various human interface and/or communication devices (e.g., display monitors, smart phones, tablets, personal digital assistants (PDAs)). The network may be a private network, such as a LAN or WAN, or may be a public network, such as the Internet. Input to the system may be received via direct user input and/or received remotely either in real-time or as a batch process. Additionally, some implementations may be performed on modules or hardware not identical to those described. Accordingly, other implementations are within the scope that may be claimed.
[0430] It must be noted that, as used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.
[00378] Any processes, descriptions or blocks in flowcharts described herein should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the exemplary embodiment of the present advancements in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order depending upon the functionality involved.
[0124] A number of embodiments have been described. Nevertheless, it will be understood that various modifications are optionally made without departing from the spirit and scope of this disclosure. Accordingly, other embodiments are within the scope of the following claims. Non-limiting examples for the above-noted embodiments include ad serving, customer relationship management, fraud detection, matchmaking, real estate, predicting political affiliations, vacation recommendations, educational/professional recommendations, health care provider recommendations, disease diagnosis, babysitter recommendations, employment recommendations, supply chain recommendations and business consulting / knowledge management.

Claims

1. A method implemented by at least one server, the method comprising:
receiving, at the at least one server, attribute data for a plurality of users, the data relating to a plurality of attributes of a user, at least a first venue for which the user has an affinity and a user destination;
receiving, at the at least one server,
local venue data for a plurality of venues of a user locale, the local venue data relating to a plurality of attributes of the venues, and
destination venue data for a plurality of venues of the user destination, the destination venue data relating to a plurality of attributes of the venues;
receiving, at the at least one server, local review data for the plurality of venues of the user locale, the local review data reflecting the affinity of a plurality of reviewers for the plurality of venues,
accessing, via the at least one server, a data network having nodes corresponding at least to the plurality of venues of the user locale and user destination and the plurality of reviewers and further having links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, wherein at least a plurality of the links strengths are a function of at least the local review data and the local venue data, are further a function of both content-based and collaborative interrelationships, and are based in part on higher order interrelationships between venues;
performing, at the at least one server, interconnectivity augmentation between a plurality of venues of the user locale and the plurality of venues of the user destination to form specific links therebetween;
determining, at the at least one server and based on the interconnectivity
augmentation, a plurality of recommended venues out of the plurality of venues of the user destination, the plurality of recommended venues being further based on the link strengths and at least one venue parameter;
generating, at the at least one server, recommendation data having at least one of the recommend venues; and
serving the recommendation data to a client device for display on a screen of the client device.
2. The method of claim 1, wherein the plurality of venues of the user local and user destination include at least one of restaurants, hotels, and theaters.
3. The method of claim 1, wherein the user locale identifies a location of the user in which the data network contains a predetermined number of links between nodes
corresponding to the plurality of venues in the location.
4. The method of claim 1 , wherein the user destination identifies a destination location the user is visiting in which the data network does not contain a predetermined number of links between nodes corresponding to the plurality of venues in the destination location.
5. The method of claim 1 , further comprising:
receiving, at the at least one server, destination review data for the plurality of venues of the user destination, the destination review data reflecting the affinity of the plurality of reviewers for the plurality of venues, and
performing the interconnectivity augmentation based on the local review data and destination review data.
6. The method of claim 5, wherein the interconnectivity augmentation forms the specific links and determines corresponding link strengths between the plurality of venues of the user local and user destination by identifying collaborative interrelationships
therebetween based on review data of reviewers who have reviewed corresponding venues of both the user locale and user destination.
7. The method of claim 1 , where in the interconnectivity augmentation is performed between a plurality of venues of the user locale and the plurality of venues of the user destination based on the plurality of attributes of the venues of the user locale and user destination.
8. The method of claim 7, wherein the interconnectivity augmentation forms the specific links and determines corresponding link strengths between the plurality of venues of the user local and user destination by calculating a congruency factor between venues of the user locale and user destination with respect to the plurality of attributes therebetween.
9. The method of claim 8, wherein the congruency factor is determined based on the amount of corresponding attributes between the at least a first venue for which the user has an affinity and the venues of the user destination.
10. The method of claim 1 , further comprising:
performing geometric contextualization to rank the plurality of recommended venues based on the number of recommended venues, a quality of the recommended venues, and a diversity of the recommended venues; and
generating, at the at least one server, recommendation data having at least one of the recommend venues in an order based on the rank of the recommended venues.
1 1. The method of claim 1 , further comprising:
serving a user interface depicting a query node representing the first venue, a plurality of nodes having interrelationships with the at least first venue and the corresponding links therebetween,
wherein a thickness of the depicted links is a function of the link strengths between the query node and the plurality of nodes.
12. The method of claim 1 , further comprising:
storing, in a database, a plurality of previous recommendation data having a plurality of recommended venues stored in correspondence with at least one of user attribute data, venue attribute data, and local review data;
comparing, at the at least one server, the recommendation data to the plurality of previous recommendation data to generate a resonance quantifier identifying a level of resonance between the recommendation data and the plurality of previous recommendation data;
storing, in response to the resonance quantifier being greater than a predetermined threshold, the recommendation data in the database; and
serving only the recommendation data having a resonance quantifier greater than the predetermined threshold to the client device for display on the screen of the client device.
13. The method of claim 12, wherein a plurality of resonance values are calculated by comparing the user attribute data, venue attribute data and local review data of each recommended venue to user attribute data, venue attribute data and local review data of each of the plurality of previously recommendation data, and the resonance quantifier is determined based on each resonance value.
14. A method implemented by at least one server, the method comprising:
receiving, at the at least one server, attribute data for a plurality of users, the data relating to a plurality of attributes of a user, and to at least a first venue for which the user has an affinity;
receiving, at the at least one server, venue data for a plurality of venues, the venue data relating to a plurality of attributes of the venues;
receiving, at the at least one server, review data for the plurality of venues, the review data reflecting the affinity of a plurality of reviewers for the plurality of venues;
accessing, via the at least one server, a data network having nodes corresponding at least to the plurality of venues and the plurality of reviewers and further having links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, wherein at least a plurality of the links strengths are a function of at least the review data and the venue data, are further a function of both content-based and collaborative
interrelationships, and are based in part on higher order interrelationships between venues; determining, at the at least one server and based on the link strengths and at least one venue parameter, a plurality of recommended venues having links to the user;
performing geometric contextualization to rank the recommended venues based on the number of recommended venues, a quality of the recommended venues, and a diversity of the recommended venues;
generating, at the at least one server, recommendation data having at least one of the recommend venues in an order based on the rank of the recommended venues; and
serving the recommendation data to a client device for display on a screen of the client device.
15. The method of claim 14, wherein the quality of the recommended venues is based on at least one of link strengths to the first venue, and user purchase data and user affinity data with respect to the recommended venues.
16. The method of claim 14, wherein the diversity of the recommended venues is based on a diversity factor representative of link strengths between the plurality of recommended venues and the amount of corresponding attributes between venue data of the plurality of recommended venues.
17. The method of claim 14, wherein the geometric contextualization is further based on a user distance function indicating a radial distance within which the plurality of recommended venues must be located.
18. The method of claim 14, further comprising:
serving a user interface depicting a query node representing the first venue, a plurality of nodes having interrelationships with the at least first venue and the corresponding links therebetween,
wherein a thickness of the depicted links is a function of the link strengths between the query node and the plurality of nodes.
19. The method of claim 14, further comprising:
storing, in a database, a plurality of previous recommendation data having a plurality of recommended venues stored in correspondence with at least one of user attribute data, venue attribute data, and review data;
comparing, at the at least one server, the recommendation data to the plurality of previous recommendation data to generate a resonance quantifier identifying a level of resonance between the recommendation data and the plurality of previous recommendation data;
storing, in response to the resonance quantifier being greater than a predetermined threshold, the recommendation data in the database; and
serving only the recommendation data having a resonance quantifier greater than the predetermined threshold to the client device for display on the screen of the client device.
20. The method of claim 19, wherein each attribute data of the recommendation data is compared to each attribute of the plurality of previously recommendation data to determine a resonance value of each attribute data, and the resonance quantifier is determined based on each resonance value of each attribute data.
21. A method implemented by at least one server, the method comprising: receiving, at the at least one server, attribute data for a plurality of users, the data relating to a plurality of attributes of a user, and to at least a first item for which the user has an affinity;
receiving, at the at least one server, item data for a plurality of items, the item data relating to a plurality of attributes of the items;
receiving, at the at least one server, review data for the plurality of items, the review data reflecting the affinity of a plurality of reviewers for the plurality of items;
receiving, at the at least one server and via an application programming interface, a request from third party vendor, the request including external item data relating to at least one external item sold by the third party vendor, and information identifying a type of the at least one external item included in the request;
accessing, via the at least one server, a data network having nodes corresponding at least to the type of the at least one external item, the plurality of items and the plurality of reviewers, and further having links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, wherein at least a plurality of the links strengths are a function of at least the review data and the item data, are further a function of both content-based and collaborative interrelationships, and are based in part on higher order interrelationships between items;
determining, at the at least one server and based on the link strengths and the at least one external item, a plurality of recommended items having the same or similar type as the at least one external item;
generating, at the at least one server, recommendation data having at least one of the recommend items; and
serving the recommendation data to the third party vendor via the application programming interface.
22. The method of claim 21 , further comprising:
receiving, via the application programming interface, a request from the third party vendor that includes
item data for a plurality of third party vendor items, the item data relating to a plurality of attributes of the third party vendor items items;
external attribute data for a plurality of third party vendor customers, the external attribute data relating to a plurality of attributes of the customers, and external review data for the at least one external item, the external review data reflecting the affinity of a plurality of external reviewers for the plurality of external items; and
generating, in response to receiving the request, a third party vendor data network index having nodes corresponding at least to the third party vendor items and the plurality of external reviewers and further having links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, wherein at least a plurality of the links strengths are a function of at least the item data of the third party vendor items and the external review data, are further a function of both content-based and collaborative interrelationships, and are based in part on higher order interrelationships between items.
23. The method of claim 22, further comprising:
determining, based on the link strengths within the third party vendor data network index and at the least one external item, a plurality of recommended items having the same or similar type as the at least one external item;
generating, at the at least one server, recommendation data having at least one of the recommend items; and
serving the recommendation data to the third party vendor via the application programming interface.
24. The method of Claim 22, further comprising:
serving the third party vendor data network index to the third party vendor via the application programming interface.
25. The method of claim 21, further comprising:
performing geometric contextualization on the plurality of recommended items to rank the recommended venues based on the number of recommended items, a quality of the recommended items, and a diversity of the recommended items; and
generating, at the at least one server, recommendation data having at least one of the recommend items in an order based on the rank of the recommended items.
26. A method comprising: receiving, at at least one server, attribute data for a plurality of users, the attribute data relating to a plurality of attributes of the plurality of users and to one or more venues for which the plurality of users has an affinity;
receiving, at the at least one server, venue data for a plurality of venues, the plurality of venues including the one or more venues for which the plurality of users have an affinity, the venue data relating to a plurality of attributes of the plurality of venues;
receiving, at the at least one server, review data for the plurality of venues, the review data reflecting the affinity of a plurality of reviewers for the plurality of venues;
accessing, via the at least one server, a data network comprising nodes corresponding at least to the plurality of venues, the plurality of reviewers, and the plurality of users, and further comprising links between said nodes, each link reflecting a strength of an
interrelationship between at least two nodes, wherein at least a plurality of the link strengths are a function of at least the review data and the venue data and are further a function of both content-based and collaborative interrelationships;
calculating, at the server and from the data network, user personality profiles for at least a first user and a second user of the plurality of users,;
calculating, at the server and from the user personality profiles, a combined personality profile;
determining, at the at least one server and based on the link strengths and at least one venue attribute, one or more recommended venues that have the strongest links to the combined personality profile;
generating, at the at least one server, recommendation data comprising at least one recommended venue of the one or more recommended venues; and
serving to a client device the recommendation data for display on a screen of the client device.
27. The method according to Claim 26, wherein the plurality of venues include at least one of restaurants, hotels, and theaters.
28. The method according to Claim 26, wherein the venue data includes categorical property descriptors and corresponding property attributes for the plurality of venues.
29. The method according to Claim 26, wherein the user personality profiles include at least one of data relating to the link strength between the at least first and second users, and the attributes of at least the one or more venues for which the at least first and second users have the affinity.
30. The method according to Claim 26, wherein the combined personality profile corresponds to an aggregation of at least one of link strengths between the at least first and second users, and the attributes of the one or more venues for which the at least first and second users have the affinity.
31. The method according to Claim 26, further comprising:
determining, at the at least one server, a candidate list of venues based on the combined personality profile, wherein
the candidate list of venues includes at least one of the one or more venues for which the at least first and second users have the affinity and additional venues sharing a nodal interrelationship with the one or more venues for which the at least first and second users have the affinity.
32. The method according to Claim 26, further comprising:
calculating, at the at least one server and as part of the user personality profiles, weights corresponding to the at least first and second users' affinity for each venue attribute of the one or more venues for which the at least first and second users have the affinity; and determining, at the at least one server and based at least on the weights, an overall score for each venue attribute in the at least first and second users' user personality profiles.
33. The method according to Claim 32, wherein the weights are calculated based on the attribute data for the at least first and second users.
34. The method according to Claim 32, wherein the weights are calculated based on the link strength between the at least first and second users.
35. The method according to Claim 32, wherein the weights are calculated based on the attributes of the one or more venues for which the at least first and second users have the affinity.
36. The method according to Claim 32, wherein the overall scores in the first and second users' user personality profiles are combined to generate the combined personality profile.
37. The method according to Claim 26, further comprising:
receiving, at the at least one server, filter conditions for one or more venue attributes of the one or more venues for which the at least first and second users have the affinity.
38 The method according to Claim 37, further comprising:
adjusting, at the at least one server and based on the filter conditions, at least one of the user personality profiles, the recommendation data, and the combined personality profile.
39. The method according to Claim 26, wherein the recommendation data includes at least one recommended user of the plurality of users.
40. A method of providing venue recommendations on a client device, the method comprising:
transmitting, from the client device to at least one server, attribute data for a plurality of users, the attribute data relating to a plurality of attributes of the plurality of users and to one or more venues for which the plurality of users has an affinity;
transmitting, from the client device to the at least one server, a recommendation request;
receiving, from the at least one server based on the recommendation request, recommendation data identifying one or more recommended venues, each recommended venue being selected based on at least one venue attribute and the strength of a nodal interrelationship between a plurality of venues and a combined personality profile; and
displaying, on a screen of the client device, the recommendation data identifying the at least one recommended venue, wherein
the nodal interrelationships are developed within a data network comprising nodes corresponding at least to the plurality of venues that includes the one or more venues for which the plurality of users have the affinity, a plurality of reviewers, and the plurality of users, and further comprising links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, at least a plurality of the link strengths are a function of at least review data reflecting an affinity of a plurality of reviewers for the plurality of venues and venue data relating to a plurality of attributes of the plurality of venues, and the link strengths being further a function of both content-based and collaborative interrelationships, and
the combined personality profile is calculated based on user personality profiles calculated from the data network for at least a first user and a second user of the plurality of users.
41. The method according to Claim 40, wherein the user personality profiles include at least one of data relating to the link strength between the at least first and second users, and the attributes of at least the one or more venues for which the at least first and second users have the affinity.
42. The method according to Claim 40, wherein the combined personality profile corresponds to an aggregation of at least one of link strengths between the at least first and second users, and the attributes of the one or more venues for which the at least first and second users have the affinity.
43. The method according to Claim 40, wherein:
the at least one server calculates weights corresponding to the at least first and second users' affinity for each venue attribute of one or more venues, of the plurality of venues, for which the at least first and second users have an affinity, and
the at least one server determines, based on the weights, an overall score for each venue attribute in the at least first and second users' user personality profiles.
44. The method according to Claim 43, wherein the overall scores in the at least first and second users' user personality profiles are combined to form the combined personality profile.
45. The method according to Claim 40, further comprising:
transmitting, from the client device to at the at least one server, filter conditions for one or more venue attributes of the one or more venues for which the at least first and second users have the affinity, wherein the at least one server adjusts, based on the filter conditions, one or more of the user personality profiles, the recommendation data, and the combined personality profile.
46. The method according to Claim 40, wherein the client device displays the recommendation data in a user interface comprising a query limitations section disposed above a recommendation comparison section.
47. The method according to Claim 40, wherein the client device displays the recommendation data in a user interface comprising an overview section having one or more objects of various shapes and sizes corresponding to the one or more recommended venues and based on interrelationships between the plurality of users and venues.
48. A method comprising:
receiving, at least one server, attribute data for a plurality of users and location data, the attribute data relating to a plurality of attributes of a user, user affinity data, and to at least a first venue for which the user has an affinity;
receiving, at the at least one server, venue data for a plurality of venues, the venue data relating to a plurality of attributes of the venues;
receiving, at the at least one server, review data for the plurality of venues, the review data reflecting the affinity of a plurality of reviewers for the plurality of venues;
encoding, at the server, the venue data of at least one venue as an encoded item of data containing at least one predetermined value for each venue attribute;
identifying, at the server, one or more local venues based on the location data;
comparing encoded venue data for each identified local venue to the user affinity data to generate a filtered set of venues;
accessing, via the at least one server, a data network comprising nodes corresponding at least to the plurality of venues and the plurality of reviewers and further comprising links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, wherein at least a plurality of the link strengths are a function of at least the review data and the venue data and are further a function of both content-based and collaborative interrelationships;
determining, at the at least one server and based on the link strengths and at least one venue parameter, a plurality of recommended venues from the filtered set of venues which have the strongest links to a user; generating, at the at least one server, recommendation data comprising at least one recommended venue; and
serving to a client device the recommendation data for display on a screen of the client device.
49. The method according to Claim 48, wherein the plurality of venues include at least one of restaurants, hotels and theaters.
50. The method according to Claim 48, wherein the location data includes at least one of a location of a user or a location received from the user.
51. The method according to Claim 48, wherein the plurality of attributes of the venues includes at least venue location data.
52. The method according to Claim 48, further comprising:
spatially segmenting geographic data into a plurality of grids;
storing at least one venue in association with a grid in which the at least one venue is located; and
storing encoded venue data of at least one venue in association with a grid in which the venue is located.
53. The method according to Claim 52, wherein the one or more local venues are identified by determining which venues of the plurality of venues are located in a grid corresponding to the location data.
54. The method according to Claim 52, wherein at least one grid is stored in association with at least one other grid based on a location of the grids with respect to each other.
55. The method according to Claim 54, wherein the one or more local venues are identified by determining which venues of the plurality of venues are located in a grid corresponding to the location data and any grids stored in association with the grid.
56. The method according to Claim 48, further comprising: applying weights corresponding to the user affinity data to each venue attribute of each venue of the filtered set of venues to determine an overall score for each venue; and modifying the filter set based on the overall score of each venue.
57. The method according to Claim 48, wherein the data network is accessed to provide a recommendation after performing the encoding, identifying and comparing.
58. The method according to Claim 48, wherein the encoded item of data is a string containing the values in a predetermined order.
59. The method according to Claim 58, wherein each value contained within the encoded item of data is separated by a predetermined character to distinguish values from each other.
60. The method according to Claim 48, wherein the values contained within the encoded item of data are ordered in a sequence based on a quality level of each attribute.
61. A method for providing venue recommendations on a client device, comprising: transmitting, from the client device to at least one server device, attribute data for a user and location data, the attribute data relating to a plurality of attributes of a user, user affinity data, and to at least a first venue for which the user has an affinity;
transmitting, from the client device to the at least one server device, a
recommendation request including at least one venue attribute;
receiving, from the at least one server device, data identifying a plurality of recommended venues, each recommended venue being selected from a filtered set of venues based on the strength of a nodal interrelationship between the venue and the user within a data network comprising nodes corresponding at least to a plurality of venues and a plurality of reviewers and further comprising links between said nodes, each link reflecting a strength of an interrelationship between at least two nodes, wherein at least a plurality of the link strengths are a function of venue data relating to a plurality of attributes of the venues and review data reflecting the affinity of a plurality of reviewers for the plurality of venues, at least a plurality of the link strengths are further a function of both content-based and collaborative interrelationships and are based in part on connection growth from collaborative interrelationships, and wherein the venue data of at least one venue is encoded as an encoded item of data containing predetermined values for each venue attribute, one or more local venues from the data network are identified based on the location data, and the filtered set of venues is generated by comparing encoded venue data for each identified local venue to the user affinity data; and
displaying, on a screen of the client device, data identifying the plurality of recommended venues.
62. The method according to Claim 61, wherein the at least one server device spatially segments geographic data into a plurality of grids,
stores at least one venue in association with a grid in which the venue is located, and stores encoded venue data of at least one venue in association with a grid in which the venue is located.
63. The method according to Claim 62, wherein the one or more local venues are identified by determining which venues of the plurality of venues are located in a grid corresponding to the location data.
64. The method according to Claim 62, wherein the at least one server device applies weights corresponding to the user affinity data to each venue attribute of each venue of the filtered set of venues to determine an overall score for each venue, and
modifies the filter set based on the overall score of each venue.
65. The method according to Claim 62, wherein the data network is accessed to provide a recommendation after performing the encoding, identifying and comparing.
66. The method according to Claim 62, wherein the encoded item of data is a string containing the values in a predetermined order.
67. The method according to Claim 66, wherein each value contained within the encoded item of data is separated by a predetermined character to distinguish values from each other.
EP13852285.9A 2012-11-05 2013-08-28 Systems and methods for providing enhanced neural network genesis and recommendations to one or more users Withdrawn EP2915063A4 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13/669,150 US20140129371A1 (en) 2012-11-05 2012-11-05 Systems and methods for providing enhanced neural network genesis and recommendations
US13/842,665 US8732101B1 (en) 2013-03-15 2013-03-15 Apparatus and method for providing harmonized recommendations based on an integrated user profile
US13/842,165 US20140279196A1 (en) 2013-03-15 2013-03-15 System and methods for providing spatially segmented recommendations
PCT/US2013/057136 WO2014070293A1 (en) 2012-11-05 2013-08-28 Systems and methods for providing enhanced neural network genesis and recommendations to one or more users

Publications (2)

Publication Number Publication Date
EP2915063A1 true EP2915063A1 (en) 2015-09-09
EP2915063A4 EP2915063A4 (en) 2016-04-13

Family

ID=50627915

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13852285.9A Withdrawn EP2915063A4 (en) 2012-11-05 2013-08-28 Systems and methods for providing enhanced neural network genesis and recommendations to one or more users

Country Status (2)

Country Link
EP (1) EP2915063A4 (en)
WO (1) WO2014070293A1 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10467677B2 (en) 2011-09-28 2019-11-05 Nara Logics, Inc. Systems and methods for providing recommendations based on collaborative and/or content-based nodal interrelationships
US10769523B2 (en) * 2017-04-05 2020-09-08 International Business Machines Corporation Using analytics to determine dining venue based on group preferences
US10896424B2 (en) 2017-10-26 2021-01-19 Mastercard International Incorporated Systems and methods for detecting out-of-pattern transactions
US20190130448A1 (en) * 2017-10-27 2019-05-02 Dinabite Limited System and method for generating offer and recommendation information using machine learning
CN110209946B (en) * 2019-06-10 2021-03-09 合肥工业大学 Social and community-based product recommendation method, system and storage medium
CN111061961B (en) * 2019-11-19 2023-05-26 江西财经大学 Multi-feature-fused matrix decomposition interest point recommendation method and implementation system thereof
CN112651778B (en) * 2020-12-25 2022-08-23 平安科技（深圳）有限公司 User behavior prediction method, device, equipment and medium

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060106655A1 (en) * 2003-08-05 2006-05-18 Ladislav Lettovsky System and method for coordinating travel itineraries
US20080214204A1 (en) * 2005-11-01 2008-09-04 Jorey Ramer Similarity based location mapping of mobile comm facility users
US20080045236A1 (en) * 2006-08-18 2008-02-21 Georges Nahon Methods and apparatus for gathering and delivering contextual messages in a mobile communication system
US8949340B2 (en) * 2007-02-05 2015-02-03 Boadin Technology, LLC Systems and methods for organizing content for mobile media services
US9159034B2 (en) * 2007-11-02 2015-10-13 Ebay Inc. Geographically localized recommendations in a computing advice facility
US8666909B2 (en) * 2007-11-02 2014-03-04 Ebay, Inc. Interestingness recommendations in a computing advice facility
US11159909B2 (en) * 2008-02-05 2021-10-26 Victor Thomas Anderson Wireless location establishing device
US20090216563A1 (en) * 2008-02-25 2009-08-27 Michael Sandoval Electronic profile development, storage, use and systems for taking action based thereon
GB2458388A (en) * 2008-03-21 2009-09-23 Dressbot Inc A collaborative online shopping environment, virtual mall, store, etc. in which payments may be shared, products recommended and users modelled.
US20110208822A1 (en) * 2010-02-22 2011-08-25 Yogesh Chunilal Rathod Method and system for customized, contextual, dynamic and unified communication, zero click advertisement and prospective customers search engine
US8489330B2 (en) * 2010-10-09 2013-07-16 Fleetcor Technologies Operating Company, Llc Navigation system with distance limitation mechanism and method of operation thereof
US20120109749A1 (en) * 2010-11-02 2012-05-03 Visa International Service Association Systems and Methods to Provide Recommendations
US8170971B1 (en) * 2011-09-28 2012-05-01 Ava, Inc. Systems and methods for providing recommendations based on collaborative and/or content-based nodal interrelationships

Also Published As

Publication number Publication date
WO2014070293A1 (en) 2014-05-08
EP2915063A4 (en) 2016-04-13

Similar Documents

Publication Publication Date Title
US11651412B2 (en) Systems and methods for providing recommendations based on collaborative and/or content-based nodal interrelationships
US11151617B2 (en) Systems and methods for providing recommendations based on collaborative and/or content-based nodal interrelationships
US9449336B2 (en) Apparatus and method for providing harmonized recommendations based on an integrated user profile
US20140279196A1 (en) System and methods for providing spatially segmented recommendations
US10423880B2 (en) Systems and methods for providing recommendations based on collaborative and/or content-based nodal interrelationships
US20210117757A1 (en) Systems and methods for constructing and applying synaptic networks
US20140129371A1 (en) Systems and methods for providing enhanced neural network genesis and recommendations
US20200401918A1 (en) Interestingness recommendations in a computing advice facility
US20220207575A1 (en) Systems and methods for providing recommendations based on collaborative and/or content-based nodal interrelationships
US11263543B2 (en) Node bootstrapping in a social graph
US10318534B2 (en) Recommendations in a computing advice facility
CA2955330C (en) Geographically localized recommendations in a computing advice facility
EP2915063A1 (en) Systems and methods for providing enhanced neural network genesis and recommendations to one or more users
US11727249B2 (en) Methods for constructing and applying synaptic networks

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150522

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HUESKE, EMILY A.

Inventor name: HOULE, MICHAEL D.

Inventor name: COPEMAN, THOMAS C.

Inventor name: KENYON, ELEANOR

Inventor name: STERNBERG, JOAKIM A.

Inventor name: LI, LUYAO

Inventor name: WILSON, NATHAN R.

DAX Request for extension of the european patent (deleted)
RA4 Supplementary search report drawn up and despatched (corrected)

Effective date: 20160314

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 17/00 20060101AFI20160308BHEP

Ipc: G06N 5/02 20060101ALI20160308BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170202

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170613