DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending and have been examined.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 8-12, and 16-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Poduval, US Patent Application Publication NO 2022/0358507.
Regarding claims 1, 8, and 15;
(Claim 1) A method, comprising:
obtaining, with at least one processor, a plurality of features associated with an instance,
See Poduval [0107] To generate the graphical transaction features, the feature generation engine 220 is configured to connect with the graph creation engine 220a (see, 306). More specifically, the feature generation engine 220 accesses the network graph of account holders and merchants. In the network graph, the account holders may be represented as the first nodes and the merchants may be represented as the second nodes, and relationships between the account holders and the merchants may be represented as edges. The term “relationship” herein may refer to a payment transaction performed between an account holder (e.g., the account holder 104) and a merchant (e.g., the merchant 106). In addition, the edges may be weighted or unweighted. The feature generation engine 220 is configured to generate the graphical transaction features from the network graph of account holders and merchants. In one example, the graphical transaction features may include hand-crafted transaction features.
wherein the plurality of features includes a first subset of the plurality of features associated with a first entity, a second subset of the plurality of features associated with a second entity, and a third subset of the plurality of features associated with each of the first entity and the second entity;
See Poduval Figure 4 – The various account holders and merchants read on the claim language. Wherein the plurality of features reads on the various possible account holder-merchant relationships and the subsets on a specific account holder-merchant relationship. Since the subsets can include combinations of account holder-merchant relationships this teaching reads on the 1st-3rd subsets and the 1st-2nd entities. For example the A1-M1 relationship can read on the a first subset of the plurality of features associated with a first entity; the A1-M2 relationship can read on a second subset of the plurality of features associated with a second entity; and the totality of the A1-M1&M2 relationship can read on a third subset of the plurality of features associated with each of the first entity and the second entity; see Equations 1-3 in paragraphs [0119-0122]; See also [0127] describing spend transactions, merchants, and features
[0119] As explained above, the processor 206 is configured to generate the graphical transaction features i.e., a group of the set of transaction features based, at least in part, on a network graph between an account holder 104 and a plurality of merchants interacted with the account holder 104 and a graph neural network (GNN). With reference to the FIG. 4, the processor 206 is configured to generate a network graph 402 of account holders (e.g., the account holder 104) and merchants (e.g., the merchant) at which the account holders transacted (i.e., performed payment transactions). The network graph 402 includes the account holders as the first nodes and the merchants as the second nodes. In addition, relationships between the first nodes and the second nodes are represented as edges. More specifically, an edge exists between a first node (e.g., account holder A1) and a second node (e.g., merchant M1) when the account holder A1 performed a payment transaction at the merchant M1.
[0125] The GBDT technique can be used for classification and regression problems. The gradient boosting decision tree-based model utilizes regression trees where a target variable can take continuous values (typically real numbers). For example, the target variable may be a likelihood of raising a chargeback by an account holder within a prediction period. Gradient boosting decisions trees are represented as a tree-like set of nodes forming a branch-like structure, in which each internal node represents a “test” on an attribute (e.g., if the age of a person is greater than or equal to 18), each branch represents the outcome of the test, and each leaf node represents a numerical score that is mapped to a class label (decision taken after computing all attributes). The paths from root node to leaf node represent classification rules. Gradient boosting decision trees may be used to reach a conclusion or predict an event or outcome given the input. In general, algorithms for constructing decision trees usually work top-down, by choosing a variable at each node or step that best splits the set of items or observations. Different algorithms use different metrics for measuring the best split, but these algorithms generally measure the homogeneity of the target value within the subset of observations. The metrics are applied to each candidate subset and the resulting values are combined (e.g., averaged) to provide a measure of the quality of the split. For example, an algorithm to make a locally optimal decision at each node or step with the goal of finding a global optimum (e.g., a greedy algorithm) is a common strategy for learning decision trees from training data (e.g., historical transaction data). Examples of gradient boosting decision trees include FastTree, XGBoost, AdaBoost, etc.
training, with the at least one processor, a plurality of machine learning models encapsulated in a single framework,
See Poduval [0085] The chargeback prediction engine 222 is configured to initially train the chargeback risk prediction model 226. During the training phase, the data pre-processing engine 218 is configured to access training data i.e., historical transaction data associated with a plurality of account holders from the transaction database 118. The historical transaction data further includes a plurality of transaction indicators corresponding to payment transactions performed between the plurality of account holders (e.g., the account holder 104) and the plurality of merchants (e.g., the merchant 106) within a period of time. The period of time may include 6 months, 12 months, 2 years, and the like.
by: providing, as input to a first machine learning model, the first subset of the plurality of features and, receiving as output from the first machine learning model, a plurality of first outputs;
See Poduval [0127] The training data used for the GBDT based classification model may include, but not limited to, transaction features of historical payment transactions performed by the plurality of account holders. The historical payment transactions may include payment transactions of a particular time interval (for example, 3 years). In an implementation, the transaction features may include spend transaction features represented as s1, s2, s3 . . . sn (see, 502). In another implementation, the transaction features may include merchant features represented as m1, m2, m3 . . . mn (see, 504). In yet another implementation, the transaction features may include fraud risk features represented as f1, f2, f3 . . . fn (see, 506). The various feature categories read on a subset of features, the gradient boosting decision tree (GBDT) model read on the machine learning model, and the resulting values (see [0125]) read on the plurality of first outputs. Since this analysis can be done on multiple subsets (e.g., the account-holder-merchant relationship, spend transaction features, merchant features, fraud risk features, this would read on the subsequent providing steps pertaining to 1st-3rd outputs.
[0125] The GBDT technique can be used for classification and regression problems. The gradient boosting decision tree-based model utilizes regression trees where a target variable can take continuous values (typically real numbers). For example, the target variable may be a likelihood of raising a chargeback by an account holder within a prediction period. Gradient boosting decisions trees are represented as a tree-like set of nodes forming a branch-like structure, in which each internal node represents a “test” on an attribute (e.g., if the age of a person is greater than or equal to 18), each branch represents the outcome of the test, and each leaf node represents a numerical score that is mapped to a class label (decision taken after computing all attributes). The paths from root node to leaf node represent classification rules. Gradient boosting decision trees may be used to reach a conclusion or predict an event or outcome given the input. In general, algorithms for constructing decision trees usually work top-down, by choosing a variable at each node or step that best splits the set of items or observations. Different algorithms use different metrics for measuring the best split, but these algorithms generally measure the homogeneity of the target value within the subset of observations. The metrics are applied to each candidate subset and the resulting values are combined (e.g., averaged) to provide a measure of the quality of the split. For example, an algorithm to make a locally optimal decision at each node or step with the goal of finding a global optimum (e.g., a greedy algorithm) is a common strategy for learning decision trees from training data (e.g., historical transaction data). Examples of gradient boosting decision trees include FastTree, XGBoost, AdaBoost, etc.
providing, as input to a second machine learning model, the second subset of the plurality of features and, receiving as output from the second machine learning model, a plurality of second outputs;
See Poduval [0125] The GBDT technique can be used for classification and regression problems. The gradient boosting decision tree-based model utilizes regression trees where a target variable can take continuous values (typically real numbers). For example, the target variable may be a likelihood of raising a chargeback by an account holder within a prediction period. Gradient boosting decisions trees are represented as a tree-like set of nodes forming a branch-like structure, in which each internal node represents a “test” on an attribute (e.g., if the age of a person is greater than or equal to 18), each branch represents the outcome of the test, and each leaf node represents a numerical score that is mapped to a class label (decision taken after computing all attributes). The paths from root node to leaf node represent classification rules. Gradient boosting decision trees may be used to reach a conclusion or predict an event or outcome given the input. In general, algorithms for constructing decision trees usually work top-down, by choosing a variable at each node or step that best splits the set of items or observations. Different algorithms use different metrics for measuring the best split, but these algorithms generally measure the homogeneity of the target value within the subset of observations. The metrics are applied to each candidate subset and the resulting values are combined (e.g., averaged) to provide a measure of the quality of the split. For example, an algorithm to make a locally optimal decision at each node or step with the goal of finding a global optimum (e.g., a greedy algorithm) is a common strategy for learning decision trees from training data (e.g., historical transaction data). Examples of gradient boosting decision trees include FastTree, XGBoost, AdaBoost, etc.
providing, as input to a third machine learning model, the third subset of the plurality of features and, receiving as output from the third machine learning model, a plurality of third outputs;
See Poduval [0125] The GBDT technique can be used for classification and regression problems. The gradient boosting decision tree-based model utilizes regression trees where a target variable can take continuous values (typically real numbers). For example, the target variable may be a likelihood of raising a chargeback by an account holder within a prediction period. Gradient boosting decisions trees are represented as a tree-like set of nodes forming a branch-like structure, in which each internal node represents a “test” on an attribute (e.g., if the age of a person is greater than or equal to 18), each branch represents the outcome of the test, and each leaf node represents a numerical score that is mapped to a class label (decision taken after computing all attributes). The paths from root node to leaf node represent classification rules. Gradient boosting decision trees may be used to reach a conclusion or predict an event or outcome given the input. In general, algorithms for constructing decision trees usually work top-down, by choosing a variable at each node or step that best splits the set of items or observations. Different algorithms use different metrics for measuring the best split, but these algorithms generally measure the homogeneity of the target value within the subset of observations. The metrics are applied to each candidate subset and the resulting values are combined (e.g., averaged) to provide a measure of the quality of the split. For example, an algorithm to make a locally optimal decision at each node or step with the goal of finding a global optimum (e.g., a greedy algorithm) is a common strategy for learning decision trees from training data (e.g., historical transaction data). Examples of gradient boosting decision trees include FastTree, XGBoost, AdaBoost, etc.
learning, based on the plurality of first outputs, the plurality of second outputs, and the plurality of third outputs, a plurality of first learnable weights associated with the plurality of first outputs, wherein the plurality of first learnable weights is applied to the plurality of first outputs to generate a plurality of first weighted outputs;
See Poduval [0129] The spend transaction features, the merchant features, and the fraud risk features are aggregated together along with a corresponding chargeback label to generate an aggregated vector with chargeback label 508 for training the chargeback risk prediction model 226.
[0120] In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in FIG. 4). In one example, the graphical transaction features for each merchant (e.g., the merchant) are generated based on the set of transaction indicators associated with the merchant. Mathematically, the graphical transaction features for the merchant M1 may be represented as:
Feature.sub.M1=[chargeback risk, fraud risk, average credit risk score . . . ] Eqn. (1)
[0121] Similarly, the graphical transaction features for the merchant M2 may be represented as:
Feature.sub.M2=[chargeback risk, fraud risk, average credit risk score . . . ] Eqn. (2)
learning, based on the plurality of first outputs, the plurality of second outputs, and the plurality of third outputs, a plurality of second learnable weights associated with the plurality of second outputs, wherein the plurality of second learnable weights is applied to the plurality of second outputs to generate a plurality of second weighted outputs;
See Poduval [0129] The spend transaction features, the merchant features, and the fraud risk features are aggregated together along with a corresponding chargeback label to generate an aggregated vector with chargeback label 508 for training the chargeback risk prediction model 226.
[0120] In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in FIG. 4). In one example, the graphical transaction features for each merchant (e.g., the merchant) are generated based on the set of transaction indicators associated with the merchant.
and learning, based on the plurality of first outputs, the plurality of second outputs, and the plurality of third outputs, a plurality of third learnable weights associated with the plurality of third outputs, wherein the plurality of third learnable weights is applied to the plurality of third outputs to generate a plurality of third weighted outputs;
See Poduval [0129] The spend transaction features, the merchant features, and the fraud risk features are aggregated together along with a corresponding chargeback label to generate an aggregated vector with chargeback label 508 for training the chargeback risk prediction model 226.
[0120] In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in FIG. 4). In one example, the graphical transaction features for each merchant (e.g., the merchant) are generated based on the set of transaction indicators associated with the merchant.
generating, with the at least one processor, based on the plurality of first weighted outputs, the plurality of second weighted outputs, and the plurality of third weighted outputs, a prediction for the instance; and
See Poduval [0124] FIG. 5 is an example representation 500 of a chargeback risk prediction model (e.g., chargeback risk prediction model 226), in accordance with an embodiment of the present disclosure. As mentioned above, the chargeback risk prediction model is configured to generate one or more chargeback risk probability scores for an account holder. The chargeback risk prediction model is a machine learning model or a neural network model. In one implementation, the chargeback risk prediction model is a gradient boosting decision tree (GBDT) based classification model. The GBDT techniques for training a model is a type of supervised learning used for machine-learning techniques. The supervised learning may be used to infer a function from labeled training data consisting of a set of training examples. In supervised learning, each training example is a pair consisting of an input object (typically a vector) and a desired output value.
[0129] The spend transaction features, the merchant features, and the fraud risk features are aggregated together along with a corresponding chargeback label to generate an aggregated vector with chargeback label 508 for training the chargeback risk prediction model 226.
providing, with the at least one processor, the prediction for the instance.
See Poduval [0124] FIG. 5 is an example representation 500 of a chargeback risk prediction model (e.g., chargeback risk prediction model 226), in accordance with an embodiment of the present disclosure. As mentioned above, the chargeback risk prediction model is configured to generate one or more chargeback risk probability scores for an account holder. The chargeback risk prediction model is a machine learning model or a neural network model. In one implementation, the chargeback risk prediction model is a gradient boosting decision tree (GBDT) based classification model. The GBDT techniques for training a model is a type of supervised learning used for machine-learning techniques. The supervised learning may be used to infer a function from labeled training data consisting of a set of training examples. In supervised learning, each training example is a pair consisting of an input object (typically a vector) and a desired output value.
Regarding claims 2, 9, and 16;
(Claim 2) The method of claim 1, wherein the obtaining, with the at least one processor, the plurality of features associated with the instance includes:
segmenting each feature of the plurality of features into one of the first subset, the second subset, and the third subset.
See Poduval [0125] The GBDT technique can be used for classification and regression problems. The gradient boosting decision tree-based model utilizes regression trees where a target variable can take continuous values (typically real numbers). For example, the target variable may be a likelihood of raising a chargeback by an account holder within a prediction period. Gradient boosting decisions trees are represented as a tree-like set of nodes forming a branch-like structure, in which each internal node represents a “test” on an attribute (e.g., if the age of a person is greater than or equal to 18), each branch represents the outcome of the test, and each leaf node represents a numerical score that is mapped to a class label (decision taken after computing all attributes). The paths from root node to leaf node represent classification rules. Gradient boosting decision trees may be used to reach a conclusion or predict an event or outcome given the input. In general, algorithms for constructing decision trees usually work top-down, by choosing a variable at each node or step that best splits the set of items or observations. Different algorithms use different metrics for measuring the best split, but these algorithms generally measure the homogeneity of the target value within the subset of observations. The metrics are applied to each candidate subset and the resulting values are combined (e.g., averaged) to provide a measure of the quality of the split. For example, an algorithm to make a locally optimal decision at each node or step with the goal of finding a global optimum (e.g., a greedy algorithm) is a common strategy for learning decision trees from training data (e.g., historical transaction data). Examples of gradient boosting decision trees include FastTree, XGBoost, AdaBoost, etc.
Regarding claims 3, 10, and 17;
(Claim 3) The method of claim 1, wherein the generating, with the at least one processor, based on the plurality of first weighted outputs, the plurality of second weighted outputs, and the plurality of third weighted outputs, the prediction for the instance includes:
See Poduval [0120] In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in FIG. 4). In one example, the graphical transaction features for each merchant (e.g., the merchant) are generated based on the set of transaction indicators associated with the merchant.
generating a first entity score by aggregating the first plurality of weighted outputs; generating a second entity score by aggregating the second plurality of weighted outputs; generating a shared entity score by aggregating the third plurality of weighted outputs;
See Poduval [0120] In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in FIG. 4). In one example, the graphical transaction features for each merchant (e.g., the merchant) are generated based on the set of transaction indicators associated with the merchant.
and generating, based on the first entity score, the second entity score, and the shared entity score, the prediction.
See Poduval [0124] FIG. 5 is an example representation 500 of a chargeback risk prediction model (e.g., chargeback risk prediction model 226), in accordance with an embodiment of the present disclosure. As mentioned above, the chargeback risk prediction model is configured to generate one or more chargeback risk probability scores for an account holder. The chargeback risk prediction model is a machine learning model or a neural network model. In one implementation, the chargeback risk prediction model is a gradient boosting decision tree (GBDT) based classification model. The GBDT techniques for training a model is a type of supervised learning used for machine-learning techniques. The supervised learning may be used to infer a function from labeled training data consisting of a set of training examples. In supervised learning, each training example is a pair consisting of an input object (typically a vector) and a desired output value.
Regarding claims 4, 11, and 17;
(Claim 4) The method of claim 1, wherein the prediction for the instance is provided with the plurality of first learnable weights, the plurality of second learnable weights, and the plurality of third learnable weights.
See Poduval [0120] In one embodiment, each edge is a weighted edge. For example, weight w1 represents the weight of the edge existing between the account holder A1 and the merchant M1. Similarly, weight w2 represents the weight of the edge existing between the account holder A1 and the merchant M2 (as shown in FIG. 4). In one example, the graphical transaction features for each merchant (e.g., the merchant) are generated based on the set of transaction indicators associated with the merchant.
Regarding claims 5, 12, and 18;
(Claim 5) The method of claim 1, wherein the instance includes a transaction between a payer account and a payee account in a real-time payment (RTP) network,
See Poduval [0052] In one non-limiting example (not in accordance with embodiments of the present disclosure), the account holder 104 opens a merchant application on the user device 126 and performs a payment transaction using the information of a primary account number (PAN) and/or a payment card associated therewith to purchase goods or services offered by a merchant (e.g., the merchant 106). After submitting a payment from the payment account associated with the payment card, a payment authorization request associated with the submitted payment is authorized in near real-time and the required funds associated with the payment are kept pending for the payment transaction. However, the actual transfer of funds from the payment account of the account holder 104 may take 2 to 3 business working days. In other words, it may take 2 to 3 business working days for the payment transaction to clear the account holder's payment account. The clearing information may include merchant information (such as merchant ID, merchant state, merchant country, etc.), card product type, e-commerce indicator, cross-border indicator, recurring transaction indicator, card present (CP)/card-not present (CNP) transaction indicator, etc. At this point, the account holder 104 has a period of time (for example, 180 days, etc.) during which the payment transaction can be disputed by the account holder 104. In some scenarios, it may be possible that the account holder 104 may dispute the payment transaction based on various reasons. In an example, the account holder 104 may be unsatisfied with the goods or services provided by the merchant 106. In another example, the account holder 104 may not recognize the purchase for which the funds have been debited from the payment account of the account holder 104. In yet another example, the account holder 104 may determine that the purchase for which the funds have been debited from the payment account of the account holder 104 is fraudulent.
wherein the first entity includes the payer account, wherein the second entity includes the payee account,
See Poduval [0052] In one non-limiting example (not in accordance with embodiments of the present disclosure), the account holder 104 opens a merchant application on the user device 126 and performs a payment transaction using the information of a primary account number (PAN) and/or a payment card associated therewith to purchase goods or services offered by a merchant (e.g., the merchant 106). After submitting a payment from the payment account associated with the payment card, a payment authorization request associated with the submitted payment is authorized in near real-time and the required funds associated with the payment are kept pending for the payment transaction. However, the actual transfer of funds from the payment account of the account holder 104 may take 2 to 3 business working days. In other words, it may take 2 to 3 business working days for the payment transaction to clear the account holder's payment account. The clearing information may include merchant information (such as merchant ID, merchant state, merchant country, etc.), card product type, e-commerce indicator, cross-border indicator, recurring transaction indicator, card present (CP)/card-not present (CNP) transaction indicator, etc.
wherein the prediction includes a probability that the transaction is a fraudulent and/or money laundering transaction,
See Poduval [0116] In one implementation, the chargeback risk prediction model 226 transmits the notification to the issuer server 108 based on the set of chargeback risk probability scores. In another implementation, the chargeback amount prediction model 228 transmits the notification to the issuer server 108 based on the set of chargeback risk levels. The issuer server 108 may further analyze the set of chargeback risk probability scores and the set of chargeback risk levels to perform one or more downstream prediction tasks (e.g., prediction of fraudulent payment transaction). In one implementation, the server system 200 is configured to transmit the set of chargeback risk probability scores and the set of chargeback risk levels associated with each of the plurality of account holders in the form of reports and insights to the issuer server 108. The reports are provided to the issuer server 108 to provide various recommendations to the issuer server 108 about the various account holders that are expected to raise chargeback claims in the future along with their expected chargeback claim amount.
and wherein the method further includes: automatically authorizing or automatically denying, with the at least one processor, based on the prediction, the transaction.
See Poduval [0042] More specifically, techniques disclosed herein enable determination of future chargeback requests in advance, thus enabling an issuing bank to take appropriate actions (for example, declining particular payment transactions that may result in chargeback) in advance.
[0117] In another implementation, the chargeback risk prediction model 226 transmits the notification based on the chargeback risk probability scores to the issuer server 108 in real-time via the network 112. For instance, if an account holder (e.g., the account holder 104) is performing a payment transaction with a merchant (e.g., the merchant 106) that is likely to experience the chargeback, the chargeback risk prediction model 226 routes the payment transaction along with the computed set of chargeback risk probability scores to the issuer server 108, thereby enabling the issuer server 108 to decline the payment transaction in real-time based on the computed set of chargeback risk probability scores.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 6, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Poduval as applied to claims 1-5, 8-12, and 16-18 above, and further in view of Srivastava, US Patent Application Publication NO 2020/0311808.
Regarding claims 6, 13, and 19;
Poduval does not teach this claim
SRIVASTAVA teaches:
(Claim 6) The method of claim 1, wherein the instance includes a credit application initiated by a customer with a merchant, wherein the first entity includes the customer, wherein the second entity includes the merchant,
See SRIVASTAVA [0073] Turning now to FIG. 6, further details of the seller blockchain node 108 of the merchant system 162 are described. The seller blockchain node 108 further comprises a credit broker application 176 that selects one of the plurality of loan approvals based on executing a credit broker rules set 177. In an embodiment, the credit broker application 176 obtains personal information on the customer, evaluates a plurality of loan approval responses associated with the customer that are output by executing the credit models, where the evaluation is conducted based on the credit broker rule set 177. The credit broker application 176 selects one of the loan approvals based on the evaluating and presents information to the customer 163 about the selected loan approval. For example, the credit broker application 176 presents information comprising the maximum loan amount and the loan validity time period of the selected loan approval. It is noted that the credit broker application 176 and the system 160, generally, enables making credit available to the customer 163 before the customer presents goods to be purchased at a point-of-sale (POS) station, for example at a POS station in a store of the merchant. The information may be presented via a mobile application (e.g., via a notification in the application), via email, via a web site, via a text message (e.g., SMS message or MMS message). The information may be presented via a kiosk, for example a kiosk located in a store of the merchant.
wherein the prediction includes an amount for which the credit application is approved, See SRIVASTAVA [0073] For example, the credit broker application 176 presents information comprising the maximum loan amount and the loan validity time period of the selected loan approval.
and wherein the method further includes: automatically approving, with the at least one processor, based on the prediction, the credit application for the amount.
See SRIVASTAVA [0073] Turning now to FIG. 6, further details of the seller blockchain node 108 of the merchant system 162 are described. The seller blockchain node 108 further comprises a credit broker application 176 that selects one of the plurality of loan approvals based on executing a credit broker rules set 177. In an embodiment, the credit broker application 176 obtains personal information on the customer, evaluates a plurality of loan approval responses associated with the customer that are output by executing the credit models, where the evaluation is conducted based on the credit broker rule set 177. The credit broker application 176 selects one of the loan approvals based on the evaluating and presents information to the customer 163 about the selected loan approval. For example, the credit broker application 176 presents information comprising the maximum loan amount and the loan validity time period of the selected loan approval. It is noted that the credit broker application 176 and the system 160, generally, enables making credit available to the customer 163 before the customer presents goods to be purchased at a point-of-sale (POS) station, for example at a POS station in a store of the merchant. The information may be presented via a mobile application (e.g., via a notification in the application), via email, via a web site, via a text message (e.g., SMS message or MMS message). The information may be presented via a kiosk, for example a kiosk located in a store of the merchant.
Motivation Statement
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the predictions of the primary reference, the ability to make a prediction concerning loan approvals as taught by SRIVASTAVA since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes predicting loan approvals increases the usability of the invention.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Poduval as applied to claims 1-5, 8-12, and 16-18 above, and further in view of Abdallah, US Patent Application Publication NO 2022/0092621.
Regarding claims 7, 14, and 20;
Poduval does not teach this claim
Abdallah teaches:
(Claim 7) The method of claim 1, wherein the instance includes a house price estimation for a house in a neighborhood,
See Abdallah [017] For example, the guided search system can use one or more machine learning techniques, such as neural networks, learning to rank, deep learning, etc. to train a model to predict a user's interaction based on, for example, past user interactions with filter criteria, other information about the user and the user's preferences (e.g., demographic information, location, past user interactions with search, interactions with other part of the information), other interactions of the users with the system, information about a geographic area and properties located there, etc.
[0033] While various filters have been used as examples herein, one of ordinary skill in the art will recognize that listings can be filtered according to any number of fields or attributes, including listing type, listing status, price (e.g., minimum and/or maximum), number of bedrooms (e.g., minimum and/or maximum), number of bathrooms (e.g., maximum and/or minimum), property type (e.g., house, apartment, condominium, duplex, townhome, barn, log cabin, houseboat, commercial, industrial), owners association fees (e.g., maximum and/or minimum), open house availability, 3D home availability, parking spaces (e.g., maximum and/or minimum), garage, square footage (e.g., maximum and/or minimum), lot size (e.g., maximum and/or minimum), year built (e.g., earliest and/or latest), basement status (e.g., finished or unfinished), basement type, number of stories (e.g., maximum and/or minimum), air conditioning, pool, waterfront, city view, park view, mountain view, water view, ocean front, lake front, frontage feet, ownership (e.g., current resident, property broker, property management company), number of days listed (e.g., maximum and/or minimum), allows large dogs, allows small dogs, allows cats, room for other animals (e.g., horses, cows, goats), in-unit laundry, whether or not the property owner/manager will take particular types of applications, whether or not there are income or other restrictions associated with the property. In some embodiments, the guided search system provides support for users wishing to filter search results based on parking type, neighborhood, city, state, ZIP code, borough, county, nearby school(s), school districts, school attendance zone, school ratings (e.g., elementary, middle, junior high, high), street, community, subdivision, building, other unofficial regional information, unofficial regional terms (e.g., Silicon Valley, Lake Tahoe, West Seattle, On Lake Washington), open houses, price changes, data retrieved from a multiple listing service (MLS), new construction availability date, senior housing, single story living, photo count, room count, territorial view, estimated monthly payment, student housing, tax assessed value, owner occupied, new construction available lot/plan count, new construction move in ready, new construction under construction, and so on. Furthermore, the filter criteria can relate to the presence (true or false), quantity, and/or size(s) of various features, such as attics, barbeque areas, ceiling fans, decks, doorkeepers, elevators, fenced yard, gardens, gated entries, greenhouses, hot tubs, spas, saunas, jacuzzies, intercoms, jetted tubs, lawns, mother-in-law apartments, ponds, porches, patios, skylights, sprinkler systems, sports courts, double pane windows, storm windows, wet bars, RV parking, security system, wired for cable, wired for high speed networking, satellite tv ready, high speed internet availability, vaulted ceilings, docks, basketball court, storage availability, tennis court, quarter baths, half baths, ¾ baths, full baths, fireplaces, breakfast nooks, dining rooms, family rooms, laundry rooms, libraries, master baths, mud rooms, offices, pantries, recreation rooms, workshops, solariums, atriums, sun rooms, walk-in closets, included appliances, floor covering, foundation type, fitness center proximity and availability, proximity to transportation options, and so on. In some embodiments, the guided search system provides support for filters that allow users to narrow search results based on Zestimates and other estimates of a home's market value or rental value, a home's forecasted value, forecasted valuations, architecture style, architecture type, year updated, roof type, primary exterior material, primary heating source, covered parking spaces, primary heating system, primary cooling system, swimming pool type, building shape type, construction quality type, construction type, garage carport location type, attic square feet, per floor square feet, lot depth, lot width, unit count, garage square feet, basement square feet (finished, unfinished), addition square feet, which floor a unit is on, whether or not the home is furnished, controlled access, 55-plus active community, assisted living community, maintenance fees, common charges, ADU (Accessory Dwelling Unit) status, handicapped access, and so on.
wherein the first entity includes the house, wherein the second entity includes the neighborhood, wherein the prediction includes an estimated price of the house,
See Abdallah [0033] In some embodiments, the guided search system provides support for filters that allow users to narrow search results based on Zestimates and other estimates of a home's market value or rental value, a home's forecasted value, forecasted valuations, architecture style, architecture type, year updated, roof type, primary exterior material, primary heating source, covered parking spaces, primary heating system, primary cooling system, swimming pool type, building shape type, construction quality type, construction type, garage carport location type, attic square feet, per floor square feet, lot depth, lot width, unit count, garage square feet, basement square feet (finished, unfinished), addition square feet, which floor a unit is on, whether or not the home is furnished, controlled access, 55-plus active community, assisted living community, maintenance fees, common charges, ADU (Accessory Dwelling Unit) status, handicapped access, and so on.
and wherein the method further includes: automatically controlling, with the at least one processor, based on the prediction, a display to display the estimated price of the house in a map of the neighborhood at a location of the house in the map.
See Abdallah Figure 6
[0029] FIG. 6 is a display page 600 illustrating a user interface for specifying filter criteria and displaying listings in accordance with some embodiments of the disclosed technology. In this example, display page 600 includes text box 620 for specifying a geographic area, map view 625 for selecting or specifying and displaying a geographic area, filter criteria specification user interface element 630 for specifying filter criteria, such as a number of bedrooms or a number of bathrooms, and results section 610 for displaying results of listings consistent with a user's search. In this example, the user has searched form homes in Seattle with any number of bedrooms and two or more bathrooms.
[0017] Accordingly, the inventors have conceived a software and/or hardware guided search system for suggesting and arranging filter criteria within an improved user interface (e.g., graphical user interface, textual user interface, audio or voice user interface, etc.) for presentation to a user to help guide the user's search for listings, such as real estate listings, listings for products and/or services, etc. In some embodiments, the guided search system initially receives, from a user, a selection of a geographic area, such as a selection of a ZIP code, postal code, municipality, county, state, or any combination thereof, and so on. As another example, the guided search system can identify a geographic area based on information received from a user, such as a geographic area bounded or defined by a user's selection of a number of coordinates, a center point and a radius, a selection of an area manually drawn by a user, a portion of a map zoomed in on (or out of) by a user, and so on
[0033] In some embodiments, the guided search system provides support for filters that allow users to narrow search results based on Zestimates and other estimates of a home's market value or rental value, a home's forecasted value, forecasted valuations, architecture style, architecture type, year updated, roof type, primary exterior material, primary heating source, covered parking spaces, primary heating system, primary cooling system, swimming pool type, building shape type, construction quality type, construction type, garage carport location type, attic square feet, per floor square feet, lot depth, lot width, unit count, garage square feet, basement square feet (finished, unfinished), addition square feet, which floor a unit is on, whether or not the home is furnished, controlled access, 55-plus active community, assisted living community, maintenance fees, common charges, ADU (Accessory Dwelling Unit) status, handicapped access, and so on.
Motivation Statement
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the predictions of the primary reference, the ability to make a prediction concerning housing pricing as taught by Abdullah since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes pricing houses increases the usability of the invention.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights