DETAILED ACTION
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 . 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/12/2025 has been entered.
Claims 1-20 are pending.
Claims 1, 3, 4, 7, 9, 11, 12, and 15, 17, 18, are currently amended.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-3, 5, 7, 9, 10, 11, 13, 15-17 and 19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments, see page 12-16, filed 05/07/2025 with respect to 1-20 have been fully considered and are persuasive. The rejection under 35 USC § 112(b) of 08/12/2025 has been withdrawn.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5, 7, 9, 10, 11, 13, 15-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Booth et al. (U. S. 2020/0279235 A1) (hereinafter “Booth”) in view of Kumnick et al. (U. S. PGPub. No. 2012/0221468 A1) (hereinafter “Kumnick”) and Merz et al (US 2016/0335639 A1) (hereinafter “Merz”); and in further view of Golan et al (U. S. PG. Pub. No. 2005/0097320 A1) (hereinafter “Golan”) and Hearn et al (U. S. Pat. No. 9,348,981 B1) (hereinafter “Hearn”) and Rapowitz et al (U. S. PGPub. No. 2023/0009527 A1) (hereinafter "Rapowitz");
Regarding Claim 1, Booth teaches:
A computing system for authenticating users-utilizing an interactive chatbot, the computing system comprising:
at least one processor in communication with a memory, the interactive chatbot, a merchant computing system (Booth: [0023], User device 110 may be in electronic communication with merchant system 120, via a user interface (UI) 125, and/or decisioning processor 130), a payment processor (Booth: [0022], System 100 may comprise one or more of a user device 110, a merchant system 120, a decisioning processor 130, a risk and fraud assessment platform 140, a tokenization system 150, a payment processor 160, a sender bank 193, and/or a receiver bank 195), and an issuer system separate from the computing system (Booth: [0045] In various embodiments, sender bank 193 and receiver bank 195 may comprise different banks or financial institutions (=issuer system). In various embodiments, sender bank 193 and receiver bank 195 may comprise the same bank or financial institution, or separate banks or financial institutions in partnership with each other. [0094], For example, the components of the systems and apparatuses may be integrated or separated), the at least one processor programmed to (Booth: [0105] The various system components discussed herein may include one or more of the following: a host server or other computing systems including a processor for processing digital data; a memory coupled to the processor for storing digital data; an input digitizer coupled to the processor for inputting digital data; an application program stored in the memory and accessible by the processor for directing processing of digital data by the processor; a display device coupled to the processor and memory for displaying information derived from digital data processed by the processor; and a plurality of databases):
compare the user input to at least one of the transaction data or the user data to determine whether to decline or approve authentication of the user (Booth: [0028], Decisioning processor 130 may compare the received input against stored biometric data, username and password data, or the like to validate the user's response and authenticate the user. [0081], Decisioning processor 130 may compare the authentication challenge response against stored biometric data, username and password data, authentication number, or the like to validate the user's response and authenticate the user (=authentication of the user));
in response to determining whether to decline or approve the authentication of the user,(Booth: [0041], Decisioning processor 130 may be configured to decline or authorize the payment transfer, and/or require additional authentication, in response to receiving the risk assessment, as discussed further herein)
in response to declining authentication of the user based upon the user input (Booth: [0082] In various embodiments, in response to the authentication challenge response failing validation (e.g., the authentication challenge response did not match the authentication challenge), decisioning processor 130 may be configured to transmit a second authentication challenge (or any other desired number of authentication challenges) before declining the payment request (e.g., step 407)), decline the transaction on behalf of the issuer system (Booth: [0079] In response to the risk comprising a “high risk,” method 401 may comprise declining the payment request (step 407). Decisioning processor 130 may transmit a payment declined notification to user device 110, via UI 125. The payment declined notification may comprise data indicating that the payment request was declined);
and transmit the authorization request message indicating that the transaction is declined to the merchant computing system and the payment processor (Booth: Decisioning processor 130 may transmit a payment declined notification to user device 110 (e.g., directly or displayed via UI 125). The payment declined notification may comprise data indicating that the payment request was declined or failed),
Booth does not explicitly disclose:
the authorization message formatted according to ISO 8583 network messaging protocol or an equivalent messaging protocol used by the processing network.
However, in an analogous art, Kumnick teaches:
the authorization message formatted according to ISO 8583 network messaging protocol or an equivalent messaging protocol used by the processing network (Kumnick: [0136], the authorization request message may be converted to an ISO format prior to being received by the payment processing network 112. [0080] The data conversion module 112(J) can convert authorization request messages from one format to another format. In embodiments of the invention, and the data conversion module 112(J) converts the message into an ISO format (e.g. ISO 8583) prior to sending them to issuers).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Booth’s method of declining the payment transaction if authentication challenge response fails by applying Kumnick’s method of formatting authorization request messages into an ISO 8583 in order to processing a transaction through a payment processing network configured to process and transmit transaction data to a multitude of payment networks and debit gateways on the merchant's behalf and without the merchant directly interacting with a plurality of acquirer computers (Kumnick: [0007]).
Booth in view of Kumnick does not explicitly disclose:
receive, via processing network, an authorization request message for a transaction initiated by a user with the merchant computing system, wherein the authorization request message includes transaction data;
retrieve, from the memory, user data associated with the user;
determine, based upon the transaction data and the user data, a risk associated with the transaction, wherein the risk is one of (i) high indicating that the transaction is likely to be fraudulent or (ii) low indicating that the transaction is likely to be legitimate;
determine, based upon the risk associated with the transaction, a difficulty level of one or more prompts for the user to answer, wherein the difficulty level is determined to be high when the risk is high, and wherein the difficulty level is determined to be low when the risk is low;
generate, based upon the determined difficulty level and at least one of the transaction data or the user data, the one or more prompts;
transmit, via the interactive chatbot, the one or more prompts to the user;
receive user input in response to the one or more prompts;
However, in an analogous art, Merz teaches:
Receive, via a processing network, an authorization request message for a transaction initiated by a user with the merchant computing system, wherein the authorization request message includes transaction data (Merz: [0023], in other embodiments, the AE computer device receives the authorization request message from the merchant bank. The authorization requests message includes transaction data about the candidate online payment transaction, such as, but not limited to, transaction amount, primary account number, and merchant identifier. [0032], In operation 203, the institution (e.g., via an online service application) may send a request to the risk-based authentication local module 120, which may forward the information it to the risk-based authentication server 150, via for example the user's web browser or via another method);
retrieve, from the memory, user data associated with the user (Merz: [0066], provides for retrieves 520 the authentication data associated with the candidate’s online payment transaction from the database);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick by applying the well-known technique as disclosed by Merz’s method of receiving transaction request and retrieving authentication data associated with online payment transaction in order to determine that the candidate payment transaction is not fraudulent (Merz: [Abstract]).
Booth in view of Kumnick and Merz does not explicitly disclose:
determine, based upon the transaction data and the user data, a risk associated with the transaction, wherein the risk is one of (i) high indicating that the transaction is likely to be fraudulent or (ii) low indicating that the transaction is likely to be legitimate;
embed an authentication indicator into the authorization request message, wherein the authentication indicator indicates whether the user is authenticated based upon the user input;
In response to decline the authentication of the user based upon the user input, decline the on behalf of the issuer system
However, in an analogous art, Golan teaches:
determine, based upon the transaction data and the user data, a risk associated with the transaction (Golan: [0028] If it is determined that risk level is sufficiently low or below a certain threshold, user and/or transaction data may be collected, for example for later use. [0057] Without limiting the embodiments of the invention discussed herein, embodiments of the present invention could be used together with for example any of the following additional authentication methods, in order to adapt the level of security or alter the authentication level requirements following assessment of the transaction risk: (1) Shared secrets--using users' shared secrets that are known to the transaction provider (e.g. date of birth or postal code(=user data)); (2) Time sensitive secrets--asking users to provide a secret that changes in time (e.g. amount of last deposit or withdrawal(=transaction data)); [0067] provides for perform a risk assessment (e.g., use a risk assessment engine) to assess the risk of a specific login or Transaction. The process may select the appropriate level of login security according to this level. [0068] 3. The details used for a risk assessment may include the following, or may include other suitable sets of details: [0058-0076], provides risk assessment method based on various data),
wherein the risk is one of (i) high indicating that the transaction is likely to be fraudulent or (ii) low indicating that the transaction is likely to be legitimate (Golan: [0029]: If an initial risk level is high, authentication may be mandated upfront. For example, if it is determined that a login is from a hijacked computer, or from a foreign country, or from a computer not used previously by the VIP user, the exception for the customer may not be allowed);
(Golan: [0042] The fraud miner 180 or another suitable unit may collect information about specific fraudsters, and may update the fraud profiles database 179 with such information. The fraud miner 180 may use information from the activity log 182, and may detect fraud profiles based on for example past activities and decisions, as well as inputs from institutions such as banks on actual fraud);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick and Merz by applying the well-known technique as disclosed by Golan’s method of determine risk level based on shared secrets and Time sensitive secrets, in order to authenticate the user. The motivation is the risk assessment, or security level or the level of authentication may be raised due to factors unrelated to the specific transaction or user, for example "an environmental risk" such as a current wave of cyber-attacks, a government or trade group warning, etc. (Golan: [0027]).
Booth in view of Kumnick and Merz and Golan does not explicitly disclose:
determine, based upon the risk associated with the transaction, a difficulty level of one or more prompts for the user to answer, wherein the difficulty level is determined to be high when the risk is high, and wherein the difficulty level is determined to be low when the risk is low;
generate, based upon the determined difficulty level, and at least one of the transaction data or the user data the one or more prompts;
In response to decline the authentication of the user based upon the user input, decline the on behalf of the issuer system
However, in an analogous art, Hearn teaches:
determine, based upon the risk associated with the transaction, a difficulty level of one or more prompts for the user to answer (Hearn: [Col 14, lines 42-45], provides for FIG. 6 is a flow chart illustrating a method 600 for identifying risk level of a user and generating an associated challenge according to one embodiment),
wherein the difficulty level is determined to be high when the risk is high (Hearn: [Col 13, lines 26-31], in some embodiments, the authentication engine 140 may also make determinations about the number of questions to ask based on other factors, such as a strength rating for the questions (e.g., one "difficult" question may be equal to two or more "easy" questions. [Col 14, lines 49-53], provides for the challenge generation engine 306 determines 608 whether the login request is coming from a “High Risk User.” If the login request is coming from a “High Risk User,” (608—Yes), then a difficult challenge is generated 610),
and wherein the difficulty level is determined to be low when the risk is low (Hearn: [Col 14, lines 57-61], provides for the challenge generation engine 306 then determines 612 whether the login request is coming from a “Low Risk User.” If the login request is coming from a “Low Risk User,” (612—Yes), then a simple challenge (=difficult level of the prompts will be low) is generated 614);
generate, based upon the determined difficulty level, (Hearn: [Col 15, lines 6-16], provides for if the generated challenge was not completed successfully (414—No), another authentication challenge (=one or more prompt) is generated 408. In some embodiments, this cycle of generating 408 and determination 414 of successful completion is repeated until the challenge is successfully completed. In other embodiments, this cycle of generating 408 and determination 414 of successful completion is repeated for a limited number of times and after the limit is reached, a warning is sent for display (not shown)), and at least one of the transaction data or the user data (Hearn: [Col 10, lines 22-27], The risk analysis engine 304 of the authentication module 220a performs a series of determinations regarding information about the user (=user data) in order to determine the user's level of risk. [Col 14, lines 57-75], The challenge generation engine 306 then determines 612 whether the login request is coming from a “Low Risk User.” If the login request is coming from a “Low Risk User,” (612—Yes), then a simple challenge is generated 614. If the login request is not coming from a “Low Risk User,” (612—No), the login request is coming from an “Unknown User.” If the login request is coming from an “Unknown User,” the “Unknown User” is allowed to login 618) ;
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz and Golan by applying the well-known technique as disclosed Hearn of generating simple authentication challenge if risk is low and generating difficult authentication challenge if risk is high. The motivation is to generating/prompting an authentication challenge based on the identified level of risk is generated. The login request is allowed or denied based on the completion on the authentication challenge (Hearn: [Col 1, lines 57-60]).
Booth in view of Kumnick, Merz, Golan and Hearn does not disclose:
transmit, via the interactive chatbot, the one or more prompts to the user;
receive user input in response to the one or more prompts;
However, in an analogous art, Rapowitz teaches
transmit, via the interactive chatbot, the one or more prompts to the user (Rapowitz: [0069], provides in step 408, the computing device may cause presentation (transmit prompt) of the one or more authentication questions generated in step 407. Causing presentation of the authentication question may comprise causing one or more computing devices to display and/or otherwise output the authentication question. The authentication question might be provided in a text format (e.g., in text on a website), in an audio format (e.g., over a telephone call), or the like);
receive user input in response to the one or more prompts (Rapowitz: [0070], provides in step 409, the computing device may receive one or more responses (=user inputs) to the one or more authentication questions presented in step 408. A response may be any indication of a response, by a user, to the authentication question(s) presented in step 408. For example, if an authentication question comprises one or more answers from which the user should select, the response might comprise a selection of at least one of the one or more answers. As another example, in the case of a telephone call, the response might comprise an oral response to an authentication question provided using a text-to-speech system over the call);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz, Golan and Hearn by applying the well-known technique as disclosed by Rapowitz of for transmitting/prompting questions and receiving inputs (answers) in response questions prompted in order to dynamically generate security questions when transactions appear to be fraudulent and with the purpose of establishing whether an authorized user made the transactions. The motivation is to improve the safety of financial accounts and computer transaction systems by generating authentication questions (Rapowitz: [0005]).
Regarding claim 2, the Booth in view of Kumnick, Merz , Golan, Hearn, Rapowitz teaches:
The method of claim 1 (see rejection of claim 1 above),
compare the user input and the received user data (Merz: [0027], provides the AE computer device may evaluate the cardholders total amount spent in a certain period of time, the amount that the interchange network earns off of the cardholder's payment transactions, cardholder's prior history of payment transactions similar to the candidate online payment transaction, and/or the size of the cardholder's transaction portfolio in comparison to other payment card accounts in the payment network or in the issuer processor. The AE computer device may calculate the cost of a false negative based on the cost of historical series of similar fraudulent transactions);
determine, based upon the comparison, a risk score for the user input, wherein the risk score indicates an accuracy level of the user input (Merz: [0067], provides AE computer device 212 combines the authentication data and the authorization request message to calculate an assurance level score for the candidate online payment transaction);
determine, based upon the comparison, an assurance level for the user input, wherein the assurance level indicates an authentication level for the user based upon at least one the risk score (Merz: [0067], The assurance level score represents a level of confidence that the candidate online payment transaction is not fraudulent. The assurance level score includes a plurality of calculations and business rules to determine the level of confidence in the candidate online payment transaction) Or a difficulty level of the one or more prompts (Hearn: [Col 14, lines 42-45], provides for FIG. 6 is a flow chart illustrating a method 600 for identifying risk level of a user and generating an associated challenge according to one embodiment);
and embed the assurance level into the authorization request message (Merz: (Merz: [abstract: the authorization request message including the assurance level score. [0016], provides for the authentication system, many known systems also use a fraud scoring system to detect potentially fraudulent transactions. The fraud scoring system receives the authorization request message, including the transaction information, on behalf of the fraud management platform).
Regarding claim 3, the Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz teaches:
The method of claim 1 (see rejection of claim 1 above),
receive from one or more issuer computing devices, a predetermined threshold indicating a minimum risk score for the user to be authenticated (Rapowitz: [0059], provides the threshold might be modified based on this accuracy. If the accuracy is relatively poor, then the threshold might be relaxed, such that the computing device may determine that the user device was near the location of a merchant even if, e.g., the location data suggests that the user device 301 was relatively far away from the location of the merchant. In contrast, if the accuracy is relatively high, then the threshold might be made stricter, such that the computing device may determine that the user device was near the location of a merchant only if, e.g., the location data suggests that the user device 301 was particularly close to the location of the merchant);
store, in the at least one memory, the predetermined threshold (Merz: [0016], provides, in addition, or alternatively, the payment card issuer may have predefined business rules, the violation of one or more of which results in a determination that a transaction is fraudulent or at a high risk of being fraudulent);
and authenticate the user based upon the user having a first risk score above the predetermined threshold (Golan: [0031] In one embodiment, if it is determined that the level of risk is above a threshold, the user may be required to provide security or authentication details, for example information in addition to what was provided to initiate the transaction, or other information. [0050], In certain embodiments of the current invention Transaction risk assessment is based on any of the following criteria, or similar criteria; other suitable criteria may be used. It should be understood by those skilled in this art that this list can be tailored and expanded depending on the type, and nature of the Transaction, as well as the availability of information regarding the Transaction. (4) Measuring the velocity of Transactions performed by a specific account, or originating from a certain IP address, user or source or made at a certain merchant or service provider. If velocity is above a certain threshold, it may indicate a higher level of risk; (5) Measuring the velocity and/or number of accounts performing Transactions that originate from a certain IP address, source, address, user, merchant, or service provider. If velocity is above a certain threshold, it would indicate a higher level of risk).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz, Hearn, Rapowitz by applying the well-known technique as disclosed by Golan’s method of determine risk level based on shared secrets and Time sensitive secrets and decline the authentication if risk level is high, in order to authenticate the user. The motivation is the risk assessment, or security level or the level of authentication may be raised due to factors unrelated to the specific transaction or user, for example "an environmental risk" such as a current wave of cyber-attacks, a government or trade group warning, etc. (Golan: [0027]),
Regarding claim 5, the Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz teaches:
The method of claim 1 (see rejection of claim 1 above),
generate the one or more prompts with a low difficulty level for the user to answer when the risk is low (Hearn: [Col 14, lines 57-61], provides for the challenge generation engine 306 then determines 612 whether the login request is coming from a “Low Risk User.” If the login request is coming from a “Low Risk User,” (612—Yes), then a simple challenge (=difficult level of the prompts will be low) is generated 614);
generate the one or more prompts with a high difficulty level for the user to answer when the risk is high (Hearn: [Col 10, lines 17-21], provides for a user may be categorized as a “High Risk User” if the adversarial reputation data of the user is abundant or clearly indicates an adversarial user, and therefore, the system 100 has high confidence that the user is an adversarial user. [Col 15, lines 6-16], provides for if the generated challenge was not completed successfully (414—No), another authentication challenge is generated 408. In some embodiments, this cycle of generating 408 and determination 414 of successful completion is repeated until the challenge is successfully completed. In other embodiments, this cycle of generating 408 and determination 414 of successful completion is repeated for a limited number of times and after the limit is reached, a warning is sent for display (not shown)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz, Golan by applying the well-known technique as disclosed by Hearn generating simple authentication challenge if risk is low and generating difficult authentication challenge if risk is high. The motivation is to an authentication challenge based on the identified level of risk is generated. The login request is allowed or denied based on the completion on the authentication challenge (Hearn: [Col 1, lines 57-60]).
Regarding claim 7, the Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz teaches:
The method of claim 1 (see rejection of claim 1 above),
transmit the embedded authorization request message to the processing network for further processing of the transaction (Merz: [0047], provides for transmitting the authorization request message including (embedded) the assurance level score to an issuer processor 130 (shown in FIG. 1).
Regarding Claim 9, this claim contains limitations found within that of claim 1 above albeit directed to a different statutory category (computing system medium), and the for this reason the same grounds of rejection are applied to claim 9.
Regarding claim 10, this claim contains limitations found within that of claim 2 above albeit directed to a different statutory category (method), and the for this reason the same grounds of rejection are applied to claim 10.
Regarding claim 13, this claim contains limitations found within that of claim 5 above albeit directed to a different statutory category (method), and the for this reason the same grounds of rejection are applied to claim 13.
Regarding claim 15, this claim contains identical limitations found within that of claim 1
above albeit directed to a different statutory category (non‐transitory computer-readable medium), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 15.
Regarding claim 16, this claim contains identical limitations found within that of claim 2
above albeit directed to a different statutory category (non‐transitory computer-readable medium), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 16.
Regarding claim 11, this claim contains limitations found within that of claim 3 above albeit directed to a different statutory category (method), and the for this reason the same grounds of rejection are applied to claim 11.
Regarding claim 17, this claim contains identical limitations found within that of claim 3
above albeit directed to a different statutory category (non‐transitory medium), and for this
reason the same rationale of rejection is used where applicable grounds of rejection are applied
to claim 17.
Regarding claim 19, this claim contains identical limitations found within that of claim 5
above albeit directed to a different statutory category (non‐transitory computer-readable medium), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 19.
Claim(s) 4, 6, 8, 12, 14, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Booth et al. (U. S. PGPub. No. 2020/0279235 A1) (hereinafter “Booth”) in view of Kumnick et al. (U. S. PGPub. No. 2012/0221468 A1) (hereinafter “Kumnick”) and Merz et al (US 2016/0335639 A1) in view of Golan et al (U. S. PGPub. No. 2005/0097320 A1) (hereinafter “Golan”) and Hearn et al (U. S. Pat. No. 9,348,981 B1) (hereinafter “Hearn”), Rapowitz et al (US 2023/0009527 A1) ; and in further view of Larson et al (US 2020/0366671 A1).
Regarding claim 4, Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz teaches:
The method of claim 3 (see rejection of claim 3 above),
wherein the one or more additional prompts have a higher difficulty level than the difficulty level than an initial difficulty level of the initial prompts (Hearn: [Col 15, lines 1-16), provides for the challenge assessment engine 308 of the authentication module 220a receives a response from the user and assesses 412 the authentication challenge and determines 414 whether the generated challenge was completed successfully. If the challenge was completed successfully (414—Yes), the login is allowed 416. In some embodiments, if the generated challenge was not completed successfully (414—No), another authentication challenge is generated 408. In some embodiments, this cycle of generating 408 and determination 414 of successful completion is repeated until the challenge is successfully completed. In other embodiments, this cycle of generating 408 and determination 414 of successful completion is repeated for a limited number of times and after the limit is reached, a warning is sent for display (not shown)).
transmit, via the interactive chatbot, the one or more additional prompts to the user
(Rapowitz: [0069], provides in step 408, the computing device may cause presentation of the one or more authentication questions generated in step 407. Causing presentation of the authentication question may comprise causing one or more computing devices to display and/or otherwise output the authentication question. The authentication question might be provided in a text format (e.g., in text on a website),
receive additional user input in response to the one or more additional prompts; (Rapowitz: [0072] provides for determining whether to provide access to the account might be based on an authentication score. If the computing device generates and presents a plurality of authentication questions, an authentication score might be calculated based on the responses to each of the plurality of different authentication questions. For example, where the computing device generated a plurality of authentication questions (e.g., relating to transactions where the user was present) and a second plurality of authentication questions (additional question) (e.g., relating to transactions where the user was not present), an authentication score might be calculated based on the responses to the plurality of authentication questions and based on responses to the second plurality of authentication questions).
determine a third risk score of the additional user input (Rapowitz: [0009] generate a second plurality of authentication questions based on the second subset of transactions, and calculate, based on the responses to the plurality of authentication questions and based on responses to the second plurality of authentication questions, an authentication score. [0072], provides for determining whether to provide access to the account might be based on an authentication score. If the computing device generates and presents a plurality of authentication questions, an authentication score might be calculated based on the responses to each of the plurality of different authentication questions. For example, where the computing device generated a plurality of authentication questions (e.g., relating to transactions where the user was present) and a second plurality of authentication questions (e.g., relating to transactions where the user was not present), an authentication score might be calculated based on the responses to the plurality of authentication questions and based on responses to the second plurality of authentication questions. If the authentication score satisfies a threshold (e.g., at least 50% of the questions being correct), the computing device might determine to provide access to the account.)
authenticate the user when the third risk score for the additional user input above the predetermined threshold (Merz: [0032], provides for calculating an assurance level score based on the authentication data, the authorization request message, the initial assurance score, a cost of a false positive, a cost of a false negative, and a probability that the candidate payment transaction is fraudulent, wherein the assurance level score represents a level of confidence that the candidate payment transaction is not fraudulent. [0032], provides for transmitting to an issuer processor the authorization request message including the assurance level score, at least one of the one or more merchant reason codes, and at least one of the one or more generated reason codes. The resulting technical effect is that a more accurate fraud detection system provides an enhanced fraud score to the issuer processor to assist the issuer processor in determining whether to approve or deny an online payment transaction);
and decline authenticating the user when the third risk score for the additional user input below the predetermined threshold (Golan: [0029]: If an initial risk level is high, authentication may be mandated upfront. For example, if it is determined that a login is from a hijacked computer, or from a foreign country, or from a computer not used previously by the VIP user, the exception for the customer may not be allowed. [0055] According to one embodiment of the current invention a Transaction may opt to use any of the following modes of action: (2) Authentication without fallback, meaning that after failing to complete the first authentication method for a number of consecutive times (defined by provider) the user may not be presented with alternative authentication methods; (3) No extra authentication at all. [0060], Since risk is higher than normal, the system may initiate an extra authentication step, or may raise the authentication level of the transaction. The authentication results may be fed back into the risk-scoring module. If almost all authentications fail, this may indicate a fraudster and the specific IP may enter a black list; higher levels of authentication (or even automatic decline) may be used.).
generate, when the user has a second risk score below the predetermined threshold, one or more additional prompts for the user (Larson: [0100], provides if the overall trust score is below the threshold score (or one or more indicators have failing or review type conditions indicated), the enrollee may then be asked follow-up (e.g., KBA) questions).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz, Hearn, Rapowitz by applying the well-known technique as disclosed by Larson’s method of generating follow-up questions (additional prompts). The motivation is Identity verification services are often used by businesses and/or government agencies to ensure that information provided by users is associated with the identity of a real person. Businesses or government agencies may verify the identity of the real person using identity information indicated by physical identifying documents (e.g., driver's license, passport, identity cards, etc.), or they may verify identity information against authoritative sources (e.g., credit bureaus, government database(s), corporate database(s), etc.)(Larson: [0004]).
Regarding claim 6, the Booth in view of Kumnick, Merz ,Golan, Hearn, Rapowitz teaches:
The computing system of claim 1 (see rejection of claim 1).
The above cited combination of Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz does not disclose:
utilize at least one of a machine learning algorithm or an artificial intelligence algorithm to generate the one or more prompts for the user to answer, wherein the generated one or more prompts are specific to the user based upon the user data.
However, Larson teaches:
utilize at least one of a machine learning algorithms (Larson: [0219] provides for the NN 6600 may represent one or more ML models that are trained using training data. The term "machine learning" or "ML" refers to the use of computer systems implementing algorithms and/or statistical models to perform specific task(s) without using explicit instructions, but instead relying on patterns and inferences).
and an artificial intelligence algorithm to generate the one or more prompts for the user (Larson: [0015], provides for the live interview may be per formed by a human interviewer or an autonomous software agent, such as a virtual assistant, chatbot, artificial intelligence (AI) agent, and/or the like).
wherein the generated prompts are specific to the user based upon the user data.
(Larson: [0019], provides for the knowledge-based assessment or knowledge-based authentication (KBA) questions are generated based on the collected information, which are
then used during the live interview. KBA is a method of authenticating a user's identity, which requires the knowledge of private information of the user to prove that the person providing the identity information is the actual owner of the identity. KEA-generated questions may be static KBAs or dynamic KBAs. Static KBAs are based on a pre-agreed set of shared secrets, such as place of birth, mother's maiden name, name of first pet, and/or the like. Dynamic KBAs are based on questions generated from a wider base of personal information such as account numbers, loan amounts, tax payment amounts, etc. [0091] provides for the client application 110 prompts the enrollee to input biographic information into a web form or the like. For example, enrollee may enter the last four digits of their Social Security number (SSN), their cell phone number, their email address, physical mailing address, mother's maiden name, etc.).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz by applying the well-known technique as disclosed by Larson to generate prompt by using machine learning algorithm and artificial intelligence which can be chat bot, virtual assistance. The motivation is Identity verification services are often used by businesses and/or government agencies to ensure that information provided by users is associated with the identity of a real person. Businesses or government agencies may verify the identity of the real person using identity information indicated by physical identifying documents (e.g., driver's license, passport, identity cards, etc.), or they may verify identity information against authoritative sources (e.g., credit bureaus, government database(s), corporate database(s), etc.)(Larson: [0004]).
Regarding claim 8, the Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz teaches:
The computing system of Claim 1 (see rejection of claim 1),
wherein the transaction data is received from a merchant computing device and includes a payment account identifier, a merchant identifier, a transaction amount (Merz: [0023[, provides for the AE computer device receives the authorization request message from the merchant bank. The authorization requests message includes transaction data about the candidate online payment transaction, such as, but not limited to, transaction amount, primary account number, and merchant identifier).
and a transaction location, wherein the user data is received from at least one of a user computing device (Merz: [0021] provides for (1) consumer device attributes such as, for example, device attribute data (i.e., data derived from the device that the cardholder is transacting from, which can ultimately be used for creating a device fingerprint, and which may include IP address, physical address associated with IP address, device type, and phone number), and geo-location data (i.e., data from the device of the card holder, indicating the assessed location of the device. Such as GPS location, country, city, etc.)
[[and]] or an issuer computing device (Merz: [0021], provides for the data from merchant 124 Such as, for example, consumer contact information (personally identifiable information (PII) about cardholder 122 associated with payment account 132 (shown in FIG. 1) that the candidate online payment transaction is for, which will be used to determine the likelihood that merchant 124 has the correct cardholder 122, and which may include email address, mobile phone number, landline phone number, confirmed shipping address, and consumer identity verification (e.g., anonymous, unverified, externally scored (e.g., credit reference agency), authentic issued official ID (e.g., passport, driver's license)), and age of cardholder relationship);
and includes a user address, transaction history (Merz: [0063]: merchant reference data Such as, for example, days account has been on file with merchant 124, days since cardholder 122 last used the card on file, verification method of cardholder performed by merchant 124 at the time of candidate online payment transaction, purchases information (i.e., type of goods/services provided-digital only, low value, high value with verified address, in-store), and a merchant risk score (i.e., a risk score derived from the merchant's risk systems and reference data, also known as a merchant fraud grading. [0069]: provides AE computer device may evaluate the cardholders total amount spent in a certain period of time, the amount that interchange network earns off of the cardholder's payment transactions, cardholder's prior history of payment transactions similar to the candidate online payment transaction, and/or the size of the cardholder's transaction portfolio in comparison to other payment card accounts in interchange network or in issuer processor), previous fraudulent activity (Larson: [0042], provides for the service which involve the one or more IVS servers 145 using the data collected from the client system 105 and the external data to verify additional information such as, for example, whether the user's device (e.g., client system 105A) been associated with identity fraud in the past), and wherein the one or more prompts include user-specific questions based upon the user data (Larson: [0019], provides for, knowledge-based assessment or knowledge-based authentication (KBA) questions are generated based on the collected information, which are then used during the live interview. KBA is a method of authenticating a user's identity, which requires the knowledge of private information of the user to prove that the person providing the identity information is the actual owner of the identity. KEA-generated questions may be static KBAs or dynamic KBAs. Static KBAs are based on a pre-agreed set of shared secrets, such as place of birth, mother's maiden name, name of first pet, and/or the like. Dynamic KBAs are based on questions generated from a wider base of personal information such as account numbers, loan amounts, tax payment amounts, etc. [0091] In some embodiments, the client application 110 prompts the enrollee to input biographic information into a web form or the like. For example, enrollee may enter the last four digits of their Social Security number (SSN), their cell phone number, their email address, physical mailing address, mother's maiden name, etc.), one or more requests for biometric data (Larson: [Abstract]: provides for the enrollment process includes collecting various identifying data and biometric data of a user. A live interview portion during the enrollment process is used to check the liveness and verify the collected identifying data and biometric data. [0101] After the live interview 214A-B, at operation 215 the client application 110 (or the IVS (Identity Verification Service)140) will invoke the SPP process 121, and passes back the approval/denial recommendation and any additional biometric data that was collected to the SPP 120. [0139]: As shown by FIG. 27B, authentication intro GUI instance 27B15 includes a GCE 27B25, which when selected by the enrollee, for example, by performing a tap gesture 27B20 on the GCE 27B25, may cause the authenticate process, such as process 2800 of FIG.28, to begin.), and a one-time use code sent to the user computing device (Larson: [0019], provides a One Time Password (OTP) may be used instead of a set of KBAs for enrollees who do not show signs of fraudulent activity with respect to their enrollment (e.g., low risk enrollments). [0137]: The user may paste the obtained one-time identity authentication code into the text field GCE 27All, and then select the GCE (Graphical Control Element) 27 A06 to validate his/her identity in a same or similar manner as discussed infra with respect to GUI (Graphical User Interface) instances 2915A-2915D. After the user's identity is authenticated, the user may select the GCE 27A25 to complete the money transfer. [0141]: provides for, in other embodiments, the one-time authorization code may be sent to the client system in an SMS message or using some other messaging system/service. As examples, the one-tine authentication code 2908 may be pasted into a separate identity verification application as shown by GUI 2915 (including GUI instances 2915A, 2915B, 2915C, and 2915D), a separate application such as a banking application (see, e.g., GUI instance 27A05 of FIG. 27A), social networking application, or the like).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Booth in view of Kumnick, Merz, Golan, Hearn, Rapowitz by applying the well-known technique as disclosed by Larson to perform transaction from merchant devices by authentication user using biometric identification and sending OTP (one-time password) to the user’s computer. The motivation is Identity verification services are often used by businesses and/or government agencies to ensure that information provided by users is associated with the identity of a real person. Businesses or government agencies may verify the identity of the real person using identity information indicated by physical identifying documents (e.g., driver's license, passport, identity cards, etc.), or they may verify identity information against authoritative sources (e.g., credit bureaus, government database(s), corporate database(s), etc.)(Larson: [0004]).
Regarding claim 12, this claim contains limitations found within that of claim 4 above albeit directed to a different statutory category (method), and the for this reason the same grounds of rejection are applied to claim 12.
Regarding claim 18, this claim contains identical limitations found within that of claim 4
above albeit directed to a different statutory category (non‐transitory medium), and for this
reason the same rationale of rejection is used where applicable grounds of rejection are applied
to claim 18.
Regarding claim 14, this claim contains limitations found within that of claim 6 above albeit directed to a different statutory category (method), and the for this reason the same grounds of rejection are applied to claim 14.
Regarding claim 20, this claim contains identical limitations found within that of claim 6
above albeit directed to a different statutory category (non‐transitory medium), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Royyuru et al. (U. S. Pat. No. 10,354,247 B2): Embodiments of the disclosure relate to systems and methods for communicating transaction-related data to a recipient device. In at least one embodiment, a computer-implemented method can be provided. The method can include directing storage of transaction-related information comprising payment data and value added services data. The method can further include communicating the transaction-related information to a recipient device during a card emulation communication initiated by the recipient device, wherein the recipient device utilizes the transaction-related information to complete a payment transaction and provide one or more value added services associated with the payment transaction.
Bellenger et al. (U. S. PGPub. No. 2021/0067316 A1): A method is disclosed. The method comprises receiving, from a communication device, a provisioning request message including a user device identifier and a cryptogram in a first message format, which is received from the user device by the communication device during a message exchange process between the user device and the communication device. The method also includes generating an authorization request message in a second message format, the authorization request message comprising the cryptogram, transmitting the authorization request message to an authorizing computer, and receiving an authorization response message from the authorizing computer. The method also includes providing access data to the communication device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights