PayPal, Inc.
[2023] APO 54
•27 October 2023
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
PayPal, Inc. [2023] APO 54
Patent Application: 2019395313
Title:System and method for obtaining recommendations using scalable cross-domain collaborative filtering
Patent Applicant: PayPal, Inc.
Delegate:Dr S. J. Smith
Decision Date: 27 October 2023
Hearing Date: Written submissions filed on 28 July 2023
Catchwords: PATENTS – examiner’s objection – whether invention is a manner of manufacture – system for providing recommendations for transactions to a user using machine learning – alleged invention not a manner of manufacture – application refused
Representation: Patent attorney for the applicant: FPA Patent Attorneys Pty Ltd
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2019395313
Title:System and method for obtaining recommendations using scalable cross-domain collaborative filtering
Patent Applicant: PayPal, Inc.
Date of Decision: 27 October 2023
DECISION
The claimed invention is not for a manner of manufacture.
I refuse the application.
REASONS FOR DECISION
Background
Patent application 2019395313 (the application) in the name of PayPal, Inc. (the applicant) was filed on 3 December 2019 under the provisions of the Patent Cooperation Treaty. The application claims priority from US 16/215,808 filed on 11 December 2018.
Examination was requested on 3 June 2021, and a first examination report was issued on 19 May 2022 raising objections of lack of manner of manufacture, clarity, novelty and inventive step. A response to the examination report, accompanied by amendments to the specification, was filed on 23 November 2022, and a second examination report, maintaining the objection to lack of manner of manufacture and objecting to lack of clarity and inventive step, was issued on 12 December 2022. A response to the second examination report, again accompanied by amendments to the specification, was filed on 16 February 2023. A third examination report, maintaining only the objection to lack of manner of manufacture, was issued on 9 March 2023. On 24 March 2023 the applicant requested to be heard in relation to the outstanding objection. The matter was heard by written submissions filed on 28 July 2023. I note that no objections were raised to the allowability of the amendments proposed during examination, and this decision relates to the specification as proposed to be amended.
The application was filed after 15 April 2013 and therefore is governed by the Patents Act 1990 (the Act) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012. The standard of proof that applies to examination is the balance of probabilities – if satisfied on the balance of probabilities that the application complies with the Act I must accept the application.[1] If I am not so satisfied, then I can refuse the application.[2]
[1] Section 49 of the Act as amended.
[2] The Explanatory Memorandum, Intellectual Property Laws Amendment (Raising the Bar) Bill 2011 at page 54.
Pursuant to regulation 13.4(1)(g) when the Commissioner gives an applicant an opportunity to be heard in relation to an examiner’s objection and issues a written decision, the period for gaining acceptance of the application may be extended until three months from the date the decision is issued, or, pursuant to regulation 13.4(3), for a period of longer than three months if the Commissioner considers it appropriate.
The specification
By way of background, it is explained in the specification that electronic devices and communications are used for processing transactions, which generally begin with a consumer submitting a funding instrument for payment and continue to a vendor for transaction authorisation. The specification states that in some instances a recommendation may be provided to a consumer prior to completion of such a transaction (for example, donating to a cause or charity), but this type of recommendation is often not tailored to the user. The specification concludes that “to increase the chance of a user purchase or donation, it would be beneficial to create a system that provides recommendations that are tailored to a user and across domains.”[3]
[3] Specification, [0003].
The specification states:
“Conventionally, to increase customer’s engagement, merchants, third-party service providers, and other entities that provide a product or service, may rely on a recommendation of a product or service based on popularity. The engagement is easy to implement, and the product and/or service may be easily presented and considered for purchase. For example, consider Figure 1 which illustrates a basic system and method for presenting a recommendation to user. As illustrated, a recommendation may derive from a network 102. The network 102 can include any two computers, servers, or other system/device which can be linked together in order to share resources and exchange electronic information. The internet, the cloud, a group of servers, a data center, social media may all be considered part of a network 102. This network may be access and used for determining a most popular item, product, service, or entity to recommend. For example, social media may be scraped, and the data obtained analyzed to determine that a new smart gadget has been released and is trending. Such smart gadget may therefore be presented to a user on a device 106. As another example, a natural disaster may have occurred recently and as a result of the media coverage a popular entity providing relief effort may be presented to the user for donation. Still further, in looking for a charity to contribute to, the YMCA, United Way, Red Cross, etc. may be presented based on knowledge and popularity. These examples, however, fail to neglect a customer’s behaviors and/or products, services, entities, etc., which may be smaller or in lower demand.
It is therefore beneficial to have a system which can consider various aspects of a user before making a recommendation. For example, consider a recommendation to a charitable cause. Using the simplified method and system 100 presented in Figure 1, smaller charities will be neglected, and customer’s behaviors omitted. Alternatively, by associating purchase behaviors, user profiles, donation history, transactional history, and the like with donations recommendations may be more customized and relevant to a user.”[4]
[4] Specification, [0017]-[0018].
I note here that while the focus in the description is on charities, the specification states that the application is not limited to such recommendations and may be used for providing recommendations for other products, services and entities.[5]
[5] Specification, [0019].
Characterisation information that may be used for making a recommendation include donation history (if the user is an existing donor), user profile information, purchase history, and charities associated with locations where purchases are made. General characterisation information such as cause popularity, trends and other relational information may also be used.
Figures 3A-3C, reproduced below, illustrate recommendation scenarios and use cases based on varying characterisation scenarios.
Figure 3A shows a use case that uses prior donation information for making the charitable cause recommendation. This use case may use a collaborative filter type approach. Specifically, user 302a has a donor history with donations made to charitable causes 304-310. User 302b has a donation history focused on a single cause 308. User 302c has a donor history focused on causes 306 and 310. It is explained that:
“In one embodiment, a charitable cause recommendation may be provided to a user 302c using a collaborative filtering approach. In this scenario, an observation, analysis, or correlation can be made such that a similarity is identified between user 302a and user 302b. This correlation or similarity 312 can be identified based in part on the observation that user 302c, like user 302a, donated to charitable causes 306 and 308. Therefore, based on this assessment and similarity 312, two new recommendations 314 may be made and surfaced to user 302c.”[6]
[6] Specification, [0023].
Figures 3B and 3C are similarly explained:
“At Figures 3B, another recommendation scenario and use case is presented based on other varying characterization information. For the use case, transactional information is considered for making a recommendation. In particular, who a user has transacted with and in particular other peers the user has transacted with, (e.g., P2P transaction history). Additionally, characterization information regarding the charitable causes which were donated are also used. In order to provide some insight on the use of P2P transaction history for making a recommendation, Figure 3B is provided. For this use case, user 302d is illustrated as having transacted 320 with user 302e, while user 302e transacts 320 with user 302f. And moreover, user 302e and user 302f have a donation history, with user 302e donating 322 to charitable causes 324 and 326 while user 302f donates 322 to charitable cause 324. Therefore, the known transaction history and donation characterization information may be used to provide user 302d with a recommendation. In this use case, user 302d is recommended 318 charitable causes 318 and 324 based on the charities the user’s 302d contacts are donating to.
Turning to Figure 3C, yet another recommendation scenario is presented. In this recommendation use case, the purchase history and charitable relationships are considered as the characterization information. For the use case, user 302g may be provided with a recommendation that is surfaced based on the user’s purchase history. Thus, charitable cause 328 is presented bases on a purchase 324 of an item 330 by user 302g. To make this recommendation, in one embodiment, metadata attributes associated with the purchase item 330 may be extracted. For example, attributes including the item name, category, description, and the like may be extracted. Then, using the extracted metadata attributes, a charitable cause 328 or other recommendation may be presented to the user 302g.”[7]
[7] Specification, [0024]-[0025]
Figure 4, shown below, shows an exemplary architecture for implementing a system and platform for making recommendations.
Figure 4 is explained as follows:
“At checkout 402, the user 302h may be preparing to complete a purchase and may be prompted with the opportunity to make a donation to a charitable cause. Checkout 402 at the payment provider may then trigger a communication with a customer engagement platform 404 and a cause module 406. The cause module 406 may be triggered immediately and/or be accessed upon checkout and when the user 302h makes a donation where the donation details may be gathered and stored in an elastic storage component 408 available for making future recommendations and/or receiving charitable details from the customer engagement platform 404. The customer engagement platform 404 can be a processing unit, operating system, and/or a group of technologies from which the other processes and modules may be developed. For example, at the customer engagement platform technologies, modules, or storage units may exist which store, access, or retrieve user characterization information that may be used for making a recommendation. In particular, as exemplified at Figure 4, the customer engagement platform 404 can include a personalization, content management, customer profile, tracking, and customer segment modules. These modules may be used when extracting customer details during a 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 receive and process entries, updates provided by a secondary user 302i. The secondary user 302i, may be an internal employee of the payment provider with insight on internal strategy and marketing information such that the content input to the customer engagement platform is useful and relevant. Note that the content input may also be dynamically created or automated such that secondary user 302i may be an external system.
Next, the details transferred to the storage and tracking modules 408,410 may be used in the analytics portion of the architecture for making a recommendation. For example, the content tracked at database 410 may then be processed bidirectionally by a streaming software 412 for use by a recommendation component 414. The streaming software 412 (e.g., Kafka) may be used to enable batch content to be read continuously as streams. Generally, such capability is not available as an out of the box feature, which can switch between batch and stream intelligently based on the processing capability in the application and the incoming rate of data. However, the customer engagement module 404/database 410 and the recommendation component 414 may be equipped with an intelligent mode that can seamlessly switch between batch and stream by processing the data through the streaming software 412 like Kafka.
The data at the recommendation component 414 can then be used by a cause model 416 for making predictions. Predictions may be made and the model trained by accessing the details of the user 302i which may be housed in a data warehouse 418. The data warehouse can include various repositories with details about the user 302i including but not limited to purchases made by the user, donations, profile information, contact and friends, as well as merchants with whom the user 302i may transact with.
For training the cause model 416, a combination of the data tracked by the elastic tracking module 408 and manual intervention by another user 302j may occur. The another user 302j may be a data scientist who can determine the information relevant for input to the recommendation model 416. Additionally, or alternatively, a system or other component may be used without the need for manual intervention by the another user 302j. The data tracked by the elastic tracking module 408 used to input to the cause model 416 may include data obtained using feedback. In one embodiment, feedback may be used to train the cause model 416 in order to provide continuous tuning of the cause model 416.
In particular, feedback may be used and collected based on user actions based on the suggested charitable causes presented at checkout. For example, feedback useful and tracked can include whether the users donated to the suggested charities if the charities are the ones they support, or they are willing to support. Other feedback that may be tracked may include whether the users 302 like the suggest charities since generally if a user 302 does not like the charity, they are probably not going to donate to them. Hence, the recommendation architecture 400, provides a system that can continuously track the suggested charities that are being donated (conversion) to, how often the charity may be presented to a user 302j to measure a shown count (impression) from all the products as feedback, and then tune the cause model 416 to provide a better recommendation result.
Therefore, by conversion and impression data may be provided and used to create a suggest charity score value. In one embodiment, a charity score value may be computed by first giving each suggested charity from the cause model 416 with a feedback influence weight (w) value 1. Then, after some observation if the suggested charity surfaced to users 302 does not gain any conversion after a defined time period then, the weight (w) value may be reduced. Ultimately, the weight value can be decreased close to 0 when there is no conversion for N impression times. In such case the probability of recommending a suggested charity to a user 302 lessens. On the other hand, if the suggested charity gains conversion, the weight value (w) may be reset back to 1 to maximize the suggest charity score value, so that next time this charity will be highly promoted to the user 302. Thus, continuous collection of the conversion and impressions by a user 302 based on interactions with a charitable cause may be tracked to construct the recommendation, creating a feedback loop tuned to provide an updated recommendation score/suggested charity score value and produce a more accurate result.”[8]
[8] Specification, [0028]-[005*] (I note there is discontinuity in paragraph numbering in that paragraphs numbered [001]-[008] separate paragraphs [0028] and [0029] and for clarity I refer to these as paragraphs [001*]-[008*]).
The specification explains that the cause model 416 may include one or more models and machine learning algorithms designed to make recommendations, and states that:
“Machine learning algorithms can include those based off supervised and unsupervised learning and can include models such as but not limited to clustering, tree-based, ensemble, random walk, etc.”[9]
[9] Specification, [006*].
The recommendation may be achieved across multiple models, which may each be personalised to provide a recommended list of charitable causes with a recommendation score provided for each cause, with a higher score reflecting a better chance of a correct charitable cause prediction. Various techniques for predicting the most adequate charitable cause are discussed.
Figure 5, reproduced below, illustrates a diagram of the implementation of cross-domain collaborative filtering for making recommendations. The recommendation presented is based on a total recommendation score 510 computed and obtained using an ensemble model 508 (which is a modelling technique or process that uses two or more analytical models to obtain a final recommendation). The final recommendation score 510 may be obtained by combining a prediction made by each of the models to generate a more accurate final result, or the ensemble model 508 may obtain the final result by selecting and using the model(s) that create the best model for the problem considered.[10]
[10] Specification, [0031].
With reference to Figure 5, a more customised recommendation may be obtained using cross-domain collaborative filtering 502, random walk technique 504 and clustering 506. Each of these models is explained in more detail as follows:
“The first model, which includes the use of cross-collaborative filtering 502 is a model designed to consider not only a user and his/her transactions but consider transactions across domains. For example, transactional information about a merchant and a charity are considered. Thus, one focus of the cross-collaborative filtering model 502 may include making a recommendation based in part on an association or prediction regarding people who made a purchase with a particular merchant and also donated to a particular charity. In other words, the system is designed to show that users who make purchases at a particular merchant are also likely to make a donation to a specific cause. To illustrate this, consider a user who ordered online pet food at merchant X, then given that the user purchased pet food at merchant X, there is a likelihood that the user will donate to the Friends of Animals charity. Thus, a user is presented with a customized charity as opposed to a random or most popular one which may have little or no association with the user and his/her behaviors. …
The random walk model 504 is a model that is focused more on transactions and peers associated with a user. For example, consider a user associated with a third-party provider like PayPal. This 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 as well as those with Venmo and Xoom. Additionally, the random walk model 504, may also use information regarding who the transactions or what peers the user transacted with. Thus, the random walk model can be generated using a mathematical path that can be generated between transactions across entities and/or with other peers. …
Next, a cluster model 506 may be used for the determination of a recommendation score. The cluster model 506 uses a technique based on grouping objects or dividing a population based on similarities. For example, provided the users are members of a third-party payment provider service (e.g., PayPal) the users may be clustered based on profile data. Thus, in the charity example, a user may be presented with a customized charity or provided a recommendation score based on the cluster the user falls in. The users may therefore be classified into one of n clusters based on a profile data which can include information including but not limited to gender, address, age, marital status, etc. Thus, the focus in using the cluster model 506 may be to present recommendations based on the profile information. For example, all users may be classified into N clusters based on gender and age. In such example, the 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 the cluster (male, 20>age<30), then the most popular charity in the cluster will be recommended to that user.
To determine how to obtain a recommendation or a recommendation score, a score for every charity for each user may be calculated and represented by
the probability of the charity in the user’s cluster.”[11]
[11] Specification, [0033]-[0036].
Once the models 502-506 have the corresponding recommendation score, the ensemble model 508, which can include a decision tree model, may be used to obtain the total recommendation score.
The specification explains in some detail how a random walk-based recommendation may be derived, but indicates that, where an even more personal/tailored recommendation is desired than a random walk or cluster-based recommendation, a cross-domain based recommendation score may be appropriate. Figure 7, reproduced below, provides an illustration of this, showing matrix diagram 700 of item-to-item collaborative filtering used to obtain a recommendation score. In this example, the recommendation score would be based on a prediction where purchases with a merchant X are correlated with donations to a charity Y.[12]
[12] Specification, [0043]-[0044].
As shown in similarity matrix 700, a charity and merchant are examined to determine similarities between the two. For example, both the charity 702 and 704 share similarities in rows 1, m-2 and m. A similarity value may be computed from these similarities and used for determining a recommendation score. Then, a prediction may be determined and used in making a recommendation. Methods of making a prediction/recommendation are described in the specification.[13]
[13] Specification, [0045]-[0046].
As shown in Figure 5 (reproduced above), once the recommendation score is determined using cross-domain collaborative filtering and/or random walk and/or clustering, it may be further analysed to obtain a total recommendation score.
Figure 8, reproduced below, illustrates a flow diagram illustrating operations for obtaining a recommendation score using cross-domain collaborative filtering. The process 800 may include one or more operations 802-814, which may be implemented in the form of executable code stored on a non-transitory, tangible, machine-readable media that may, when run on one or more hardware processors, cause a system to perform said operation(s).[14]
[14] Specification, [0047].
The specification provides detail regarding operations 802-814. In particular, determination of the optimal recommendation model to use (806) and computation of the recommendation score(s) (808) is explained as follows:
“Once the user information is available for transacting, process 800 can continue to operation 806 where based in part on the characterization or user information retrieved, a determination is made regarding which model(s) to use for obtaining and presenting a recommendation to the user. As indicated above an in conjunction with Figure 5, a random walk, cluster, and cross-domain collaborative model may be used. Additionally, the model(s) used may be further used in conjunction with an ensemble model for determining recommendation score(s) for charitable causes that may be presented to a user for donation at operation 808. Recall that in the cross-domain filtering model, a recommendation may be made based in part on an association or prediction regarding people who made a purchase with a particular merchant and also donated to a particular charity. In other words, the system is designed to show that users who make purchases at a particular merchant are also likely to make a donation to a specific cause. The random walk model may include a model that is focused more on transactions and peers associated with a user and may also use information regarding who the transactions or what peers the user transacted with. Thus, the random walk model can be generated using a mathematical path 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 dividing a population based on similarities. For example, provided the users are members of a third-party payment provider service (e.g., PayPal) the users may be clustered based on profile data. Thus, in the charity example, a user may be presented with a customized charity or provided a recommendation score based on the cluster the user falls in. The users may therefore be classified into one of n clusters based on a profile data which can include information including but not limited to gender, address, age, marital status, etc. As such, the clustering model may be a model that users a user profile information to provide a recommendation score.
The ensemble model may be used when it is determined that an input to the ensemble model is necessitated to obtain a recommendation score from a combination of one or more of the models. For example, in one embodiment, the ensemble model may be used to obtain the recommendation score from the model using cross-domain filtering. In another embodiment, it may determine that an input to the ensemble model may necessitate the recommendation score from the model using random walk and/or a combination of the cross-domain filtering model. Still in another embodiment, it may determine that the input to the ensemble model may necessitate the recommendation score from the model using the cross-domain filtering model, and the random walk model, and/or the clustering model.”[15]
[15] Specification, [0049]-[0050].
In relation to operation 814, the specification explains that the donation or lack thereof following transmittal of the recommendation is recorded, and that:
“feedback to the training model of that future charitable cause recommendations may be presented accordingly and based on the user’s past donation behavior. Thus, the recommendation model is re-trained based on a feedback received, over a communication network, from the user device in response to the recommendation transmitted”[16]
[16] Specification, ]0052].
The specification states that the order of the models used, analysis or recommendation scores and presentation of charitable causes may vary, and that the recommendation may be presented to a user on a range of devices: “a mobile device, smart phone, laptop, desktop, or other device”.[17]
[17] Specification, [0053].
Figure 9, shown below, is a block diagram of a networked system 900 for providing recommendations using cross domain filtering.[18] The specification explains that the system 900 may include or implement a plurality of devices, computers, servers and/or software components, and the devices, computers and/or servers may be deployed differently as required by a given embodiment, and explains the features and functions of these components at some length. It is not apparent to me, and the applicant has not suggested, that any unusual functions are described with respect to the devices, computers, servers etc., and so I consider the degree of detail provided in Figure 9 to suffice for present purposes.
[18] Specification, [0061].
The claims
The claims the subject of this decision are as proposed to be amended on 16 February 2023. There are 18 claims; claims 1 and 10 are independent and relate to a system and corresponding method, respectively. The entire claim set is annexed to this decision and claim 1 is reproduced below.
1. A system, comprising:
a non-transitory memory storing instructions; and
a hardware processor configured to execute the instructions to cause the system to:
receive, via a network, from a merchant device, payment information for a transaction between a user and a merchant associated with a merchant device, based on an interaction by the user with a payment application associated with the merchant;
retrieve, from a database, user information for the user and cross-domain information for the merchant and other entities associated with a service provider;
determine, using a specific algorithm-based model with a first part of the user information retrieved from the database, a first recommendation score representing a first correlation between the user and the other entities;
determine, using a cross-domain collaborative filtering model with a second part of the user information and the cross-domain information retrieved from the database, a second recommendation score representing a second correlation between the user and the other entities;
apply, the first and second recommendation scores as inputs to train an ensemble machine learning model to determine correlations between the user information and the cross-domain information using at least one of the specific algorithm-based model or the cross-domain collaborative filtering model;
determine, using the trained ensemble machine learning model, a total recommendation score; and
present, via a graphical user interface of the payment application, a recommendation for a possible transaction between the user and at least one of the other entities, based on the total recommendation score.Appended claims 2-9 and 11-17 define details of the machine learning models and the data used to determine the recommendation scores. Claim 18 defines a non-transitory machine-readable medium having instructions executable to cause the method of any one of claims 10-17 to be performed.
The examiner has not identified any difficulties in construing the claims and nor have I. The applicant explains that the claimed invention utilises three machine learning (ML) models:
“A first ML model (i.e. an algorithm-based model) is used to determine a first recommendation score based on user information. The first recommendation score represents a first correlation between a user and other entities. For example, the first ML model may generate a recommendation based on transactions made by the user and transactions made by one or more peers of the user.
A second ML model (i.e., a cross-domain collaborative filtering model) is used to generate a second recommendation score based on the user information and cross-domain information, the second recommendation score represents a second correlation between a user and other entities. For example, the cross-collaborative filtering model may include making a recommendation based in part on an association or prediction regarding people who made a purchase with a particular merchant and donated to a particular charity.
The claimed invention further includes applying the first and second recommendation scores to train a third ML model (i.e., an ensemble machine learning model) to determine correlations between user information and cross-domain information and then use the trained ensemble machine learning model to generate a more accurate total recommendation score.
The claimed invention then determines a recommendation for the user based on the total recommendation score and presents the recommendation on a graphical user interface of an electronic device the user is interacting with.”[19]
[19] Applicant’s submissions at [16]-[19].
The law on manner of manufacture
It is a requirement of paragraph 18(1)(a) of the Act that an invention be a manner of manufacture within the meaning of section 6 of the Statute of Monopolies. The classic question to be asked when deciding whether an invention is a “manner of manufacture” is set out in National Research Development Corporation v Commissioner of Patents:[20]
“The right question is: ‘Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies?’”[21]
[20] [1959] HCA 67; 102 CLR 252 (‘NRDC’).
[21] NRDC at 269, [14].
The High Court in NRDC went on to set out a test in terms relevant to the facts of that case:
“a process, to fall within the limits of patentability which the context of the Statute of Monopolies has supplied, must be one that offers some advantage which is material, in the sense that the process belongs to a useful art as distinct from a fine art ... that its value to the country is in the field of economic endeavour.”[22]
and
“The effect produced by the appellant’s method exhibits the two essential qualities upon which ‘product’ and ‘vendible’ seem designed to insist. It is a ‘product’ because it consists in an artificially created state of affairs, discernible by observing over a period the growth of weeds and crops respectively on sown land on which the method has been put into practice. And the significance of the product is economic; for it provides a remarkable advantage, indeed to the lay mind a sensational advantage, for one of the most elemental activities by which man has served his material needs, the cultivation of the soil for the production of its fruits.”[23]
[22] NRDC at 275, [22].
[23] NRDC at 277, [25].
However, the High Court has made clear that there is no precise formulation to be applied unthinkingly to answer the question of manner of manufacture:
“This Court in NRDC did not prescribe a well-defined pathway for the development of the concept of ‘manner of manufacture’ in its application to unimagined technologies with unimagined characteristics and implications. Rather, it authorised a case-by-case methodology.”[24]
[24] D’Arcy v Myriad Genetics Inc [2015] HCA 35; 258 CLR 334 at [23] (‘Myriad’).
That case-by-case methodology must have regard to the substance of the claimed invention, and not simply the form of the claim.[25] This point was made succinctly in Myriad by Gageler and Nettle JJ:
“Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.”[26]
[25] Myriad at [6], [88].
[26] Myriad at [144].
In Commissioner of Patents v RPL Central Pty Ltd[27] the Full Court of the Federal Court said the same thing in the context of an invention that was in substance a scheme:
“A claimed invention must be examined to ascertain whether it is in substance a scheme or plan or whether it can broadly be described as an improvement in computer technology. The basis for the analysis starts with the fact that a business method, or mere scheme, is not, per se, patentable. The fact that it is a scheme or business method does not exclude it from properly being the subject of letters patent, but it must be more than that. There must be more than an abstract idea; it must involve the creation of an artificial state of affairs where the computer is integral to the invention, rather than a mere tool in which the invention is performed. Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not a patentable invention simply to ‘put’ a business method ‘into’ a computer to implement the business method using the computer for its well-known and understood functions.
Is the mere implementation of an abstract idea in a well-known machine sufficient to render patentable subject matter? Is the artificial effect that arises, because information is stored in RAM and there is communication over the Internet or wifi, sufficient? Does any physical effect give rise to a manner of manufacture? Are the mere presence of an artificial effect and economic utility, without more, sufficient to determine manner of manufacture?
It is not a question of stating precise guidelines but of deciding, in each case, whether the claimed invention, as a matter of substance not form, is properly the subject of a patent.”[28]
[27] [2015] FCAFC 177 (‘RPL Central’).
[28] RPL Central at [96]-[98].
In Research Affiliates LLC v Commissioner of Patents[29] the Full Court of the Federal Court stated:
[29] [2014] FCAFC 150 (‘Research Affiliates’).
“When the authorities in Australia prior to and including Grant are considered, a consistent approach emerges as to the relevance of:
· a distinction between a claim to a business scheme and claims to methods which in practice result in a new machine or process or an old machine giving a new and improved result – that is, a distinction between mere intellectual information and a method that affects the operation of an apparatus in a physical form (Grant at [18]);
· the fact that the claimed steps are foreign to the normal use of computers, such as the production of an improved curve image (IBM 2 at 225-226);
· the particular mode or manner of achieving an end result which is an artificially created state of affairs, such as the storage of data as to Chinese characters and retrieval of graphic representations to enable word processing (CCOM at 295);
· whether part of the invention is an inventive method which includes the application and operation in a physical device (Grant at [30]);
· the distinction drawn in Catuity, as explained in Grant (at [24]), between ‘a technological innovation which is patentable and a business innovation which is not’. In Catuity, Heerey J did not accept that a physically observable effect was necessarily required (at [128]) but the Full Court in Grant expressed the opinion that a physical effect in the sense of a concrete effect or phenomenon, or manifestation or transformation is required (at [32]).
· the fact that a physical effect is required does not make it sufficient to confer patentability;
· the fact that a method may be called a business method does not prevent it being properly the subject of letters patent (Grant at [26] citing Catuity at [125]-[126]);
· the fact that for claimed computer programs, the courts look to the application of the program to produce a practical and useful result, so that more than ‘intellectual information’ is involved (Grant at [29]). A method that is in the nature of directions for use does not constitute an invention or a manner of manufacture in the absence of some previously unrecognised property of an aspect of the method (Grant at [29]).”[30]
[30] Research Affiliates at [94].
In considering the substance of the invention the Full Court went on to say:
“In the context of the claim, the significance lies in the content of the data rather than any specific effect generated by the computer. The computer-implementation is an essential integer of the claimed process. That is, of course, important. It is of particular importance in the assessment of, for example, novelty and infringement. However, in examining whether a claimed invention is properly the subject of letters patent, it is necessary to look not only at the integers of that claimed invention but also at the substance of that invention.
The claimed method in this case clearly involves what may well be an inventive idea, but it is an abstract idea. The specification makes it apparent that any inventive step arises in the creation of the index as information and as a scheme. There is no suggestion in the specification or the claims that any part of the inventive step lies in the computer implementation. Rather, it is apparent that the scheme is merely implemented in a computer and a standard computer at that. It is not part of the claimed method that there is an improvement in what might broadly be called ‘computer technology’.”[31]
[31] Research Affiliates at [117]-[118].
The Full Court in Encompass Pty Ltd v InfoTrack Pty Ltd[32] did not find it necessary to revisit the correctness of RPL Central or Research Affiliates, explaining that:
“In each case, the Full Court was seeking to describe the conceptual distinction between a manner of manufacture and an unpatentable abstraction. In each case, the Full Court was explaining that a claimed method that is unpatentable does not change its legal character merely because the method is implemented by the instrumentality of a computer.”[33]
[32] [2019] FCAFC 161; 372 ALR 646 at [7] (‘Encompass’).
[33] Encompass at [91].
The outcomes of the above-mentioned decisions were not criticised in the most recent High Court decision concerning manner of manufacture: Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents[34]. However, the six judges of the High Court were evenly divided in that case and in Motorola Solutions, Inc. v Hytera Communications Corporation Ltd (Liability) Perram J stated:
“I do not read Aristocrat [the 2021 decision of the Full Court] as departing from any of the authorities which preceded it. An appeal in that case to the High Court was dismissed by force of s 23(2)(a) of the Judiciary Act 1903 (Cth) when the Court split 3-3. As such, the High Court’s decision has no ratio decidendi and stands only for the proposition that the Full Court’s decision stands.”[35]
[34] [2022] HCA 29. See also UbiPark Pty Ltd v TMA Capital Australia Pty Ltd (No 2) [2023] FCA 885 at [198].
[35] [2022] FCA 1585 at [356] (citations omitted).
As such, I consider that the principles established in the body of Full Court decisions[36] remain relevant to characterising an invention in order to distinguish between whether it is in substance a mere scheme or business method or potentially patentable subject matter, including considerations of:
·whether the contribution of the claimed invention is technical in nature;[37]
·whether the invention solves a technical problem (either within or outside the computer);[38]
·whether the invention results in an improvement in the functioning of the computer;[39]
·whether the invention merely requires generic computer implementation (that is, “purely conventional… utilised for its well-known and well-understood effects”[40]), as distinct from steps that are “foreign” to the normal use of computers;[41] and
·whether the computer is merely an intermediary, adding nothing to the substance of the idea.[42]
[36] In particular, RPL Central, Research Affiliates, Encompass, Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86 (‘Rokt’).
[37] See, e.g., RPL Central at [99], Research Affiliates at [114].
[38] See, e.g., RPL Central at [99].
[39] See, e.g., RPL Central at [99], Research Affiliates at [118], Encompass at [109].
[40] Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 at [112] (Nicholas J).
[41] See, e.g., RPL Central at [99], [102], Research Affiliates at [110].
[42] See, e.g., RPL Central at [99], Encompass at [99], Rokt at [108].
As will be apparent from the discussion of the applicant’s submissions below, I do not understand the applicant to disagree that these are relevant principles.
The objection
The objection of lack of manner of manufacture maintained in the third examination report relevantly reads as follows:
“Regarding the problem addressed by the present invention, the Applicant has submitted:
‘The claimed invention is directed to systems and methods for obtaining recommendations using scalable cross-domain collaborative filtering (see Title and Technical field). As noted in the background section, a number of recommendation systems are known. However, these known recommendation systems have issues and are not accurate. The claimed invention addresses these issues with existing recommendation systems – in particular, it provides an improved recommendation system that acts as an advisor and provides intelligent recommendations tailored to a user and across domains.
The Examiner will appreciate that improving the accuracy of a recommendation system is a technical problem.’
However it is not accepted that the problem of improving product recommendations for a customer can be considered technical in nature. The task of recommending products to a customer is essentially a business problem, and relates to the implementation of intellectual concepts, rather than a technical deficiency within any technical component. The ability of a computer system to help facilitate the product recommendation process is not limited by any technical constraint within the computer system per se. Rather, any potential deficiencies seen in the product recommendation systems of the prior art are simply the result of the particular intellectual concepts utilised in making those recommendations. Said intellectual concepts are computerised with the use of the well-known and well-understood conventional data processing capabilities of the computer. There is no technical limitation within the prior art which prevents the computer system from performing this data processing efficiently or accurately. If the output of the prior art product recommendation systems is deficient in any sense, it is because of the intellectual processes implemented in the data processing, and not because of a technical limitation of the computer. However, the problem of improving the intellectual concepts utilised in recommending products to a user is not a problem which can be considered technical in nature.
Regarding the solution presented by the invention, the Applicant has submitted:
‘In particular, the claimed invention utilizes three machine learning models. A first model (i.e. an algorithm-based model) is used to determine a first recommendation score based on the user information, the first recommendation score representing a first correlation between a user and other entities. For example, the first model may generate a recommendation based on transactions made by the user and one or more peers of the user. A second model (i.e., a cross-domain collaborative filtering model) is used to generate a second recommendation score based on the user information and cross-domain information, the second recommendation score representing a second correlation between a user and other entities. For example, the cross-collaborative filtering model may include making a recommendation based in part on an association or prediction regarding people who made a purchase with a particular merchant and also donated to a particular charity. The method further includes applying the first and second recommendation scores to train an ensemble machine learning model to determine correlations between user information and cross-domain information and then use the trained ensemble machine learning model to generate a total recommendation score and present it to a user.
Accordingly, by using an ensemble model that is trained based on outputs from two other models, the claimed invention provides a more customizable approach for making recommendations (see p[0016] of the specification as filed).’
However, it is not accepted that the solution, as described above by the Applicant, is one which can be considered technical in nature. As discussed by the Applicant, the invention utilises three machine learning models to ultimately determine a total recommendation score and present it to a user. However it is clear from reading the specification as a whole that the machine learning utilised in the invention is characterised solely by the particular information which is being operated upon. That is, the invention does not relate to an improvement to the involved machine learning techniques, but rather, known techniques are utilised in the conventional way in order to operate on particular data sets and produce recommendations for a customer. The application of known machine learning techniques to particular data, in order to solve the business problem of product recommendations, is not considered to make a technical contribution to the art. The invention clearly does not involve an improvement in the operation of the computer irrespective of the data being processed, as discussed in RPL at [99].
While it may be the case that the prior art does not teach providing recommendations to customers at a checkout using the precise sequence of data processing presently claimed, this does not inevitably lead to the conclusion that the invention is patentable. That is, just because a computer had not been previously used to implement the exact intellectual concepts on the particular data as is presently claimed, does not mean that a technical problem has been surmounted within the computer, or that a technical improvement has been made to ‘computer technology’ as understood from Research Affiliates at [118].
Moreover, the recommendation for a possible transaction which results from the claimed method is merely intellectual information which carries only notional meaning. It cannot be said that the calculation of this data value improves the operation of the computer in any technical sense, regardless of how it is derived.
Therefore, it remains that the claimed invention neither addresses a technical problem, nor provides a technical solution thereto.
Consequently, the substance of the invention is a scheme for applying conventional machine learning techniques to user data and cross-domain information to determine a total recommendation score and present a recommendation for a possible transaction between the user and at least one other entity. This is not subject matter suitable for a patent.”
Applicant’s submissions
The applicant’s submissions, summarised below, are helpfully framed around considerations of the substance of the invention, the contribution made by the invention, the technicality of the problem solved by the invention and of the solution itself, and the role of the computer.
Substance of the invention
The applicant submits that the claimed invention is directed to a new and improved recommendation system that generates more accurate recommendations than known systems using machine learning, by inputting recommendation scores from two different models into an ensemble machine learning model, which cannot be considered a mere scheme or business idea, and is, in substance, technical in nature.[43]
Contribution made by the claimed invention
[43] Applicant’s submissions at [23]-[26].
The applicant submits that before the priority date:
“it was not common general knowledge to utilize recommendation scores from an algorithm-based ML model and a cross-domain collaborative filtering ML model to train an ensemble ML model to determine correlations between the user information and the cross-domain information using at least one of the specific algorithm-based model or the cross-domain collaborative filtering model. Further, it was not common general knowledge to use the ensemble ML model to generate a total recommendation score.”[44]
[44] Applicant’s submissions at [29].
As such, the applicant submits that the contribution made by the claimed invention to the state of the art is the specific combination of machine learning models, which is technical in nature. The applicant emphasises that the specification does not suggest that the specific combination of the machine learning models claimed is conventional in any relevant art, making the following points:
·the specification describes a conventional mechanism for increasing customer engagement and describes associated deficiencies;[45]
·the specification presents an exemplary architecture for implementation (Figure 5, reproduced above);[46]
·the specification discusses that part of the inventive concept is identifying the suitability of the architecture to the problem of forming a recommendation score;[47]
·the specification “contains no statement that the combination of cross-domain collaborative filtering with the two (e.g. claim 1) or three (e.g. claim 9) models is conventional” and “it has not been established, as a matter of fact, that the claimed machined (sic) learning techniques are known”;[48]
·the reasons for allowance of a related US patent state that:
“the inclusion of the specific applying first and second recommendation scores as inputs to train an ensemble machine learning model to determine correlations between the user information and the cross-domain information using at least one of the specific algorithm-based model or the cross-domain collaborative filtering model … in combination with the other elements recited, … is not found in the prior art of record.”[49]
Claimed invention solves a technical problem with a technical solution
[45] Applicant’s submissions at [35].
[46] Applicant’s submissions at [36].
[47] Applicant’s submissions at [38].
[48] Applicant’s submissions at [39].
[49] Applicant’s submissions at [40].
The applicant submits that the invention solves a technical problem that can be characterised as: “how to apply machine learning to generate more accurate recommendations that are customized for users” or “how to improve existing recommendation systems using machine learning”.[50] According to the applicant it does this via technical means, that is, the “unique combination of three ML models to generate a customized and accurate recommendation to a user”, which is a specific machine learning solution to the problem of how to apply machine learning in the field of the invention.[51]
Role of the computer
[50] Applicant’s submissions at [42].
[51] Applicant’s submissions at [43]-[44].
The applicant submits that the invention provides an “intelligent advisor” type functionality utilising various models to generate a recommendation score and subsequently presenting a recommendation to a user; the computer is not used as an intermediary. Accordingly, the applicant submits that the invention should be considered an improvement in computer technology rather than a business scheme.[52] In this regard, the applicant points to the comments of the Full Court in RPL Central distinguishing a computer which functions as an intermediary from one that functions as an advisor:
“The computer is, in effect, operating as an intermediary in the user’s quest for an evaluation of his or her competency for a particular course and entitlement to obtain a qualification without participating in that course. However, the computer does not evaluate the user’s input to provide the answer. It is not functioning in the nature of an advisor or an artificial intelligence. Rather, the programming allows for a series of prepared words to be prepended to the user information, to turn the statement into a question.”[53]
[52] Applicant’s submissions at [45].
[53] RPL Central at [109] (applicant’s emphasis).
From this, the applicant submits that “[t]he clear implication … is that a data processing system functioning in the nature of an advisor or an artificial intelligence would be a manner of manufacture.”[54] The applicant elaborates on this role of the computer in the invention:
“As noted, the presently claimed invention does function in such a way. For example, the claims of the present application are generally directed to an intelligent recommendation system predicting preferences of users for different items. This is done, inter alia, by utilizing two different recommendation machine learning models and using the outputs from these two models to train a third machine learning model to generate a total recommendation score.
As can be seen, therefore, not only is the present invention distinguished from the invention considered in RPL Central, but the features that distinguish the present invention are precisely the types of features that the Full Federal Court suggests would lead to an invention being a manner of manufacture.
It is also relevant to consider the nature of an ‘adviser’ as referred to in RPL Central. A meaning of ‘advise’ is ‘to recommend as wise, prudent, etc’ (Macquarie Dictionary, fifth edition). Accordingly the examiner’s apparent dismissal of the useful result of the claimed invention of providing a recommendation for a possible transaction as ‘merely intellectual information which carries only notional meaning’ is misplaced.”[55]
[54] Applicant’s submissions at [47].
[55] Applicant’s submissions at [48]-[50].
Consideration
It is apparent from the specification that the invention described addresses a problem which is, at a high level, a business problem: the provision of improved recommendations for possible transactions between a user and an entity. The applicant has framed the invention more specifically as directed to the application of machine learning to generate such improved recommendations, and I accept that this is a reasonable characterisation of the claimed invention.
Turning to the contribution made by the claimed invention, the applicant submits that the specific combination of machine learning models is a technical contribution made by the claimed invention, and, relatedly, a technical solution to a technical problem. While the applicant notes that it has not been established “as a matter of fact” that the claimed machine learning techniques are known, I do not take the applicant to be seriously pursuing an argument that they were not. It is apparent, including from the way these techniques are discussed in the specification, that they were known techniques. Indeed, if there were any doubt that the techniques were known, it is assuaged by a brief internet search revealing documents such as: B. Li, “Cross-Domain Collaborative Filtering: A Brief Survey,” 2011 IEEE 23rd International Conference on Tools with Artificial Intelligence, Boca Raton, FL, USA, 2011, pp. 1085-1086, doi: 10.1109/ICTAI.2011.184; R. Polikar, “Ensemble based systems in decision making,” in IEEE Circuits and Systems Magazine, vol. 6, no. 3, pp. 21-45, Third Quarter 2006, doi: 10.1109/MCAS.2006.1688199; Rui Xu and D. Wunsch, “Survey of clustering algorithms,” in IEEE Transactions on Neural Networks, vol. 16, no. 3, pp. 645-678, May 2005, doi: 10.1109/TNN.2005.845141. Moreover, it is not suggested at any point in the specification or the submissions that the contribution made by the applicant is a new machine learning technique.
The applicant points to various indicators that the claimed combination of machine learning techniques is not conventional, including the observation made in the reasons for allowance of a related US patent that the combination is not known in the art. That the specific combination defined in the present claims is new does not appear controversial and is consistent with the absence of any extant novelty or inventive step objection. This, however, is not an answer to patentability. As noted by the delegate in BaVelPay S.L.U. (B-67506527), there is a difference between “an invention allowing a computer to do something it could not do previously” and “an invention utilising a computer to do something it had not done previously”; the former is likely to be patentable, the latter may not be.[56] Similarly, the Full Court in Rokt observed that “[e]ven if the scheme is new and ingenious, it is not made patentable merely because it can or must be implemented using computer technology.”[57] It follows that more than merely a novel use of computer technology is required for a patentable invention. Accordingly, while I accept that the specific application of the combination of models claimed is a contribution made by the claimed invention, I am not persuaded that this combination or arrangement of known models applied to a specific business context represents a technical contribution or anything relevantly foreign to the normal use of computers. It is not apparent that there is anything “foreign” or unconventional in the provision and extraction of relevant data from these models, or in the computing arrangement allowing for the implementation of the system/method. That is, while multiple machine learning models are used, they are simply put together such that the recommendation scores from the first and second models are the input to the ensemble model. While this may be a complicated arrangement for data processing, it remains to my mind simply a scheme for processing data, with no improvement or adaptation to computer function which might afford patentability. For completeness, I do not consider that an application of machine learning must inevitably lead to an invention that is technical in substance simply because of the requirement for technical elements. All inventions implemented on computers inherently require technical elements, but the outcomes in Rokt, Encompass, etc., clearly demonstrate that this is not sufficient to found patentability; something more is required.
[56] [2022] APO 78 at [48] (emphasis in original).
[57] Rokt at [115].
In addition, it is clear that the assessment of manner of manufacture, which, as is well-established, is to be undertaken on a case-by-case basis, cannot be reduced to a simplistic consideration whereby inventions involving artificial intelligence are patentable. With respect to the applicant’s submissions regarding the “intelligent advisor” functionality of the invention, I agree with the Deputy Commissioner’s comment in Accenture Global Solutions Limited regarding the reference in RPL Central to the failure of the computer in that case to function as an advisor or artificial intelligence:
“I do not see that decision as making some definitive statement that things which can be considered broadly as ‘advisors or an artificial intelligence’ are necessarily patentable.”[58]
In characterising what the invention at issue in RPL Central was not, I do not think it can be said that the Full Court was making a clear statement as to the patentability of other hypothetical inventions. Accordingly, while I accept that the claimed invention may be distinguished from that in RPL Central, it does not necessarily follow that, simply because it can be distinguished from RPL Central in this respect, it must satisfy the manner of manufacture requirement. To the contrary, as set out above, I can see nothing relevantly foreign, or any adaptation or improvement, to the normal use of computers in the claimed invention. Nor do I consider that the dictionary meaning of “adviser” and the useful result it entails advances the applicant’s argument. It is clear that many inventions that are in substance unpatentable abstractions (e.g. Encompass, Rokt) yield colloquially “useful” results, but more than this is required. I take it that there needs to be a physical, tangible phenomenon coming into existence as mentioned at [114] of Research Affiliates for an invention to be relevantly useful. This is clearly not the case here. Despite the presence of a recommendation derived via machine learning, what is achieved is manifestly intangible or abstract – the presentation of a recommendation for a possible transaction between a user and an entity.
[58] [2022] APO 8 at [46].
While it is clear, given the nature of the invention, that the presence of a computer is mandatory, it also seems to me that the computer, and the machine learning aspects of the invention, are used for their ordinary purposes to implement a scheme for providing recommendations for possible transactions between a user and an entity. As set out above, I cannot see anything unconventional or foreign in the use of the computing technology as described in the specification, and it is not apparent to me that the defined combination of existing machine learning techniques with specific data inputs can be considered a technical contribution. It follows that I conclude that the invention (as claimed in all of the claims) is in substance a scheme for providing tailored transaction recommendations to a user. It addresses a business problem (of providing more effective transaction recommendations to a user) and the innovation is a business innovation rather than a technical innovation. In accordance with the Full Court authorities discussed previously, this is not patentable subject matter.
Conclusion
I note that the applicant’s request that, if the objection is upheld, it be provided an opportunity to amend the specification. However, in view of my conclusions above, and noting that the applicant has, in any event, filed and requested examination of a divisional application through which it appears that prosecution will be continued, I consider it appropriate to refuse the application to avoid any uncertainty.
Dr S. J. Smith
Delegate of the Commissioner of Patents
Annex: Claims
1. A system, comprising:
a non-transitory memory storing instructions; and
a hardware processor configured to execute the instructions to cause the system to:receive, via a network, from a merchant device, payment information for a transaction between a user and a merchant associated with a merchant device, based on an interaction by the user with a payment application associated with the merchant;
retrieve, from a database, user information for the user and cross-domain information for the merchant and other entities associated with a service provider;
determine, using a specific algorithm-based model with a first part of the user information retrieved from the database, a first recommendation score representing a first correlation between the user and the other entities;
determine, using a cross-domain collaborative filtering model with a second part of the user information and the cross-domain information retrieved from the database, a second recommendation score representing a second correlation between the user and the other entities;
apply, the first and second recommendation scores as inputs to train an ensemble machine learning model to determine correlations between the user information and the cross-domain information using at least one of the specific algorithm-based model or the cross-domain collaborative filtering model;
determine, using the trained ensemble machine learning model, a total recommendation score; and
present, via a graphical user interface of the payment application, a recommendation for a possible transaction between the user and at least one of the other entities, based on the total recommendation score.
2. The system of claim 1, wherein:
the specific algorithm-based model is a random walk model.
3. The system of claim 2, wherein the first recommendation score is obtained using at least one of the random walk model or a clustering model.
4. The system of claim 3, wherein the random walk model uses a combination of user profile information and peer-to-peer transactions information from the user information to determine the first recommendation score.
5. The system of claim 3, wherein the clustering model uses profile information from the user information retrieved to determine the first recommendation score.
6. The system of claim 1, wherein the second recommendation score is obtained using a combination of the specific algorithm-based model and the cross-domain collaborative filtering model.
7. The system of claim 1, wherein the cross-domain collaborative filtering model uses a combination of the user information and the cross-domain information to determine the second recommendation score.
8. The system of claim 1, wherein the ensemble machine learning model includes a decision tree model and uses one or more of the first and second recommendation scores to obtain the total recommendation score.
9. The system of claim 1, wherein a total recommendation score is obtained using the ensemble machine learning model and a combination of the first recommendation score and the second recommendation score and a third recommendation score determined using a clustering model.
10. A method, comprising:
receiving, via a network, from a merchant device, payment information for a transaction
between a user and a merchant associated with a merchant device, based on an interaction by the user with a payment application associated with the merchant;
retrieving, from a database, user information for the user and cross-domain information for the merchant and other entities associated with a service provider;
determining, using a specific algorithm-based model with a first part of the user information retrieved from the database, a first recommendation score representing a first correlation between the user and the other entities;
determining, using a cross-domain collaborative filtering model with a second part of the user information and the cross-domain information retrieved from the database, a second recommendation score representing a second correlation between the user and the other entities;
applying the first and second recommendation scores as inputs to train an ensemble machine learning model to determine correlations between the user information and the cross-domain information using at least one of the specific algorithm-based model or the cross-domain collaborative filtering model;
determining, using the trained ensemble machine learning model, a total recommendation
score; and
presenting, via a graphical user interface of the payment application, a recommendation for a possible transaction between the user and at least one of the other entities based on the total
recommendation score.
11. The method of claim 10, wherein the specific algorithm-based model is a random walk model and wherein the first recommendation score is obtained using at least one of the random
walk model or a clustering model.12. The method of claim 10, wherein the random walk model uses a combination of user
profile information and peer-to-peer transactions information from the user information to determine the first recommendation score.13. The method of claim 10, wherein the clustering model uses profile information from the user information retrieved to determine the first recommendation score.
14. The method of claim 8, wherein the second recommendation score is obtained using a combination of the specific algorithn-based model and the cross-domain collaborative filtering model.
15. The method of claim 10, wherein the cross-domain collaborative filtering model uses a combination of the user information and the cross-domain information to determine the second
recommendation score.16. The method of claim 10, wherein the ensemble machine learning model includes a decision tree model and uses one or more of the first and second recommendation scores to obtain the total recommendation score.
17. The system of claim 1, wherein a total recommendation score is obtained using the ensemble machine learning model and a combination of the first recommendation score and the second recommendation score and a third recommendation score determined using a clustering model.
18. A non-transitory machine-readable medium having instructions stored thereon, the instructions executable to cause performance of the method of any one of claims 10-17.
0
10
0