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 .
Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Priority
Application 19/109,117 filed on 03/05/2025 is a 371 of PCT/US2023/074498 09/18/2023, which claims benefit of 63/410,055 09/26/2022.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A method comprising: prompting, by a second user device operated by a second user, a first user to interact a portable device of the first user with the second user device in a transaction;
receiving, by the second user device, interaction data comprising a credential or token, from the portable device in a contactless communication;
determining, by the second user device, that the transaction cannot be completed without further interaction by the first user;
responsive to determining that the transaction cannot be completed, providing, by the second user device, at least one alternate transaction option for the first user;
receiving, by the second user device from the first user, a selection of an alternate transaction option from the at least one alternate transaction option; and
processing, by the second user device, the transaction according to the selected alternate transaction option.
Claim 18 recites the limitations of:
A method comprising: receiving, by an interaction processing server from a second user device operated by a second user in a transaction between the second user and a first user, after the first user interacts a contactless portable device with the second user device, a payload comprising payload information comprising a credential or token, and transaction information;
determining, by the interaction processing server, if the payload information can be used to complete the transaction;
determining, by the interaction processing server that the payload information cannot be used to complete the transaction; and
transmitting, by the interaction processing server, a response message to the second user device, wherein the second user device provides options for completing the transaction to the first user.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction made by a consumer using a payment device or payment account. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover the use of a computer system for collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction made by a consumer using a payment device or payment account. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting “a second user device”, “a portable device of the first user”, “portable device in a contactless communication”, and “interaction processing server”, to perform the steps of “prompting”, “determining”, and “processing”, nothing in the claim elements preclude the steps from practically being a certain method of organizing human activity or mental process. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction made by a consumer using a payment device or payment account. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the specification discloses “[0021] A "user device" may be any suitable device that a user can interact with (e.g., a payment card or mobile phone). User devices may be in any suitable form. cellular phones, PDAs, personal computers (PCs), tablet computers, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component. [0022] A "mobile device" (sometimes referred to as a mobile communication device) may comprise any suitable electronic device that may be transported and operated by a user, which may also provide remote communication capabilities to a network. A mobile communication device may communicate using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, wearable devices (e.g., watches), vehicles such as smart cars, electric cars, automobiles, and motorcycles, personal music players, hand-held specialized readers, etc. A mobile device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device - i.e., using the other device as a modem - both devices taken together may be considered a single mobile device).”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “a second user device”, “a portable device of the first user”, “portable device in a contactless communication”, and “interaction processing server”, to perform the steps of “prompting”, “determining”, and “processing”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction made by a consumer using a payment device or payment account in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”. See MPEP 2106.05(g).
Claim 17 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 17 recites the additional elements of “A second user device comprising: a processor; and a non-transitory computer readable medium, the non-transitory computer readable medium comprising code, executable by the processor, for performing operations comprising:”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 2-16 and 19-20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 14-15, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375.
As per claim 1,
Foster explicitly teaches:
A method comprising: prompting, by a second user device operated by a second user, a first user to interact a portable device of the first user with the second user device in a transaction;
(Foster US20210176615 at paras. 71, 78-80) ("[0071] FIG. 5A is a flowchart illustrating a process 500 for initiating an anonymous peer-to-peer payment, according to some embodiments. The process shown in FIG. 5A can be performed by a first mobile device, such as the sender device 110, that executes the payment application 115 and is used by a first user who is sending money to a second user. The process is described with respect to FIGS. 5B-5D, which illustrate example interfaces displayed by the payment application 115." "[0078] At block 504, the first mobile device establishes a direct communication channel with a second device associated with the second user. For example, the first mobile device performs a handshake procedure to connect to the second device using Bluetooth. In another example, the first mobile device begins outputting a signal by a radio frequency or NFC transceiver that is detectable by a corresponding second device transceiver when the first mobile device comes into proximity to the second device.")
receiving, by the second user device, interaction data comprising a credential or token, from the portable device in a contactless communication;
(Foster US20210176615 at paras. 71, 78-80) ("[0079] At block 506, the first mobile device communicates with the second mobile device via the established communication channel to send a tokenized transaction identifier associated with the transaction to the second mobile device. The transaction identifier can be transmitted via a URL that includes instructions to cause the recipient device to perform one or more actions. An action can include displaying information to the second user, such as the amount of money the first user is transferring to the second user or instructions to download the mobile payment application.")
Foster does not explicitly teach, however, Shah does teach:
determining, by the second user device, that the transaction cannot be completed without further interaction by the first user;
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
responsive to determining that the transaction cannot be completed, providing, by the second user device,
(Shah US20190258786 at paras. 49-58) ("[0050] Referring to FIG. 2I, at step 233, client authentication computing platform 110 may determine updated user account state information corresponding to the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). For example, client authentication computing platform 110 may determine an updated security state of the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130) based on multi-channel authentication state information corresponding the user account and/or one or more authentication rules maintained by client authentication computing platform 110. At step 234, client authentication computing platform 110 may generate one or more step-up authentication prompt commands (e.g., based on the updated user account state information determined by client authentication computing platform 110). At step 235, client authentication computing platform 110 may send the one or more step-up authentication prompt commands to client computing device 130. At step 236, client authentication computing platform 110 may receive the one or more step-up authentication prompt commands from client authentication computing platform 110. For example, at step 236, after sending the second authentication request to the client authentication computing platform (e.g., client authentication computing platform 110), client computing device 130 may receive, via the communication interface, from the client authentication computing platform (e.g., client authentication computing platform 110), one or more step-up authentication prompt commands. [0051] Referring to FIG. 2J, at step 237, client computing device 130 may present one or more step-up authentication prompts. For example, at step 237, client computing device 130 may present one or more step-up authentication prompts based on the one or more step-up authentication prompt commands received from the client authentication computing platform (e.g., client authentication computing platform 110). In some instances, in presenting the one or more step-up authentication prompts based on the one or more step-up authentication prompt commands received from the client authentication computing platform (e.g., client authentication computing platform 110), client computing device 130 may display and/or otherwise present a graphical user interface similar to graphical user interface 600, which is illustrated in FIG. 6. As seen in FIG. 6, graphical user interface 600 may include one or more fields prompting the user of client computing device 130 to enter additional credentials, such as a one-time passcode associated with an online banking account or other user profile, information indicating that client computing device 130 is also collecting and verifying biometric data from linked wearable devices, and/or other user-selectable options and/or content.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster and Shah, because it allows for an improved system to provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with providing information security and preventing unauthorized access to resources of an information system by implementing advanced biometric authentication techniques. (Shah at Abstract and paras. 1-14).
Foster and Shah do not explicitly teach, however, Gurunathan does teach:
at least one alternate transaction option for the first user;
(Gurunathan US20200143375 at paras. 38-41) ("[0039] The user is provided with a plurality of authentication options to select an authentication option for validating authentication of the payment card and/or the user. Some examples of the plurality of authentication options may include, but are not limited to, a One-Time Password (OTP) option, a Quick-Response (QR) code option, a static password option and a biometric-based password option.")
receiving, by the second user device from the first user, a selection of an alternate transaction option from the at least one alternate transaction option; and
(Gurunathan US20200143375 at paras. 38-41) ("[0039] The user is provided with a plurality of authentication options to select an authentication option for validating authentication of the payment card and/or the user. Some examples of the plurality of authentication options may include, but are not limited to, a One-Time Password (OTP) option, a Quick-Response (QR) code option, a static password option and a biometric-based password option.")
processing, by the second user device, the transaction according to the selected alternate transaction option.
(Gurunathan US20200143375 at paras. 38-41) ("[0040] As the user selects the authentication option of the issuer interface, the issuer interface initiates an authentication session with a timeout period for the user to complete the authentication process. ")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, and Gurunathan, because it allows for an improved system for efficiently and securely authenticating the payment transaction. (Gurunathan at Abstract and paras. 1-9).
As per claim 14,
Foster explicitly teaches:
wherein the second user device receives the token.
(Foster US20210176615 at paras. 71, 78-80) ("[0079] At block 506, the first mobile device communicates with the second mobile device via the established communication channel to send a tokenized transaction identifier associated with the transaction to the second mobile device. The transaction identifier can be transmitted via a URL that includes instructions to cause the recipient device to perform one or more actions. An action can include displaying information to the second user, such as the amount of money the first user is transferring to the second user or instructions to download the mobile payment application.")
As per claim 15,
Foster explicitly teaches:
wherein the second user device receives the credential.
(Foster US20210176615 at paras. 34-41) ("[0037] To initiate a payment from the sender to a recipient, the sender device 110 can generate a tokenized transaction identifier that is transmitted to the recipient device 120 via a direct communication channel. Information about the transaction—such as an identity of the sender and the amount of money to transfer—is encoded into the tokenized transaction identifier generated uniquely for each transaction. In some embodiments, the tokenized transaction identifier is transmitted in a uniform resource locator (URL), which when accessed on the recipient device 120 causes the recipient device to perform one or more actions. can retrieve a unique identifier associated with the recipient. In some embodiments, the sender device 110 is configured to retrieve the recipient identifier over a direct peer-to-peer communication channel between the sender device 110 and recipient device 120. For example, the unique identifier can be a device identifier associated with the recipient device 120, such as an international mobile equipment identity (IMEI), a mobile equipment identifier (MEID), and/or a secure element identifier (SEID). In other cases, the sender device 110 can retrieve an identifier of the recipient by reading a visible code displayed by the recipient device 120 or printed on a sign. For example, a camera of the sender device 110 can be used to capture a quick response (QR) code that encodes an identifier of the recipient that can be read by the sender device 110." "[0040] In some embodiments, the recipient device 120 can be used to initiate a financial transaction by soliciting money from the sender. For example, the recipient device 120 can generate instructions to retrieve a unique identifier of the sender device over direct peer-to-peer communication. The recipient can use the payment app 115 to request money from the sender. If the transfer is confirmed by the sender, the payment app 115 can send the identifier of the sender device 110, an identifier of the recipient device 120, and an indication of the amount of money requested to the payment server 130 to conduct a transaction.")
As per claim 18,
Foster explicitly teaches:
receiving, by an interaction processing server from a second user device operated by a second user in a transaction between the second user and a first user, after the first user interacts a contactless portable device with the second user device, a payload comprising payload information comprising a credential or token, and transaction information;
(Foster US20210176615 at paras. 71, 78-80) ("[0078] At block 504, the first mobile device establishes a direct communication channel with a second device associated with the second user. For example, the first mobile device performs a handshake procedure to connect to the second device using Bluetooth. In another example, the first mobile device begins outputting a signal by a radio frequency or NFC transceiver that is detectable by a corresponding second device transceiver when the first mobile device comes into proximity to the second device. [0079] At block 506, the first mobile device communicates with the second mobile device via the established communication channel to send a tokenized transaction identifier associated with the transaction to the second mobile device. The transaction identifier can be transmitted via a URL that includes instructions to cause the recipient device to perform one or more actions. An action can include displaying information to the second user, such as the amount of money the first user is transferring to the second user or instructions to download the mobile payment application. For example, the URL may include a link that directs the recipient to the payment application 115 in an app store. Another example action includes causing the second mobile device to open the payment app 115 in an app store, enabling the recipient to immediately download the payment app 115. Once the recipient downloads the application 115, the recipient can register the application and create a profile, including entering bank account information that will allow the payment server 130 to transfer money to the recipient. Once the payment app 15 has been installed (or if the second mobile device already has the payment app 115 installed when the transaction is initiated), the action can include causing the payment app 115 to output information to complete the transaction. Example information output by the payment app 115 includes returning a unique device identifier of the second mobile device to the first device to allow the first device to complete the transaction at the payment server 130, or the payment app 115 communicating with the payment server 130 to send the tokenized transaction identifier and an identifier of the second device.")
Foster does not explicitly teach, however, Shah does teach:
determining, by the interaction processing server, if the payload information can be used to complete the transaction;
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
determining, by the interaction processing server that the payload information cannot be used to complete the transaction; and
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
transmitting, by the interaction processing server, a response message to the second user device,
(Shah US20190258786 at paras. 49-58) ("[0050] Referring to FIG. 2I, at step 233, client authentication computing platform 110 may determine updated user account state information corresponding to the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). For example, client authentication computing platform 110 may determine an updated security state of the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130) based on multi-channel authentication state information corresponding the user account and/or one or more authentication rules maintained by client authentication computing platform 110. At step 234, client authentication computing platform 110 may generate one or more step-up authentication prompt commands (e.g., based on the updated user account state information determined by client authentication computing platform 110). At step 235, client authentication computing platform 110 may send the one or more step-up authentication prompt commands to client computing device 130. At step 236, client authentication computing platform 110 may receive the one or more step-up authentication prompt commands from client authentication computing platform 110. For example, at step 236, after sending the second authentication request to the client authentication computing platform (e.g., client authentication computing platform 110), client computing device 130 may receive, via the communication interface, from the client authentication computing platform (e.g., client authentication computing platform 110), one or more step-up authentication prompt commands. [0051] Referring to FIG. 2J, at step 237, client computing device 130 may present one or more step-up authentication prompts. For example, at step 237, client computing device 130 may present one or more step-up authentication prompts based on the one or more step-up authentication prompt commands received from the client authentication computing platform (e.g., client authentication computing platform 110). In some instances, in presenting the one or more step-up authentication prompts based on the one or more step-up authentication prompt commands received from the client authentication computing platform (e.g., client authentication computing platform 110), client computing device 130 may display and/or otherwise present a graphical user interface similar to graphical user interface 600, which is illustrated in FIG. 6. As seen in FIG. 6, graphical user interface 600 may include one or more fields prompting the user of client computing device 130 to enter additional credentials, such as a one-time passcode associated with an online banking account or other user profile, information indicating that client computing device 130 is also collecting and verifying biometric data from linked wearable devices, and/or other user-selectable options and/or content.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster and Shah, because it allows for an improved system to provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with providing information security and preventing unauthorized access to resources of an information system by implementing advanced biometric authentication techniques. (Shah at Abstract and paras. 1-14).
Foster and Shah do not explicitly teach, however, Gurunathan does teach:
wherein the second user device provides options for completing the transaction to the first user.
(Gurunathan US20200143375 at paras. 38-41) ("[0039] The user is provided with a plurality of authentication options to select an authentication option for validating authentication of the payment card and/or the user. Some examples of the plurality of authentication options may include, but are not limited to, a One-Time Password (OTP) option, a Quick-Response (QR) code option, a static password option and a biometric-based password option.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, and Gurunathan, because it allows for an improved system for efficiently and securely authenticating the payment transaction. (Gurunathan at Abstract and paras. 1-9).
Claim 17 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claims 2, 4, 6, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375; in view of Borden, U.S. Patent Application Publication Number 2021/0125165.
As per claim 2,
Foster and Shah do not explicitly teach, however, Gurunathan does teach:
wherein, processing the transaction according to the selected alternate transaction option comprises:
(Gurunathan US20200143375 at paras. 38-41) ("[0040] As the user selects the authentication option of the issuer interface, the issuer interface initiates an authentication session with a timeout period for the user to complete the authentication process. ")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, and Gurunathan, because it allows for an improved system for efficiently and securely authenticating the payment transaction. (Gurunathan at Abstract and paras. 1-9).
Foster, Shah, and Gurunathan do not explicitly teach, however, Borden does teach:
displaying a QR code encoding transaction information, and then allowing a first user device to obtain an image of the QR code and to process the transaction according to the transaction information and the credential or the token.
(Borden US20210125165 at paras. 27-29) ("[0028] FIG. 2 illustrates a flow chart for a scan-to-pay method in which a user scans an encoding, such as a QR code, in order to be taken to a payment page to authorize a payment for a transaction. Steps illustrated on the top of the chart are conducted on the POS device and by the merchant. Steps illustrated on the bottom of the chart are conducted on the personal device and by the user. In a first optional step 201 a request to print an unpaid bill is received on a POS device the request can be a print command issued by the operator of the POS device. In a first decision block 202, if scan-to-pay is not enabled in the POS device, the flow chart continues to a step 206 in which a bill is printed without a QR code; and if scan-to-pay is enabled, the flow chart continues to a step 203 in which a QR code is generated or fetched and displayed. The QR can be generated and displayed by a native register application. Alternatively, the QR code can be fetched from the server architecture connected to the POS device. If the QR service is reachable, the flow chart continues to a step 205 of displaying or printing the unpaid bill with the QR code. If the QR service is not reachable, the flow chart continues to a step 206 of printing the bill without the QR code. In either of the above cases in which the bill is printed without the QR code, the bill can be paid without using the scan-to-pay channel, as represented in step 208. However, if the bill was displayed or printed with the QR code, the QR code can be provided to the user with the QR code as represented by step 207. The customer can then chose to pay using scan-to-pay or chose to pay using a conventional method such as tendering a credit card in step as represented by step 209. If at this point the user elects to not pay using other tender, they can do so it step 208. However, in the alternative, the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Borden, because it allows for improved systems and methods for efficiently processing a transaction using a point of sale (POS) system and a URL which is provisioned to a purchaser in the transaction. (Borden at Abstract and paras. 2-10).
As per claim 4,
Foster explicitly teaches:
wherein the contactless communication is an NFC communication.
(Foster US20210176615 at paras. 56-58) ("[0057] To initiate a payment, the sender can initiate a process using the sender device 110 to send a tokenized transaction identifier to the recipient device 120. For example, the sender can select an option in the payment app 115 that initiates a transaction. In some embodiments, the sender device 110 transmits the transaction identifier by generating a request that is output when an NFC transceiver of the sender device 110 comes into range of an NFC transceiver of the recipient device 120. For example, after selecting the option in the payment app 115, the sender device 110 begins emitting a signal via the NFC transceiver that causes the sender device 120 to send a URL containing the transaction identifier to the recipient device 120 when the sender taps the device 110 against the recipient's device 120. The sender device 110 can use communications protocols other than NFC.")
As per claim 6,
Foster and Shah do not explicitly teach, however, Gurunathan does teach:
wherein, processing the transaction according to the selected alternate transaction option comprises:
(Gurunathan US20200143375 at paras. 38-41) ("[0040] As the user selects the authentication option of the issuer interface, the issuer interface initiates an authentication session with a timeout period for the user to complete the authentication process. ")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, and Gurunathan, because it allows for an improved system for efficiently and securely authenticating the payment transaction. (Gurunathan at Abstract and paras. 1-9).
Foster, Shah, and Gurunathan do not explicitly teach, however, Borden does teach:
a process for providing a link to a first user device of the first user device, wherein the link directs the first user device to an application server, which allows the first user to complete the transaction.
(Borden US20210125165 at paras. 31-32) ("[0032] FIG. 5 illustrates a flow chart for an approach in which multiple URLs are provided to a user to complete more than one component of a transaction. Steps conducted by the personal device and purchaser are filled in white. Steps conducted by the POS device and merchant are filled in grey. In a first step 501, a customer enters an establishment such as a store, bar, or restaurant. In a next step 502, the establishment presents an advertisement such as a bar promo tent on a table with an encoded URL. The customer can then either scan (if the encoded URL is in a QR code) or tap (if the encoded URL is in an RFID tag) to obtain the encoded URL from the advertisement in step 503. In a next step 504, the personal device of the user is routed to an order page. The order page can be similar to the order pages described herein (e.g., it can allow a user to enter identifying information to serve as the basis for a future order, or it can allow the user to directly modify their purchase order). In the illustrated case, the order page includes a request for the customer to authorize a purchase order creation which is backed by a method of payment (e.g., an electronic wallet or credit card) in step 505. For example, the user could enter their Google Pay credentials. In a next step 506, the server architecture receives a payment token, customer name, and phone number from the payment system. This information can be provided from the electronic wallet after the user provides their credentials to the payment system, or it can be provided on the order page directly from the user. Next, in step 507, the server architecture creates a transaction and purchase order with the customer's name. The server architecture can then send an SMS message to the customer with a URL embedded in the message in step 508. Subsequently, the purchaser and merchant can create the purchase order for the user with reference to the customer's name in step 509. When the customer is ready to pay, the customer can click on a link in the SMS message in step 510. The personal device can then be routed to a payment page by a URL in the link in the SMS message which is associated with the purchase order and transaction that the server architecture initially created, in step 511. The customer can then complete checkout on the payment page in step 512. Finally, the server architecture can notify the merchant that the transaction has settled, in step 513. The notification can be provided to the merchant through the standard order fulfillment workflow of the POS device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Borden, because it allows for improved systems and methods for efficiently processing a transaction using a point of sale (POS) system and a URL which is provisioned to a purchaser in the transaction. (Borden at Abstract and paras. 2-10).
As per claim 19,
Foster, Shah, and Gurunathan do not explicitly teach, however, Borden does teach:
wherein the options include the generation of a QR code encoding the transaction information, which can be scanned by a first user device operated by the first user to complete the transaction.
(Borden US20210125165 at paras. 27-29) ("[0028] FIG. 2 illustrates a flow chart for a scan-to-pay method in which a user scans an encoding, such as a QR code, in order to be taken to a payment page to authorize a payment for a transaction. Steps illustrated on the top of the chart are conducted on the POS device and by the merchant. Steps illustrated on the bottom of the chart are conducted on the personal device and by the user. In a first optional step 201 a request to print an unpaid bill is received on a POS device the request can be a print command issued by the operator of the POS device. In a first decision block 202, if scan-to-pay is not enabled in the POS device, the flow chart continues to a step 206 in which a bill is printed without a QR code; and if scan-to-pay is enabled, the flow chart continues to a step 203 in which a QR code is generated or fetched and displayed. The QR can be generated and displayed by a native register application. Alternatively, the QR code can be fetched from the server architecture connected to the POS device. If the QR service is reachable, the flow chart continues to a step 205 of displaying or printing the unpaid bill with the QR code. If the QR service is not reachable, the flow chart continues to a step 206 of printing the bill without the QR code. In either of the above cases in which the bill is printed without the QR code, the bill can be paid without using the scan-to-pay channel, as represented in step 208. However, if the bill was displayed or printed with the QR code, the QR code can be provided to the user with the QR code as represented by step 207. The customer can then chose to pay using scan-to-pay or chose to pay using a conventional method such as tendering a credit card in step as represented by step 209. If at this point the user elects to not pay using other tender, they can do so it step 208. However, in the alternative, the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Borden, because it allows for improved systems and methods for efficiently processing a transaction using a point of sale (POS) system and a URL which is provisioned to a purchaser in the transaction. (Borden at Abstract and paras. 2-10).
As per claim 20,
Foster, Shah, and Gurunathan do not explicitly teach, however, Borden does teach:
wherein the options include a transmission of a link to a first user device, which can be used by the first user to complete the transaction.
(Borden US20210125165 at paras. 31-32) ("[0032] FIG. 5 illustrates a flow chart for an approach in which multiple URLs are provided to a user to complete more than one component of a transaction. Steps conducted by the personal device and purchaser are filled in white. Steps conducted by the POS device and merchant are filled in grey. In a first step 501, a customer enters an establishment such as a store, bar, or restaurant. In a next step 502, the establishment presents an advertisement such as a bar promo tent on a table with an encoded URL. The customer can then either scan (if the encoded URL is in a QR code) or tap (if the encoded URL is in an RFID tag) to obtain the encoded URL from the advertisement in step 503. In a next step 504, the personal device of the user is routed to an order page. The order page can be similar to the order pages described herein (e.g., it can allow a user to enter identifying information to serve as the basis for a future order, or it can allow the user to directly modify their purchase order). In the illustrated case, the order page includes a request for the customer to authorize a purchase order creation which is backed by a method of payment (e.g., an electronic wallet or credit card) in step 505. For example, the user could enter their Google Pay credentials. In a next step 506, the server architecture receives a payment token, customer name, and phone number from the payment system. This information can be provided from the electronic wallet after the user provides their credentials to the payment system, or it can be provided on the order page directly from the user. Next, in step 507, the server architecture creates a transaction and purchase order with the customer's name. The server architecture can then send an SMS message to the customer with a URL embedded in the message in step 508. Subsequently, the purchaser and merchant can create the purchase order for the user with reference to the customer's name in step 509. When the customer is ready to pay, the customer can click on a link in the SMS message in step 510. The personal device can then be routed to a payment page by a URL in the link in the SMS message which is associated with the purchase order and transaction that the server architecture initially created, in step 511. The customer can then complete checkout on the payment page in step 512. Finally, the server architecture can notify the merchant that the transaction has settled, in step 513. The notification can be provided to the merchant through the standard order fulfillment workflow of the POS device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Borden, because it allows for improved systems and methods for efficiently processing a transaction using a point of sale (POS) system and a URL which is provisioned to a purchaser in the transaction. (Borden at Abstract and paras. 2-10).
Claims 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375; in view of Borden, U.S. Patent Application Publication Number 2021/0125165; in view of Pai, U.S. Patent Application Publication Number 2024/0086500.
As per claim 3,
Foster, Shah, Gurunathan, and Borden do not explicitly teach, however, Pai does teach:
wherein the portable device is a card.
(Pai US20240086500 at paras. 28-30) ("[0029] The transaction device 220 may include one or more devices capable of being used for an electronic transaction. In some implementations, the transaction device 220 may include a transaction card (or another physical medium with integrated circuitry) capable of storing and communicating account information, such as a credit card, a debit card, a gift card, an ATM card, a transit card, a fare card, and/or an access card. In some implementations, the transaction device 220 may be the user device 230 or may be integrated into the user device 230. For example, the user device 230 may execute an electronic payment application capable of performing functions of the transaction device 220 described herein. Thus, one or more operations described herein as being performed by the transaction device 220 may be performed by a transaction card, the user device 230, or a combination thereof.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, Borden, and Pai, because it allows for an improved system for use of a payment credential in a transaction, thereby improving information security and/or reducing monetary losses, and reducing a risk of credit card fraud. (Pai at Abstract and paras. 9-14).
As per claim 5,
Foster explicitly teaches:
wherein the first user device is a first mobile phone, the second user device is a second mobile phone, and
(Foster US20210176615 at paras. 35-38) ("[0035] The sender device 110 is a mobile device used by a person who wants to give money to another person (referred to herein as a “sender”)." "[0038] The recipient device 120 is a mobile device used by a person who receives money from a sender (referred to herein as a “recipient”).")
Foster, Shah, Gurunathan, and Borden do not explicitly teach, however, Pai does teach:
the portable device is a card.
(Pai US20240086500 at paras. 28-30) ("[0029] The transaction device 220 may include one or more devices capable of being used for an electronic transaction. In some implementations, the transaction device 220 may include a transaction card (or another physical medium with integrated circuitry) capable of storing and communicating account information, such as a credit card, a debit card, a gift card, an ATM card, a transit card, a fare card, and/or an access card. In some implementations, the transaction device 220 may be the user device 230 or may be integrated into the user device 230. For example, the user device 230 may execute an electronic payment application capable of performing functions of the transaction device 220 described herein. Thus, one or more operations described herein as being performed by the transaction device 220 may be performed by a transaction card, the user device 230, or a combination thereof.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, Borden, and Pai, because it allows for an improved system for use of a payment credential in a transaction, thereby improving information security and/or reducing monetary losses, and reducing a risk of credit card fraud. (Pai at Abstract and paras. 9-14).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375; in view of Cox, U.S. Patent Application Publication Number 2022/0321405.
As per claim 7,
Foster does not explicitly teach, however, Shah does teach:
wherein determining, by the first user device, that the transaction cannot be completed without further interaction by the first user,
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster and Shah, because it allows for an improved system to provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with providing information security and preventing unauthorized access to resources of an information system by implementing advanced biometric authentication techniques. (Shah at Abstract and paras. 1-14).
Foster, Shah, and Gurunathan do not explicitly teach, however, Cox does teach:
is based on a requirement that a secret of the first user is required to be entered into the second device, but the second device is incapable of processing the secret.
(Cox US20220321405 at paras. 28-35) ("[0033] FIG. 4 illustrates a method for enabling the PIN pads for microprocessor-enabled payment vehicles and contactless payment vehicles. In operation 410, POS 112 or ISV 280 may request enabling PIN pad 114 to support microprocessor-enabled payment vehicles and contactless payment vehicles. Configuration service 220, may receive the request from POS 112 or ISV 280 through POS engine 250 and PIN pad actor 240 to enable the PIN pad to accept at least one of microprocessor-enabled payment vehicles and contactless payment vehicles. At operation 420, configuration service 220 may retrieve a PIN pad configuration hash value from PIN pad 114 through socket gateway 210. In operation 430, the configuration service 220 may obtain the current configuration associated with the PIN pad configuration hash value. In operation 440, configuration service 220 may determine whether PIN pad 114 is configured for reading at least one of the microprocessor-enabled payment vehicles and contactless payment vehicles but that such capability is disabled. [0034] In operation 450, upon determining that PIN pad 114 is configured for reading at least one of the microprocessor-enabled payment vehicles and contactless payment vehicles but that such capability is disabled, configuration service 220 may generate instructions to enable PIN pad 114 for reading at least one of microprocessor-enabled payment vehicles and contactless payment vehicles. Configuration service 220 may send the instructions to enable PIN pad 114 for reading at least one of microprocessor-enabled payment vehicles and contactless payment vehicles, over the computer network, according to operation 452.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Cox, because it allows for an improved system for electronic payment processing and, more particularly, to managing the configuration of personal identification number (PIN) pad terminals associated with a merchant point of sale (POS). (Cox at Abstract and paras. 9-14).
As per claim 8,
Foster does not explicitly teach, however, Shah does teach:
wherein determining, by the first user device, that the transaction cannot be completed without further interaction by the first user, is based on a requirement that an authorizing entity associated with the credential or token requires that the first user device be in contact with the second user device to conduct the transaction,
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster and Shah, because it allows for an improved system to provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with providing information security and preventing unauthorized access to resources of an information system by implementing advanced biometric authentication techniques. (Shah at Abstract and paras. 1-14).
Foster, Shah, and Gurunathan do not explicitly teach, however, Cox does teach:
but the first user device and the second user device are incapable of being on physical and electrical contact with each other.
(Cox US20220321405 at paras. 28-35) ("[0033] FIG. 4 illustrates a method for enabling the PIN pads for microprocessor-enabled payment vehicles and contactless payment vehicles. In operation 410, POS 112 or ISV 280 may request enabling PIN pad 114 to support microprocessor-enabled payment vehicles and contactless payment vehicles. Configuration service 220, may receive the request from POS 112 or ISV 280 through POS engine 250 and PIN pad actor 240 to enable the PIN pad to accept at least one of microprocessor-enabled payment vehicles and contactless payment vehicles. At operation 420, configuration service 220 may retrieve a PIN pad configuration hash value from PIN pad 114 through socket gateway 210. In operation 430, the configuration service 220 may obtain the current configuration associated with the PIN pad configuration hash value. In operation 440, configuration service 220 may determine whether PIN pad 114 is configured for reading at least one of the microprocessor-enabled payment vehicles and contactless payment vehicles but that such capability is disabled. [0034] In operation 450, upon determining that PIN pad 114 is configured for reading at least one of the microprocessor-enabled payment vehicles and contactless payment vehicles but that such capability is disabled, configuration service 220 may generate instructions to enable PIN pad 114 for reading at least one of microprocessor-enabled payment vehicles and contactless payment vehicles. Configuration service 220 may send the instructions to enable PIN pad 114 for reading at least one of microprocessor-enabled payment vehicles and contactless payment vehicles, over the computer network, according to operation 452.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Cox, because it allows for an improved system for electronic payment processing and, more particularly, to managing the configuration of personal identification number (PIN) pad terminals associated with a merchant point of sale (POS). (Cox at Abstract and paras. 9-14).
Claims 9 and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375; in view of Gosset, U.S. Patent Application Publication Number 2019/0392450.
As per claim 9,
Foster, Shah, and Gurunathan do not explicitly teach, however, Gosset does teach:
wherein the determination that the transaction cannot be completed is based on a total value of the transaction.
(Gosset US20190392450 at paras. 154-157) ("[0156] Transactions in some regulated markets may be subject to forced SCA for all transactions. In the example embodiment, the regulated market for this example transaction has opted into conditional SCA as described herein. In such markets, regulators may generally mandate SCA on transactions, but may allow transactions to be authenticated without SCA in particular circumstances. As such, directory server 610 identifies a transaction limit and a risk threshold for conditional SCA of that particular regulated market. The transaction limit represents a threshold transaction value below which SCA may be avoided if the risk threshold is also satisfied. In the embodiments described herein, the transaction limit may be, for example, a monetary value for a particular transaction (e.g., 2000 rupees, 30 Euro, etc.), a number of transactions (e.g., 5 frictionless transactions), or a cumulative monetary value (e.g., 100 Euro). Accordingly, the transaction limit may be defined by parameters other than a monetary value of the transaction. Those of skill in the art will appreciate that any suitable type of transaction limit may be established.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Gosset, because it allows for an improved system for authenticating online users over an electronic network, and more particularly, to authenticating online users using risk-based authentication in regulated environments. (Gosset at Abstract and paras. 2-10).
As per claim 11,
Foster, Shah, and Gurunathan do not explicitly teach, however, Gosset does teach:
wherein the at least one alternate transaction option is more secure than a transaction process conducted with the second user device.
(Gosset US20190392450 at paras. 154-157) ("[0156] Transactions in some regulated markets may be subject to forced SCA for all transactions. In the example embodiment, the regulated market for this example transaction has opted into conditional SCA as described herein. In such markets, regulators may generally mandate SCA on transactions, but may allow transactions to be authenticated without SCA in particular circumstances. As such, directory server 610 identifies a transaction limit and a risk threshold for conditional SCA of that particular regulated market. The transaction limit represents a threshold transaction value below which SCA may be avoided if the risk threshold is also satisfied. In the embodiments described herein, the transaction limit may be, for example, a monetary value for a particular transaction (e.g., 2000 rupees, 30 Euro, etc.), a number of transactions (e.g., 5 frictionless transactions), or a cumulative monetary value (e.g., 100 Euro). Accordingly, the transaction limit may be defined by parameters other than a monetary value of the transaction. Those of skill in the art will appreciate that any suitable type of transaction limit may be established.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Gosset, because it allows for an improved system for authenticating online users over an electronic network, and more particularly, to authenticating online users using risk-based authentication in regulated environments. (Gosset at Abstract and paras. 2-10).
As per claim 12,
Foster explicitly teaches:
further comprising: transmitting, by the second user device to an interaction processing server, a payload comprising payload information comprising the credential or token, and transaction information,
(Foster US20210176615 at paras. 61-64) ("[0062] The sender device 110 or the recipient device 120 sends the tokenized transaction identifier and an identifier of the recipient device 120 to the payment server 130. Using the tokenized transaction identifier and the identifier of the recipient device 120, the payment server 130 identifies the recipient and accesses a profile associated with the recipient. The payment server 130 stores the information received from the sender device 110 as transaction data. [0063] The payment server 130 can generate bank transfer instructions to cause a transfer of money from the sender to the recipient. The bank transfer instructions specify a financial account associated with the sender (which is stored, for example, in the sender's user profile), a financial account associated with the recipient (stored, for example, in the recipient's user profile), and the amount of money the sender wishes to send to the recipient. The payment server 130 sends the instructions to the financial system that maintains the sender's account, causing the financial system to transfer the amount of money specified by the sender from the sender's account to the recipient's account.")
Foster does not explicitly teach, however, Shah does teach:
wherein the second user device determines that transaction cannot be completed without further interaction after receiving the message.
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster and Shah, because it allows for an improved system to provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with providing information security and preventing unauthorized access to resources of an information system by implementing advanced biometric authentication techniques. (Shah at Abstract and paras. 1-14).
Foster, Shah, and Gurunathan do not explicitly teach, however, Gosset does teach:
which determines that the transaction cannot be completed without further interaction by the first user and generates a message indicating that the transaction cannot be completed without further interaction, and
(Gosset US20190392450 at paras. 154-157, 164-165) ("[0154] FIGS. 11A and 11B are swim-lane diagrams illustrating additional example embodiments involving conditional SCA evaluation on transactions associated with a regulated market. FIG. 11A is directed to transactions that are allowed to avoid regulator-imposed SCA step-up challenges when the transactions are determined to be of sufficiently low risk and low value. FIG. 11B is directed to transactions that are forced into SCA step-up challenges when the transactions are more risky or when the transactions are of higher value. In such scenarios, any of the above-described systems and methods involving the RBA-enabled directory server (or just “directory server”) 610 and RBA engine 612 may be employed in conjunction with conditional SCA, subject to the restrictions imposed by regulators as described herein." "[0164] Referring now to FIG. 11B, in this example, the authentication platform determines that the transaction does not meet the requirements to avoid SCA step-up and, as such, SCA step-up is mandated. In the example embodiment, RBA engine 612 determines, at step 1150, that either the transaction value is above the transaction limit set by the regulatory entity, or that the transaction risk does not satisfy the risk threshold set by the regulatory entity, or both. If, at test 1152, the authentication platform is acting on behalf of issuer 514, and presuming no other reason for denying authentication of the transaction, RBA engine 612 prompts step-up 1156 of consumer 22 at step 1154. Consumer 22 responds with step-up input 1142 at step 1140, either directly with directory server 610 or via 3DS server 506 at step 1158 and, upon successful step-up challenge, 3DS server 506 transmits ARes message 1106 to 3DS server 506 approving authentication of the transaction. [0165] If, at test 1152, ACS 512 is acting on behalf of issuer 514, RBA engine 612 transmits, at step 1154, the enhanced AReq 1108 (represented here by 1162) along with an indication to force SCA step-up challenge of consumer 22 for this transaction. Enhanced AReq may include, in addition to the additional RBA data described above associated with 3DS 2, a data field mandating ACS 512 to perform SCA step-up for the transaction (e.g., if the transaction is otherwise deemed to be approved for authentication by ACS 512). In other words, AReq 1108 serves to inform ACS 512 that the transaction may not be authenticated without SCA. Presuming no other reason to reject authentication of the transaction, ACS 512 identifies that the transaction is subject to a mandated SCA step-up and prompts step-up 1138 in steps 1136, 1140, 1144, and transmits ARes 1132 approving the transaction in steps 1146 and 1120, as described above.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Gosset, because it allows for an improved system for authenticating online users over an electronic network, and more particularly, to authenticating online users using risk-based authentication in regulated environments. (Gosset at Abstract and paras. 2-10).
As per claim 13,
Foster, Shah, and Gurunathan do not explicitly teach, however, Gosset does teach:
wherein the interaction processing server comprises a rules database with rules that are used to make determination that the transaction cannot be completed without further interaction.
(Gosset US20190392450 at paras. 154-157) ("[0025] The systems and methods described herein are directed to “conditional” strong consumer authentication of online users in regulated markets. A risk-based authentication enabled (RBA-enabled) directory server stores an authentication profile which includes rules for performing and routing authentication requests." "[0085] Database 120 may store one or more authentication profiles, where each authentication profile includes one or more authentication rules, one or more risk level thresholds, and one or more routing rules based on the risk level thresholds." "[0156] Transactions in some regulated markets may be subject to forced SCA for all transactions. In the example embodiment, the regulated market for this example transaction has opted into conditional SCA as described herein. In such markets, regulators may generally mandate SCA on transactions, but may allow transactions to be authenticated without SCA in particular circumstances. As such, directory server 610 identifies a transaction limit and a risk threshold for conditional SCA of that particular regulated market. The transaction limit represents a threshold transaction value below which SCA may be avoided if the risk threshold is also satisfied. In the embodiments described herein, the transaction limit may be, for example, a monetary value for a particular transaction (e.g., 2000 rupees, 30 Euro, etc.), a number of transactions (e.g., 5 frictionless transactions), or a cumulative monetary value (e.g., 100 Euro). Accordingly, the transaction limit may be defined by parameters other than a monetary value of the transaction. Those of skill in the art will appreciate that any suitable type of transaction limit may be established.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Gosset, because it allows for an improved system for authenticating online users over an electronic network, and more particularly, to authenticating online users using risk-based authentication in regulated environments. (Gosset at Abstract and paras. 2-10).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375; in view of Yerradoddi, U.S. Patent Application Publication Number 2020/0320534.
As per claim 10,
Foster does not explicitly teach, however, Shah does teach:
wherein determining, by the second user device, that the transaction cannot be completed without further interaction by the first user comprises
(Shah US20190258786 at paras. 49-58) ("[0049] At step 231, client computing device 130 may receive a request for a high-security transaction, such as a high-value transfer of funds, a transfer of funds to an external account, or the like, and a step-up authentication routine may be performed, as illustrated in greater detail below. For example, at step 231, client computing device 130 may receive input requesting a high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130). At step 232, client computing device 130 may send an authentication request to client authentication computing platform 110. For example, at step 232, based on receiving the input requesting the high-security transaction involving the user account associated with the mobile banking application installed on the computing device (e.g., client computing device 130), client computing device 130 may send, via the communication interface, to the client authentication computing platform (e.g., client authentication computing platform 110), a second authentication request.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster and Shah, because it allows for an improved system to provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with providing information security and preventing unauthorized access to resources of an information system by implementing advanced biometric authentication techniques. (Shah at Abstract and paras. 1-14).
Foster, Shah, and Gurunathan do not explicitly teach, however, Yerradoddi does teach:
determining that the second user device is not sufficiently secure to complete the transaction.
(Yerradoddi US20200320534 at paras. 51-53) ("[0052] In some embodiments, the event analysis manager 202 may also retrieve device information of the user device (e.g., the user device 110) used by the consumer (e.g., the user 140) in conducting the transaction. For example, the event analysis manager 202 may retrieve, from the user device 110, information such as a location of the user device 110 when the transaction was conducted, a language used on the device, a device type (e.g., a desktop, a mobile device, etc.), an operating system running on the device, a browser running on the device, and other information that may be obtained from the user device 110. In some embodiments, the event analysis manager 202 may derive a device risk level based on the device information. For example, the risk level of a device (e.g., the user device 110) that is involved with the transaction may be initialized with a zero value, and the event analysis manager 202 may increase the risk level of the user device 110 (e.g., by a predetermined value) when the event analysis manager 202 determines risk indicators that indicates a risk based on the device information. The risk indicators may include an inconsistency between the location of the user device 110 and the language used on the user device 110, a browser type of the browser used to conduct the transaction, an inconsistency between the location of the user device 110 and the destination address of the shipment, etc. The determined risk level of the user device 110 and/or the risk indicators determined for the user device 110 may be provided to the machine learning model for determining the likelihood of the event.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Yerradoddi, because it allows for improved methods and systems for predicting a risk level of an event associated with an electronic transaction based on monitoring user interactions of a user with one or more computing systems. (Yerradoddi at Abstract and paras. 1-12).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Foster, U.S. Patent Application Publication Number 2021/0176615; in view of Shah, U.S. Patent Application Publication Number 2019/0258786; in view of Gurunathan, U.S. Patent Application Publication Number 2020/0143375; in view of Pai, U.S. Patent Application Publication Number 2024/0086500.
As per claim 16,
Foster, Shah, and Gurunathan do not explicitly teach, however, Pai does teach:
wherein the credential is an account identifier for an account of the first user.
(Pai US20240086500 at paras. 18-20) (“[0019] As further shown in FIG. 1A, and by reference number 120, the user device may access the credential system and may identify a physical merchant location. For example, as described herein, the credential system may be associated with a financial institution, such as a bank or a credit card, and a user of the user device may own one or more accounts that are managed through the credential system (e.g., the user may be a holder of the one or more accounts or a person who is authorized to enter into transactions using the one or more accounts). For example, in some implementations, the one or more accounts may include a credit card account, a checking account, a savings account, an investment account, or another suitable account type. Furthermore, in some implementations, the one or more accounts may each be associated with a primary account number (PAN) or a primary payment credential that can be used to enter into transactions using the associated account. For example, the PAN or primary payment credential may be associated with a credit card, whereby amounts associated with transactions that are performed using the credit card may be added to a balance of the PAN or primary payment credential. In another example, the PAN or primary payment credential may be associated with a debit card, whereby amounts associated with transactions that are performed using the debit card may be deducted from a balance of the PAN or primary payment credential (e.g., from a balance in a checking or savings account).”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Foster, Shah, Gurunathan, and Pai, because it allows for an improved system for use of a payment credential in a transaction, thereby improving information security and/or reducing monetary losses, and reducing a risk of credit card fraud. (Pai at Abstract and paras. 9-14).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights