Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-20 were rejected in the Non-Final Office action mailed on 08/21/2025. Applicant’s amended claimset, entered on 11/21/2025, amended Claims 1, 11, 13, and 16 and canceled Claims 5 and 20. Herein this Final Office Action, Claims 1-4 and 6-19 are rejected.
Response to Arguments
Applicant’s arguments filed 11/21/2025, with respect to Rejections under 35 U.S.C. 112(b) for Claim 13, have been fully considered and are persuasive.
Applicant’s arguments filed 11/21/2025, with respect to Rejections under 35 U.S.C. 101 for Claims 1-4 and 6-19, have been fully considered and are not persuasive.
On Pages 10-13, Applicant argues that the claims provide a patent eligible improvement by integrating the alleged abstract idea into a practical application. Applicant argues that Specification ¶17 outlines the problem (“Current channels for providing reviews, primarily provided by third parties unassociated with the entities being reviewed and unable to access information to authenticate a user interaction with the entity, may have insufficient options available for authenticating interactions. Accordingly, improvements in technology relating to review generation and authentication are needed.”). Applicant argues that because the “first interaction data” is received “without the user providing any input or selections beyond their interactions with the resources,” the claims provide “many efficiencies and improvements over the traditional search user interfaces, and thus exemplifies an improvement to the technology of recommendation systems.” Additionally, Applicant argues that Specification ¶18 and ¶¶72-75 demonstrates that use of a classification model trained on real and fabricated reviews provides an improvement to computer functionality. Particularly, Applicant argues that the use of specific defined factors within the training data improve the accuracy of the model and therefore improves the machine learning model itself. Examiner does not agree.
Examiner responds that the inability of third parties to “access” data needed to authenticate a review is not a technical problem, but a business problem. The reason a third party cannot access the data has to do with the corporate relationship between the entities being reviewed and the parties administrating the review channels. For example, if the entity being reviewed makes the business decision to grant access to the authentication data to the third party, the problem no longer exists. Because the problem being solved by the instant claims is a part of the abstract idea, it is not a “technical problem” under MPEP 2106.05(a).
An improvement in the accuracy of the model, or the use of a model to improve accuracy in detecting fraudulent (i.e. in-authentic) reviews, is an improvement in the abstract idea itself. As demonstrated in PEG Example 47 Claim 2, training a model, and using a model to detect anomalies is a part of the abstract idea, and does not integrate the abstract idea into a practical application. Thus, the training of the model and use of the model does not provide an improvement under MPEP 2106.05(a)
Finally, the improved “efficiencies” are asserted in a conclusory manner. Specification ¶18 and ¶¶72-75 discuss the training of the model, but fail to provide a “technical explanation,” per MPEP 2106.05(a), as to how the claims provide an improvement to the technology “itself” via improved “efficiencies.” Thus, the claims do not integrate the recited abstract idea into a practical application.
On Page 13-16, Applicant argues that the instant claims are analogous to eligible PEG Example 47 Claim 3. Applicant argues that “. . . claim 1 as presently amended reflects an improvement in the technical field of review authentication.” Applicant argues that the use of a classification model that is trained to enhance review authenticity, and finetuned with a threshold, by detecting fraudulent reviews before storing the reviews. Examiner does not agree.
Examiner responds that the “malicious network packets” of PEG Example 47 Claim 3 are distinguishable from the “[fraudulent] reviews” of the instant claims. PEG Example 47 Claim 3 Step 2A, Prong Two states “The claimed invention reflects this improvement in the technical field of network intrusion detection. Steps (d)-(f) provide for improved network security using the information from the detection to enhance security by taking proactive measures to remediate the danger by detecting the source address associated with the potentially malicious packets.” A person of ordinary skill in the art would understand that a “malicious network packet,” would result in the performance of a computer/network operation that harms the functioning of the computer/network itself. Thus, automatically detecting and eliminating those packets improves the functioning of the computer itself. The instant application, on the other hand, detects and eliminates “[fraudulent] reviews,” which can harm the business reputation and profitability. Thus, the detecting and eliminating “[fraudulent] reviews” provides an improvement in business reputation (i.e. abstract idea), not an improvement in the functioning of a computer (e.g. network security that reduces malicious network traffic).
As discussed above, the training and use of a threshold to create the classification model does not provide an eligible improvement under MPEP 2106.05(a), similar to PEG Example 47 Claim 2. Thus, the rejection remains.
Applicant’s arguments filed 11/21/2025, with respect to Rejections under 35 U.S.C. 103 for Claims 1-4 and 6-19, have been fully considered and are not persuasive.
On Pages 17-18, Applicant argues that Murali fails to teach the limitations related to the classification model because Murali fails to teach “the exact problem identified [at Specification ¶17].” Examiner does not agree.
Examiner responds that (1) the features of Specification ¶17 (e.g. unassociated third party) are not included in the claims, and (2) Specification ¶17 describes the problem being solved by Applicant’s asserted invention. Thus, Specification ¶17 does not prohibit Murali from teaching the claimed limitations.
On Pages 18-19, Applicant argues that El Kaake does not teach the use of “a classification model” or the specific training and finetuning of the model. Examiner does not agree.
Examiner responds that El Kaake ¶¶91-96 and ¶¶99-100 shows that the “review” includes the transaction itself, i.e. El Kaake teaches the first and second interactions are inputs to the classification model. Thus, generally, the computer functionality if Fig. 4 used to determine the authenticity of a review teaches the “classification model.”
Additionally, ¶83 discusses the “learning” used to create the algorithms and rules that are applied to determine if a review is authentic. ¶158 specifically discusses iterative tuning (i.e. finetuning). Thus, El Kaake teaches the portion of the amended limitations. Thus, the claims are rejected under 35 U.S.C. 103 as discussed in greater detail below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4 and 6-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 1-4 and 6-10 recite a method (i.e. a process), Claims 11-15 recite a method (i.e. a process), and Claims 16-19 recite a non-transitory computer-readable medium (i.e. a machine or manufacture). Therefore, Claims 1-4 and 6-19 all fall within the one of the four statutory categories of invention of 35 U.S.C. 101.
Step 2A, Prong One
Independent Claim 1 recites the abstract idea of:
“receiving, . . ., a detection . . . of an interaction between a user . . . and an entity . . . ;
determining that the interaction between the user and the entity is reviewable based on first interaction data;
wherein the first interaction data includes at least one of: (i) identification of items exchanged in the interaction; (ii) a merchant category code (MCC) for the entity; (iii) valuations of the items exchanged in the interaction; or (iv) qeo-location data of the entity;
upon determining that the interaction between the user and the entity is reviewable, causing . . . to prompt the user to enter second interaction data including a user review of the entity associated with the detected interaction;
receiving, . . . , the second interaction data including the user review of the entity;
determining that the user review of the entity is authentic based on a classification model, the first interaction data and the second interaction data being input to the classification model;
wherein the classification model is [created] using training data comprising real reviews and fabricated reviews, and wherein the training data is used to generate a fraudulence threshold, and
wherein the classification model is finetuned using the fraudulence threshold;
upon determining that the user review of the entity is authentic, storing, . . . , the user review . . . associated with the entity; and
transmitting, . . . , the user review to . . . displays the user review to the user.”
The limitations stated above are processes/ functions that under broadest reasonable interpretation covers (1) detecting an interaction between a user and an entity, (2) determining if the interaction is reviewable based on certain information, (3) prompting the user to enter a review of the entity associated with the detected interaction, (4) using a model to determine the authenticity of the review, (5) creating the model using certain data, (6) generating a fraudulence threshold and using the threshold to improve the model, (7) storing the authenticated review, and (8) transmitting the review to be displayed, all of which are: mathematical relationships (i.e. generating and using a threshold), which are mathematical concepts, an abstract idea, under MPEP 2106.04(a)(2)I and managing personal behavior by following rules and interacting between people (i.e. authenticating the review based on the model, and creating a model for that purpose, are at least “following rules or instructions”) and commercial or legal interactions (i.e. Identifying a reviewable interaction, authenticating the review based on the model, and creating a model for that purpose, storing and communicating a review is at least “marketing or sales activities or behaviors” and identifying a reviewable interaction is a “business relations”), which are certain methods of organizing human activity, an abstract idea, under MPEP 2106.04(a)(2)II. The mere the recitation of generic computer components (i.e., the “remote device,” “user device,” “first electronic application,” “second electronic application,” “data storage” “trained,” and “user interface module”), which are additional elements implementing the identified abstract idea does prevent the claim from “recit[ing]” an abstract idea in Step 2A, Prong One. Therefore, Claim 1 recites an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claim 1 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent) and (ii) generally links the use of a judicial exception to a particular technological environment or field of use. The claim recites the additional elements of:
(i) “remote device,”
(ii) “user device,”
(iii) “first electronic application,”
(iv) “second electronic application,”
(v) “data storage,”
(vi) “trained” (to the extent training is performed on a computer), and
(vii) “user interface module.”
The additional elements of (i) “remote device” (Fig. 1 and ¶36 shows “remote device 130.” See also Fig. 5 and ¶¶85-86.), (ii) “user device” (Fig. 1 and ¶33 shows “user device 110.” See also Fig. 5 and ¶¶85-86.), (iii) “first electronic application” (iv) “second electronic application” (Fig. 1 and ¶¶34-35 shows “first and second electronic applications 106.” See also Fig. 5 and ¶¶85-86.), (v) “data storage” (Fig. 1 and ¶65 shows “database(s) 145.” See also Fig. 5 and ¶¶85-86.), (vi) “trained” (¶¶26-27 shows training a “machine-learning model.” ¶27 shows “Any suitable type of training may be used, . . .”), and (vii) “user interface module” (Fig. 2A and ¶49 shows “user interface module.” ¶¶85-86 shows that modules are software.), are recited at a high-level of generality, such that, when viewed as whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), they amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
The (i) “remote device,” (ii) “user device,” (iii) “first electronic application,” (iv) “second electronic application,” (v) “data storage,” (vi) “trained,” and (vii) “user interface module,” when viewed as whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), does no more than generally link the use of the judicial exception to a particular technological environment or field of use (i.e. online computer environment) (See MPEP 2106.05(h)).
Accordingly, these additional elements, when viewed as a whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea.
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent) and (ii) generally link the use of a judicial exception to a particular technological environment or field of use, and are not a practical application of the abstract idea. The same analysis applies here in Step 2B, i.e., (i) merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) and (ii) generally linking the use of a judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of the (i) “remote device,” (ii) “user device,” (iii) “first electronic application,” (iv) “second electronic application,” (v) “data storage,” (vi) “trained,” and (vii) “user interface module,” do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible.
Dependent Claims 2-4 and 6-10 recite the abstract idea of:
“. . . wherein determining that the interaction between the user and the entity is reviewable comprises: determining the entity is an entity for which reviews are applicable; and determining that user interest of the user for submission of the review exceeds a threshold.” (Claim 2)
“. . . wherein: determining the entity is an entity that for which reviews are applicable comprises inputting the first interaction data into a rule-based algorithm.” (Claim 3)
“. . . wherein: determining that the user interest of the user for submission of the review exceeds the threshold comprises inputting the first interaction data into a trained . . . learning model.” (Claim 4)
“. . . wherein causing . . . to prompt the user to enter second interaction data is performed a predetermined time after the detected interaction.” (Claim 6)
“. . . wherein the predetermined time is determined based on the first interaction data.” (Claim 7)
“. . . wherein the interaction occurs at a [certain place].” (Claim 8)
“. . . wherein the classification model is a trained . . . learning model.” (Claim 9)
“. . . wherein upon determining that the user review of the entity is authentic, transmitting the user review to at least one [destination].” (Claim 10)
Dependent Claims 2-4 and 6-10, have been given the full two-prong analysis including analyzing the further elements and limitations, both individually and in combination. When analyzed individually and in combination, these claims are also held to be patent ineligible under 35 U.S.C. 101. The further limitation of Claims 2-4 and 6-10 fail to establish claims that are not directed to an abstract idea because the further limitations (1) determine if a review is applicable to an entity based on a rule based algorithm and the user interest exceeds a threshold based on a trained learning model, (2) the prompt is given to the user at a certain time, (3) the interaction occurs at a certain place, (4) the classification model is a trained learning model, and (5) transmit the review to a certain destination, all of which are a part of the abstract idea. The further elements of Claims 2-4 and 6-10 (i.e. “trained machine learning model” of Claims 4 and 9, “point-of-sale (POS)” of Claim 8, and “digital channel” in Claim 10) fails to establish claims that are not directed to an abstract idea because the elements merely recite additional generic computer components similar to the generic computer components of Claim 1 and generally link the abstract idea to a particular technology or field of use (i.e. online computer environment) just as in Claim 1. The organization of the further limitations of Claims 2-4 and 6-10 fail to integrate an abstract idea into a practical application just as discussed above for Claim 1. Additionally, performing the abstract idea of Claim 1 as recited in each of the further limitations of Claims 2-4 and 6-10, individually or in combination, does not (1) impose any meaningful limits on practicing the abstract ideas, or (2) provide improvements to the functioning of computing systems or to another technology or technical field, just as discussed above regarding Claim 1. Therefore, Claims 2-4 and 6-10 amount to mere instructions to implement the abstract idea (1) using generic computer components—using the computer, in its ordinary capacity, as a tool to perform the abstract idea, and (2) generally linked to a particular technology or field of use. Because the claims merely use a computer, in its ordinary capacity in a particular field of use, as a tool to perform the abstract idea cannot provide an inventive concept, the elements and limitations of Claims 2-4 and 6-10 fail to establish that the claims provide an inventive concept, just as in Claim 1. Therefore, Claims 2-4 and 6-10 fails the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Independent Claim 11 recites the abstract idea of:
“receiving, . . . , first interaction data associated with a user and an entity, the first interaction data including a user review of the entity, wherein the first interaction data includes at least one of: (i) identification of items exchanged in the interaction; (ii) a merchant category code (MCC) for the entity; (iii) valuations of the items exchanged in the interaction; or (iv) qeo-location data of the entity;
retrieving, . . . , second interaction data associated with the user and the entity, the second interaction data indicating an interaction between the user and the entity;
determining that the user review of the entity is authentic based on a classification model, the first interaction data and the second interaction data being input to the classification model;
wherein the classification model is [created] using training data comprising real reviews and fabricated reviews, and wherein the training data is used to generate a fraudulence threshold, and
wherein the classification model is finetuned using the fraudulence threshold;
upon determining that the user review of the entity is authentic, storing, . . . , the user review . . . associated with the entity
transmitting, from the data storage, the user review to . . . displays the user review to the user.”
The limitations stated above are processes/ functions that under broadest reasonable interpretation covers (1) detecting an interaction between a user and an entity, (2) determining if the interaction is reviewable based on certain information, (3) prompting the user to enter a review of the entity associated with the detected interaction, (4) using a model to determine the authenticity of the review, (5) creating the model using certain data, (6) generating a fraudulence threshold and using the threshold to improve the model, (7) storing the authenticated review, and (8) transmitting the review to be displayed, all of which are: mathematical relationships (i.e. generating and using a threshold), which are mathematical concepts, an abstract idea, under MPEP 2106.04(a)(2)I and managing personal behavior by following rules and interacting between people (i.e. authenticating the review based on the model, and creating a model for that purpose, are at least “following rules or instructions”) and commercial or legal interactions (i.e. Identifying a reviewable interaction, authenticating the review based on the model, and creating a model for that purpose, storing and communicating a review is at least “marketing or sales activities or behaviors” and identifying a reviewable interaction is a “business relations”), which are certain methods of organizing human activity, an abstract idea, under MPEP 2106.04(a)(2)II. The mere the recitation of generic computer components (i.e., the “remote device,” “first electronic application,” “second electronic application,” “data storage,” “trained,” and “user interface module”), which are additional elements implementing the identified abstract idea does prevent the claim from “recit[ing]” an abstract idea in Step 2A, Prong One. Therefore, Claim 11 recites an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claim 11 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent) and (ii) generally links the use of a judicial exception to a particular technological environment or field of use. The claim recites the additional elements of:
(i) “remote device,”
(ii) “first electronic application,”
(iii) “second electronic application,” and
(iv) “data storage”
(v) “trained” (to the extent training is performed on a computer), and
(vi) “user interface module.”
The additional elements of (i) “remote device” (Fig. 1 and ¶36 shows “remote device 130.” See also Fig. 5 and ¶¶85-86.), (ii) “first electronic application” (iii) “second electronic application” (Fig. 1 and ¶¶34-35 shows “first and second electronic applications 106.” See also Fig. 5 and ¶¶85-86.), (iv) “data storage” (Fig. 1 and ¶65 shows “database(s) 145.” See also Fig. 5 and ¶¶85-86.), (v) “trained” (¶¶26-27 shows training a “machine-learning model.” ¶27 shows “Any suitable type of training may be used, . . .”), and (vi) “user interface module” (Fig. 2A and ¶49 shows “user interface module.” ¶¶85-86 shows that modules are software.), are recited at a high-level of generality, such that, when viewed as whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), they amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
The (i) “remote device,” (ii) “first electronic application,” (iii) “second electronic application,” (iv) “data storage,” (v) “trained,” and (vi) “user interface module,” when viewed as whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), does no more than generally link the use of the judicial exception to a particular technological environment or field of use (i.e. online computer environment) (See MPEP 2106.05(h)).
Accordingly, these additional elements, when viewed as a whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea.
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent) and (ii) generally link the use of a judicial exception to a particular technological environment or field of use, and are not a practical application of the abstract idea. The same analysis applies here in Step 2B, i.e., (i) merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) and (ii) generally linking the use of a judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of the (i) “remote device,” (ii) “first electronic application,” (iii) “second electronic application,” (iv) “data storage,” (v) “trained,” and (vi) “user interface module,” do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination (Fig. 1-2A, ¶¶26-27, ¶31, and ¶49 shows elements in combination.), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible.
Dependent Claims 12-15 recite the abstract idea of:
. . . wherein the interaction occurs at a [certain place]. (Claim 13)
. . . wherein the classification model is a trained . . . learning model. (Claim 14)
. . . wherein upon determining that the user review of the entity is authentic, transmitting the user review to at least one [destination]. (Claim 15)
Dependent Claims 12-15, have been given the full two-prong analysis including analyzing the further elements and limitations, both individually and in combination. When analyzed individually and in combination, these claims are also held to be patent ineligible under 35 U.S.C. 101. The further limitation of Claims 12-15 fail to establish claims that are not directed to an abstract idea because the further limitations (1) the interaction occurs at a certain place, (2) the classification model is a trained learning model, and (3) transmit the review to a certain destination, all of which are apart of the abstract idea. The further elements of Claims 12-15 (i.e. “digital channel” of Claims 12 and 15, and “point-of-sale (POS) remote from the user device” of Claim 13, and “trained machine learning model” of Claims 14) fails to establish claims that are not directed to an abstract idea because the elements merely recite additional generic computer components similar to the generic computer components of Claim 11 or generally link the abstract idea to a particular technology or field of use (i.e. online computer environment) just as in Claim 11. The organization of the further limitations of Claims 12-15 fail to integrate an abstract idea into a practical application just as discussed above for Claim 11. Additionally, performing the abstract idea of Claim 11 as recited in each of the further limitations of Claims 12-15, individually or in combination, does not (1) impose any meaningful limits on practicing the abstract ideas, or (2) provide improvements to the functioning of computing systems or to another technology or technical field, just as discussed above regarding Claim 11. Therefore, Claims 12-15 amount to mere instructions to implement the abstract idea (1) using generic computer components—using the computer, in its ordinary capacity, as a tool to perform the abstract idea, and (2) generally linked to a particular technology or field of use. Because the claims merely use a computer, in its ordinary capacity in a particular field of use, as a tool to perform the abstract idea cannot provide an inventive concept, the elements and limitations of Claims 12-15 fail to establish that the claims provide an inventive concept, just as in Claim 11. Therefore, Claims 12-15 fails the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Claims 16-19 recite elements and limitations that are substantially similar to Claims 1-4. Claims 1-4 recites a method embodied by the elements and limitations of Claims 16-19. Therefore, Claims 16-19 are rejected under 35 U.S.C. 101 just as Claims 1-4 are rejected under 35 U.S.C. 101 as discussed below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4 and 8-19 are rejected under 35 U.S.C. 103 as being unpatentable over US-20220198501-A1 (“Jones”) in view of US-20160196566-A1 (“Murali”) and WO-2025000074-A1 (“El Kaake” priority date of 06/29/2023).
Regarding Claim 1, Jones teaches “A computer-implemented method” (Fig. 3A-4B and 6A-6C shows a computer implemented method.), “comprising:”
“receiving, at a remote device, a detection by a first electronic application operating on a user device of an interaction between a user of the user device and an entity, wherein the interaction occurs via a second electronic application” (Fig. 1, ¶¶26-27, and ¶¶32-33 shows a computing environment comprising “client device 102” (i.e. user device) that executes “software” (i.e. first electronic application and second electronic application), “user 101” (i.e. user), “merchant 111” (i.e. entity), and “financial institution (FI) system 130” (i.e. remote device). Fig. 3B and ¶87 shows “As illustrated in FIG. 3B, when presented within notification interface 354, the graphical representation of payment notification 324 may prompt user 101 to approve or reject the $930.00 payment requested by Josh's Stone and Landscape for the landscaping project completed on Sep. 30,2021, e.g., based on additional input provided to input unit 109B of client device 102 that selects a respective one of an “APPROVE” icon 352A and a “REJECT” icon 352B presented within notification interface 354.” ¶23 shows “the FI computing system may receive data that characterizes the counterparty-specific review, the product-specific review, or the service-specific review from the client device in conjunction with, or contemporaneously with, additional data confirming an approval, or a rejection, of the real-time payment requested from the customer by the merchant using any of the exemplary RTP processes described herein.”¶88 shows “In some instances, not illustrated in FIG. 3B, user 101 may elect to reject the $930.00 real-time payment requested by merchant 111 for the now-completed landscaping project, and user 101 may provide input to client device 102 (e.g., via input unit 109B) that selects “REJECT” icon 352B. Based on the input, executed mobile banking application 108 may perform operations (not illustrated in FIG. 3B), that generate and transmit a response that confirmation of the rejected payment across network 120 to FI computing system 130, . . .” (Emphasis added). The accepting or rejecting of payment on the “client device 102” (i.e. user device), which is transmitted to “FI computing system 130” (i.e. remote device), teaches the claimed “interaction.” See also ¶34 showing that “FI computing system 130” maintains a queue of requests for payment “until a receipt, at FI computing system 130, of confirmation data from corresponding ones of the computing systems or devices indicating an approval, or a rejection, of the corresponding requested payment.”);
“determining that the interaction between the user and the entity is reviewable based on first interaction data” (Fig. 3B-3C and ¶¶87-89 shows that “corresponding notification interface 354” of Fig. 3C, which prompts “user 101” to input and submit a review, is only displayed in response to the selection of “APPROVE icon 352A,” and is not displayed in response to selection of ““REJECT” icon 352B.” Therefore, only approving the payment will trigger an opportunity for the user to review. Thus, the determination of whether or not to present “notification interface 354” of Fig. 3C (i.e. interface for submitting a review) based on input received on “interface elements 352” of Fig. 3B (i.e. interface for approving or rejecting payment) teaches “determining that the interaction between the user and the entity is reviewable based on first interaction data.” See also Fig. 3B-4B and ¶¶116-18 further discussing the concepts.),
“wherein the first interaction data includes at least one of: (i) identification of items exchanged in the interaction; (ii) a merchant category code (MCC) for the entity; (iii) valuations of the items exchanged in the interaction; or (iv) qeo-location data of the entity” (Fig. 3B shows:
PNG
media_image1.png
70
5
media_image1.png
Greyscale
. Thus, Fig. 3B teaches that the first interaction data includes “(i) identification of items exchanged” (i.e. landscaping project completed on September 30th) and “(iii) valuations of the items exchanged in the interaction” (i.e. $930.00). ¶115 shows “executed notification module 348 may perform operations that, upon receipt of payment confirmation 360 from executed RTP module 358 (e.g., response to a provisioning of input 355 to client device 102 via input unit 109B), generate one or more elements of additional response data that include payment confirmation 360, along with customer identifier 328 and/or merchant identifier 338, and that cause client device 102 transmit the one or more elements additional response data to FI computing system 130.” (Emphasis added). ¶37 shows that the later submitted review is associated with the transaction data (i.e. first interaction data) of “ at least one of an identifier of a corresponding merchant (e.g., a name of merchant 111, an alphanumeric identifier of merchant 111, a standard industrial classification (SIC) code or merchant category code (MCC) associated with merchant 111 [(i.e. (ii) a merchant category code (MCC) for the entity)], etc.) or an identifier of a corresponding product or service (e.g., a product or service name or type [((i) identification of items exchanged in the interaction)], etc.).” ¶43 and ¶108-09 shows that “review data store 142,” includes “[0109] merchant identifier 338,” and “[0109] data 414 that includes a SIC or MCC code assigned to Josh's Stone and Landscaping and geographic data 416 that identifies a geographic region in which Josh's Stone and Landscaping operates (e.g., all, or a portion of, the street address of merchant 111, such as a city of operation or a postal code, etc.) [(i.e. (iv) geo-location data of the entity)].” See also Fig. 3A-3B, ¶¶81-82, and ¶87 showing “payment notification 324,” which represents the data transmitted to “client Device 102” for approval and includes “merchant identified 338,” description of services, and payment amount.);
“upon determining that the interaction between the user and the entity is reviewable, causing the first electronic application to prompt the user to enter second interaction data including a user review of the entity associated with the detected interaction” (Fig. 3B-3C and ¶89 shows “As illustrated in FIG. 3B, input unit 109B may route input data 356 indicative of provisioned input 355, and the selection of APPROVE icon 352A by user 101, to a real-time payment (RTP) module 358 of executed mobile banking application 108. In some instances, executed RTP module 358 may perform operations that process input data 356 and generate a payment confirmation 360 indicative of the approval [(i.e. “upon determining that the interaction between the user and the entity is reviewable”)], by user 101, of the $930.00 real-time payment requested by merchant 111 for the now-completed landscaping project, and that store payment confirmation 360 within a corresponding portion of memory 105, e.g., in conjunction with or in association with payment notification 324. Further, executed RTP module 358 may also provide payment confirmation as an input to notification module 348 of executed mobile banking application 108, which may perform any of the exemplary processes described herein to present, via display unit 109A within notification interface 354, one or more interface elements that are representative of review notification 344 that prompt user 101 to provision, to client device 102 via input unit 109B, further input specifying a review of merchant 111 [(i.e. prompt the user to enter second interaction data including a user review of the entity associated with the detected interaction)] (e.g., “Josh's Stone and Landscaping”) and additionally, or alternatively, of one or more products or services provided by merchant 111 (e.g., the lawn care and mulching services associated with the now-completed landscaping project, etc.).” See also Fig. 3C and ¶¶90-92, and ¶95-97 further discussing the user review input.);
“receiving, at the remote device and from the user device, the second interaction data including the user review of the entity” (Fig. 3B-4A and ¶98 shows “Executed notification module 348 may package payment confirmation 360 and customer review data 382 [(i.e. second interaction data including the user review of the entity)] into corresponding portions of response data 402, along with customer identifier 328 and additionally, or alternatively, merchant identifier 338. Executed notification module 348 may perform operations that cause client device 102 [(i.e. user device)] to transmit response data 402 across network 120 to FI computing system 130 [(i.e. remote device)].” See also Fig. 3C and ¶¶90-92, and ¶95-97 further discussing the user review input.);
“determining that the user review of the entity is authentic based on . . . the first interaction data and the second interaction data . . .” (¶¶24-25 and ¶82 shows a distinction between “a ‘verified’ review,” which is linked to an actual transaction, and “[an] ‘unverified’ review,” which does not correspond to an actual transaction. Fig. 3B-4A and ¶98 shows “Executed notification module 348 may package payment confirmation 360 and customer review data 382 [(i.e. second interaction data including the user review of the entity)] into corresponding portions of response data 402, along with customer identifier 328 and additionally, or alternatively, merchant identifier 338.” The input review teaches the “second interaction data.” ¶113 shows “As described herein, each of these counterparty-, product, or service-specific reviews may correspond to a “verified” [(i.e. authenticated)] review associated with not only an initiated purchase transaction involving a corresponding customer and one or more products or services provisioned by merchant 111 or the similar merchants (e.g., the purchased products and services associated with the landscaping project completed by Josh's Stone and Landscaping), but also with a real-time payment approved by the corresponding customer and executed by FI computing system 130 in conjunction with one or more of intermediate computing systems 236 associated with participants in the RTP ecosystem (e.g., the real-time payment of $930.00 requested by Josh's Stone and Landscaping and approved by user 101 using any of the exemplary processes described herein).” (Emphasis added). The initiated purchase transaction and payment approval teaches the “first interaction data.” Therefore, Jones teaches that a review is “verified” (i.e. authenticated) based on linking the review (i.e. second interaction data) with the payment (i.e. first interaction data). See also ¶97 discussing “verified review module 380.”);
“upon determining that the user review of the entity is authentic, storing, by the remote device, the user review in a data storage associated with the entity” (¶97 shows “Executed verified review module 380 may also perform operations that store customer review data 382 within a corresponding portion of memory 105, e.g., in conjunction with or in association with payment confirmation 360 and payment notification 324 [(i.e. associated with the entity)].” Fig. 4A-4B and ¶119 shows “As described herein, FI computing system 130 may maintain, within data records 142B of review data store 142, aggregated values of counterparty-, product-, or service-specific verified [(i.e. authentic)] reviews of corresponding merchants that participate in the RTP ecosystem.” See also ¶¶93-94 showing that the verified reviews are stored.); and
“transmitting, from the data storage, the user review to a user interface module, wherein the user interface module displays the user review to the user” (Fig. 4A and ¶110 shows “Referring back to FIG. 4A, executed review aggregation engine 154 may also perform operations that package all, or a selected portion of, customer review data 382 and updated aggregated review data 424 into corresponding portions of a merchant notification 432, either alone or in conjunction with elements of comparative review data 434 . . . Executed review aggregation engine 154 may also perform operations that cause FI computing system 130 to transmit merchant notification 432 across network 120 to merchant computing system 110 in accordance with a predetermined schedule (e.g., on a daily, weekly, or monthly basis, etc.) . . .” Fig. 4B and ¶111 shows “As illustrated in FIG. 4B, a programmatic interface [(i.e. user interface module)] established and maintained by merchant computing system 110, such as an application programming interface (API) 436, may receive merchant notification 432, and may route [(i.e. transmitting from the data storage)] merchant notification to an application program 438 executed by the one or more processors of merchant computing system 110, such as, but not limited to, an executed web browser or an executed banking application.” Fig. 4B and ¶¶28-29 shows “display unit 109A.” Fig. 4B and ¶¶111-12 shows “verified ratings notifications [444]” (i.e. the user view) displayed on “display unit 109A.”).
Jones does not explicitly teach, but Murali teaches “determining that the user review of the entity is authentic based on a classification model, the first interaction data and the second interaction data being input to the classification model” (Fig. 1 and ¶19 shows that “review entity 102” can be incorporated with the “merchant 106,” “payment network 104,” or “a separate review warehouse.” ¶21 shows “Upon receiving the review, the review entity 102 communicates, via the network 112, a request to the payment network 104 to validate the review.” Fig. 3 and ¶40 shows “Upon receiving the review, the review entity 102 communicates a request to the payment network 104 to validate the review. And, the request is received by the payment network 104, at 306, via computing device 200. The request includes the profile of the consumer 110, which may be a complete profile, or a partial profile.” Fig. 3 and ¶¶41-43 shows that “payment network 104” compares “details included in the review (e.g., date/time of the review, product name, service description, merchant name, MID, etc.) [(i.e. second interaction data)] to transaction data [(i.e. first interaction data)] in the identified payment accounts” in step 312. Fig. 3 and ¶43 shows a “validity indicator” that authenticates the review in steps 314, 316, and 318. ¶45 shows “the validity indicator may include a score (e.g., on a scale of one to ten, etc.), indicating a degree of confidence that the consumer 110 providing the review actually purchased the product or service identified in the review, or was a patron of the merchant 106.” ¶46 provides an example of how a score of 1-10 could be calculated, i.e. conditions for scores of 0-1, 3, 5, 7, or 10. The validity indicator score of ¶¶45-46 teaches the claimed “classification model” used to authenticate the review. Further, Fig. 3, ¶¶41-43, and ¶¶45-46 teaches that the review data (i.e. second interaction data) and transaction data (i.e. first interaction data) are used as inputs to calculate the score (i.e. classification model).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Murali with Jones because Jones teaches that a review can be a verified review by confirming actual commercial interaction relative to actual transaction information and review information (¶¶24-25, ¶82, and ¶113), and Murali teaches authenticating a review by comparing actual transaction information and review information can improve the quality of the review (¶¶10-11). Thus, combining Murali with Jones furthers the interest taught in Jones, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Jones and Murali do not explicitly teach, but El Kaake teaches:
“wherein the classification model is trained using training data comprising real reviews and fabricated reviews, and wherein the training data is used to generate a fraudulence threshold” (Fig. 4 and ¶¶174-79 shows “method 400” implemented with “system 100 of Figure 1” or “device 300 of Figure 3” includes the steps of “[410] Receiving review submissions from customers, initiated after each customer transaction,” “[420] Processing the received review submissions for the content,” “[430] Analyzing the processed review content to identify specific keywords, phrases, or patterns that correspond with predefined moderation categories,” “[440] Evaluating the review content against a set of moderation rules derived from legal and ethical guidelines, as well as business specific policies,” and “[450] Based on the evaluation, approving or declining the review submissions.” ¶129 shows that “device 300” of Fig. 3 may be “server 110” of Fig. 1. Fig. 1 and ¶60 shows “an Al-based analysis module 122, a moderation rules module 124, [and] a decision-making module 126,” which teaches the “classification model.” ¶¶91-96 and ¶¶99-100 further shows that the “review” includes the transaction itself, i.e. El Kaake teaches the first and second interactions are inputs to the classification model. Fig. 1 and ¶83 shows “Supervised learning involves the algorithms [within the Al-based analysis module 122] being trained on a labeled dataset [(i.e. training data)], where each review is marked as either approved [(i.e. real reviews)] or declined [(i.e. fabricated reviews)], teaching the Al to recognize patterns associated with each outcome.” Fig. 2 and ¶71 shows “The moderation rules module 124 operates by parsing incoming review submissions (as received via the review submissions module 120) and matching the content therein against a database of the foregoing rules (not shown). Each rule within the framework is encoded with specific conditions [(i.e. fraudulence threshold. See also ¶¶34-37 showing converting the review to a numerical vector)] that review submissions may meet or avoid. For instance, rules may target the presence of certain keywords indicative of spam or hate speech, patterns suggesting fraudulent content, or the absence of elements that confirm the review's relevance to the product or service. This rules-based approach enables the moderation rules module 124 to categorize and flag reviews for further action based on predefined parameters.” ¶85 and ¶90 shows that the “moderation rules” can be adjusted based on further “learning.” Thus, the “moderation rules module 124” teaches the generated fraudulence threshold based on training data.), and
“wherein the classification model is finetuned using the fraudulence threshold” (The broadest reasonable interpretation of this limitation includes a “classification model” comprising “the fraudulence threshold,” wherein the “classification model” is “tuned” such that “the fraudulence threshold” within the “classification model” is “tuned” (i.e. “. . . using the fraudulence threshold”). See Specification ¶73. ¶158 shows “The dynamic feedback loop data 362 may capture feedback from the moderation outcomes to refine the machine learning models and update the moderation rules database. The data 362 may include data on reviews that were manually approved or declined post-AI moderation, providing a feedback mechanism that allows for the iterative tuning [(i.e. finetuned)] of algorithms and rules [(i.e. “moderation rules data 332” of ¶155, which teaches “the fraudulence threshold.”)] within the system, ensuring its relevance and effectiveness over time.” (Emphasis added).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 2, Jones in view of Murali and El Kaake teaches “The method of claim 1,” as discussed above.
Jones further teaches “wherein determining that the interaction between the user and the entity is reviewable comprises: determining the entity is an entity for which reviews are applicable; and determining that user interest of the user for submission of the review exceeds a threshold” (As discussed above in greater detail, Fig. 3B-3C and ¶¶87-89 shows that “user 101” can “approve” or “reject” the payment request, such that approval creates “payment confirmation 360,” and the approval of payment teaches the determination that the interaction is reviewable. Fig. 3B shows:
PNG
media_image1.png
70
5
media_image1.png
Greyscale
.Thus, by approving payment for “Josh’s Stone and Landscaping” (i.e. entity), Jones teaches “determining the entity is an entity for which reviews are applicable,” under the broadest reasonable interpretation (e.g. if the payment was rejected a review for “Josh’s Stone and Landscaping” would not be applicable). Further, Fig. 3B, ¶¶87-89, and ¶117 presents the user with a binary choice to approve (“352A”) or reject (“352B”) the payment. Under the broadest reasonable interpretation of “user interest,” read in light of Specification ¶67, a person of ordinary skill in the art would understand that purchasing a service (i.e. approve 352A) represents an interest in reviewing that services, and not purchasing the service (i.e. reject 352B) represents a disinterest in reviewing that service. Further, the broadest reasonable interpretation of “exceeds a threshold,” includes a binary decision (e.g. reject=0, approve=1, and threshold=0.5). Thus, given its broadest reasonable interpretation, Jones teaches the recited limitation.).
Regarding Claim 3, Jones in view of Murali and El Kaake teaches “The method of claim 2,” as discussed above.
Jones further teaches “wherein: determining the entity is an entity that for which reviews are applicable comprises inputting the first interaction data into a rule-based algorithm” (As discussed above in greater detail, Fig. 3B-3C and ¶¶87-89 shows that “user 101” can “approve” or “reject” the payment request, such that approval creates “payment confirmation 360,” and the approval of payment teaches the determination that the interaction is reviewable. The binary choice to approve (“352A”) or reject (“352B”) the payment (i.e. first interaction data), directly results in the determination of whether or not to present the user with the ability to review the service (i.e. determine reviewability). Because the binary payment choice follows a strict cause-and-effect logic, Jones teaches the use of a “rule-based algorithm” applied to the “first interaction data.”).
Regarding Claim 4, Jones in view of Murali and El Kaake teaches “The method of claim 2,” as discussed above.
Jones and Murali do not explicitly teach, but El Kaake further teaches “wherein: determining that the user interest of the user for submission of the review exceeds the threshold comprises inputting the first interaction data into a trained machine learning model” (Fig. 4 and ¶¶174-79 shows “method 400” implemented with “system 100 of Figure 1” or “device 300 of Figure 3” includes the steps of “[410] Receiving review submissions from customers, initiated after each customer transaction,” “[420] Processing the received review submissions for the content,” “[430] Analyzing the processed review content to identify specific keywords, phrases, or patterns that correspond with predefined moderation categories,” “[440] Evaluating the review content against a set of moderation rules derived from legal and ethical guidelines, as well as business specific policies,” and “[450] Based on the evaluation, approving or declining the review submissions.” Fig. 2 and ¶71 shows “The moderation rules module 124 operates by parsing incoming review submissions (as received via the review submissions module 120) and matching the content therein against a database of the foregoing rules (not shown). Each rule within the framework is encoded with specific conditions [(i.e. fraudulence threshold. See ¶¶34-37 showing converting the review to a numerical vector. Thus, the condition teaches “exceeds the threshold”)] that review submissions may meet or avoid. For instance, rules may target the presence of certain keywords indicative of spam or hate speech, patterns suggesting fraudulent content, or the absence of elements that confirm the review's relevance to the product or service. This rules-based approach enables the moderation rules module 124 to categorize and flag reviews for further action based on predefined parameters.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 8, Jones in view of Murali and El Kaake teaches “The method of claim 1,” as discussed above.
Jones further teaches “wherein the interaction occurs at a point-of-sale (POS) device remote from the user device” (¶17 shows “For example, the merchant computing system may be communicatively coupled to a point-of-sale terminal, which may receive one or more of the elements of payment data from the customer (e.g., via a input device capable of interrogating a magnetic strip or an integrated circuit included within a physical payment card, or via wireless channel of communication with the client device, etc.), and which may provision the received elements of payment data to the merchant computing system.”).
Regarding Claim 9, Jones in view of Murali and El Kaake teaches “The method of claim 1,” as discussed above.
Jones and Murali do not explicitly teach, but El Kaake further teaches “wherein the classification model is a trained machine learning model” (¶83 shows the “learning” used to create the classification model. Thus, El Kaake teaches that the classification model is a “trained machine learning model.” See also ¶¶152-61 showing that the machine learning model is “trained.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 10, Jones in view of Murali and El Kaake teaches “The method of claim 1,” as discussed above.
Jones further teaches “wherein upon determining that the user review of the entity is authentic, transmitting the user review to at least one digital channel” (Fig. 4A and ¶110 shows “Referring back to FIG. 4A, executed review aggregation engine 154 may also perform operations that package all, or a selected portion of, customer review data 382 and updated aggregated review data 424 into corresponding portions of a merchant notification 432, either alone or in conjunction with elements of comparative review data 434 . . . Executed review aggregation engine 154 may also perform operations that cause FI computing system 130 to transmit merchant notification 432 across network 120 to merchant computing system 110 in accordance with a predetermined schedule (e.g., on a daily, weekly, or monthly basis, etc.) . . .” Fig. 4B and ¶111 shows “As illustrated in FIG. 4B, a programmatic interface established and maintained by merchant computing system 110, such as an application programming interface (API) 436, may receive merchant notification 432, and may route merchant notification to an application program 438 executed by the one or more processors of merchant computing system 110, such as, but not limited to, an executed web browser or an executed banking application.” Fig. 4B and ¶¶113-14 shows that the reviews transmitted to “merchant computing system 110” and displayed on a web browser (i.e. at least one digital channel) are “verified.”).
Regarding Claim 11, Jones teaches “A computer-implemented method” (Fig. 3A-4B and 6A-6C shows a computer implemented method.), “comprising:”
“receiving, at a remote device from a first electronic application, first interaction data associated with a user and an entity, the first interaction data including a user review of the entity” (Fig. 1, ¶¶26-27, and ¶¶32-33 shows a computing environment comprising “client device 102” that executes “software” (i.e. first electronic application and second electronic application), “user 101” (i.e. user), “merchant 111” (i.e. entity), and “financial institution (FI) system 130” (i.e. remote device). Fig. 3B-4A and ¶98 shows “Executed notification module 348 may package payment confirmation 360 and customer review data 382 [(i.e. first interaction data including the user review of the entity)] into corresponding portions of response data 402, along with customer identifier 328 and additionally, or alternatively, merchant identifier 338. Executed notification module 348 may perform operations that cause client device 102 [(i.e. first electronic application)] to transmit response data 402 across network 120 to FI computing system 130 [(i.e. remote device)].” See also Fig. 3C and ¶¶90-92, and ¶95-97 further discussing the user review input.);
“wherein the first interaction data includes at least one of: (i) identification of items exchanged in the interaction; (ii) a merchant category code (MCC) for the entity; (iii) valuations of the items exchanged in the interaction; or (iv) qeo-location data of the entity” (Fig. 3B shows:
PNG
media_image1.png
70
5
media_image1.png
Greyscale
. Thus, Fig. 3B teaches that the first interaction data includes “(i) identification of items exchanged” (i.e. landscaping project completed on September 30th) and “(iii) valuations of the items exchanged in the interaction” (i.e. $930.00). ¶115 shows “executed notification module 348 may perform operations that, upon receipt of payment confirmation 360 from executed RTP module 358 (e.g., response to a provisioning of input 355 to client device 102 via input unit 109B), generate one or more elements of additional response data that include payment confirmation 360, along with customer identifier 328 and/or merchant identifier 338, and that cause client device 102 transmit the one or more elements additional response data to FI computing system 130.” (Emphasis added). ¶37 shows that the later submitted review is associated with the transaction data (i.e. first interaction data) of “ at least one of an identifier of a corresponding merchant (e.g., a name of merchant 111, an alphanumeric identifier of merchant 111, a standard industrial classification (SIC) code or merchant category code (MCC) associated with merchant 111 [(i.e. (ii) a merchant category code (MCC) for the entity)], etc.) or an identifier of a corresponding product or service (e.g., a product or service name or type [((i) identification of items exchanged in the interaction)], etc.).” ¶43 and ¶108-09 shows that “review data store 142,” includes “[0109] merchant identifier 338,” and “[0109] data 414 that includes a SIC or MCC code assigned to Josh's Stone and Landscaping and geographic data 416 that identifies a geographic region in which Josh's Stone and Landscaping operates (e.g., all, or a portion of, the street address of merchant 111, such as a city of operation or a postal code, etc.) [(i.e. (iv) geo-location data of the entity)].” See also Fig. 3A-3B, ¶¶81-82, and ¶87 showing “payment notification 324,” which represents the data transmitted to “client Device 102” for approval and includes “merchant identified 338,” description of services, and payment amount.);
“retrieving, at the remote device from a second electronic application, second interaction data associated with the user and the entity, the second interaction data indicating an interaction between the user and the entity” (Fig. 3B and ¶87 shows “As illustrated in FIG. 3B, when presented within notification interface 354, the graphical representation of payment notification 324 may prompt user 101 to approve or reject the $930.00 payment requested by Josh's Stone and Landscape for the landscaping project completed on Sep. 30,2021, e.g., based on additional input provided to input unit 109B of client device 102 that selects a respective one of an “APPROVE” icon 352A and a “REJECT” icon 352B presented within notification interface 354.” ¶23 shows “the FI computing system may receive data that characterizes the counterparty-specific review, the product-specific review, or the service-specific review from the client device in conjunction with, or contemporaneously with, additional data confirming an approval, or a rejection, of the real-time payment requested from the customer by the merchant using any of the exemplary RTP processes described herein.”¶88 shows “In some instances, not illustrated in FIG. 3B, user 101 may elect to reject the $930.00 real-time payment requested by merchant 111 for the now-completed landscaping project, and user 101 may provide input to client device 102 (e.g., via input unit 109B) that selects “REJECT” icon 352B. Based on the input, executed mobile banking application 108 may perform operations (not illustrated in FIG. 3B), that generate and transmit a response that confirmation of the rejected payment across network 120 to FI computing system 130, . . .” (Emphasis added). The accepting or rejecting of payment on the “client device 102,” which is transmitted to “FI computing system 130” (i.e. remote device), teaches the claimed “interaction.” See also ¶34 showing that “FI computing system 130” maintains a queue of requests for payment “until a receipt, at FI computing system 130, of confirmation data from corresponding ones of the computing systems or devices indicating an approval, or a rejection, of the corresponding requested payment.”);
“determining that the user review of the entity is authentic based on . . . the first interaction data and the second interaction data . . .” (¶¶24-25 and ¶82 shows a distinction between “a ‘verified’ review,” which is linked to an actual transaction, and “[an] ‘unverified’ review,” which does not correspond to an actual transaction. Fig. 3B-4A and ¶98 shows “Executed notification module 348 may package payment confirmation 360 and customer review data 382 [(i.e. second interaction data including the user review of the entity)] into corresponding portions of response data 402, along with customer identifier 328 and additionally, or alternatively, merchant identifier 338.” The input review teaches the “second interaction data.” ¶113 shows “As described herein, each of these counterparty-, product, or service-specific reviews may correspond to a “verified” [(i.e. authenticated)] review associated with not only an initiated purchase transaction involving a corresponding customer and one or more products or services provisioned by merchant 111 or the similar merchants (e.g., the purchased products and services associated with the landscaping project completed by Josh's Stone and Landscaping), but also with a real-time payment approved by the corresponding customer and executed by FI computing system 130 in conjunction with one or more of intermediate computing systems 236 associated with participants in the RTP ecosystem (e.g., the real-time payment of $930.00 requested by Josh's Stone and Landscaping and approved by user 101 using any of the exemplary processes described herein).” (Emphasis added). The initiated purchase transaction and payment approval teaches the “first interaction data.” Therefore, Jones teaches that a review is “verified” (i.e. authenticated) based on linking the review (i.e. second interaction data) with the payment (i.e. first interaction data). See also ¶97 discussing “verified review module 380.”);
“upon determining that the user review of the entity is authentic, storing, by the remote device, the user review in a data storage associated with the entity” (¶97 shows “Executed verified review module 380 may also perform operations that store customer review data 382 within a corresponding portion of memory 105, e.g., in conjunction with or in association with payment confirmation 360 and payment notification 324 [(i.e. associated with the entity)].” Fig. 4A-4B and ¶119 shows “As described herein, FI computing system 130 may maintain, within data records 142B of review data store 142, aggregated values of counterparty-, product-, or service-specific verified [(i.e. authentic)] reviews of corresponding merchants that participate in the RTP ecosystem.” See also ¶¶93-94 showing that the verified reviews are stored.); and
“transmitting, from the data storage, the user review to a user interface module, wherein the user interface module displays the user review to the user” (Fig. 4A and ¶110 shows “Referring back to FIG. 4A, executed review aggregation engine 154 may also perform operations that package all, or a selected portion of, customer review data 382 and updated aggregated review data 424 into corresponding portions of a merchant notification 432, either alone or in conjunction with elements of comparative review data 434 . . . Executed review aggregation engine 154 may also perform operations that cause FI computing system 130 to transmit merchant notification 432 across network 120 to merchant computing system 110 in accordance with a predetermined schedule (e.g., on a daily, weekly, or monthly basis, etc.) . . .” Fig. 4B and ¶111 shows “As illustrated in FIG. 4B, a programmatic interface [(i.e. user interface module)] established and maintained by merchant computing system 110, such as an application programming interface (API) 436, may receive merchant notification 432, and may route [(i.e. transmitting from the data storage)] merchant notification to an application program 438 executed by the one or more processors of merchant computing system 110, such as, but not limited to, an executed web browser or an executed banking application.” Fig. 4B and ¶¶28-29 shows “display unit 109A.” Fig. 4B and ¶¶111-12 shows “verified ratings notifications [444]” (i.e. the user view) displayed on “display unit 109A.”).
Jones does not explicitly teach, but Murali teaches “determining that the user review of the entity is authentic based on a classification model, the first interaction data and the second interaction data being input to the classification model” (Fig. 1 and ¶19 shows that “review entity 102” can be incorporated with the “merchant 106,” “payment network 104,” or “a separate review warehouse.” ¶21 shows “Upon receiving the review, the review entity 102 communicates, via the network 112, a request to the payment network 104 to validate the review.” Fig. 3 and ¶40 shows “Upon receiving the review, the review entity 102 communicates a request to the payment network 104 to validate the review. And, the request is received by the payment network 104, at 306, via computing device 200. The request includes the profile of the consumer 110, which may be a complete profile, or a partial profile.” Fig. 3 and ¶¶41-43 shows that “payment network 104” compares “details included in the review (e.g., date/time of the review, product name, service description, merchant name, MID, etc.) [(i.e. first interaction data)] to transaction data [(i.e. second interaction data)] in the identified payment accounts” in step 312. Fig. 3 and ¶43 shows a “validity indicator” that authenticates the review in steps 314, 316, and 318. ¶45 shows “the validity indicator may include a score (e.g., on a scale of one to ten, etc.), indicating a degree of confidence that the consumer 110 providing the review actually purchased the product or service identified in the review, or was a patron of the merchant 106.” ¶46 provides an example of how a score of 1-10 could be calculated, i.e. conditions for scores of 0-1, 3, 5, 7, or 10. The validity indicator score of ¶¶45-46 teaches the claimed “classification model” used to authenticate the review. Further, Fig. 3, ¶¶41-43, and ¶¶45-46 teaches that the review data (i.e. first interaction data) and transaction data (i.e. second interaction data) are used as inputs to calculate the score (i.e. classification model).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Murali with Jones because Jones teaches that a review can be a verified review by confirming actual commercial interaction relative to actual transaction information and review information (¶¶24-25, ¶82, and ¶113), and Murali teaches authenticating a review by comparing actual transaction information and review information can improve the quality of the review (¶¶10-11). Thus, combining Murali with Jones furthers the interest taught in Jones, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Jones and Murali do not explicitly teach, but El Kaake teaches:
“wherein the classification model is trained using training data comprising real reviews and fabricated reviews, and wherein the training data is used to generate a fraudulence threshold” (Fig. 4 and ¶¶174-79 shows “method 400” implemented with “system 100 of Figure 1” or “device 300 of Figure 3” includes the steps of “[410] Receiving review submissions from customers, initiated after each customer transaction,” “[420] Processing the received review submissions for the content,” “[430] Analyzing the processed review content to identify specific keywords, phrases, or patterns that correspond with predefined moderation categories,” “[440] Evaluating the review content against a set of moderation rules derived from legal and ethical guidelines, as well as business specific policies,” and “[450] Based on the evaluation, approving or declining the review submissions.” ¶129 shows that “device 300” of Fig. 3 may be “server 110” of Fig. 1. Fig. 1 and ¶60 shows “an Al-based analysis module 122, a moderation rules module 124, [and] a decision-making module 126,” which teaches the “classification model.” ¶¶91-96 and ¶¶99-100 further shows that the “review” includes the transaction itself, i.e. El Kaake teaches the first and second interactions are inputs to the classification model. Fig. 1 and ¶83 shows “Supervised learning involves the algorithms [within the Al-based analysis module 122] being trained on a labeled dataset [(i.e. training data)], where each review is marked as either approved [(i.e. real reviews)] or declined [(i.e. fabricated reviews)], teaching the Al to recognize patterns associated with each outcome.” Fig. 2 and ¶71 shows “The moderation rules module 124 operates by parsing incoming review submissions (as received via the review submissions module 120) and matching the content therein against a database of the foregoing rules (not shown). Each rule within the framework is encoded with specific conditions [(i.e. fraudulence threshold. See also ¶¶34-37 showing converting the review to a numerical vector)] that review submissions may meet or avoid. For instance, rules may target the presence of certain keywords indicative of spam or hate speech, patterns suggesting fraudulent content, or the absence of elements that confirm the review's relevance to the product or service. This rules-based approach enables the moderation rules module 124 to categorize and flag reviews for further action based on predefined parameters.” ¶85 and ¶90 shows that the “moderation rules” can be adjusted based on further “learning.” Thus, the “moderation rules module 124” teaches the generated fraudulence threshold based on training data.), and
“wherein the classification model is finetuned using the fraudulence threshold” (The broadest reasonable interpretation of this limitation includes a “classification model” comprising “the fraudulence threshold,” wherein the “classification model” is “tuned” such that “the fraudulence threshold” within the “classification model” is “tuned” (i.e. “. . . using the fraudulence threshold”). See Specification ¶73. ¶158 shows “The dynamic feedback loop data 362 may capture feedback from the moderation outcomes to refine the machine learning models and update the moderation rules database. The data 362 may include data on reviews that were manually approved or declined post-AI moderation, providing a feedback mechanism that allows for the iterative tuning [(i.e. finetuned)] of algorithms and rules [(i.e. “moderation rules data 332” of ¶155, which teaches “the fraudulence threshold.”)] within the system, ensuring its relevance and effectiveness over time.” (Emphasis added).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 12, Jones in view of Murali and El Kaake teaches teach “The method of claim 11,” as discussed above.
Jones further teaches “wherein the first electronic application is a digital channel” (Fig 1 and ¶27 shows “Client device 102 may include a computing device having one or more tangible, non-transitory memories, such as memory 105, that store data and/or software instructions, and one or more processors, e.g., processor 104, configured to execute the software instructions. The one or more tangible, non-transitory memories may, in some aspects, store application programs, application engines or modules, and other elements of code executable by the one or more processors, such as, but not limited to, an executable web browser 106 (e.g., Google Chrome™, Apple Safari™, etc.) [(i.e. a digital channel)], and additionally or alternatively, an executable application associated with FI computing system 130 (e.g., mobile banking application 108) [(i.e. a digital channel)].” See also ¶¶152-53 showing that interactions with a user can utilize a “web browser.”).
Regarding Claim 13, Jones in view of Murali and El Kaake teaches “The method of claim 11,” as discussed above.
Jones further teaches “wherein the interaction occurs at a point-of-sale (POS) device remote from [[the]] a user device” (¶17 shows “For example, the merchant computing system may be communicatively coupled to a point-of-sale terminal, which may receive one or more of the elements of payment data from the customer (e.g., via a input device capable of interrogating a magnetic strip or an integrated circuit included within a physical payment card, or via wireless channel of communication with the client device, etc.), and which may provision the received elements of payment data to the merchant computing system.”).
Regarding Claim 14, Jones in view of Murali and El Kaake teaches “The method of claim 11,” as discussed above.
Jones and Murali do not explicitly teach, but El Kaake further teaches “wherein the classification model is a trained machine learning model” (¶83 shows the “learning” used to create the classification model. Thus, El Kaake teaches that the classification model is a “trained machine learning model.” See also ¶¶152-61 showing that the machine learning model is “trained.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 15, Jones in view of Murali teach “The method of claim 11,” as discussed above.
Jones further teaches “wherein upon determining that the user review of the entity is authentic, transmitting the user review to at least one digital channel” (Fig. 4A and ¶110 shows “Referring back to FIG. 4A, executed review aggregation engine 154 may also perform operations that package all, or a selected portion of, customer review data 382 and updated aggregated review data 424 into corresponding portions of a merchant notification 432, either alone or in conjunction with elements of comparative review data 434 . . . Executed review aggregation engine 154 may also perform operations that cause FI computing system 130 to transmit merchant notification 432 across network 120 to merchant computing system 110 in accordance with a predetermined schedule (e.g., on a daily, weekly, or monthly basis, etc.) . . .” Fig. 4B and ¶111 shows “As illustrated in FIG. 4B, a programmatic interface established and maintained by merchant computing system 110, such as an application programming interface (API) 436, may receive merchant notification 432, and may route merchant notification to an application program 438 executed by the one or more processors of merchant computing system 110, such as, but not limited to, an executed web browser or an executed banking application.” Fig. 4B and ¶¶113-14 shows that the reviews transmitted to “merchant computing system 110” and displayed on a web browser (i.e. at least one digital channel) are “verified.”).
Regarding Claim 16, Jones teaches “A non-transitory computer-readable medium comprising instructions for recordation of interaction data, the instructions executable by at least one processor of a remote device to perform operations” (Fig. 1, ¶¶26-27, and ¶¶32-33 shows a computing environment comprising “client device 102” (i.e. user device) that executes “software” (i.e. first electronic application and second electronic application), “user 101” (i.e. user), “merchant 111” (i.e. entity), and “financial institution (FI) system 130” (i.e. remote device). Fig. 3A-4B and 6A-6C shows computer operations. ¶30 shows “Merchant computing system 110 and FI computing system 130 may each represent a computing system that includes one or more servers and one or more tangible, non-transitory memory devices storing executable code, application engines, or application modules. Each of the one or more servers may include one or more processors, which may be configured to execute portions of the stored code, application engines or modules, or application programs to perform operations consistent with the disclosed exemplary embodiments.”), “including:”
“causing, at the remote device, a first electronic application operating on a user device to detect an interaction between a user of the user device and an entity via a second electronic application” (Fig. 1, ¶¶26-27, and ¶¶32-33 shows a computing environment comprising “client device 102” (i.e. user device) that executes “software” (i.e. first electronic application and second electronic application), “user 101” (i.e. user), “merchant 111” (i.e. entity), and “financial institution (FI) system 130” (i.e. remote device). Fig. 3B and ¶87 shows “As illustrated in FIG. 3B, when presented within notification interface 354, the graphical representation of payment notification 324 may prompt user 101 to approve or reject the $930.00 payment requested by Josh's Stone and Landscape for the landscaping project completed on Sep. 30,2021, e.g., based on additional input provided to input unit 109B of client device 102 that selects a respective one of an “APPROVE” icon 352A and a “REJECT” icon 352B presented within notification interface 354.” ¶23 shows “the FI computing system may receive data that characterizes the counterparty-specific review, the product-specific review, or the service-specific review from the client device in conjunction with, or contemporaneously with, additional data confirming an approval, or a rejection, of the real-time payment requested from the customer by the merchant using any of the exemplary RTP processes described herein.”¶88 shows “In some instances, not illustrated in FIG. 3B, user 101 may elect to reject the $930.00 real-time payment requested by merchant 111 for the now-completed landscaping project, and user 101 may provide input to client device 102 (e.g., via input unit 109B) that selects “REJECT” icon 352B. Based on the input, executed mobile banking application 108 may perform operations (not illustrated in FIG. 3B), that generate and transmit a response that confirmation of the rejected payment across network 120 to FI computing system 130, . . .” (Emphasis added). The accepting or rejecting of payment on the “client device 102” (i.e. user device), which is transmitted to “FI computing system 130” (i.e. remote device), teaches the claimed “interaction.” See also ¶34 showing that “FI computing system 130” maintains a queue of requests for payment “until a receipt, at FI computing system 130, of confirmation data from corresponding ones of the computing systems or devices indicating an approval, or a rejection, of the corresponding requested payment.”);
“determining that the interaction between the user and the entity is reviewable based on first interaction data” (Fig. 3B-3C and ¶¶87-89 shows that “corresponding notification interface 354” of Fig. 3C, which prompts “user 101” to input and submit a review, is only displayed in response to the selection of “APPROVE icon 352A,” and is not displayed in response to selection of ““REJECT” icon 352B.” Therefore, only approving the payment will trigger an opportunity for the user to review. Thus, the determination of whether or not to present “notification interface 354” of Fig. 3C (i.e. interface for submitting a review) based on input received on “interface elements 352” of Fig. 3B (i.e. interface for approving or rejecting payment) teaches “determining that the interaction between the user and the entity is reviewable based on first interaction data.” See also Fig. 3B-4B and ¶¶116-18 further discussing the concepts.);
“wherein the first interaction data includes at least one of: (i) identification of items exchanged in the interaction; (ii) a merchant category code (MCC) for the entity; (iii) valuations of the items exchanged in the interaction; or (iv) qeo-location data of the entity” (Fig. 3B shows:
PNG
media_image1.png
70
5
media_image1.png
Greyscale
. Thus, Fig. 3B teaches that the first interaction data includes “(i) identification of items exchanged” (i.e. landscaping project completed on September 30th) and “(iii) valuations of the items exchanged in the interaction” (i.e. $930.00). ¶115 shows “executed notification module 348 may perform operations that, upon receipt of payment confirmation 360 from executed RTP module 358 (e.g., response to a provisioning of input 355 to client device 102 via input unit 109B), generate one or more elements of additional response data that include payment confirmation 360, along with customer identifier 328 and/or merchant identifier 338, and that cause client device 102 transmit the one or more elements additional response data to FI computing system 130.” (Emphasis added). ¶37 shows that the later submitted review is associated with the transaction data (i.e. first interaction data) of “ at least one of an identifier of a corresponding merchant (e.g., a name of merchant 111, an alphanumeric identifier of merchant 111, a standard industrial classification (SIC) code or merchant category code (MCC) associated with merchant 111 [(i.e. (ii) a merchant category code (MCC) for the entity)], etc.) or an identifier of a corresponding product or service (e.g., a product or service name or type [((i) identification of items exchanged in the interaction)], etc.).” ¶43 and ¶108-09 shows that “review data store 142,” includes “[0109] merchant identifier 338,” and “[0109] data 414 that includes a SIC or MCC code assigned to Josh's Stone and Landscaping and geographic data 416 that identifies a geographic region in which Josh's Stone and Landscaping operates (e.g., all, or a portion of, the street address of merchant 111, such as a city of operation or a postal code, etc.) [(i.e. (iv) geo-location data of the entity)].” See also Fig. 3A-3B, ¶¶81-82, and ¶87 showing “payment notification 324,” which represents the data transmitted to “client Device 102” for approval and includes “merchant identified 338,” description of services, and payment amount.);
“upon determining that the interaction between the user and the entity is reviewable, causing the first electronic application to prompt the user to enter second interaction data including a user review of the entity associated with the detected interaction” (Fig. 3B-3C and ¶89 shows “As illustrated in FIG. 3B, input unit 109B may route input data 356 indicative of provisioned input 355, and the selection of APPROVE icon 352A by user 101, to a real-time payment (RTP) module 358 of executed mobile banking application 108. In some instances, executed RTP module 358 may perform operations that process input data 356 and generate a payment confirmation 360 indicative of the approval [(i.e. “upon determining that the interaction between the user and the entity is reviewable”)], by user 101, of the $930.00 real-time payment requested by merchant 111 for the now-completed landscaping project, and that store payment confirmation 360 within a corresponding portion of memory 105, e.g., in conjunction with or in association with payment notification 324. Further, executed RTP module 358 may also provide payment confirmation as an input to notification module 348 of executed mobile banking application 108, which may perform any of the exemplary processes described herein to present, via display unit 109A within notification interface 354, one or more interface elements that are representative of review notification 344 that prompt user 101 to provision, to client device 102 via input unit 109B, further input specifying a review of merchant 111 [(i.e. prompt the user to enter second interaction data including a user review of the entity associated with the detected interaction)] (e.g., “Josh's Stone and Landscaping”) and additionally, or alternatively, of one or more products or services provided by merchant 111 (e.g., the lawn care and mulching services associated with the now-completed landscaping project, etc.).” See also Fig. 3C and ¶¶90-92, and ¶95-97 further discussing the user review input.);
“receiving, at the remote device and from the user device, the second interaction data including the user review of the entity” (Fig. 3B-4A and ¶98 shows “Executed notification module 348 may package payment confirmation 360 and customer review data 382 [(i.e. second interaction data including the user review of the entity)] into corresponding portions of response data 402, along with customer identifier 328 and additionally, or alternatively, merchant identifier 338. Executed notification module 348 may perform operations that cause client device 102 [(i.e. user device)] to transmit response data 402 across network 120 to FI computing system 130 [(i.e. remote device)].” See also Fig. 3C and ¶¶90-92, and ¶95-97 further discussing the user review input.);
“determining that the user review of the entity is authentic based on . . . the first interaction data and the second interaction data . . .” (¶¶24-25 and ¶82 shows a distinction between “a ‘verified’ review,” which is linked to an actual transaction, and “[an] ‘unverified’ review,” which does not correspond to an actual transaction. Fig. 3B-4A and ¶98 shows “Executed notification module 348 may package payment confirmation 360 and customer review data 382 [(i.e. second interaction data including the user review of the entity)] into corresponding portions of response data 402, along with customer identifier 328 and additionally, or alternatively, merchant identifier 338.” The input review teaches the “second interaction data.” ¶113 shows “As described herein, each of these counterparty-, product, or service-specific reviews may correspond to a “verified” [(i.e. authenticated)] review associated with not only an initiated purchase transaction involving a corresponding customer and one or more products or services provisioned by merchant 111 or the similar merchants (e.g., the purchased products and services associated with the landscaping project completed by Josh's Stone and Landscaping), but also with a real-time payment approved by the corresponding customer and executed by FI computing system 130 in conjunction with one or more of intermediate computing systems 236 associated with participants in the RTP ecosystem (e.g., the real-time payment of $930.00 requested by Josh's Stone and Landscaping and approved by user 101 using any of the exemplary processes described herein).” (Emphasis added). The initiated purchase transaction and payment approval teaches the “first interaction data.” Therefore, Jones teaches that a review is “verified” (i.e. authenticated) based on linking the review (i.e. second interaction data) with the payment (i.e. first interaction data). See also ¶97 discussing “verified review module 380.”);
“upon determining that the user review of the entity is authentic, storing, by the remote device, the user review in a data storage associated with the entity” (¶97 shows “Executed verified review module 380 may also perform operations that store customer review data 382 within a corresponding portion of memory 105, e.g., in conjunction with or in association with payment confirmation 360 and payment notification 324 [(i.e. associated with the entity)].” Fig. 4A-4B and ¶119 shows “As described herein, FI computing system 130 may maintain, within data records 142B of review data store 142, aggregated values of counterparty-, product-, or service-specific verified [(i.e. authentic)] reviews of corresponding merchants that participate in the RTP ecosystem.” See also ¶¶93-94 showing that the verified reviews are stored.); and
“transmitting, from the data storage, the user review to a user interface module, wherein the user interface module displays the user review to the user” (Fig. 4A and ¶110 shows “Referring back to FIG. 4A, executed review aggregation engine 154 may also perform operations that package all, or a selected portion of, customer review data 382 and updated aggregated review data 424 into corresponding portions of a merchant notification 432, either alone or in conjunction with elements of comparative review data 434 . . . Executed review aggregation engine 154 may also perform operations that cause FI computing system 130 to transmit merchant notification 432 across network 120 to merchant computing system 110 in accordance with a predetermined schedule (e.g., on a daily, weekly, or monthly basis, etc.) . . .” Fig. 4B and ¶111 shows “As illustrated in FIG. 4B, a programmatic interface [(i.e. user interface module)] established and maintained by merchant computing system 110, such as an application programming interface (API) 436, may receive merchant notification 432, and may route [(i.e. transmitting from the data storage)] merchant notification to an application program 438 executed by the one or more processors of merchant computing system 110, such as, but not limited to, an executed web browser or an executed banking application.” Fig. 4B and ¶¶28-29 shows “display unit 109A.” Fig. 4B and ¶¶111-12 shows “verified ratings notifications [444]” (i.e. the user view) displayed on “display unit 109A.”).
Jones does not explicitly teach, but Murali teaches “determining that the user review of the entity is authentic based on a classification model, the first interaction data and the second interaction data being input to the classification model” (Fig. 1 and ¶19 shows that “review entity 102” can be incorporated with the “merchant 106,” “payment network 104,” or “a separate review warehouse.” ¶21 shows “Upon receiving the review, the review entity 102 communicates, via the network 112, a request to the payment network 104 to validate the review.” Fig. 3 and ¶40 shows “Upon receiving the review, the review entity 102 communicates a request to the payment network 104 to validate the review. And, the request is received by the payment network 104, at 306, via computing device 200. The request includes the profile of the consumer 110, which may be a complete profile, or a partial profile.” Fig. 3 and ¶¶41-43 shows that “payment network 104” compares “details included in the review (e.g., date/time of the review, product name, service description, merchant name, MID, etc.) [(i.e. second interaction data)] to transaction data [(i.e. first interaction data)] in the identified payment accounts” in step 312. Fig. 3 and ¶43 shows a “validity indicator” that authenticates the review in steps 314, 316, and 318. ¶45 shows “the validity indicator may include a score (e.g., on a scale of one to ten, etc.), indicating a degree of confidence that the consumer 110 providing the review actually purchased the product or service identified in the review, or was a patron of the merchant 106.” ¶46 provides an example of how a score of 1-10 could be calculated, i.e. conditions for scores of 0-1, 3, 5, 7, or 10. The validity indicator score of ¶¶45-46 teaches the claimed “classification model” used to authenticate the review. Further, Fig. 3, ¶¶41-43, and ¶¶45-46 teaches that the review data (i.e. second interaction data) and transaction data (i.e. first interaction data) are used as inputs to calculate the score (i.e. classification model).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Murali with Jones because Jones teaches that a review can be a verified review by confirming actual commercial interaction relative to actual transaction information and review information (¶¶24-25, ¶82, and ¶113), and Murali teaches authenticating a review by comparing actual transaction information and review information can improve the quality of the review (¶¶10-11). Thus, combining Murali with Jones furthers the interest taught in Jones, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Jones and Murali do not explicitly teach, but El Kaake teaches:
“wherein the classification model is trained using training data comprising real reviews and fabricated reviews, and wherein the training data is used to generate a fraudulence threshold” (Fig. 4 and ¶¶174-79 shows “method 400” implemented with “system 100 of Figure 1” or “device 300 of Figure 3” includes the steps of “[410] Receiving review submissions from customers, initiated after each customer transaction,” “[420] Processing the received review submissions for the content,” “[430] Analyzing the processed review content to identify specific keywords, phrases, or patterns that correspond with predefined moderation categories,” “[440] Evaluating the review content against a set of moderation rules derived from legal and ethical guidelines, as well as business specific policies,” and “[450] Based on the evaluation, approving or declining the review submissions.” ¶129 shows that “device 300” of Fig. 3 may be “server 110” of Fig. 1. Fig. 1 and ¶60 shows “an Al-based analysis module 122, a moderation rules module 124, [and] a decision-making module 126,” which teaches the “classification model.” ¶¶91-96 and ¶¶99-100 further shows that the “review” includes the transaction itself, i.e. El Kaake teaches the first and second interactions are inputs to the classification model. Fig. 1 and ¶83 shows “Supervised learning involves the algorithms [within the Al-based analysis module 122] being trained on a labeled dataset [(i.e. training data)], where each review is marked as either approved [(i.e. real reviews)] or declined [(i.e. fabricated reviews)], teaching the Al to recognize patterns associated with each outcome.” Fig. 2 and ¶71 shows “The moderation rules module 124 operates by parsing incoming review submissions (as received via the review submissions module 120) and matching the content therein against a database of the foregoing rules (not shown). Each rule within the framework is encoded with specific conditions [(i.e. fraudulence threshold. See also ¶¶34-37 showing converting the review to a numerical vector)] that review submissions may meet or avoid. For instance, rules may target the presence of certain keywords indicative of spam or hate speech, patterns suggesting fraudulent content, or the absence of elements that confirm the review's relevance to the product or service. This rules-based approach enables the moderation rules module 124 to categorize and flag reviews for further action based on predefined parameters.” ¶85 and ¶90 shows that the “moderation rules” can be adjusted based on further “learning.” Thus, the “moderation rules module 124” teaches the generated fraudulence threshold based on training data.), and
“wherein the classification model is finetuned using the fraudulence threshold” (The broadest reasonable interpretation of this limitation includes a “classification model” comprising “the fraudulence threshold,” wherein the “classification model” is “tuned” such that “the fraudulence threshold” within the “classification model” is “tuned” (i.e. “. . . using the fraudulence threshold”). See Specification ¶73. ¶158 shows “The dynamic feedback loop data 362 may capture feedback from the moderation outcomes to refine the machine learning models and update the moderation rules database. The data 362 may include data on reviews that were manually approved or declined post-AI moderation, providing a feedback mechanism that allows for the iterative tuning [(i.e. finetuned)] of algorithms and rules [(i.e. “moderation rules data 332” of ¶155, which teaches “the fraudulence threshold.”)] within the system, ensuring its relevance and effectiveness over time.” (Emphasis added).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 17, Jones in view of Murali and El Kaake teaches “The non-transitory computer-readable medium of claim 16,” as discussed above.
Jones further teaches “wherein determining that the interaction between the user and the entity is available for review comprises: determining the entity is an entity for which reviews are applicable; and determining that user interest of the user for submission of the review exceeds a threshold” (The broadest reasonable interpretation of being “available for review” includes being reviewable. As discussed above in greater detail, Fig. 3B-3C and ¶¶87-89 shows that “user 101” can “approve” or “reject” the payment request, such that approval creates “payment confirmation 360,” and the approval of payment teaches the determination that the interaction is reviewable. Fig. 3B shows:
PNG
media_image1.png
70
5
media_image1.png
Greyscale
.Thus, by approving payment for “Josh’s Stone and Landscaping” (i.e. entity), Jones teaches “determining the entity is an entity for which reviews are applicable,” under the broadest reasonable interpretation (e.g. if the payment was rejected a review for “Josh’s Stone and Landscaping” would not be applicable). Further, Fig. 3B, ¶¶87-89, and ¶117 presents the user with a binary choice to approve (“352A”) or reject (“352B”) the payment. Under the broadest reasonable interpretation of “user interest,” read in light of Specification ¶67, a person of ordinary skill in the art would understand that purchasing a service (i.e. approve 352A) represents an interest in reviewing that services, and not purchasing the service (i.e. reject 352B) represents a disinterest in reviewing that service. Further, the broadest reasonable interpretation of “exceeds a threshold,” includes a binary decision (e.g. reject=0, approve=1, and threshold=0.5). Thus, given its broadest reasonable interpretation, Jones teaches the recited limitation.).
Regarding Claim 18, Jones in view of Murali and El Kaake teaches “The non-transitory computer-readable medium of claim 17,” as discussed above.
Jones further teaches “wherein: determining the entity is an entity that for which reviews are applicable comprises inputting the first interaction data into a rule-based algorithm” (As discussed above in greater detail, Fig. 3B-3C and ¶¶87-89 shows that “user 101” can “approve” or “reject” the payment request, such that approval creates “payment confirmation 360,” and the approval of payment teaches the determination that the interaction is reviewable. The binary choice to approve (“352A”) or reject (“352B”) the payment (i.e. first interaction data), directly results in the determination of whether or not to present the user with the ability to review the service (i.e. determine reviewability). Because the binary payment choice follows a strict cause-and-effect logic, Jones teaches the use of a “rule-based algorithm” applied to the “first interaction data.”).
Regarding Claim 19, Jones in view of Murali and El Kaake teaches “The non-transitory computer-readable medium of claim 17,” as discussed above.
Jones and Murali do not explicitly teach, but El Kaake further teaches “wherein: determining that the user interest of the user for submission of the review exceeds the threshold comprises inputting the first interaction data into a trained machine learning model” (Fig. 4 and ¶¶174-79 shows “method 400” implemented with “system 100 of Figure 1” or “device 300 of Figure 3” includes the steps of “[410] Receiving review submissions from customers, initiated after each customer transaction,” “[420] Processing the received review submissions for the content,” “[430] Analyzing the processed review content to identify specific keywords, phrases, or patterns that correspond with predefined moderation categories,” “[440] Evaluating the review content against a set of moderation rules derived from legal and ethical guidelines, as well as business specific policies,” and “[450] Based on the evaluation, approving or declining the review submissions.” Fig. 2 and ¶71 shows “The moderation rules module 124 operates by parsing incoming review submissions (as received via the review submissions module 120) and matching the content therein against a database of the foregoing rules (not shown). Each rule within the framework is encoded with specific conditions [(i.e. fraudulence threshold. See ¶¶34-37 showing converting the review to a numerical vector. Thus, the condition teaches “exceeds the threshold”)] that review submissions may meet or avoid. For instance, rules may target the presence of certain keywords indicative of spam or hate speech, patterns suggesting fraudulent content, or the absence of elements that confirm the review's relevance to the product or service. This rules-based approach enables the moderation rules module 124 to categorize and flag reviews for further action based on predefined parameters.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine El Kaake with Jones and Murali because El Kaake teaches that authenticating reviews with a trained machine learning model improves the quality of the review depository (¶¶65-67). Thus, combining El Kaake with Jones and Murali furthers the interest taught in El Kaake, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over US-20220198501-A1 (“Jones”) in view of US-20160196566-A1 (“Murali”), WO-2025000074-A1 (“El Kaake” priority date of 06/29/2023), and US-20150213522-A1 “Gao”).
Regarding Claim 6, Jones in view of Murali and El Kaake teaches “The method of claim 1,” as discussed above.
Jones further teaches “wherein causing the first electronic application to prompt the user to enter second interaction data is performed a . . . time after the detected interaction” (Fig. 4C-4A, ¶96-97, and ¶115 shows that instead of transmitting “payment confirmation 360” and “customer review data 382” to “FI Computing System 13)” in “single response,” the “client device 102” can transmit “payment confirmation 360, along with customer identifier 328 and/or merchant identifier 338” (i.e. the detected interaction), before “client device 102” presents the user interface that receives the review data from “user 101” (i.e. prompt the user to enter second interaction data). Although ¶115 further teaches a “delay” (i.e. a time) “which may provide user 101 with additional time to consider the [review],” Jones does not explicitly teach that the “delay” includes a “predetermined time.”).
Jones, Murali, and El Kaake do not explicitly teach, but Gao teaches “. . . to prompt the user to enter second interaction data is performed a predetermined time after the detected interaction” (¶22 shows “After the user completes the purchase, or accepts or uses the purchased products, the server sends review invitation information to the client corresponding to the user, such as the user's mobile terminal, tablet, PC or other clients. The review invitation information sent to the client can be written review invitation information, audio review invitation information, and review invitation email. The client can provide review by directly replying to the review invitation information. In another embodiment of the present invention, the server can obtain the type of the operation record, preset a prompt time based on the type of the operation record; and send review invitation information to the corresponding client after the prompt time. For example, if the user purchased a food voucher [(i.e. detected interaction)], review invitation information can be sent to a corresponding client of the user two hours after the food voucher is used [(i.e. prompt user to enter second interaction data)]. If the user reserved a hotel room, review invitation information can be sent to a corresponding client of the user at noon of the day after checking in, or when the user checks out.” (Emphasis added). Because the time is “preset” Gao teaches a “predetermined time.” See also Fig. 5-8 for alternative embodiments.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gao with Jones, Murali, and El Kaake because Gao teaches that soliciting a review at a certain time can improve the quality of the reviews (¶4 and ¶8). Thus, combining Gao with Jones, Murali, and El Kaake furthers the interest taught in Gao, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Regarding Claim 7, Jones in view of Murali and El Kaake teaches “The method of claim 6,” as discussed above.
Jones, Murali, and El Kaake do not explicitly teach, but Gao teaches “wherein the predetermined time is determined based on the first interaction data” (¶22 shows “After the user completes the purchase, or accepts or uses the purchased products, the server sends review invitation information to the client corresponding to the user, such as the user's mobile terminal, tablet, PC or other clients. The review invitation information sent to the client can be written review invitation information, audio review invitation information, and review invitation email. The client can provide review by directly replying to the review invitation information. In another embodiment of the present invention, the server can obtain the type of the operation record, preset a prompt time based on the type of the operation record; and send review invitation information to the corresponding client after the prompt time. For example, if the user purchased a food voucher [(i.e. detected interaction)], review invitation information can be sent to a corresponding client of the user two hours after the food voucher is used [(i.e. prompt user to enter second interaction data)]. If the user reserved a hotel room, review invitation information can be sent to a corresponding client of the user at noon of the day after checking in, or when the user checks out.” (Emphasis added). Fig. 2 and ¶34 shows “The server can obtain the type of the operation record, and preset a prompt time based on the type of the operation record. Based on the prompt time, the server can automatically send review invitation information to the corresponding client after the user purchases a product, or accepts or uses the purchased products, prompting the user that he/she can provide review by directly replying to the review invitation information. The server can send review invitation information to the client by sending a text message to the user's mobile phone, or by instant messaging to a user's mobile terminal or computer through the server's official enterprise account.” Fig. 3 and ¶47 shows “In another embodiment of the present invention, the apparatus further includes a timing module 39 connected to the sending module 32, and the timing module is used for obtaining a type of the operation record; presetting a prompt time based on the type of the operation record; start timing to the prompt time; and initiating the sending module 32 to send review invitation information to a corresponding client based on the operation record after the timing.” Gao teaches that the duration of the prompt time (i.e. predetermined time) is based on the type of item purchased (i.e. first interaction data).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gao with Jones, Murali, and El Kaake because Gao teaches that soliciting a review at a certain time can improve the quality of the reviews (¶4 and ¶8). Thus, combining Gao with Jones, Murali, and El Kaake furthers the interest taught in Gao, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows:
US-20190034986-A1 (“Robinson”) shows training and use of a machine learning model to authentical reviews, i.e. identify fraudulent reviews.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW PARKER GOODMAN whose telephone number is (571) 272-5698. The examiner can normally be reached on Monday-Thursday from 9:30 AM ET to 6:00 PM ET. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Zimmerman, can be reached at telephone number (571) 272-4602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/MATTHEW PARKER GOODMAN/Examiner, Art Unit 3628
/MICHAEL P HARRINGTON/Primary Examiner, Art Unit 3628
Prosecution Insights