CN113168424A - System and method for obtaining recommendations using scalable cross-domain collaborative filtering - Google Patents

Abstract

Aspects of the present invention relate to systems, methods, apparatuses, etc. for presenting recommendations. In one embodiment, a system is presented that includes a plurality of models for obtaining recommendation scores. Recommendation scores may be obtained using one or more recommendation models, and recommendations made based on the determined recommendation scores. In another embodiment, a system is presented that may retrain a recommendation model based on feedback received in response to a recommendation made using an obtained recommendation score.

Description

System and method for obtaining recommendations using scalable cross-domain collaborative filtering

Cross Reference to Related Applications

This application is a partial continuation of U.S. patent application serial No. 16/213346, filed on 7.12.2018, and is incorporated by reference in its entirety.

Technical Field

The present disclosure relates generally to communication devices for generating recommendations and, more particularly, to communication devices that provide user-specific recommendations using cross-domain collaborative filtering.

Background

With the development of technology, the industry has turned to the use of electronic devices and communications to process transactions. The transaction may typically begin with the consumer submitting a funds broker to make a payment, and then proceed to the seller authorizing such transaction. In some cases, recommendations may be provided to consumers prior to completing such transactions, based in part on mass items or trends. For example, at checkout, the user may be provided with a recommendation to donate money to a public cause or charity. However, this type of recommendation is generally not appropriate for the user's interests, preferences, purchases, and/or associations. Therefore, to increase the chances of a user purchasing or donating, it would be beneficial to create a system that is customized for the user and that is cross-domain recommendations.

Drawings

FIG. 1 illustrates a system for presenting recommendations on a user device.

FIG. 2 shows an exemplary diagram illustrating features of information used to make recommendations.

Fig. 3A-3C illustrate recommendation scenarios based on different information.

FIG. 4 illustrates an exemplary system for making and presenting recommendations.

FIG. 5 shows a diagram of an implementation of cross-domain collaborative filtering for making recommendations.

FIG. 6 illustrates a sub-graph node representation containing user and corresponding point-to-point (peer-to-peer) associations for obtaining recommendation scores.

FIG. 7 illustrates a table diagram of item-to-item collaborative filtering for obtaining recommendation scores.

FIG. 8 illustrates a flow diagram that illustrates operations for determining recommendations using cross-domain collaborative filtering.

FIG. 9 illustrates a block diagram of a system for determining recommendations using cross-domain collaborative filtering.

Fig. 10 illustrates an exemplary block diagram of a computer system suitable for implementing one or more of the devices of the communication systems of fig. 1-9.

Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, and the illustrations herein are for the purpose of describing embodiments of the disclosure and are not intended to limit embodiments of the disclosure.

Detailed Description

In the following description, specific details are set forth describing some embodiments consistent with the present disclosure. It will be apparent, however, to one skilled in the art, that some embodiments may be practiced without some or all of these specific details. The specific embodiments disclosed herein are intended to be illustrative, not limiting. Although not specifically described herein, those skilled in the art will recognize other elements that are within the scope and spirit of the disclosure. In addition, one or more features illustrated and described in connection with one embodiment may be incorporated into other embodiments to avoid unnecessary repetition, unless expressly described otherwise or where such feature or features would render the embodiments inoperative.

Aspects of the present disclosure relate to systems, methods, devices, etc. for presenting recommendations. In one embodiment, a system is presented that includes a plurality of models for obtaining recommendation scores. The recommendation score may be obtained using one or more models, which may include supervised and unsupervised learning and a combination of user information and transactions. In another embodiment, it is described that the system may provide an overall recommendation score and recommendation generated by a combined model (ensemble model) whose inputs may include one or more recommendation scores previously obtained.

Conventionally, to increase customer involvement, merchants, third party service providers, and other entities that provide products or services may rely on recommendations based on awareness of the products or services. Such participation is easily accomplished and products and/or services are easily presented and considered for purchase. For example, referring to FIG. 1, a basic system and method for presenting recommendations to a user is shown. As shown, the recommendation may originate from the network 102. Network 102 may include any two computers, servers, or other systems/devices that may be linked together to share resources and exchange electronic information. The internet, cloud, set of servers, data center, social media may all be considered part of the network 102. The network may be accessed and used to determine the most popular items, products, services or entities to recommend. For example, social media may be reluctant to maintain, and the data analysis obtained suggests that new smart gadgets have been released and are trending. Thus, such smart gadgets may be presented to the user on the device 106. As another example, a natural disaster may have recently occurred, and due to the media reports, the mass entities providing rescue efforts may be presented to the user for donation. Further, to find charitable organizations to donate, YMCA, Union road, red cross, etc. may be presented based on cognition and awareness. However, these examples do not ignore the behavior of the customer and/or the product, service, entity, etc., which may be smaller or less demanding.

Therefore, it would be beneficial to have a system that can take into account various aspects of the user before making recommendations. For example, consider a recommendation for a charitable cause. Using the simplified method and system 100 shown in FIG. 1, smaller charities will be ignored and the customer's actions will be omitted. Alternatively, recommendations may be more personalized and relevant to the user by associating purchasing behavior, user profiles, donation history, transaction history, etc. with donations.

Note that throughout this application, recommendations and analysis will typically focus on charitable institutions, however, this application is not limited to charitable based recommendations, and as noted above, the methods and systems presented herein may be used to provide recommendations for other products, services, entities, and the like.

Turning to FIG. 2, a Venn diagram illustrating how recommendations are customized is provided. In particular, FIG. 2 shows an exemplary diagram illustrating features of information for making recommendations. As noted, it is beneficial to consider various aspects of the user before making a recommendation. In one embodiment, FIG. 2 illustrates initial aspects that may be considered before making a recommendation. For exemplary purposes and continuing with the charitable utility use case, consider the wien diagram 200. In the exemplary Venn diagram 200, a first aspect of making recommendations is considered, and may include whether a user is or was a donor. For example, on the left circle 202 of the wien diagram 200, previous donors of charitable causes may be considered and characterization information defined. And alternatively, users without donation history may be sorted along with the characterization information on the right circle 204 of the venn diagram 200. Additionally, in some instances, the characterization information may be used and shared 206 between the previous donor 202 and the non-donor 204 to make recommendations to the charity.

As an example of the characterization information that may be used to make recommendations, the characterization information may include a donation history that may be used and considered for users who have made previous donations. As another example, the characterization information that can be used and considered for a user without a donation history may include user profile information, contacts, merchants, entities, etc. with which the user may have made transactions, as well as a purchase history and charities associated with the location where the purchase was made. As yet another example, other general characterization information that can be used to make recommendations can include charitable cause awareness, trends, and other relationship information.

Note that although wien diagram 200 is used to illustrate characterization information that can be used to make recommendations based on donor/non-donor status, the characterization information is not limited and is used for exemplary purposes. Other characterizing information may also be used, and the position in the wien diagram may be different.

To illustrate how the characterization information is used to make recommendations, fig. 3A-3C are presented. In particular, FIGS. 3A-3C illustrate recommendation scenarios and use cases based on different characterization information. Turning to FIG. 3A, a first recommendation use case is presented that can make charity recommendations using previous donation characterization information. The use case considered in FIG. 3A may use a collaborative filtering type approach and use case, where recommendations may be presented to user 302c based on contributions made by user 302c and/or other users 302a, b. To illustrate this approach, user 302a is considered. The user 302a has a donation history, and as shown, the user 302a has a donation history to charity 304-. Turning to user 302b, the user 302b also has a history of donations, but in this example, the donations are concentrated on a single charity 308. Using a similar approach, the user 302c may now be characterized as having donation history support previous donations primarily concentrated on two charities 306, 310. In one embodiment, the user 302c may be provided with charity cause recommendations using a collaborative filtering method. In this scenario, observations, analyses, or associations may be made to identify similarities between the user 302a and the user 302 b. Such associations or similarities 312 may be identified based in part on observing that the user 302c donates to the charities 306 and 308 as the user 302 a. Thus, based on this evaluation and similarity 312, two new recommendations 314 may be made and presented to the user 302 c.

In FIG. 3B, another recommendation scenario and use case is presented based on other different characterization information. For this use case, recommendations are made in view of the transaction information. Specifically, who the user has transacted with, and in particular, other peers who have transacted with the user (e.g., P2P transaction history). In addition, characterization information about the donated charitable cause is also used. To provide some insight into making recommendations using P2P transaction history, fig. 3B is provided. For this use case, user 302d is shown as having transacted 320 with user 302e, while user 302e transacted 320 with user 302 f. And further, user 302e and user 302f have a donation history, where user 302e makes donations 322 to charities 324 and 326, and user 302f makes donations 322 to charities 324. Thus, the user 302d may be provided with recommendations using known transaction history and donation characterization information. In this use case, charities 318 and 324 are recommended 318 to the user 302d based on the charities of the user's 302d contact donation.

Turning to FIG. 3C, yet another recommendation scenario is presented. In the recommended use case, the purchase history and the charitable relationship are considered as the characterizing information. For this use case, the user 302g may be provided with recommendations that are presented based on the user's purchase history. Thus, the charity 328 is presented based on the purchase 324 of the item 330 by the user 302 g. To make this recommendation, in one embodiment, metadata attributes associated with the purchase item 330 may be extracted. For example, attributes including item names, categories, descriptions, etc. may be extracted. Then, using the extracted metadata attributes, the charity 328 or other recommendation may be presented to the user 302 g.

Note that FIGS. 3A-3C are provided as exemplary use case scenarios to illustrate how the characterization information may be used to provide recommendations. Note that other use cases and the use of more, less, and alternative characterization information are possible. For example, trends, awareness, relationships, and other characterizing information may be used, and use cases may be presented. Further, the number of donations, recommendations, transactions, and similarities identified may vary from one recommendation to another.

FIG. 4 is next presented to provide an exemplary architecture that can be used to implement the system and platform for making recommendations. Note that to continue the entire example, the architecture 400 in FIG. 4 is also defined for charity recommendations. However, the platform and system 400 can be used to, update, and implement any recommendation.

As shown in FIG. 4, in one embodiment, the system may be partitioned based on its functionality, with the left side of the dashed line including modules and interactions primarily applicable to payment provider applications (e.g., PayPal), and the right side including those modules and interactions that are considered in performing the analysis. Since the goal in the recommendation system 200 is to present charities of interest to the user 302, interaction with the recommendation system 200 will begin with the user 302h interacting with the application at checkout 402. At checkout 402, the user 302h may be ready to complete the purchase and may be prompted with an opportunity to donate to a charity. Checkout 402 at the payment provider may then trigger communication with customer participation platform 404 and cause module (house module) 406. The career module 406 may be triggered and/or accessed immediately at checkout and at the time the user 302h makes a donation, where the donation details may be collected and stored in the elastic storage component 408, which elastic storage component 408 may be used to make future recommendations and/or receive charity details from the customer participation platform 404. Customer participation platform 404 may be a processing unit, an operating system, and/or a set of technologies from which other processes and modules can be developed. For example, on a customer participation platform, there may be a technology, module, or storage unit that stores, accesses, or retrieves user characterization information that can be used to make recommendations. In particular, as illustrated in FIG. 4, customer participation platform 404 may include personalization, content management, customer profiling, tracking, and customer segmentation modules. These modules may be used in extracting customer details during checkout for providing characterization information and other relevant details to the cause module 406 for transferring details to a storage/tracking module (e.g., elastic storage component 408, database 410), and/or receiving and processing entries, with updates provided by the secondary user 302 i. The secondary users 302i may be internal employees of the payment provider with insight into internal policies and marketing information, such that content input to the customer participation platform is useful and relevant. Note that content input may also be dynamically created or automatically made so that the secondary user 302i may be an external system.

The details communicated to the storage and tracking modules 408, 410 may then be used in the analysis portion of the architecture to make recommendations. For example, content tracked at the database 410 can then be processed bi-directionally by the streaming software 412 for use by the recommendation component 414. Streaming software 412 (e.g., Kafka) may be used to enable batch content to be read continuously as a stream. Typically, this capability is not an off-the-shelf function that can intelligently switch between batch and streaming processing depending on the processing power in the application and the incoming rate of data. However, the customer participation module 404/database 410 and recommendation component 414 can be equipped with an intelligent mode that can seamlessly switch between batch and streaming by processing data by streaming software 412 such as Kafka.

The career model 416 can then use the data at the recommendation component 414 to make predictions. The model may be predicted and trained by accessing details of the user 302i, which may be accommodated in the data warehouse 418. The data warehouse may include various repositories with detailed information about user 302i, including but not limited to purchases made by the user, donations, profile information, contacts and friends, and merchants conducting transactions with user 302 i.

To train the career model 416, a combination of data tracked by the elastic tracking module 408 and manual intervention by another user 302j may occur. Another user 302j may be a data scientist who may determine information related to the input of the recommendation model 416. Additionally, or alternatively, the system or other components may be used without manual intervention by another user 302 j. The data tracked by the elastic tracking module 408 for input to the utility model 416 may include data obtained using feedback. In one embodiment, the feedback may be used to train the business model 416 to provide continuous adjustment of the business model 416.

In particular, feedback can be used and collected from user actions based on suggested charities presented at checkout. For example, useful feedback tracked may include: whether these users donate money to the proposed charity when the charity is user supported or they are willing to support. Other feedback that can be tracked may include whether the user 302 likes suggested charities because generally if the user 302 dislikes these charities, they may not donate money to these charities. Thus, the recommendation architecture 400 provides a system that can continuously track suggested charities that are being donated (redeemed) and the frequency with which charities are presented to the user 302j, to measure display counts (impressions) from all products as feedback, and then adjust the cause model 416 to provide better recommendations.

Thus, through the transformation and impressions, data may be provided and used to create suggested charity score values. In one embodiment, the charity score value may be calculated by first giving a feedback impact weight (w) value of 1 to each suggested charity from the cause model 416. Then, after making some observations, the weight (w) value may be reduced if the suggested charity presented to the user 302 does not receive any redemption after a defined period of time. Finally, when there is no redemption for N impressions, the weight value may decrease to close to 0. In this case, the probability of recommending a suggested charity to the user 302 decreases. On the other hand, if the suggested charity obtains a redemption, the weight value (w) may be reset back to 1 to maximize the suggested charity score value for the next time the charity is strongly recommended to the user 302. Thus, the continuous collection of the user's 302 redemptions and impressions based on interactions with charities may be tracked to compose recommendations, creating an adjusted feedback loop to provide updated recommendation scores/suggested charity score values and produce more accurate results.

Note that the career model 416 may include one or more models and machine learning algorithms designed to make recommendations. Machine learning algorithms may include those based on supervised and unsupervised learning, and may include models such as, but not limited to, clustering, tree-based, combination, random walking, and the like.

Further, the recommendation score may be implemented across multiple models. Each model may be personalized to provide a list of recommendations for charitable causes for which a recommendation score is provided. The higher the score, the greater the chance of correctly predicting the cause of the charity. However, if multiple models predict a list of charities, it is necessary to predict the most appropriate charities among the various personalized models. Various techniques may be used to achieve this. A first technique may include making predictions based on available information. Using this technique may be appropriate when not all desired data is available at any time to calculate the desired charity for all users. For example, in some instances, the user donation history may be lost. In other instances, the purchase history may not be available or may be limited. In such instances, personalized models that are not sufficiently detailed may be excluded from or disregarded from the available personalized models when predicting the charitable cause list.

Another technique may include using cross-model score calibration for use and prediction. This technique is sufficient where there are multiple factors that are considered in obtaining the recommended score for a given model. These factors may differ from model to model, and thus, may be calibrated across each other model to obtain a recommendation score that is consistent across models. Note that the use of this technique may include using ranking where the charitable cause is ranked and presented to the user 302 in a ranking order.

Yet another technique may include using a polling method to identify the most relevant model to the user 302. For example, this technique may be useful compared to other approaches in cases where some users prefer to use a charitable cause that their friends have donated. This may be identified by cycling charities across different models in a round robin fashion, which may identify the user's affinity to a particular model.

Two other techniques may include scoring charitable causes recommended by multiple models and using champion techniques. In instances where various charities are recommended by multiple models, techniques using scoring are very useful. In such instances, various charities may obtain the secondary recommendation score based on the probability of user selection. Champion technology requires the use of multiple models simultaneously. Here, the best performing model may be selected as the champion, and the model selected to generate recommendations for the user. Other models can still challenge the champion with simulation data. Once the performance of another model exceeds the existing champions, the other model will be used to present recommendations.

Turning to FIG. 500, a more personalized method for making recommendations is shown. In particular, FIG. 5 shows a diagram of an implementation of cross-domain collaborative filtering 500 for making recommendations. As shown in FIG. 5, the presented recommendations are based on an overall recommendation score 510 calculated and obtained using the combined model 508. The combined model 508 is a modeling technique or process that uses two or more analytical models to obtain a final result or recommendation. To obtain or generate a more accurate final result, a final result or recommendation 510 may be obtained by combining the predictions made by each model. Alternatively, the combined model 508 may obtain the final result by selecting and using one or more models that create the best model for the problem under consideration. For example, in the charitable organization example considered, the combined model 508 may obtain recommendations for one or more best charities by obtaining separate recommendation scores from each of the multiple models.

In one embodiment, three different models 502-506 are presented in order to obtain a more customized recommendation for charities. In a first model, a recommendation score may be obtained using a model that includes cross-domain collaborative filtering 502. The second model may include using a random walk technique to determine the recommendation score 504. While a third model may include using clustering to determine the recommendation score 506.

A first model that includes the use of cross-domain collaborative filtering 502 is a model designed to consider not only the user and his/her transactions but also cross-domain transactions. For example, consider transaction information about merchants and charities. Thus, one focus of the cross-domain collaborative filtering 502 model may include making recommendations based in part on associations or predictions about people who make purchases with a particular merchant and also donate to a particular charity. In other words, the system is designed to show that users shopping at a particular merchant are also likely to donate to a particular cause. To illustrate this, consider that a user ordered pet food online at merchant X, and then, assuming that the user purchased pet food at merchant X, the user would likely donate to an animal's friend's charity. Thus, the user is presented with customized charities, rather than random or most popular charities (which may have little or no association with the user and his/her behavior). Specific details regarding the cross-domain model 502 are described below in conjunction with FIG. 7.

Random walk model 504 is a model that focuses more on transactions and peers associated with a user. For example, consider a user associated with a third party vendor (e.g., PayPal). The user may also have separate accounts with Venmo and Xoom (two entities associated with PayPal). Thus, the random walk model 504 may use knowledge of the user's transactions with PayPal and with Venmo and Xoom. In addition, the random walk model 504 may also use information about who has transacted or with which peers the user has transacted. Thus, a random walk model may be generated using mathematical paths that can be generated between transactions across entities and/or with other peers. The illustration of such a diagram is illustrated and described in detail in connection with fig. 6 and the use case shown in fig. 3B. Note that although Venmo and Xoom are used herein, it is contemplated that other transactions may be made between merchants, using digital tools, and between peers. FIG. 6 is used for exemplary purposes and to illustrate how recommendations are presented to a user (or fed to a portfolio model 510) based in part on the user's business and personal associations (including but not limited to contacts, friends, family, organizations, co-workers, etc.).

Next, the clustering model 506 may be used to determine a recommendation score. The clustering model 506 uses a technique of grouping objects based, or partitioning populations based on similarity. For example, assuming the user is a member of a third party payment provider service (e.g., PayPal), the users may be clustered based on profile data. Thus, in the charitable organization example, the user may be presented with a customized charitable organization or provided with a recommendation score based on the cluster in which the user is located. Thus, users may be classified into one of n clusters based on profile data that may include, but is not limited to, gender, address, age, marital status, etc. information. Thus, the emphasis on using the clustering model 506 may be to present recommendations based on profile information. For example, all users may be classified into N clusters based on gender and age. In such an example, clustering may result in a number of clusters including, but not limited to (male, age <20), (male, 20< age <30), (female, age <20), (female, 20< age < 30). Thus, if a user belongs to a cluster (male, 20< age <30), the most popular charities in the cluster will be recommended to the user.

To determine how to obtain a recommendation or recommendation score, the score for each charity of each user may be calculated and expressed as a probability of the charity in the user cluster:

thus, turning to FIG. 5, once the models 502-506 have corresponding recommendation scores, the combined model 508 may be used to obtain the overall recommendation score 510. In one embodiment, the combined model 508 may include a decision tree model. The decision tree model is a tree diagram created based on possible decisions and possible results. As such, a decision tree may be created using at least some of the recommendation scores, P2P data, user profile data, and cross-domain information, and a charitable recommendation score may be provided using the decision tree. As an example, consider Table 1 below, where a charity score may be generated based on the merchant's information and the P2P transaction information. The combined model may be trained on a subset of users and then used to obtain recommendations.

As previously described, obtaining a recommendation score is the first step in determining the products, services, and charities (in this example) to recommend. FIG. 6 illustrates an exemplary sub-graph node representation 600 containing a user 302 and corresponding point-to-point associations 604a, b for obtaining recommendation scores. For example, consider a recommendation, where a point-to-point transaction of a user may be considered to provide a recommendation. In particular, consider an example where one or more users 302 (using a digital wallet, payment application, merchant site, third party payment provider, etc.) are considered and transactions between users and across platforms (across other merchant sites, with associated applications such as Venmo and/or Xoom, with banks, etc.) are analyzed to make recommendations. Using these transactions, it may be determined that an association exists between a friend and/or family member and a preference. For example, using the sub-graph node representation 600, it may be determined that there is a high association between friends and donations like a cause.

For example, turning to FIG. 6, it can be seen that user B (on a payment application, such as PayPal) uses a P2P application (such as Venmo) and users A, C and D to conduct a transaction. Similarly, user D has engaged in a P2P transaction, however, as shown in P2P FIGS. 604a, 604b, the P2P transaction is primarily across applications. Thus, sub-graph node representation 600 may be created by mapping users and identification information using social network data and using (fuzzy) logic. Then, using each generated subgraph 302 and 604, algorithms such as random walks and other random processes can be implemented to identify and determine associations.

At one isIn an embodiment, a random walk 604 may be used to determine a recommendation or recommendation score. To illustrate how the random walk algorithm is used to construct recommendations, consider the example of recommending charities. To make this recommendation, a series of steps may be followed. As a first step, a transition probability matrix (X) may be constructed. To form the transition probability matrix X, a matrix is considered which is a function of the probabilities of starting from node i (at time t) to node j (at time t + 1), denoted X_i,j＝P(S_t+1＝j|S_tI) wherein S_tIs the current state and S_t+1Is the next state in the random walk. Each node is also associated with a self-loop.

Next, transition probabilities for n steps are calculated. To calculate these steps, consider XⁿX.x.x … n times, where n is a configurable parameter in the algorithm. Because the example considered here is for a donation, the probability of making the donation is calculated. In this probability, node k points to charity C_dIs considered and is based on the user's 302 transaction history, which may be expressed as

Where the obtained probabilities can then be used to calculate recommendation scores for each user/customer (node in the sub-graph node representation 600) and each charity. Thus, the recommendation score may be calculated by the following formula:

where d is a charity, k is a customer or user, and m is the number of nodes in the graph. Thus, using the random walk method 504, a first charity recommendation may be provided to the user based in part on the P2P transaction in which the user participated. Note that a similar approach may be employed for other types of recommendations, and that a charity recommendation score is calculated and used for exemplary purposes. Similarly, recommendations may be made for places to eat, items to purchase, discounts to offer, and the like. Thus, by constructing a subgraph with nodes indicating transactions or interactions, the probability of an action occurring may be computed, and thus a recommendation score may be obtained.

However, in some embodiments, the random walk based recommendation 504 may not be sufficient to meet the desired criteria, or may not provide the desired recommendation (charity). Thus, as described above, a cluster-based recommendation score may be calculated and used. In still other embodiments, more personalized or customized recommendations may be needed. As shown, cross-domain based recommendation scores may be more appropriate in these instances.

To illustrate how cross-domain based recommendation scores are obtained, some insight is presented in FIG. 7. In particular, FIG. 7 illustrates a matrix diagram 700 of item-to-item collaborative filtering for obtaining recommendation scores. In such an item-to-item collaboration approach, a cross-domain approach is considered, for example, merchants and charities are considered. Thus, in this ongoing charity example, the recommendation score will be based on a prediction regarding purchases and donations. Thus, a prediction may be made that a user making a purchase at merchant X will also contribute money to charity Y.

Using this method, a charity-merchant similarity matrix or table diagram 700 illustrating such associations is computed. Considering the matrix map 700 or the similarity matrix, the first approach is to consider charity (i) and merchant (j) and identify those instances where there is similarity between the two. Checking charity 702 and merchants as shown in the similarity matrix_i704 to determine what similarity exists between the two. For example, as shown in matrix diagram 700, charity 702 and merchants_i704 share some similarities 706 in rows 1, m-2, and m. From these similarities, similarity values may be calculated and used to determine recommendation scores. In one embodiment, a similarity matrix or matrix graph 700 may be created based on, for example, co-purchases or other similarities, such that

For model training using statistical coefficient metrics such as the Jaccard index. Alternatively, other measurement and/or indexing mechanisms may be used, including but not limited to the most common k characters, hamming distance, correlation, etc. Next, given the computed index, a prediction can be determined and used to make recommendations. The predictions may be designed to provide recommendations to the user. For example, charities may be determined and recommended to the user. For prediction, a weighted sum of similarity scores calculated based on the number of purchases made by the user and the merchant may be used. Thus, a prediction or recommendation for a given charity may be provided based on a weighted sum of the similarity scores. The charity with the highest score for the user may then be recommended to the user. In one embodiment, the top k charities based on a weighted sum of the similarity scores are recommended to the user. Thus, the weighted sum of the similarity scores of the user and the charity may be based on

Wherein R represents the number of transactions of the customer with the merchant or charity, and the sum is for the first N users the merchant_jIn (1). Note that the first N user merchants for each user may be selected based on the number of transactions of the user with each merchant, wherein the execution time of the algorithm may be (significantly) reduced if the calculation is limited to the first N merchants when calculating the weighted score for each charity. Thus, the algorithm is scalable and thus adjustable for N various values.

Recall that once the recommendation scores are determined using cross-domain collaborative filtering and/or random walks and/or clusters as discussed and in conjunction with fig. 7, the recommendation scores may be further analyzed to obtain an overall recommendation score. In one embodiment, as described above in connection with FIG. 5, the recommendation score may be fed into the combined model for further processing and overall recommendation score 510 determination.

Turning to FIG. 8, an example process 800 is presented for obtaining recommendations implemented by the systems and methods shown above and in connection with FIG. 4. In particular, FIG. 8 illustrates a flow diagram that illustrates operations for obtaining recommendation scores using cross-domain collaborative filtering. According to some embodiments, the process 800 may include one or more of the operations 802 and 814, which may be implemented at least in part in executable code stored on a non-transitory tangible machine-readable medium that, when executed on one or more hardware processors, may cause the system to perform one or more of the operations 802 and 814.

Process 800 may begin at operation 802, where the system receives or determines that user information is available for processing. The user may be determined to be checking out in part by a notification applied by a payment provider on the user device, via a beacon at a merchant location, based on communications received by a point-of-sale system, a website visited from on the user device, and so forth. At checkout, the trigger may be set in communication with the customer participation platform and/or other data repositories where user and feature information may be collected. The user information and/or characterization information may include user profiles, transaction information (including point-to-point transactions), charitable contributions, peer-to-peer associations (including but not limited to family, friends, contacts), item purchases, and associations with charitable causes, peer-to-peer contributions, and the like.

Once the user information is available for transaction processing, the process 800 may continue to operation 806, where a determination is made as to which model(s) to use to obtain and present recommendations to the user based in part on the retrieved characterization or user information. As described above in connection with fig. 5, random walk, clustering, and cross-domain collaborative models can be used. Moreover, the model(s) used may be further used in conjunction with the combined model for determining a recommendation score for the charity that may be presented to the user for donations at operation 808. Recall that in the cross-domain filtering model, recommendations may be based in part on associations or predictions about people making purchases with a particular merchant and donating to a particular charity. In other words, the system is designed to show that users making purchases at a particular merchant are also likely to donate money to a particular cause. The random walk model may include a model that is more focused on transactions and peers associated with the user, and may also use information about who transacted with or what peers transacted with the user. Thus, a random walk model may be generated using mathematical paths that can be generated between transactions across entities and/or with other peers to determine a recommendation score. The clustering model may be a model that uses a technique based on grouping objects or a technique based on similarity partitioning of populations. For example, assuming the user is a member of a third party payment provider service (e.g., PayPal), the users may be clustered based on profile data. Thus, in the charitable organization example, the user may be presented with a customized charitable organization or provided with a recommendation score based on the cluster in which the user is located. Thus, users may be classified into one of n clusters based on profile data that may include, but is not limited to, gender, address, age, marital status, etc. information. Thus, the clustering model may be a model that uses user profile information to provide recommendation scores.

The combined model may be used in the following cases: when it is determined that input is required to the combined model to obtain a recommended score from a combination of one or more models. For example, in one embodiment, the combined model may be used to obtain recommendation scores from the model using cross-domain filtering. In another embodiment, it may be determined that input to the combined model may require use of a combination of random walk and/or cross-domain filtering models to obtain a recommendation score from the model. In yet another embodiment, it may be determined that input to the combined model may require the use of a cross-domain filtering model, a random walk model, and/or a clustering model to obtain a recommendation score from the model.

Next, at operation 810, one or more causes with higher recommendation scores are determined, which recommendation scores may be used herein and presented to the user at operation 812. One or more causes presented to the user may appear on the user device through a wireless or other communication network via a user interface of an application associated with the merchant and/or payment provider.

Once the recommendation score is determined, the charity cause is selected, and the recommendation is sent to the user device, the process 800 continues to operation 814 where the recommendation model is updated in operation 814 as a result of actions taken by the user in response to the recommendation. That is, the user may or may not contribute to the rendered cause when the recommendation is sent to the user. The donations or lack thereof are recorded and based on the user's past donation behavior, feedback is presented to the training model recommended by the future charity accordingly. Thus, in response to the sent recommendations, the recommendation model is retrained based on feedback received from the user equipment over the communication network

Note that although process 800 is described as including the calculation of recommendation scores, other information and models may be used with the aid of user information. Further, the order of the models used, the analysis of the recommendation scores, and the presentation of charitable causes may occur in a different order, and the process 800 is presented herein for exemplary purposes. Further, the recommendations may be presented to the user on a mobile device, smart phone, laptop, desktop, or other device that may be used to present the recommendations. Details regarding such an apparatus are described below in connection with fig. 10.

Various embodiments of the above-described methods, systems, and non-transitory memory include the following.

A system, comprising: a non-transitory memory storing instructions; and a hardware processor configured to execute instructions to cause the system to: retrieving user characterization information from the customer participation platform in response to the received notification that the user is checkout; determining a recommendation model for making recommendations using the retrieved user characterization information; performing a calculation using the determined recommendation model to obtain at least one recommendation score; analyzing the calculated at least one recommendation score to determine which of a plurality of recommendations to present to the user; and transmitting the determined one of the plurality of recommendations over a communication network. The system may retrain the recommendation model based on feedback received from the user device over a communication network in response to the sent recommendation; the at least one recommendation score is calculated using one or more recommendation models including at least a combination model; the recommendation score is obtained using one of a random walk model and a clustering model; the random walk model determines the recommendation score using a combination of user profile information from the user characterization information and a point-to-point transaction; the clustering model determines a recommendation score using profile information from the retrieved user characterization information; the recommendation score is obtained using a cross-domain filtering model; and/or the combined model comprises a decision tree model and the total recommendation score is obtained using one or more recommendation scores.

A method, comprising: retrieving user characterization information from the customer participation platform in response to the received notification that the user is checkout; determining a recommendation model for making recommendations using the retrieved user characterization information; performing a calculation using the determined recommendation model to obtain at least one recommendation score; analyzing the calculated at least one recommendation score to determine which of a plurality of recommendations to present to the user; and transmitting the determined one of the plurality of recommendations over a communication network. The method may further comprise: in response to the sent recommendation, re-training the recommendation model based on feedback received from the user device over a communication network. The method may further comprise: the at least one recommendation score is calculated using one or more recommendation models including at least a combination model; the recommendation score is obtained using one of a random walk model and a clustering model; the random walk model determines the recommendation score using a combination of user profile information from the user characterization information and a point-to-point transaction; the clustering model determines a recommendation score using profile information from the retrieved user characterization information; the recommendation score is obtained using a cross-domain filtering model; and/or the combined model comprises a decision tree model and the total recommendation score is obtained using one or more recommendation scores.

A non-transitory machine-readable medium having instructions stored thereon, the instructions being executable to cause operations comprising: retrieving user characterization information from the customer participation platform in response to the received notification that the user is checkout; determining a recommendation model for making recommendations using the retrieved user characterization information; performing a calculation using the determined recommendation model to obtain at least one recommendation score; analyzing the calculated at least one recommendation score to determine which of a plurality of recommendations to present to the user; and transmitting the determined one of the plurality of recommendations over a communication network. The non-transitory machine-readable medium further comprises: in response to the sent recommendation, re-training the recommendation model based on feedback received from the user device over a communication network. In other embodiments of the non-transitory machine-readable medium, the at least one recommendation score is calculated using one or more recommendation models including at least a combination model; and/or the recommendation score is obtained using one of a random walk model and a clustering model.

A system, comprising: a non-transitory memory storing instructions; and a processor configured to execute instructions to cause the system to: in response to determining that the user information and the cross-domain information are available for processing, retrieving a set of data associated with the user; determining a first recommendation score using a first portion of the retrieved user information; determining a second recommendation score using a second portion of the retrieved user information or cross-domain information; analyzing the first recommendation score and the second recommendation score to determine which one or more of the first recommendation score and the second recommendation score to select; transferring the selected one or more of the first recommendation score and the second recommendation score to a combined machine learning model; obtaining a total recommendation score based in part on the transferred selected one or more recommendation scores; and presenting the recommendation on the user device based on the obtained overall recommendation score. The system may further include the first recommendation score is obtained using one of a random walk model and a clustering model; the random walk model determines the first recommendation score using a combination of user profile information from the user information and a point-to-point transaction; the clustering model determines the first recommendation score using profile information from the retrieved user information; the second recommendation score is obtained using a cross-domain filtering model; the cross-domain filtering model determines the second recommendation score using a combination of user information and cross-domain information; the combined machine learning model comprises a decision tree model and uses one or more of the first and second recommendation scores to obtain the overall recommendation score; and/or obtaining an overall recommendation score using the combined machine learning model and a combination of the first, second, and third recommendation scores.

A method, comprising: in response to determining that the user information and the cross-domain information are available for processing, retrieving a set of data associated with the user; determining a first recommendation score using a first portion of the retrieved user information; determining a second recommendation score using a second portion of the retrieved user information or cross-domain information; analyzing the first recommendation score and the second recommendation score to determine which one or more of the first recommendation score and the second recommendation score to select and use for further processing; transferring the selected one or more of the first recommendation score and the second recommendation score to a combined machine learning model; obtaining a total recommendation score based in part on the transferred selected one or more recommendation scores; and presenting the recommendation on the user device based on the obtained overall recommendation score. The method may further include, the first recommendation score is obtained using one of a random walk model and a clustering model; the random walk model determines the first recommendation score using a combination of user profile information from the user information and a point-to-point transaction; the clustering model determines the first recommendation score using profile information from the retrieved user information; the second recommendation score is obtained using a cross-domain filtering model; the cross-domain filtering model determines the second recommendation score using a combination of user information and cross-domain information; the combined machine learning model comprises a decision tree model and uses one or more of the first and second recommendation scores to obtain the overall recommendation score; and/or obtaining an overall recommendation score using the combined machine learning model and a combination of the first, second, and third recommendation scores.

A non-transitory machine-readable medium having instructions stored thereon that are executable to cause operations comprising: in response to determining that the user information and the cross-domain information are available for processing, retrieving a set of data associated with the user; determining a first recommendation score using a first portion of the retrieved user information; determining a second recommendation score using a second portion of the retrieved user information or cross-domain information; analyzing the first recommendation score and the second recommendation score to determine which one or more of the first recommendation score and the second recommendation score to select and use for further processing; transferring the selected one or more of the first recommendation score and the second recommendation score to a combined machine learning model; obtaining a total recommendation score based in part on the transferred selected one or more recommendation scores; and presenting the recommendation on the user device based on the obtained overall recommendation score. The non-transitory machine-readable medium may further include that the first recommendation score is obtained using one of a random walk model and a clustering model; the random walk model determines the first recommendation score using a combination of user profile information from the user information and a point-to-point transaction; obtaining an overall recommendation score using the combined machine learning model and a combination of the first, second, and third recommendation scores.

Fig. 9 is a block diagram of a networked system 900 for implementing the processes described herein, according to an embodiment. In particular, FIG. 9 illustrates a block diagram of a system 900 for attesting recommendations using cross-domain filtering. As shown, system 900 may include or implement a plurality of devices, computers, servers, and/or software components for performing various methods in accordance with the described embodiments. It should be understood that the devices, computers, and/or servers shown in fig. 9 may be deployed differently, and that the operations performed by and/or services provided by such devices, computers, and/or servers may be combined or separated and performed by a greater or lesser number of devices, computers, and/or servers for a given embodiment. Further, one or more of the devices, computers, and/or servers may be operated and/or maintained by the same or different entities.

The system 900 includes a merchant/charity device 902, a primary user device 932, and a third party service provider computer 912 in communication via a network 950. These devices 902, 932, and 912 are exemplary devices that may interact during a transaction that may result in a charity donation.

Merchant device 902, primary user device 932, and third-party service provider computer 912 may each include one or more processors, memories, and other suitable components for executing computer-executable instructions, such as program code and/or data. Computer-executable instructions may be stored on one or more computer-readable media or computer-readable devices to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer-readable media, such as memory or data storage devices internal and/or external to the various components of system 900, and/or accessible via network 950.

The merchant device 902 may be implemented as a communication device that may utilize suitable hardware and software configured for wired and/or wireless communication with the primary user device 932 and the third-party service provider computer 912. For example, merchant device 902 may be implemented as a Personal Computer (PC), smartphone, notebook/tablet computer, point-of-sale device, watch with suitable computer hardware resources, glasses with suitable computer hardware, other types of wearable computing devices, implantable communication devices, servers, and/or other types of computing devices capable of sending and/or receiving data. The merchant device 902 may correspond to and be used by the user, such as an employee of the merchant and/or another person authorized by the merchant, or be used independently as a stand-alone system.

Merchant device 902 may include one or more payment applications 904, other applications 906, database 908, and network interface component 910. The payment application 904 and other applications 906 may correspond to executable processes, programs, and/or applications having associated hardware. In other embodiments, merchant device 902 may include additional or different components with dedicated hardware and/or software to perform operations associated with payment application 904 and/or other applications 906.

The payment application 904 may facilitate financial transactions corresponding to sales of goods and/or services provided by the merchant. For example, the payment application 904 may provide an interface for a customer to purchase goods or services, donate money, and receive customer payment information (e.g., customer credit card information). Payment application 904 may also send the customer payment information to a payment processor (e.g., such as a payment processor corresponding to third party service provider computer 912) to process the customer payment information. The payment application 904 may also facilitate other types of financial transactions such as banking transactions, online payments, funds transfers, donations, and the like.

Merchant device 902 may execute other applications 906 to perform various other tasks and/or operations corresponding to merchant device 902. For example, other applications 906 may include: a security application for implementing client-side security features, a programmatic client application for interfacing with an appropriate Application Programming Interface (API) over network 950, or other types of applications. In various embodiments, other applications 906 may include social networking applications. Additionally, other applications 906 may include device interfaces and other display modules that may receive input and/or output information. For example, the other applications 906 may include a Graphical User Interface (GUI) configured to provide an interface to a user. For example, the graphical user interface may include a selectable button designed to provide a donation to a charity and/or the other application 906 may be associated with a charity designed to make the donation or donation.

Merchant device 902 may also include database 908, which database 908 may be stored in memory and/or other storage of merchant device 602. Database 908 may include, for example, Identifiers (IDs), such as operating system registry keys, cookies associated with payment application 904 and/or other applications 906, IDs associated with hardware of network interface component 910, IDs for payment/user/device authentication or identification, and/or other suitable IDs. Database 908 may also include information corresponding to one or more purchase transactions by customers who purchase goods or services from merchants, browsing histories of customers, or other types of customer information. In some embodiments, merchant device 902 may also include information corresponding to a payment token, such as a payment token generated by third-party service provider computer 912.

Merchant device 902 may also include at least one network interface component 910, the network interface component 910 configured to communicate with various other devices, such as a primary user device from user 302h and/or a third-party service provider computer 912. In various embodiments, the network interface component 910 may include a Digital Subscriber Line (DSL) modem, a public switched telephone network (PTSN) modem, an Ethernet device, a broadband device, a satellite device, and/or various other types of wired and/or wireless network communication devices, including microwave, radio frequency, infrared, and/or broadband devices,

Bluetooth low energy, Near Field Communication (NFC) devices, and the like. Additionally, or alternatively, the merchant device 902 may include a charity device designed to accept and conduct transactions with the user when making donations.

Third party service provider computer 912 may, for example, be maintained by a third party service provider, which may provide payment processing services for the merchant. In one example, the third party service provider may be a PAYPAL by san Jose, Calif., USA^TMProvided by a company. Alternatively, third party service provider computer 912 may be associated with user 302 of the host device. Thus, third party service provider computer 912 includes one or more payment processing applications 914 that may be configured to process payments received from merchant device 902 or from selections at primary user device 932And (4) information. For example, the payment application 904 of the merchant device 902 may receive payment information from a customer to purchase a service or good provided by the merchant. Upon receiving the payment information, payment application 904 may send the payment information to third party service provider computer 912. Payment processing application 914 of third party service provider computer 912 may receive and process payment information. As another example, the payment application 904 may present the payment code on a display of a user device associated with the merchant. The payment code may be scanned or sent to merchant device 902 for payment processing. As yet another example, when the payment processing application has been authorized and is ready for post-processing, the application may present a successful transaction notification on a display of the user device.

Third party service provider computer 912 may execute other applications 916 to perform various other tasks and/or operations corresponding to third party service provider computer 912. For example, other applications 916 may include: security applications for implementing client security features, programmatic client applications for interfacing with appropriate APIs over network 950, or applications associated with charity recommendations, and other types of applications. Other applications 916 may also include additional communication applications, such as email, text, voice, and IM application programs that enable communication of emails, calls, text, and other notifications over network 950. In various embodiments, other applications 916 may include location detection applications, such as map, compass, and/or GPS applications, which may be used to determine the location of third party service provider computer 912. In addition, other applications 916 may include device interfaces and other display modules that may receive input and/or output information. For example, other applications 916 may include GUIs configured to provide interfaces to one or more users.

Third-party service provider computer 912 may also include a database 918, and database 918 may be stored in a memory and/or other storage device of third-party service provider computer 912. The database 918 may include, for example, IDs such as operating system registry keys, cookies associated with the payment processing application 914 and/or other applications 916, IDs associated with hardware of the network interface component 922, IDs for payment/user/device authentication or identification, transaction IDs, and/or other suitable IDs.

According to particular embodiments, third party service provider computer 912 may include a set of payment profiles 920, the set of payment profiles 920 corresponding to past sales transactions performed by a merchant device for one or more customers of the merchant. Alternatively, third party service provider computer 912 may include a set of merchant payment profiles corresponding to payment sources associated with the corresponding merchants. For example, a particular payment profile from the set of payment profiles 920 may include payment information corresponding to a particular customer of a merchant and/or a merchant associated with the user. The payment information may include credit card information (e.g., encrypted card number, expiration date, security code, card issuer, and so forth), Automated Clearing House (ACH) information (e.g., encrypted account number, banking number, and so forth), identification information associated with a particular customer/user (e.g., customer identifier, name, address, phone number, date of birth, and so forth), billing information, credit rating, and/or any other type of payment information associated with a particular customer. Further, other payment profiles of the set of payment profiles 920 may include payment information corresponding to other customers of the merchant and/or other merchants associated with the user. Additionally, third party service provider computer 912 may store the set of payment profiles 920 according to a first file format.

Similarly, in another embodiment, third party service provider computer 912 may include a set of contributions, contact profiles, user profile information, etc., which may be used to provide recommendations. These recommendations may be presented to the user of the main user device 932 and identified based in part on the collected and stored profile information.

Third party service provider computer 912 may also store a set of payment tokens corresponding to the set of payment profiles 920. For example, each payment profile of the set of payment profiles 920 may be associated with a respective payment token of the set of payment tokens. In some embodiments, each payment profile may include a respective payment token from the set of payment tokens. The set of payment tokens may be specific to third-party service provider computer 912 (e.g., computers from other service providers may not be able to use the set of payment tokens), and may enable merchant device 902 to more securely process payment transactions with third-party service provider computer 912. For example, to process a payment transaction involving a credit card number associated with a particular payment profile, third party service provider computer 912 may provide merchant device 902 with a particular payment token that is different from the credit card number. The merchant device 902 may use the particular payment token to process the payment transaction instead of the credit card number. Further, the merchant device may store and associate a particular payment token with a particular payment profile rather than a credit card number, thereby protecting the credit card number from theft in a potential security breach of the merchant device 902.

In various embodiments, third-party service provider computer 912 also includes at least one network interface component 922, network interface component 922 being configured to communicate with merchant device 902 and/or primary user device 932 via network 950.

Third party provider computer 912 can also include a data classification component 924 that can be employed to classify the raw data. In one embodiment, raw data received by third party service provider computer 912 and/or stored in database 918 may be analyzed to identify errors in post-transaction processing, determine cross-domain correlations, determine user-specific recommendations, determine recommendation scores, and the like.

Primary user device 932 may be implemented as a communication device that may utilize suitable hardware and software configured for wired and/or wireless communication with merchant device 902 and third-party service provider computer 912. The primary user device 932 may be a Personal Computer (PC), a smart phone, a notebook/tablet computer, a watch with suitable computer hardware resources, glasses with suitable computer hardware (e.g., GOOGLE)

) Other types of wearable computing devices, implantable communication devices, and/or the likeOther types of computing devices that send and/or receive data. In one embodiment, the primary user device 932 may be a mobile device that communicates with a wearable device (or secondary user device), the merchant device 902, or directly with the third-party service provider system 912.

The primary user device 932 may include a payment processing application 926, which payment processing application 926 may function as a digital wallet that may communicate with the merchant device 902, the secondary user device, and/or the third-party service provider 912 to make purchases and transactions. The payment processing application 926 may work in conjunction with the database 930 to retrieve bank account information, user accounts, security codes, tokens, which may be associated with various merchant locations, charities, and other related causes. Similarly, the payment processing application may also provide access to a user profile for determining payment methods, processing codes, and/or recommendations to make and use.

The primary user device 932 may also include other applications 928 to perform various other tasks and/or operations corresponding to the primary user device 932. For example, other applications 928 may facilitate communication with merchant device 902, such as receiving an indication from merchant device 902 to switch payment processing services from a third-party service provider to a service provider. As another example, other applications 928 may include security applications, applications capable of specifying a primary interaction device, and applications that allow website searches (including access to merchant websites). Other applications 928 may also include additional communication applications such as email, text, voice, and IM applications that enable communication of emails, calls, text, and other notifications over network 950. In various embodiments, other applications 928 may include location detection applications, such as map, compass, and/or GPS applications, that may be used to determine the location of primary user device 932. Other applications 928 may include social networking applications. In addition, other applications 928 can include device interfaces and other display modules that can receive input and/or output information. For example, other applications 928 may include GUIs configured to provide interfaces to one or more users.

The primary user device 932 may also include a database 930, and the database 930 may be stored in a memory of the primary user device 932 and/or other storage devices. Database 930 may include, for example, Identifiers (IDs) such as operating system registry entries, cookies associated with web browser and/or other applications 928, IDs associated with hardware of network interface component 934, IDs for payment/user/device authentication or identification, banking information, merchant information, user accounts, and/or other suitable IDs.

Primary user device 932 may also include at least one network interface component 934, network interface component 934 being configured to communicate with various other devices, such as merchant device 902 and/or third party service provider computer 912.

FIG. 10 illustrates, in block diagram format, an example computer system 1000 suitable for implementation on one or more devices of the system in FIG. 4. In various implementations, devices including computer system 1000 may include computing devices (e.g., smart or mobile devices, computing pads, personal computers, laptops, wearable devices, PDAs, servers, etc.) capable of communicating with network 1026. The service provider and/or the content provider may utilize a network computing device (e.g., a network server or third party service provider computer 912) that is capable of communicating with the network 1026. It should be appreciated that each of the devices used by users, service providers, and content providers may be implemented as a computer system 1000 in the following manner.

Further, as more and more devices become capable of communication, such as new smart devices that report, track, communicate messages, relay information, etc., using wireless communication, these devices may be part of the computer system 1000. For example, windows, walls, and other objects may double as touch screen devices for user interaction. Such devices may be combined with the systems discussed herein.

Computer system 1000 may include a bus 1010 or other communication mechanism for communicating information data, signals and information between the various components of the computer system 1000. The components include an input/output (I/O) component 1004 that processes user actions (e.g., selecting a key from a key/keyboard, selecting one or more buttons, links, operable elements, etc., and sending corresponding signals to a bus 1010). The I/O components 1004 may also include output components such as a display 1002 and cursor controls 1008 (e.g., keyboard, buttons, mouse, touch screen, etc.). In some examples, I/O components 1004 may include an image sensor, such as a Complementary Metal Oxide Semiconductor (CMOS) image sensor or the like, for capturing images and/or video. An audio input/output component 1006 may also be included to allow a user to use speech for inputting information by converting audio signals. The audio I/O component 1006 may allow a user to hear audio. Transceiver or network interface 1022 sends and receives signals between computer system 1000 and other devices (e.g., another user device, a merchant server, an email server, an application service provider, a web server, a payment provider server, and/or other servers, etc.) via a network. In various embodiments, such as for many cellular telephone and other mobile device embodiments, the transmission may be wireless, although other transmission media and methods may also be suitable. Processor 1018 (which may be a microcontroller, Digital Signal Processor (DSP), or other processing component) processes these various signals for display on computer system 1000 or transmission over a network 1026 to other devices via a communication link 1024, for example. Further, in some embodiments, communication link 1024 may be a wireless communication. Processor 1018 may also control the transfer of information such as cookies, IP addresses, images, and the like to other devices.

Components of computer system 1000 may also include a system memory component 1012 (e.g., RAM), a static storage component 1014 (e.g., ROM), and/or a disk drive 1016. Computer system 1000 performs specific operations by processor 1018 and other components by executing one or more sequences of instructions contained in system memory component 1012. Logic may be encoded in a computer-readable medium, which may refer to any medium that participates in providing instructions to processor 1018 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, and/or transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component 1012, and transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1010. In one embodiment, the logic is encoded in a non-transitory machine-readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

Some common forms of computer-readable media include, for example, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM, any other optical medium, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.

Components of computer system 1000 may also include a short-range communications interface 1020. In various embodiments, short-range communication interface 1020 may include a transceiver circuit, an antenna, and/or a waveguide. Short-range communication interface 1020 may use one or more short-range wireless communication technologies, protocols, and/or standards (e.g., WIFI, etc.),

Bluetooth Low Energy (BLE), infrared, NFC, etc.).

In various embodiments, short-range communication interface 1020 may be configured to detect other devices (e.g., primary user device 1032, merchant device 1002. short-range communication interface 1020 may create a communication area for detecting other devices having short-range communication capabilities, when other devices having short-range communication capabilities are placed in the communication area of short-range communication interface 1020, the short-range communication interface 1020 may detect other devices and exchange data with the other devices, the short-range communication interface 1020 may receive identifier data packets from the other devices when in sufficient proximity, the identifier data packets may include one or more identifiers, which may be an operating system registry key, a cookie associated with the application, an identifier associated with hardware of another device, and/or various other suitable identifiers.

In some embodiments, short-range communication interface 1020 may use a short-range communication protocol (e.g., Wi-Fi) to identify a local area network and join the local area network. In some examples, computer system 1000 may use short-range communication interface 1020 to discover and/or communicate with other devices that are part of a local area network. In some embodiments, short-range communication interface 1020 may further exchange data and information with other devices communicatively coupled to short-range communication interface 1020.

In various embodiments of the present disclosure, execution of sequences of instructions to practice the present disclosure may be performed by computer system 1000. In various other embodiments of the present disclosure, a plurality of computer systems 1000 coupled to a network (e.g., a LAN, a WLAN, a PTSN, and/or various other wired or wireless networks including telecommunications, mobile, and cellular telephone networks) by a communication link 1024 may execute sequences of instructions in coordination with one another to practice the present disclosure. The modules described herein may be embodied in one or more computer-readable media or in communication with one or more processors to perform or process the techniques and algorithms described herein.

Computer systems can send and receive messages, data, information, and instructions, including one or more programs (i.e., application code), through communication link 1024 and communication interface. The received program code may be executed by a processor, received as received, and/or stored for execution in a disk drive component or some other non-volatile storage component.

Where applicable, the various embodiments provided by the present disclosure can be implemented using hardware, software, or a combination of hardware and software. Further, where applicable, the various hardware components and/or software components described herein can be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present invention. Where applicable, the various hardware components and/or software components described herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the invention. Further, where applicable, it is contemplated that software components can be implemented as hardware components, and vice versa.

Software, such as program code and/or data, according to the present disclosure can be stored on one or more computer-readable media. It is also contemplated that the software identified herein may be implemented using one or more computers and/or computer systems, networks, and/or otherwise. Where applicable, the order of various steps described herein can be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

The foregoing disclosure is not intended to limit the disclosure to the precise forms or particular fields of use disclosed. It is therefore contemplated that various alternative embodiments and/or modifications (whether explicitly described or implied herein) of the invention may be possible in accordance with the invention. For example, the above embodiments have focused on merchants/vendors and customers; however, the customer or consumer may pay for, or otherwise interact with, any type of recipient, including charities and individuals. Thus, a "merchant," as used herein, may also include charities, individuals, and any other entity or person that receives payment from a customer. Having thus described embodiments of the invention, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the scope of the invention. Accordingly, the disclosure is limited only by the claims.

Claims (40)

1. A system, comprising:

a non-transitory memory storing instructions; and

a hardware processor configured to execute instructions to cause the system to:

retrieving user characterization information from the customer participation platform in response to the received notification that the user is checkout;

determining a recommendation model for making recommendations using the retrieved user characterization information;

performing a calculation using the determined recommendation model to obtain at least one recommendation score;

analyzing the calculated at least one recommendation score to determine which of a plurality of recommendations to present to the user; and

transmitting the determined one of the plurality of recommendations over a communication network.

2. The system of claim 1, wherein executing the instructions further causes the system to:

in response to the sent recommendation, re-training the recommendation model based on feedback received from the user device over a communication network.

3. The system of claim 1, wherein the at least one recommendation score is calculated using one or more recommendation models including at least a combination model.

4. The system of claim 1, wherein the recommendation score is obtained using one of a random walk model and a clustering model.

5. The system of claim 2, wherein the random walk model determines the recommendation score using a combination of user profile information from the user characterization information and a point-to-point transaction.

6. The system of claim 4, wherein the clustering model uses profile information from the retrieved user characterization information to determine the recommendation score.

7. The system of claim 1, wherein the recommendation score is obtained using a cross-domain filtering model.

8. The system of claim 2, wherein the combined model comprises a decision tree model and one or more recommendation scores are used to obtain an overall recommendation score.

9. A method, comprising:

retrieving user characterization information from the customer participation platform in response to the received notification that the user is checkout;

determining a recommendation model for making recommendations using the retrieved user characterization information;

performing a calculation using the determined recommendation model to obtain at least one recommendation score;

analyzing the calculated at least one recommendation score to determine which of a plurality of recommendations to present to the user; and

transmitting the determined one of the plurality of recommendations over a communication network.

10. The method of claim 9, further comprising:

in response to the sent recommendation, re-training the recommendation model based on feedback received from the user device over a communication network.

11. The method of claim 9, wherein the at least one recommendation score is calculated using one or more recommendation models including at least a combination model.

12. The method of claim 9, wherein the recommendation score is obtained using one of a random walk model and a clustering model.

13. The method of claim 10, wherein the random walk model uses a combination of user profile information from the user characterization information and a point-to-point transaction to determine the recommendation score.

14. The method of claim 12, wherein the clustering model uses profile information from the retrieved user characterization information to determine the recommendation score.

15. The method of claim 9, wherein the recommendation score is obtained using a cross-domain filtering model.

16. The method of claim 12, wherein the combined model comprises a decision tree model and one or more recommendation scores are used to obtain an overall recommendation score.

17. A non-transitory machine-readable medium having instructions stored thereon, the instructions being executable to cause operations comprising:

retrieving user characterization information from the customer participation platform in response to the received notification that the user is checkout;

determining a recommendation model for making recommendations using the retrieved user characterization information;

performing a calculation using the determined recommendation model to obtain at least one recommendation score;

analyzing the calculated at least one recommendation score to determine which of a plurality of recommendations to present to the user; and

transmitting the determined one of the plurality of recommendations over a communication network.

18. The non-transitory machine-readable medium of claim 17, wherein the operations further comprise:

in response to the sent recommendation, re-training the recommendation model based on feedback received from the user device over a communication network.

19. The non-transitory machine-readable medium of claim 17, wherein the at least one recommendation score is calculated using one or more recommendation models including at least a combination model.

20. The non-transitory machine-readable medium of claim 17, wherein the recommendation score is obtained using one of a random walk model and a clustering model.

21. A system, comprising:

a non-transitory memory storing instructions; and

a processor configured to execute instructions to cause the system to:

in response to determining that the user information and the cross-domain information are available for processing, retrieving a set of data associated with the user;

determining a first recommendation score using a first portion of the retrieved user information;

determining a second recommendation score using a second portion of the retrieved user information or cross-domain information;

analyzing the first recommendation score and the second recommendation score to determine which one or more of the first recommendation score and the second recommendation score to select;

transferring the selected one or more of the first recommendation score and the second recommendation score to a combined machine learning model;

obtaining a total recommendation score based in part on the transferred selected one or more recommendation scores; and

the recommendation is presented on the user device based on the obtained overall recommendation score.

22. The system of claim 21, wherein the first recommendation score is obtained using one of a random walk model and a clustering model.

23. The system of claim 22, wherein the random walk model determines the first recommendation score using a combination of user profile information from the user information and a point-to-point transaction.

24. The system of claim 22, wherein the clustering model uses profile information from the retrieved user information to determine the first recommendation score.

25. The system of claim 21, wherein the second recommendation score is obtained using a cross-domain filtering model.

26. The system of claim 21, wherein the cross-domain filtering model uses a combination of user information and cross-domain information to determine the second recommendation score.

27. The system of claim 21, wherein the combined machine learning model comprises a decision tree model and the overall recommendation score is obtained using one or more of the first and second recommendation scores.

28. The system of claim 21, wherein a total recommendation score is obtained using the combined machine learning model and a combination of the first, second, and third recommendation scores.

29. A method, comprising:

in response to determining that the user information and the cross-domain information are available for processing, retrieving a set of data associated with the user;

determining a first recommendation score using a first portion of the retrieved user information;

determining a second recommendation score using a second portion of the retrieved user information or cross-domain information;

analyzing the first recommendation score and the second recommendation score to determine which one or more of the first recommendation score and the second recommendation score to select and use for further processing;

transferring the selected one or more of the first recommendation score and the second recommendation score to a combined machine learning model;

obtaining a total recommendation score based in part on the transferred selected one or more recommendation scores; and

the recommendation is presented on the user device based on the obtained overall recommendation score.

30. The method of claim 29, wherein the first recommendation score is obtained using one of a random walk model and a clustering model.

31. The method of claim 30, wherein the random walk model uses a combination of user profile information from the user information and a point-to-point transaction to determine the first recommendation score.

32. The method of claim 30, wherein the clustering model uses profile information from the retrieved user information to determine the first recommendation score.

33. The method of claim 29, wherein the second recommendation score is obtained using a cross-domain filtering model.

34. The method of claim 29, wherein the cross-domain filtering model uses a combination of user information and cross-domain information to determine the second recommendation score.

35. The method of claim 29, wherein the combined machine learning model comprises a decision tree model and one or more of the first and second recommendation scores are used to obtain the overall recommendation score.

36. The method of claim 29, wherein a total recommendation score is obtained using the combined machine learning model and a combination of the first, second, and third recommendation scores.

37. A non-transitory machine-readable medium having instructions stored thereon that are executable to cause operations comprising:

in response to determining that the user information and the cross-domain information are available for processing, retrieving a set of data associated with the user;

determining a first recommendation score using a first portion of the retrieved user information;

determining a second recommendation score using a second portion of the retrieved user information or cross-domain information;

analyzing the first recommendation score and the second recommendation score to determine which one or more of the first recommendation score and the second recommendation score to select and use for further processing;

transferring the selected one or more of the first recommendation score and the second recommendation score to a combined machine learning model;

obtaining a total recommendation score based in part on the transferred selected one or more recommendation scores; and

the recommendation is presented on the user device based on the obtained overall recommendation score.

38. The non-transitory machine-readable medium of claim 37, wherein the first recommendation score is obtained using one of a random walk model and a clustering model.

39. The non-transitory machine-readable medium of claim 38, wherein the random walk model determines the first recommendation score using a combination of user profile information from the user information and a point-to-point transaction.

40. The non-transitory machine-readable medium of claim 37, wherein an overall recommendation score is obtained using the combined machine learning model and a combination of the first, second, and third recommendation scores.

Images