DETAILED ACTION
This final office action is in response to claims filed on 6/23/2025.
Claims 1, 8, 9, 11, and 16 have been amended.
Claims 1-20 are pending and have been examined.
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 .
Response to Applicant’s Arguments
35 U.S.C. 103
Applicant's arguments filed 06/23/2025 have been fully considered but they are not persuasive.
Hammad teaches the characteristics weighted score structure. Hammad derives multiple transaction risk types (characteristics) from historical fraud data and rules. The graduated security system (GSS) “identify a set of transaction risk types associated with the current transaction request, and may calculate a risk score associated with each of the transaction risk types (¶ 0037).” Assigns a risk score and a risk score weight for each risk type. Hammad states that the GSS “may determine a risk score associated with each risk type (¶ 0031)” and that “number of data points within each cluster may serve as an indicator of the magnitude of risk associated with the risk cluster, e.g., a risk score weight.” and that “The GSS may normalize a risk score weight for a cluster/risk type (e.g., by dividing the number of risk data points in a cluster) by: a total number of risk data points, a total number of transaction (non-risky, as well as risky), a total number of non-risky transactions that would also fall within the boundary surface of the cluster, etc (¶ 0045).”
Hammad and Sulur teaches displaying these elements in a GUI on a client. Hammad’s fraud reporting and wallet interfaces are explicitly delivered and displayed as HTML forms and pages on the client device: the server retrieves a “The pay gateway server may query a database, e.g., 504 b, for the fraud report form, e.g., 513-514, and mayprovide the fraud report form, e.g., 515, to the client… The client may display, e.g., 516, the fraud report form for the user (¶ 0043).” Suluf teaches processing transactions records “according to a risk-determination rule to determine a risk level. If the risk level exceeds a pre-determined threshold, the risk indicator may be communicated (¶ 0040)” and then associating a risk indicator with the transaction record and communicating the transaction record via an alert (Fig. 3, steps 306-320). The combination of Hammand and Sulur teaches presenting on a web/client display a GUI that shows characteristics of the transaction (non-compliance characteristics).
Hammad and Sulur also teaches the GUI real-time updates. Hammad continuously updates risk scores as new information or risk-allocation responses as received. To add, Ivanoff’s recalculation of PTP scores by different engines as new data is obtained.
Hammand and Ivanoff teach dynamically updating weights when characteristics change. Hammad teaches recalculating risk scores when the allocation of risk types or mitigation input changes “may recalculate the risk score associated with the risk type (¶ 0038)” and “calculate an updated risk score for the transaction risk type (¶ 0052).” Ivanoff’s scoring subsystem further reinforces the engine scoring system. Ivanoff teaches that different types of scores are produced by engines using different weightings of characteristics and the system selects and uses these scores in reporting data changes.
The newly amended claims are rejection as below.
Claim Rejections - 35 USC § 103
35 U.S.C. 103 reads as follows:
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.
Claims 1-9 and 11-19 are rejected under 35 USC § 103 as being unpatentable over Hammad et al. (US20130218765A1), hereinafter Hammad, and in view of Biedermann et al. (US20130046666A1), hereinafter Biedermann, and further in view of Ivanoff et al. (US20150193872A1), hereinafter Ivanoff and in further of view Sulur et al. (US20150199767A1), hereinafter Sulur.
Regarding Claims 1, 11, and 16. Hammad teaches:
a method, an article of manufacture including a non-transitory computer readable memory having instructions stored thereon that, in response to execution by a processor of a non-compliance engine, and a system comprising:
Hammad - A computer systemization 2302 may comprise a clock 2330, central processing unit (“CPU(s)” and/or “processor(s)”, a memory 2329 (e.g., a read only memory (ROM) 2306, a random access memory (RAM) 2305, etc.), and/or an interface bus 2307, and most frequently, although not necessarily, are all interconnected and/or communicating through a system bus 2304 on one or more (mother)board(s) 2302 having conductive and/or otherwise transportive circuit pathways through which instructions (e.g., binary encoded signals) may travel to effectuate communications, operations, storage, etc. The computer systemization may be connected to a power source 2386; e.g., optionally the power source may be internal (¶ 0136).
receiving, in real time, by a non-compliance engine over a computer network, from at least one gateway terminal a respective transaction among a plurality of transactions executed with the at least one gateway terminal, the plurality of transactions being associated with a user account and having transaction information,
Hammad - In some embodiments, the GSS may perform security checks before authorizing a transaction using an account from the user's virtual wallet. For example, the GSS may assess transaction risks associated with authorizing the transaction to be completed. For example, the GSS may identify one or more transaction risk types, and associated risk scores to each of the transaction risk types […] The GSS may require specific security protocols to be adopted depending on the transaction risk types. In some embodiments, the GSS may determine a risk score associated with each risk type, and modify the security protocols followed to authorize the transaction depending on the risk scores. For example, the GSS may determine a risk score for each risk type based on factors such as, without limitation: the type of the current transaction (e.g., user enrollment into a new request, purchase transaction, modifying user wallet settings, modifying privacy settings, accessing personal information), current user transaction request details, historical (including recent/real-time) user virtual wallet activity, historical fraud reporting data (e.g., including parameters correlated to fraudulent activity), responses to secure authentication requests, etc (¶ 0031).
determining, by the non-compliance engine, a set of non-compliance characteristics from a plurality of characteristics preconfigured in the non-compliance engine based at least in part on a level of transactional behavior configured for the user account,
Hammad - FIG. 6A depicts a 3-dimensional risk parameter plot space, which may be utilized to extract fraud detection rules using aggregated fraud reports from individual users (¶ 0044 and FIG. 6A). A restricted payment mode 1725 may be activated for certain purchase activities such as prescription purchases. The mode may be activated in accordance with rules defined by issuers, insurers, merchants, payment processor and/or other entities to facilitate processing of specialized goods and services. In this mode, the user may scroll down the list of forms of payments 1726 under the funds tab to select specialized accounts such as a flexible spending account (FSA) 1727, health savings account (HAS), and/or the like and amounts to be debited to the selected accounts. In one implementation, such restricted payment mode 1725 processing may disable social sharing of purchase information (¶ 0104).
wherein the user account is associated with an employee of an employer and the level of transactional behavior being determined is based at least in part on a set of rules of the employer;
Hammad - A restricted payment mode 1725 may be activated for certain purchase activities such as prescription purchases. The mode may be activated in accordance with rules defined by issuers, insurers, merchants, payment processor and/or other entities to facilitate processing of specialized goods and services. In this mode, the user may scroll down the list of forms of payments 1726 under the funds tab to select specialized accounts such as a flexible spending account (FSA) 1727, health savings account (HAS), and/or the like and amounts to be debited to the selected accounts. In one implementation, such restricted payment mode 1725 processing may disable social sharing of purchase information (¶ 0104). In one embodiment, the wallet mobile application may facilitate importing of funds via the import funds user interface 1728. For example, a user who is unemployed may obtain unemployment benefit fund 1729 via the wallet mobile application. In one implementation, the entity providing the funds may also configure rules for using the fund as shown by the processing indicator message 1730. The wallet may read and apply the rules prior, and may reject any purchases with the unemployment funds that fail to meet the criteria set by the rules. Example criteria may include, for example, merchant category code (MCC), time of transaction, location of transaction, and/or the like. As an example, a transaction with a grocery merchant having MCC 5411 may be approved, while a transaction with a bar merchant having an MCC 5813 may be refused (¶ 0105).
detecting, by the non-compliance engine, non-compliance characteristics from the set of non-compliance characteristics associated with the plurality of transactions based at least in part on the transaction information of the respective transaction, a first type of non- compliance transaction characteristic, and a second type of non-compliance transaction characteristic:
Hammad - FIG. 6A depicts a 3-dimensional risk parameter plot space, which may be utilized to extract fraud detection rules using aggregated fraud reports from individual users (¶ 0044 and FIG. 6A). In one embodiment, the wallet mobile application may facilitate importing of funds via the import funds user interface 1728. For example, a user who is unemployed may obtain unemployment benefit fund 1729 via the wallet mobile application. In one implementation, the entity providing the funds may also configure rules for using the fund as shown by the processing indicator message 1730. The wallet may read and apply the rules prior, and may reject any purchases with the unemployment funds that fail to meet the criteria set by the rules. Example criteria may include, for example, merchant category code (MCC), time of transaction, location of transaction, and/or the like. As an example, a transaction with a grocery merchant having MCC 5411 may be approved, while a transaction with a bar merchant having an MCC 5813 may be refused (¶ 0105).
generating, by the non-compliance engine, a value associated with each non- compliance characteristic of the set of non-compliance characteristics, wherein the value is based at least in part on at least one of a number or percentage associated with each non- compliance characteristic of the set of non-compliance characteristics;
Hammad - In some embodiments, the GSS may attempt to allocate the transaction risks associated with the current transaction request to one or more entities involved in the current transaction (e.g., user, merchant, issuer, acquirer, payment service processor, payment network, etc.). For example, the GSS may provide an offer to one or more of the entities to assume (a portion of) the risk type associated with the transaction, e.g., 219. For example, the GSS may offer a discount, rewards, incentive, bonus, future payout, reduced transaction fees, etc., in exchange for the entity assuming the risk specified in the offer. If any of the entities accept the offer to assume (a portion of) the risk type, then the GSS may recalculate the risk score associated with the risk type. If the risk score is acceptable, see 221, (e.g., lower than a maximum allowable risk threshold value for the risk type for the current transaction), then the GSS may authorize the transaction (assuming no other transaction risks are present that need to be mitigated) (¶ 0038). However, if a transaction risk type (e.g., risk types (iii), risk type 2 (112), risk type 3 (113)), has a higher risk score, then the GSS may escalate the protocols employed from security protocol set 1 to security protocol set 2 (103 b) (which may pose a higher burden to one of the entities involved in the transaction). Similarly, as the transaction risk score for a transaction risk type increase, the GSS may escalate the security protocol set for the entities involved in the transaction to security protocol set 3 (103 c) or security protocol set 4 (103 d). It is to be understood that different transaction risk types may be escalated at different values of risk scores associated with each of the risk types, either dependent on or independent of the escalation of security protocols (¶ 0033).
assigning, by the non-compliance engine, a weight to each non-compliance characteristic of the set of non-compliance characteristics, wherein the assigned weight to each non-compliance characteristic is associated with at least one of:
Hammad - The GSS may perform a Statistical Risk Analysis, e.g., 214, on the historical fraud data records to generate transaction risk assessment reference data points, rules, score weights, etc., e.g., 215. For example, the GSS may utilize a component such as the example Statistical Risk Analysis (“SRA”) component of FIGS. 6A-B to generate the transaction risk assessment reference data points, rules, score weights, etc. Using the current transaction request data, the user's historical virtual wallet activity, and historical fraud data-based transaction risk assessment reference data points, rules, score weights, etc., the GSS may identify a set of transaction risk types associated with the current transaction request, and may calculate a risk score associated with each of the transaction risk types, e.g. (¶ 0037).
flagging, in real time, by the non-compliance engine over the computer network, the respective transaction at the at least one gateway terminal based on the non-compliance score failing to meet a threshold; and
Hammad - If any of the entities accept the offer to assume (a portion of) the risk type, then the GSS may recalculate the risk score associated with the risk type. If the risk score is acceptable, see 221, (e.g., lower than a maximum allowable risk threshold value for the risk type for the current transaction), then the GSS may authorize the transaction (assuming no other transaction risks are present that need to be mitigated). If the risk score is not at an acceptably low level, then the GSS may select a set of security protocols for the entities involved in the transaction to engage in before authorizing the transaction, e.g., 222 (¶ 0038).
displaying, by the non-compliance engine via a display screen of the web client, the graphical user interface to display the set of non-compliance characteristics, the weighted value for each non-compliance score,
Hammad - The pay gateway server may query a database, e.g., 504 b, for the fraud report form, e.g., 513-514, and may provide the fraud report form, e.g., 515, to the client. For example, the pay gateway server may provide a HTML input form to the client. The client may display, e.g., 516, the fraud report form for the user. In some implementations, the user may provide fraud report form input into the client, e.g., 517, and the client may generate a fraud report data response, e.g., 518, for the pay gateway server. The pay gateway server may parse the fraud report data response and extract the data fields and their associated values, and generate a record for storage, e.g., 519, in a database (¶ 0043). The GSS may perform a Statistical Risk Analysis, e.g., 214, on the historical fraud data records to generate transaction risk assessment reference data points, rules, score weights, etc., e.g., 215. For example, the GSS may utilize a component such as the example Statistical Risk Analysis (“SRA”) component of FIGS. 6A-B to generate the transaction risk assessment reference data points, rules, score weights, etc. Using the current transaction request data, the user's historical virtual wallet activity, and historical fraud data-based transaction risk assessment reference data points, rules, score weights, etc (¶ 0037).
wherein the weighted value for each non-compliance characteristic being displayed at the graphical user interface is updated in real time based on a change of the set of non- compliance characteristics from the first type of non-compliance transaction characteristic to the second type of non-compliance transaction characteristic.
Hammad - GSS may calculate an updated risk score for the transaction risk type, e.g., 823. For example, the GSS may utilize a component such as the example Transaction Risk Assessment (“TRA”) component of FIG. 7. The GSS may compare the updated risk score to the predetermined maximum acceptable threshold risk value for the risk type in the current transaction, and determine whether the risk score has been lowered below the threshold (¶ 0052).
Hammad does not explicitly teach the following limitations:
the first type of non-compliance transaction characteristic or the second type of non-compliance transaction characteristic, wherein the first type of non-compliance transaction characteristic is assigned a higher weight than the weight assigned to the second type of non-compliance transaction characteristic;
generating, by the non-compliance engine, a weighted value for each non- compliance characteristic of the set of non-compliance characteristics, based at least in part on the weight assigned to each non-compliance characteristic and the value associated with each non-compliance characteristic;
generating, by the non-compliance engine, a compliance score based on the weighted value generated for each non-compliance characteristic of the set of non-compliance characteristics; and
However, Biedermann teaches:
the first type of non-compliance transaction characteristic or the second type of non-compliance transaction characteristic, wherein the first type of non-compliance transaction characteristic is assigned a higher weight than the weight assigned to the second type of non-compliance transaction characteristic;
Biedermann - For example, a customer may be associated with historical data including a history of late mortgage payments and historical data including a value of money held in an investment account. The system may assign a lower weight to the historical data of late mortgage payments than to the historical data of the value of money held in the investment account. Because of the higher weight assigned to the historical data of the value of money held in the investment account, the customer may be identified as having the requisite customer-provider relationship (¶ 0048).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann because doing so allows an organization policy to indicate a stronger indicator of noncompliance for delinquent behavioral characteristics.
The combination of Hammad and Biedermann does not explicitly teach the following limitations:
generating, by the non-compliance engine, a weighted value for each non- compliance characteristic of the set of non-compliance characteristics, based at least in part on the weight assigned to each non-compliance characteristic and the value associated with each non-compliance characteristic;
generating, by the non-compliance engine, a compliance score based on the weighted value generated for each non-compliance characteristic of the set of non-compliance characteristics; and
However, Ivanhoff teaches:
generating, by the non-compliance engine, a weighted value for each non- compliance characteristic of the set of non-compliance characteristics, based at least in part on the weight assigned to each non-compliance characteristic and the value associated with each non-compliance characteristic;
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N (¶ 0145). Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above (¶ 0154).
generating, by the non-compliance engine, a compliance score based on the weighted value generated for each non-compliance characteristic of the set of non-compliance characteristics; and
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N (¶ 0145). Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above (¶ 0154).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff because doing so allows an organization to determine payments of a future guarantor based on historical payment behaviors.
transmitting, by the non-compliance engine via a wireless communication channel when a web client is offline, an alert to the web client
Note – Sulur teaches the “offline” part of the limitation by showing server 140 storing transaction records 164 in storage device 123 (¶ 0026). It would have been obvious to buffer the alert until the web client is reconnected.
Sulur - client 115 (web client) may include…any other suitable device (wireless, wireline, or otherwise)…capable of receiving…information (¶ 0023). User 135 may utilize client 115 to interact with server 140 to receive transaction record 164 via alert 195… server 140 may communicate alert 195 in response to a request from user 135 (or) pre-configured criteria may cause server 140 to communicate alert 195 (¶ 0024).
indicating the respective transaction is accessible by the web client,
Sulur - Server 140 may communicate transaction record 164 to user 135 utilizing client 115 (¶ 0023). User 135 may utilize client 115 to interact with server 140 to receive transaction record 164 via alert 195 (¶ 0024).
wherein the alert causes the non-compliance engine to launch a graphical user interface on the web client;
Sulur - In some embodiments, client 115 may include a graphical user interface (GUI) 180… GUI 180 may provide user 135 with an efficient and user-friendly presentation of transaction record 164 (¶ 0025). alert 195 may be communicated to a display or other user interface…one or more servers 140 may provide alert 195 to user 135 by utilizing client 115 (¶ 0035).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the alert presentation features of Sulur because doing allows users to quickly review risky transactions in a standard presentation and improve investigation workflow.
Regarding Claims 2 and 12. The combination of Hammad, Biedermann, Ivanhoff, and Sulur teaches the method of claim 1 and the article of manufacture of claim 11. The combination of Hammad, Biedermann, Ivanhoff, and Sulur further teaches:
wherein the set of non-compliance characteristics comprises at least one of a returned check, a late payment charge, or a late credit payment, and wherein the compliance score is a delinquent score.
Ivanoff - The historical healthcare transaction data 525A may include PTP characteristics of guarantors, which may include, but are not limited to, time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), and so on (¶ 0134).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the alert presentation features of Sulur because doing allows users to quickly review risky transactions in a standard presentation and improve investigation workflow.
Regarding Claims 3, 13, and 17. The combination of Hammad, Biedermann, Ivanhoff, and Sulur teaches the method of claim 1, the article of manufacture of claim 12, and the system of claim 16. The combination of Hammad, Biedermann, Ivanoff, and Sulur further teaches:
wherein the value is a non-compliance characteristic value, wherein the weighted value is a non-compliance characteristic weighted value, and wherein the compliance score is a consumer-level non-compliance score, wherein the method further comprises: combining, by the non-compliance engine, the respective non-compliance characteristic weighted values associated with a single transaction of the plurality of transactions; and
Ivanhoff - As disclosed above, a PTP score refers to a PTP metric, which may be derived, in part, from data acquired from the data sources 116A-N and, in particular, to billing and/or payment transaction records 214, 216. The application tier 140 may comprise a scoring subsystem 144 configured to generate PTP scores. In some embodiments, the scoring subsystem 144 is configured to generate different types of PTP scores based on a “stage” of an account (e.g., account's status within the client provider's billing system, such as pre-A/R, NR, bad debt, etc.) (¶ 0118). The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N (¶ 0145). Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above (¶ 0154).
producing, by the non-compliance engine, a transaction-level non-compliance score in response to the combining the respective non-compliance characteristic weighted values associated with the single transaction of the plurality of transactions.
Ivanhoff - As disclosed above, a PTP score refers to a PTP metric, which may be derived, in part, from data acquired from the data sources 116A-N and, in particular, to billing and/or payment transaction records 214, 216. The application tier 140 may comprise a scoring subsystem 144 configured to generate PTP scores. In some embodiments, the scoring subsystem 144 is configured to generate different types of PTP scores based on a “stage” of an account (e.g., account's status within the client provider's billing system, such as pre-A/R, NR, bad debt, etc.) (¶ 0118). The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N (¶ 0145). Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above (¶ 0154).
wherein the set of non-compliance characteristics comprises a transaction associated with at least one of an unauthorized or suspicious merchant, a personal expense, a disallowed geographic location, late-night hours, a retail purchase, a cash withdrawal, or an expensed refund,
Sulur - As examples, user 135 may request transaction records 164 associated with a particular customer, transaction records 164 associated with a particular time period, and/or transaction records 164 associated with potentially suspicious activity (e.g., based on monetary amount, location, transaction frequency, risk level, and/or other criteria) (¶ 0024). An example of a risk-determination rule may be to determine whether transaction record 164 indicates that the selected transaction is associated with potentially suspicious activity based on dollar amount, location, relationship to other potentially suspicious transactions, or other criteria (¶ 0040).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the transaction risk determination for suspicious activity in Sulur because doing so allows the determination of high risk transactions because of suspicious activity.
Regarding Claim 4. The combination of Hammad Biedermann, Ivanhoff, and Sulur teaches the method of claim 3. The combination of Hammad Biedermann, Ivanhoff, and Sulur further teaches: comprising at least one of: determining, by the non-compliance engine, whether the consumer-level non- compliance score is above a consumer-level non-compliance score threshold; or determining, by the non-compliance engine, whether the transaction-level non- compliance score is above a transaction-level non-compliance score threshold.
Sulur - For example, application 162 may process transaction record 164 according to a risk-determination rule to determine a risk level. If the risk level exceeds a pre-determined threshold, the risk indicator may be communicated (¶ 0040).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the alert presentation features of Sulur because doing allows users to quickly review risky transactions in a standard presentation and improve investigation workflow.
Regarding Claims 5, 14, and 18. The combination of Hammad, Biedermann, Ivanhoff, and Sulur teaches the method of claim 1, the article of manufacture of claim 11, and the system of claim 16. The combination of Hammad, Biedermann, Ivanhoff, and Sulur further teaches: analyzing, by the non-compliance engine, transaction information associated with a first transaction of the plurality of transactions for the first type of non-compliance transaction characteristic or the second type of non-compliance transaction characteristic;
Hammad - For example, the GSS may detect an unusual and/or suspicious transaction. The GSS may utilize the VerifyChat feature to communicate with the user, and verify the authenticity of the originator of the purchase transaction. In various implementations, the GSS may send electronic mail message, text (SMS) messages, Facebook® messages, Twitter™ tweets, text chat, voice chat, video chat (e.g., Apple FaceTime), and/or the like to communicate with the user (¶ 0128). In some embodiments, the GSS may perform security checks before authorizing a transaction using an account from the user's virtual wallet. For example, the GSS may assess transaction risks associated with authorizing the transaction to be completed. For example, the GSS may identify one or more transaction risk types, and associated risk scores to each of the transaction risk types (¶ 0031).
assigning, by the non-compliance engine, a critical weight to the first type of non- compliance transaction characteristic and a peripheral weight to the second type of non- compliance transaction characteristic;
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N. The regression analysis models 523A-N may comprise PTP statistical modeling data pertaining to sets of account records 212 (e.g., accounts in particular stages 0-4). The regression analysis models 523A-N may, therefore, correspond to different variable and/or data weighting values for the PTP data 525A-N based on, inter alia, statistical estimation and/or modeling processes within the respective account record sets. Accordingly, the PTP scores 518 generated by the PTP engines 522A-N may differ significantly despite incorporating similar sets of PTP data 525A-N (¶ 0145).
applying, by the non-compliance engine, at least one of the critical weight to the critical characteristic value, or the peripheral weight to the peripheral characteristic value;
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N. The regression analysis models 523A-N may comprise PTP statistical modeling data pertaining to sets of account records 212 (e.g., accounts in particular stages 0-4). The regression analysis models 523A-N may, therefore, correspond to different variable and/or data weighting values for the PTP data 525A-N based on, inter alia, statistical estimation and/or modeling processes within the respective account record sets. Accordingly, the PTP scores 518 generated by the PTP engines 522A-N may differ significantly despite incorporating similar sets of PTP data 525A-N (¶ 0145).
producing, by the non-compliance engine, a first transaction-level non-compliance score in response to the applying the at least one of the critical weight to the critical characteristic value, or the peripheral weight to the peripheral characteristic value; and
Ivanhoff - Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history (¶ 0154).
detecting, by the non-compliance engine, at least one of the first type of non- compliance transaction characteristic or the second type of non-compliance transaction characteristic in the transaction information associated with the first transaction;
Sulur - Application 162 communicates transaction record 164 in any suitable format. In some embodiments, application 162 communicates transaction record 164 via alert 195. Alert 195 may comprise one or more transaction records 164 associated with the customer and/or one or more risk indicators (e.g., based on suspicious activity, financial crimes, corruption, and/or economic sanctions compliance information) associated with one or more transaction records 164. In certain embodiments, alert 195 can have a standardized format comprising standardized fields. Moreover, alert 195 may be communicated to a display or other user interface, or it can be communicated to a downstream processor. For example, one or more servers 140 may provide alert 195 to user 135 by utilizing client 115. In some embodiments, user 135 may utilize client 115 to receive alert 195. For example, application 162 may communicate alert 195 in response to user 135 requesting one or more transaction records 164 associated with the customer (¶0039).
flagging, by the non-compliance engine, the first transaction with at least one of a critical flag in response to detecting the first type of non-compliance transaction characteristic, or a peripheral flag in response to detecting a peripheral second type of non- compliance transaction characteristic;
Sulur - Application 162 communicates transaction record 164 in any suitable format. In some embodiments, application 162 communicates transaction record 164 via alert 195. Alert 195 may comprise one or more transaction records 164 associated with the customer and/or one or more risk indicators (e.g., based on suspicious activity, financial crimes, corruption, and/or economic sanctions compliance information) associated with one or more transaction records 164. In certain embodiments, alert 195 can have a standardized format comprising standardized fields. Moreover, alert 195 may be communicated to a display or other user interface, or it can be communicated to a downstream processor. For example, one or more servers 140 may provide alert 195 to user 135 by utilizing client 115. In some embodiments, user 135 may utilize client 115 to receive alert 195. For example, application 162 may communicate alert 195 in response to user 135 requesting one or more transaction records 164 associated with the customer (¶0039).
calculating, by the non-compliance engine, at least one of a critical characteristic value associated with the at least one of the first type of non-compliance transaction characteristic or a peripheral characteristic value associated with the at least one of the second type of non-compliance transaction characteristic;
Sulur - In some embodiments, monitoring module 406 determines whether transaction record 164 should be communicated to downstream processes for monitoring, marketing, or other similar purposes. Monitoring module 406 may determine to communicate transaction record 164 in response to pre-configured criteria. For example, if a risk indicator is associated with transaction record 164, pre-configured criteria may cause monitoring module 406 to determine a risk score for transaction record 164. A risk score may be based on a formula that includes transaction record 164 as an input. Monitoring module 406 and/or user 135 may then use the score to evaluate the risk. If the risk score exceeds a pre-determined risk threshold, transaction record 164 may be communicated to notification module 407 for downstream processing (e.g., investigative analysis of transaction record 164) (¶ 0067).
determining, by the non-compliance engine, whether the first transaction-level non- compliance score is above a transaction-level non-compliance score threshold.
Sulur - In some embodiments, monitoring module 406 determines whether transaction record 164 should be communicated to downstream processes for monitoring, marketing, or other similar purposes. Monitoring module 406 may determine to communicate transaction record 164 in response to pre-configured criteria. For example, if a risk indicator is associated with transaction record 164, pre-configured criteria may cause monitoring module 406 to determine a risk score for transaction record 164. A risk score may be based on a formula that includes transaction record 164 as an input. Monitoring module 406 and/or user 135 may then use the score to evaluate the risk. If the risk score exceeds a pre-determined risk threshold, transaction record 164 may be communicated to notification module 407 for downstream processing (e.g., investigative analysis of transaction record 164) (¶ 0067).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the transaction risk determination for suspicious activity in Sulur because doing so allows the determination of high risk transactions because of suspicious activity.
Regarding Claim 6. The combination of Hammad, Biedermann, Ivanhoff and Sulur teaches the method of claim 5. The combination of Hammad, Biedermann, Ivanhoff and Sulur further teaches: The method of claim 5, further comprising: analyzing, by the non-compliance engine, second transaction information of the plurality of transactions for a first respective type of non-compliance transaction characteristic and a second respective type of non-compliance transaction characteristic;
Hammad - For example, the GSS may detect an unusual and/or suspicious transaction. The GSS may utilize the VerifyChat feature to communicate with the user, and verify the authenticity of the originator of the purchase transaction. In various implementations, the GSS may send electronic mail message, text (SMS) messages, Facebook® messages, Twitter™ tweets, text chat, voice chat, video chat (e.g., Apple FaceTime), and/or the like to communicate with the user (¶ 0128). In some embodiments, the GSS may perform security checks before authorizing a transaction using an account from the user's virtual wallet. For example, the GSS may assess transaction risks associated with authorizing the transaction to be completed. For example, the GSS may identify one or more transaction risk types, and associated risk scores to each of the transaction risk types (¶ 0031).
detecting, by the non-compliance engine, at least one of the first respective type of non- compliance characteristic or the second respective type of non-compliance characteristic in the second transaction information associated with the second transaction;
Sulur - Application 162 communicates transaction record 164 in any suitable format. In some embodiments, application 162 communicates transaction record 164 via alert 195. Alert 195 may comprise one or more transaction records 164 associated with the customer and/or one or more risk indicators (e.g., based on suspicious activity, financial crimes, corruption, and/or economic sanctions compliance information) associated with one or more transaction records 164. In certain embodiments, alert 195 can have a standardized format comprising standardized fields. Moreover, alert 195 may be communicated to a display or other user interface, or it can be communicated to a downstream processor. For example, one or more servers 140 may provide alert 195 to user 135 by utilizing client 115. In some embodiments, user 135 may utilize client 115 to receive alert 195. For example, application 162 may communicate alert 195 in response to user 135 requesting one or more transaction records 164 associated with the customer (¶0039).
flagging, by the non-compliance engine, the second transaction with at least one of a second critical flag in response to detecting the first type of non-compliance transaction characteristic, or a second peripheral flag in response to detecting a peripheral second type of non- compliance transaction characteristic;
Sulur - Application 162 communicates transaction record 164 in any suitable format. In some embodiments, application 162 communicates transaction record 164 via alert 195. Alert 195 may comprise one or more transaction records 164 associated with the customer and/or one or more risk indicators (e.g., based on suspicious activity, financial crimes, corruption, and/or economic sanctions compliance information) associated with one or more transaction records 164. In certain embodiments, alert 195 can have a standardized format comprising standardized fields. Moreover, alert 195 may be communicated to a display or other user interface, or it can be communicated to a downstream processor. For example, one or more servers 140 may provide alert 195 to user 135 by utilizing client 115. In some embodiments, user 135 may utilize client 115 to receive alert 195. For example, application 162 may communicate alert 195 in response to user 135 requesting one or more transaction records 164 associated with the customer (¶0039).
calculating, by the non-compliance engine, at least one of a second critical characteristic value associated with the at least one of the first respective type of non-compliance transaction characteristic or a second peripheral characteristic value associated with the second respective type of non-compliance transaction characteristic;
Sulur - In some embodiments, monitoring module 406 determines whether transaction record 164 should be communicated to downstream processes for monitoring, marketing, or other similar purposes. Monitoring module 406 may determine to communicate transaction record 164 in response to pre-configured criteria. For example, if a risk indicator is associated with transaction record 164, pre-configured criteria may cause monitoring module 406 to determine a risk score for transaction record 164. A risk score may be based on a formula that includes transaction record 164 as an input. Monitoring module 406 and/or user 135 may then use the score to evaluate the risk. If the risk score exceeds a pre-determined risk threshold, transaction record 164 may be communicated to notification module 407 for downstream processing (e.g., investigative analysis of transaction record 164) (¶ 0067).
applying, by the non-compliance engine, the at least one of the critical weight to the first respective type of non-compliance characteristic, or the peripheral weight to the peripheral weight to the second respective type of non-compliance characteristic;
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N. The regression analysis models 523A-N may comprise PTP statistical modeling data pertaining to sets of account records 212 (e.g., accounts in particular stages 0-4). The regression analysis models 523A-N may, therefore, correspond to different variable and/or data weighting values for the PTP data 525A-N based on, inter alia, statistical estimation and/or modeling processes within the respective account record sets. Accordingly, the PTP scores 518 generated by the PTP engines 522A-N may differ significantly despite incorporating similar sets of PTP data 525A-N (¶ 0145).
producing, by the non-compliance engine, a second transaction-level non-compliance score in response to the applying the at least one of the critical weight to the first respective type of non-compliance characteristic, or the peripheral weight to the second respective type of non-compliance characteristic; and
Ivanhoff - Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history (¶ 0154).
determining, by the non-compliance engine, whether the second transaction-level non- compliance score is above the transaction-level non-compliance score threshold.
Sulur - In some embodiments, monitoring module 406 determines whether transaction record 164 should be communicated to downstream processes for monitoring, marketing, or other similar purposes. Monitoring module 406 may determine to communicate transaction record 164 in response to pre-configured criteria. For example, if a risk indicator is associated with transaction record 164, pre-configured criteria may cause monitoring module 406 to determine a risk score for transaction record 164. A risk score may be based on a formula that includes transaction record 164 as an input. Monitoring module 406 and/or user 135 may then use the score to evaluate the risk. If the risk score exceeds a pre-determined risk threshold, transaction record 164 may be communicated to notification module 407 for downstream processing (e.g., investigative analysis of transaction record 164) (¶ 0067).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the alert presentation features of Sulur because doing allows users to quickly review risky transactions in a standard presentation and improve investigation workflow.
Regarding Claim 7. The combination of Hammad, Biedermann, Ivanhoff, and Sulur teaches the method of claim 6. The combination of Hammad, Biedermann, Ivanhoff, and Sulur further teaches: combining, by the non-compliance engine, the first transaction-level non-compliance score and the second transaction-level non-compliance score to produce a consumer-level non-compliance score; and determining, by the non-compliance engine, whether the consumer-level non- compliance score is above a consumer-level non-compliance score threshold.
Ivanoff - Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history (¶ 0154).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the alert presentation features of Sulur because doing allows users to quickly review risky transactions in a standard presentation and improve investigation workflow.
Regarding Claim 8. The combination of Hammad, Biedermann, Ivanhoff, and Sulur teaches the method of claim 7. The combination of Hammad, Biedermann, Ivanhoff, and Sulur further teaches: combining, by the non-compliance engine, the consumer-level non-compliance score and the compliance score to produce an overall consumer compliance score; and determining, by the non-compliance engine, whether the overall consumer compliance score is above an overall consumer score threshold.
Ivanoff - Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history (¶ 0154).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the alert presentation features of Sulur because doing allows users to quickly review risky transactions in a standard presentation and improve investigation workflow.
Regarding Claims 9, 15 and 19. The combination of Hammad, Biedermann, Ivanhoff and Sulur teaches the method of claim 1, the article of manufacture of claim 11 and the system of claim 16. The combination of Hammad, Biedermann, Ivanhoff and Sulur further teaches: determining, by the non-compliance engine, a first spending type of a first transaction of the plurality of transactions;
Sulur - In some embodiments, monitoring module 406 determines whether transaction record 164 should be communicated to downstream processes for monitoring, marketing, or other similar purposes. Monitoring module 406 may determine to communicate transaction record 164 in response to pre-configured criteria. For example, if a risk indicator is associated with transaction record 164, pre-configured criteria may cause monitoring module 406 to determine a risk score for transaction record 164. A risk score may be based on a formula that includes transaction record 164 as an input. Monitoring module 406 and/or user 135 may then use the score to evaluate the risk. If the risk score exceeds a pre-determined risk threshold, transaction record 164 may be communicated to notification module 407 for downstream processing (e.g., investigative analysis of transaction record 164) (¶ 0067).
detecting, by the non-compliance engine, a parameter associated with the first spending type in the transaction information of the first transaction;
Sulur - Application 162 communicates transaction record 164 in any suitable format. In some embodiments, application 162 communicates transaction record 164 via alert 195. Alert 195 may comprise one or more transaction records 164 associated with the customer and/or one or more risk indicators (e.g., based on suspicious activity, financial crimes, corruption, and/or economic sanctions compliance information) associated with one or more transaction records 164. In certain embodiments, alert 195 can have a standardized format comprising standardized fields. Moreover, alert 195 may be communicated to a display or other user interface, or it can be communicated to a downstream processor. For example, one or more servers 140 may provide alert 195 to user 135 by utilizing client 115. In some embodiments, user 135 may utilize client 115 to receive alert 195. For example, application 162 may communicate alert 195 in response to user 135 requesting one or more transaction records 164 associated with the customer (¶0039).
determining, by the non-compliance engine, a parameter value of the parameter; assigning, by the non-compliance engine, a parameter weight to the parameter;
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N. The regression analysis models 523A-N may comprise PTP statistical modeling data pertaining to sets of account records 212 (e.g., accounts in particular stages 0-4). The regression analysis models 523A-N may, therefore, correspond to different variable and/or data weighting values for the PTP data 525A-N based on, inter alia, statistical estimation and/or modeling processes within the respective account record sets. Accordingly, the PTP scores 518 generated by the PTP engines 522A-N may differ significantly despite incorporating similar sets of PTP data 525A-N (¶ 0145).
applying, by the non-compliance engine, the parameter weight to the parameter value;
Ivanhoff - The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N. The regression analysis models 523A-N may comprise PTP statistical modeling data pertaining to sets of account records 212 (e.g., accounts in particular stages 0-4). The regression analysis models 523A-N may, therefore, correspond to different variable and/or data weighting values for the PTP data 525A-N based on, inter alia, statistical estimation and/or modeling processes within the respective account record sets. Accordingly, the PTP scores 518 generated by the PTP engines 522A-N may differ significantly despite incorporating similar sets of PTP data 525A-N (¶ 0145).
producing, by the non-compliance engine, a parameter score based on the applying the parameter weight to the parameter value;
Ivanhoff - Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history (¶ 0154).
producing, by the non-compliance engine, a spending score based on the parameter score; and determining, by the non-compliance engine, when the spending score is above a spending score threshold.
Ivanhoff - Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history (¶ 0154).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the transaction risk determination for suspicious activity in Sulur because doing so allows the determination of high risk transactions because of suspicious activity.
Claim 10 is rejected under 35 USC § 103 as being unpatentable over Hammad, and in view of Biedermann, and further in view of Ivanoff and in further view of Sulur and in further view of Vance et al. (US20060212321A1), hereinafter Vance.
Regarding Claim 10. The combination of Hammad, Biedermann, Ivanhoff, and Sulur teaches the method of claim 9.
The combination of Hammad, Biedermann, Ivanhoff, and Sulur does not explicity teach the following limitation:
wherein the first spending type is at least one of air travel and the parameter is at least one of booking time, cost per mile, or airline;
ground travel and the parameter value is at least one of booking time, cost per trip, or travel company; hotel and the parameter weight is at least one of booking time, average rate, and duration; or food and beverage and the parameter score is at least one of average daily spend or average meal rate.
However, Vance teaches:
wherein the first spending type is at least one of air travel and the parameter is at least one of booking time, cost per mile, or airline;
Vance - The vendor chain analysis process 252 imports data from the trip table 128, the chain codes table 212, the accounting periods table 172 and the calendar year table 248 and provides an analysis of the booked plus actual activity for a specific date range for a given hotel or car chain. The output includes a total transaction count for number of room/nights or car/days plus a summary of the dollar value of each transaction as well as an average room/car nights per booking and average daily rates (¶ 0061). Now referring to FIG. 8, a detailed block diagram of the pre-trip management 74 of FIG. 3 is pictured. The analyze vendor goal share process 232 imports data from the local car table 116, the airline agreements table 200, the local property table 114, and the trip table 128. The analyze vendor goal share process 232 analyzes each preferred airline vendor on a specified city pair and divides the number of segments booked on that airline by the total number of segments booked and compares the obtained percentage with the share agreement for that airline (¶ 0055).
ground travel and the parameter value is at least one of booking time, cost per trip, or travel company; hotel and the parameter weight is at least one of booking time, average rate, and duration; or food and beverage and the parameter score is at least one of average daily spend or average meal rate.
Vance - The vendor chain analysis process 252 imports data from the trip table 128, the chain codes table 212, the accounting periods table 172 and the calendar year table 248 and provides an analysis of the booked plus actual activity for a specific date range for a given hotel or car chain. The output includes a total transaction count for number of room/nights or car/days plus a summary of the dollar value of each transaction as well as an average room/car nights per booking and average daily rates (¶ 0061). Now referring to FIG. 8, a detailed block diagram of the pre-trip management 74 of FIG. 3 is pictured. The analyze vendor goal share process 232 imports data from the local car table 116, the airline agreements table 200, the local property table 114, and the trip table 128. The analyze vendor goal share process 232 analyzes each preferred airline vendor on a specified city pair and divides the number of segments booked on that airline by the total number of segments booked and compares the obtained percentage with the share agreement for that airline (¶ 0055).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the transaction risk determination for suspicious activity in Sulur and the booking types in Vance because doing so allows the determination of high risk transactions because of suspicious activity.
Claim 20 is rejected under 35 USC § 103 as being unpatentable over Hammad, and in view of Biedermann, and further in view of Ivanoff and in further view of Gonzalez (US20160283945A1).
Regarding Claim 20. The combination of Hammad, Biedermann, and Ivanhoff teaches the system of claim 16.
The combination of Hammad, Biedermann, and Ivanhoff does not explicity teach the following limitations:
wherein the instructions, in response to the execution by the processor, cause the non-compliance engine to at least: display a user interface for configuring the set of rules, the user interface including the plurality of characteristics; and
receive a user selection of a subset of the plurality of characteristics for the level of transactional behavior associated with the set of rules.
wherein the instructions, in response to the execution by the processor, cause the non-compliance engine to at least: display a user interface for configuring the set of rules, the user interface including the plurality of characteristics; and
Gonzalez - One implementation of the disclosure allows each account holder to provide to the account issuer information about his or her account usage habits and intended future uses. This information may also be provided if the credit card holder is a commercial entity that wishes to provide company-issued cards to its employees which are limited to certain types of transactions and purchases. The information provided may be stored by the account issuer on, for example, a central database which could be referenced each time the account is used or each time it is used for an amount exceeding a pre-set amount. If the proposed attempted use falls into any of the categories of restricted usages stored on the central database, then the transaction may be denied, or at least flagged and other types of confirmation demanded from the person attempting the transaction (¶ 0018). In still further embodiments, a system according to this disclosure would be a means of pre-authorizing use, emanating from the account holder himself. It may also be used as a “blacklist”, whereby an account holder could prohibit certain uses, perhaps out of concern he may himself lack self-control while, for example, on a trip to Las Vegas or to a country auction; or that one of his sub-account holders would otherwise spend irresponsibly (¶ 0028).
receive a user selection of a subset of the plurality of characteristics for the level of transactional behavior associated with the set of rules.
Gonzalez - One implementation of the disclosure allows each account holder to provide to the account issuer information about his or her account usage habits and intended future uses. This information may also be provided if the credit card holder is a commercial entity that wishes to provide company-issued cards to its employees which are limited to certain types of transactions and purchases. The information provided may be stored by the account issuer on, for example, a central database which could be referenced each time the account is used or each time it is used for an amount exceeding a pre-set amount. If the proposed attempted use falls into any of the categories of restricted usages stored on the central database, then the transaction may be denied, or at least flagged and other types of confirmation demanded from the person attempting the transaction (¶ 0018). In still further embodiments, a system according to this disclosure would be a means of pre-authorizing use, emanating from the account holder himself. It may also be used as a “blacklist”, whereby an account holder could prohibit certain uses, perhaps out of concern he may himself lack self-control while, for example, on a trip to Las Vegas or to a country auction; or that one of his sub-account holders would otherwise spend irresponsibly (¶ 0028).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the transaction risk types and associated risk scores of Hammad with the higher weightings of Biedermann and the behavior types of Ivanhoff with the user profiles indicating spending restrictions of Gonzalez because doing so prevent fraud in credit card and other types of electronic transactions.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
(US20070288355A1)- Roland et al. - Evaluating risk associated with a financial organization's customer by prompting a user to respond to a set of questions adapted to solicit customer data relevant to evaluating the risk. The questions are part of a first risk model that includes rules for determining an overall risk rating associated with the customer based on user responses to the questions. Risks associated with individual responses from the user are quantified based on the first risk model. A first overall risk rating for the customer is determined based on the quantified risks.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C. STEVENSON whose telephone number is (571)270-7280. The examiner can normally be reached M-F 8am-5pm.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698