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 .
Applicant filed a response dated April 1, 2026 in which claims 1, 3, 4, 6, 8-11, 13-18, and 20 have been amended; claim 5 has been canceled, and claim 21 has been added. Therefore, claims 1-4 and 6-21 are currently pending in the application.
Priority
Application 18/759,533 was filed on 06/28/2024 and claims benefit of 63/524,601 06/30/2023.
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-4 and 6-21 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, system, 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 transaction provisioning system, comprising: an authentication server, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server: receives, from a backend server, a session creation request for provisioning the contactless card,
transmits, to the backend server, a session creation response and a session token,
receives, from the backend server, an authentication process function request comprising encrypted data associated with the contactless card and one or more risk signals,
the one or more risk signals comprising an account risk score and a device risk score,
decrypts the encrypted data to yield a decrypted authentication code,
compares the decrypted authentication code to the expected authentication code,
transmits, to the backend server after an unsuccessful comparison, a notification indicating an unsuccessful authentication,
assesses the one or more risk signals,
transmits, to the backend server after determining the authentication process function request is fraudulent based on the one or more risk signals, a notification indicating a fraudulent transaction, and
transmits, to the backend server after a successful comparison and determining the authentication process function request is not fraudulent based on the one or more risk signals, a session identifier associated with the session creation request and a funding primary account number.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate authentication and provision of a payment card to perform financial transactions. 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.
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 “A transaction provisioning system, comprising: an authentication server in data communication, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server:”, “a backend server”, “contactless card”, and “token server”, to perform the steps of “authenticating”, “decrypting”, “comparing”, and “assessing”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. 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 authentication and provision of a payment card to perform financial transactions in a computer environment. 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 “[0098] FIG. 3 illustrates an example configuration of a contactless card 102, which may include a contactless card, a payment card, such as a credit card, debit card, or gift card, issued by a service provider as displayed as service provider indicia 302 on the front or back of the contactless card 102. In some examples, the contactless card 102 is not related to a payment card, and may include, without limitation, an identification card. In some examples, the transaction card may include a dual interface contactless payment card, a rewards card, and so forth.” “[0240] System 1600 can include a client node 1602, which can be a network-enabled computer as described herein. In some examples, client node 1602 can be a server, which can be a dedicated server computer, a bladed server, or can be a personal computer, a laptop computer, a notebook computer, a palm top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1600.” “[0242]The client node can contain an API 1604. For example, various different APIs can be provided for an application (e.g., executed on a computing device, such as a network-enabled computer) that can interact with a service. For example, an application executed on a device (e.g., a smart phone, smart watch, tablet, laptop, or other device) call interact with a web-based service by calling the API 1604 to interact with the service, such as by performing a remote call to an API for interacting with a web-based service.” “[0245]System 1600 can include a validation node 1608, which can be a network-enabled computer as described herein. In some examples, validation node 1608 can be a server, which can be a dedicated server computer, a bladed server, or can be a personal computer, a laptop computer, a notebook computer, a palm top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1600.” “[0248]System 1600 can include a distributed ledger node 1610, which can be a network-enabled computer as described herein. In some examples, distributed ledger node 1610 can be a server, which can be a dedicated server computer, a bladed server, or can be a personal computer, a laptop computer, a notebook computer, a palm top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1600.” “[0255] System 1600 can include a client device 1614, which can be a network-enabled computer as described herein. In some examples, distributed ledger node 1614 can be a server, which can be a dedicated server computer, a bladed server, or can be a personal computer, a laptop computer, a notebook computer, a palm top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1600. Client device 1614 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple or any other mobile device running Apple’s iOS operating system, any device running Microsoft’s Windows Mobile operating system, any device running Google’s Android operating system, and/or any other smartphone, tablet, or like wearable mobile device. In some examples, client device 1614 can be in data communication with another network-enabled computer not shown in FIG. 16, such as a smart card (e.g., a contactless card or a contact-based card).”
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 transaction provisioning system, comprising: an authentication server in data communication, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server:”, “a backend server”, “contactless card”, and “token server”, to perform the steps of “authenticating”, “decrypting”, “comparing”, and “assessing”, 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 authentication and provision of a payment card to perform financial transactions 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”.
Claims 11 and 18 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 11 recites the additional elements of “A transaction provisioning method performed by an authentication server comprising a processor and a memory, the method comprising:”.
Claim 18 recites the additional elements of “A non-transitory computer readable medium containing instructions, wherein, upon execution by a processor, the instructions cause the processor to perform procedures comprising:”.
Claims 2 and 19 recite the additional elements of “a token server”.
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-4, 6-10, 12-17, and 19-21 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-4 and 6-21 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, 3, 6, 8, 11, 13, 16, 18, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Wong, U.S. Patent Application Publication Number 2022/0327527; in view of Goldman, U.S. Patent Application Publication Number 2018/0033089.
As per claim 1,
Wong explicitly teaches:
A transaction provisioning system, comprising: an authentication server, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server: receives, from a backend server, a session creation request for provisioning the contactless card,
(Wong US20220327527 at paras. 10-12, 60-62, 117-120) ("[0011] According to an embodiment, a method performed by a service provider for provisioning account credentials includes receiving, at a server computer via a first communication channel, a first provisioning request to provision a first payment credential to a first mobile device." "[0011] In an embodiment, a non-transitory computer readable medium stores instructions that when executed by a processor of a server cause the server to perform this method. In an embodiment, a server computer is described that includes a processor and the described non-transitory computer readable medium. In an embodiment, a payment account credential provisioning system is described that includes this server computer, and one or more of an issuer computer, a wallet provider server computer, and a mobile device." "[0120] The second DVV variant 600A includes—instead of generating a DVV as in block 410 of FIG. 4—transmitting a DVV request message 650 (including the delivery choice indicated in the DVV delivery choice message 462) to the issuer 240, which itself will generate the DVV at block 602, provide the DVV to the user at block 466 according to the delivery choice over the second communications channel, and return the generated DVV in message 652 to the service provider 230. The service provider 230 may store this DVV at block 604. After the user has received the DVV over the second communications channel, the user will enter the DVV into the mobile device 101 (e.g., using a mobile wallet application), which will send the entered-DVV in a message 468 to the wallet provider 210. The wallet provider 210 will then transmits a resume account message 470 including the DVV to the service provider 230, which can determine the validity of the authentication by validating the DVV at block 606, which includes comparing the stored DVV (from block 604) with the received user-entered DVV (from message 470). If the values match or are otherwise deemed equivalent, the DVV is validated and thus the authentication succeeds; otherwise, the DVV is not validated and the authentication fails.")
transmits, to the backend server, a session creation response and a session token,
(Wong US20220327527 at paras. 10-12, 60-62) ("[0061] The provisioning service module 225 may then attempt to verify the provided user authentication information. For example, if the request for provisioning included a PAN and a cryptogram, provisioning service module 225 may retrieve a master encryption key, use the master encryption key to decrypt the cryptogram, and ensure that the decrypted value is an expected value (e.g., corresponding to received value of the PAN). The provisioning service module 225 may then generate a payment token to provision onto the mobile device using token service 222. The payment token represents a PAN or other account number to be provisioned on the mobile device, and may comprise the actual PAN provided in the provisioning request, a generated token, the PAN together with a PAN sequence number, or another item of payment information to identify the account when used through the mobile payment application 208C. The payment token may be included in the personalization data later stored onto the mobile device 101.")
receives, from the backend server, an authentication process function request comprising encrypted data associated with the contactless card and one or more risk signals,
(Wong US20220327527 at paras. 10-12, 60-62, 79-83, 91) ("[0061] The provisioning service module 225 may then attempt to verify the provided user authentication information. For example, if the request for provisioning included a PAN and a cryptogram, provisioning service module 225 may retrieve a master encryption key, use the master encryption key to decrypt the cryptogram, and ensure that the decrypted value is an expected value (e.g., corresponding to received value of the PAN). The provisioning service module 225 may then generate a payment token to provision onto the mobile device using token service 222. The payment token represents a PAN or other account number to be provisioned on the mobile device, and may comprise the actual PAN provided in the provisioning request, a generated token, the PAN together with a PAN sequence number, or another item of payment information to identify the account when used through the mobile payment application 208C. The payment token may be included in the personalization data later stored onto the mobile device 101." "[0080] The provisioning request message 366, in some embodiments, includes device information (to identify the mobile device 101 and secure element 202, and may include any unique identifier for the device to identify the secure element keys necessary), consumer identifier or login information/credentials (to identify the user 107), account credentials (e.g., a PAN and/or a card verification value (e.g., CVV2 for card verification based authentication processes)), and/or a zip code (for geographic based authentication processes). The provisioning request message 366 is sent by the mobile device 101 to wallet provider 210, which may generate a risk score (or perform a “risk check” or “risk analysis” to generate risk assessment data) at block 313 based upon the provisioning request message 366. This risk analysis may occur based upon the requesting user 107, account, card, mobile device 101, or any other data that is present in the provisioning request message 366 (e.g., a CVV2 value, ZIP Code, User Identifier, etc.) or is tied to the account of the user 107 submitting the provisioning request (e.g., previously registered/provisioned card data, determining how long the account has been open, how many cards the consumer uses in total or has used, a number of purchases in the past, etc.)." "[0091] In some embodiments, the this message 376 includes one or more of the token (which may be encrypted)")
decrypts the encrypted data to yield a decrypted authentication code,
(Wong US20220327527 at paras. 10-12, 60-62) ("[0061] The provisioning service module 225 may then attempt to verify the provided user authentication information. For example, if the request for provisioning included a PAN and a cryptogram, provisioning service module 225 may retrieve a master encryption key, use the master encryption key to decrypt the cryptogram, and ensure that the decrypted value is an expected value (e.g., corresponding to received value of the PAN). The provisioning service module 225 may then generate a payment token to provision onto the mobile device using token service 222. The payment token represents a PAN or other account number to be provisioned on the mobile device, and may comprise the actual PAN provided in the provisioning request, a generated token, the PAN together with a PAN sequence number, or another item of payment information to identify the account when used through the mobile payment application 208C. The payment token may be included in the personalization data later stored onto the mobile device 101.")
compares the decrypted authentication code to the expected authentication code,
(Wong US20220327527 at paras. 10-12, 60-62) ("[0061] The provisioning service module 225 may then attempt to verify the provided user authentication information. For example, if the request for provisioning included a PAN and a cryptogram, provisioning service module 225 may retrieve a master encryption key, use the master encryption key to decrypt the cryptogram, and ensure that the decrypted value is an expected value (e.g., corresponding to received value of the PAN). The provisioning service module 225 may then generate a payment token to provision onto the mobile device using token service 222. The payment token represents a PAN or other account number to be provisioned on the mobile device, and may comprise the actual PAN provided in the provisioning request, a generated token, the PAN together with a PAN sequence number, or another item of payment information to identify the account when used through the mobile payment application 208C. The payment token may be included in the personalization data later stored onto the mobile device 101.")
transmits, to the backend server after an unsuccessful comparison, a notification indicating an unsuccessful authentication,
(Wong US20220327527 at paras. 10-12, 60-62, 65-67, 80-81) ("[0066] When provisioning service module 225, for example, has determined that it has received a partial personalization confirmation message and that it has made an authentication decision, the provisioning service module 225 may send an activation message or a deletion message to application provider 209 server computer 211. For example, provisioning service module 225 may send an activation message if the partial personalization confirmation message indicated a successful execution of the script and the authentication result indicates a successful authentication of the user. Similarly, provisioning service module 225 may send a deletion message if either the partial personalization confirmation message or authentication result indicates a failure. ")
assesses the one or more risk signals,
(Wong US20220327527 at paras. 36, 60, 80-88) ("[0036] As used herein, a “risk score” may include an arbitrary designation or ranking that represents the risk associated that a transaction may be fraudulent. The risk score may be represented by a number (and any scale), a probability, or in any other relevant manner of conveying such information. The risk score may comprise an aggregation of information about a transaction, including transaction information, account information, and verification information as defined above. The risk score may be used by any authorizing entity (such as a merchant or an issuer) in determining whether to approve a transaction. The risk score may comprise and/or utilize both current transaction information and past transaction information, and may weight such information in any suitable manner." "[0060] The application provider 209 server computer 211 receives the request for provisioning message, and may perform a risk check or risk analysis for the requesting user 107, account, mobile device 101, or any other data that is present in the received request for provisioning message, or is tied to a user's account associated with the request for provisioning message. For example, the risk check may involve determining how many times the user's account has been provisioned and how many accounts are provisioned on mobile device 101. The risk check may, for example, indicate the likelihood that the request for provisioning is fraudulent. if the risk check indicates that the risk of provisioning is acceptable, then application provider 209 server computer 211 may send the request for provisioning to provisioning service module 225 executing at service provider 230 server computer 212." "[0087] At block 318, the service provider 230 determines which level of risk was determined. As depicted, block 318 indicates identifying whether the level of risk was “High,” “Medium,” or “Low.” Of course, although in some embodiments the levels of risk may be explicitly categorical (and thus uniquely identify which risk category is determined), in other embodiments the levels of risk may be in other formats (e.g., a risk score is generated that is an integer between 0 and 100, for example, and thus the determination of the risk category may include determining if the risk score is within a range of values, meets or exceeds a value, is below a value, etc.).")
transmits, to the backend server after determining the authentication process function request is fraudulent based on the one or more risk signals, a notification indicating a fraudulent transaction, and
(Wong US20220327527 at paras. 36, 48, 60, 87) ("[0036] As used herein, a “risk score” may include an arbitrary designation or ranking that represents the risk associated that a transaction may be fraudulent. The risk score may be represented by a number (and any scale), a probability, or in any other relevant manner of conveying such information. The risk score may comprise an aggregation of information about a transaction, including transaction information, account information, and verification information as defined above. The risk score may be used by any authorizing entity (such as a merchant or an issuer) in determining whether to approve a transaction. The risk score may comprise and/or utilize both current transaction information and past transaction information, and may weight such information in any suitable manner." "[0048] The payment processing network 105 receives the authorization response message from the issuer computer 106 and transmits the authorization response message back to the acquirer computer 104. The acquirer computer 104 then sends the authorization response message back to the merchant computer 103, where the merchant can determine whether to proceed with the transaction. In some embodiments, such as when a fraud rule is triggered at payment processing network 105, payment processing network 105 may decline a transaction previously authorized by issuer computer 106. After the merchant computer 103 receives the authorization response message, the access device 102 may then provide an authorization response message for the user 107. The response message may be displayed by a display device (e.g., a display device that is part of or coupled to the access device 102), printed out on a receipt, communicated to the user's mobile device 101, etc. Alternately, if the transaction is an online transaction (e.g., via a website or application), the merchant computer 103 may provide a web page, display module, or other indication of the authorization response message to the mobile device 101." "[0060] The application provider 209 server computer 211 receives the request for provisioning message, and may perform a risk check or risk analysis for the requesting user 107, account, mobile device 101, or any other data that is present in the received request for provisioning message, or is tied to a user's account associated with the request for provisioning message. For example, the risk check may involve determining how many times the user's account has been provisioned and how many accounts are provisioned on mobile device 101. The risk check may, for example, indicate the likelihood that the request for provisioning is fraudulent. if the risk check indicates that the risk of provisioning is acceptable, then application provider 209 server computer 211 may send the request for provisioning to provisioning service module 225 executing at service provider 230 server computer 212." "[0087] At block 318, the service provider 230 determines which level of risk was determined. As depicted, block 318 indicates identifying whether the level of risk was “High,” “Medium,” or “Low.” Of course, although in some embodiments the levels of risk may be explicitly categorical (and thus uniquely identify which risk category is determined), in other embodiments the levels of risk may be in other formats (e.g., a risk score is generated that is an integer between 0 and 100, for example, and thus the determination of the risk category may include determining if the risk score is within a range of values, meets or exceeds a value, is below a value, etc.).")
transmits, to the backend server after a successful comparison and determining the authentication process function request is not fraudulent based on the one or more risk signals, [a session identifier associated with the session creation request] and a funding primary account number.
(Wong US20220327527 at paras. 10-12, 60-62, 91) ("[0061] The provisioning service module 225 may then generate a payment token to provision onto the mobile device using token service 222. The payment token represents a PAN or other account number to be provisioned on the mobile device, and may comprise the actual PAN provided in the provisioning request, a generated token, the PAN together with a PAN sequence number, or another item of payment information to identify the account when used through the mobile payment application 208C. The payment token may be included in the personalization data later stored onto the mobile device 101." "[0091] In some embodiments, the this message 376 includes one or more of the token (which may be encrypted)")
Wong does not explicitly teach, however, Goldman does teach:
the one or more risk signals comprising an account risk score and a device risk score,
(Goldman US20180033089 at paras. 69-71) ("[0070] The analytics module 119 and/or the security system 112 uses one or more of the predictive models 122 to generate risk score data 121 for one or more risk categories 123, according to one embodiment. The risk categories 123 represent characteristics, features, and/or attributes of the authorized users 144 of the client system 140, of the suspicious client system 130, and/or of the potentially fraudulent user 134, according to one embodiment. The risk categories 123 have risk category identifiers that include, but are not limited to, a user system characteristics identifier (a.k.a., visitor ID or “VID”), an IP address identifier, and a user account identifier (a.k.a., auth ID), according to one embodiment. In other words, each of the predictive models 122 receives the system access data 113 (or other input data) and generates one risk score (represented by the risk score data 121) for each of the risk categories 123, according to one embodiment. To illustrate with an example, the analytics module 119 receives system access data 113 (representative of tens, hundreds, or thousands of characteristics or features of system access activities for a session), the analytics module 119 applies the system access data 113 to one of the predictive models 122, the predictive model generates a risk score of .72 (represented by the risk score data 121) for the IP address 132 of the suspicious client system 130, and the analytics module 119 and/or the security system 112 determines whether a risk score of .72 is a strong enough indication of a security threat to warrant performing one or more risk reduction actions." "[0100] At operation 306, the tax return preparation system 303 receives the request, initiates a session, determines and stores a session ID, a user system characteristics ID, and an IP address, according to one embodiment. In one embodiment, a session ID is a session identifier that is used to identify the session that is initiated when the first client system 301 requests the new user account, according to one embodiment. The user system characteristics ID is a user system characteristics identifier that is one example of a risk category, according to one embodiment. The user system characteristics ID is determined based on one or more of the operating system, the browser, the type of computing device, the IP address, and other characteristics of the first client system 301, according to one embodiment. Operation 306 proceeds to operation 307, according to one embodiment.")
a session identifier associated with the session creation request...
(Goldman US20180033089 at paras. 69-71) ("[0070] The analytics module 119 and/or the security system 112 uses one or more of the predictive models 122 to generate risk score data 121 for one or more risk categories 123, according to one embodiment. The risk categories 123 represent characteristics, features, and/or attributes of the authorized users 144 of the client system 140, of the suspicious client system 130, and/or of the potentially fraudulent user 134, according to one embodiment. The risk categories 123 have risk category identifiers that include, but are not limited to, a user system characteristics identifier (a.k.a., visitor ID or “VID”), an IP address identifier, and a user account identifier (a.k.a., auth ID), according to one embodiment. In other words, each of the predictive models 122 receives the system access data 113 (or other input data) and generates one risk score (represented by the risk score data 121) for each of the risk categories 123, according to one embodiment. To illustrate with an example, the analytics module 119 receives system access data 113 (representative of tens, hundreds, or thousands of characteristics or features of system access activities for a session), the analytics module 119 applies the system access data 113 to one of the predictive models 122, the predictive model generates a risk score of .72 (represented by the risk score data 121) for the IP address 132 of the suspicious client system 130, and the analytics module 119 and/or the security system 112 determines whether a risk score of .72 is a strong enough indication of a security threat to warrant performing one or more risk reduction actions." "[0100] At operation 306, the tax return preparation system 303 receives the request, initiates a session, determines and stores a session ID, a user system characteristics ID, and an IP address, according to one embodiment. In one embodiment, a session ID is a session identifier that is used to identify the session that is initiated when the first client system 301 requests the new user account, according to one embodiment. The user system characteristics ID is a user system characteristics identifier that is one example of a risk category, according to one embodiment. The user system characteristics ID is determined based on one or more of the operating system, the browser, the type of computing device, the IP address, and other characteristics of the first client system 301, according to one embodiment. Operation 306 proceeds to operation 307, according to one embodiment.")
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 Wong and Goldman, because it allows for an improved system for identifying and addressing potentially fraudulent activity in a financial system, providing an efficient user experience and, efficient use of human and non-human resources. (Goldman at Abstract and paras. 1-16).
As per claim 3,
Wong explicitly teaches:
wherein the authentication process function request further comprises at least one selected from the group of the session identifier, a consent date, and a device identifier.
(Wong US20220327527 at paras. 60, 71, 74) ("[0060] To assist in understanding the depicted entities of FIG. 2, an exemplary flow for provisioning payment account credentials 207 according to some embodiments is described. A user 107 may send a request for provisioning by use of a mobile application 208 running on mobile device 101. For example, in a payment application 208C (e.g., digital wallet application), the user 107 may request provisioning of an account, credit card, or any other payment credentials for mobile device 101. The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information (e.g., a cryptogram such as a CVV2 for card verification based authentication processes, a ZIP code for geographic verification, etc.). ")
As per claim 6,
Wong explicitly teaches:
wherein the one or more risk signals further comprise at least one selected from the group of a device phone number, an email address, an internet protocol (IP) address, an account to device bonding identifier, and a device to account bonding age.
(Wong US20220327527 at paras. 79-83) ("[0080] The provisioning request message 366, in some embodiments, includes device information (to identify the mobile device 101 and secure element 202, and may include any unique identifier for the device to identify the secure element keys necessary), consumer identifier or login information/credentials (to identify the user 107), account credentials (e.g., a PAN and/or a card verification value (e.g., CVV2 for card verification based authentication processes)), and/or a zip code (for geographic based authentication processes). The provisioning request message 366 is sent by the mobile device 101 to wallet provider 210, which may generate a risk score (or perform a “risk check” or “risk analysis” to generate risk assessment data) at block 313 based upon the provisioning request message 366. This risk analysis may occur based upon the requesting user 107, account, card, mobile device 101, or any other data that is present in the provisioning request message 366 (e.g., a CVV2 value, ZIP Code, User Identifier, etc.) or is tied to the account of the user 107 submitting the provisioning request (e.g., previously registered/provisioned card data, determining how long the account has been open, how many cards the consumer uses in total or has used, a number of purchases in the past, etc.).")
As per claim 8,
Wong explicitly teaches:
wherein the one or more risk signals are generated by the backend server.
(Wong US20220327527 at paras. 79-83) ("[0080] The provisioning request message 366, in some embodiments, includes device information (to identify the mobile device 101 and secure element 202, and may include any unique identifier for the device to identify the secure element keys necessary), consumer identifier or login information/credentials (to identify the user 107), account credentials (e.g., a PAN and/or a card verification value (e.g., CVV2 for card verification based authentication processes)), and/or a zip code (for geographic based authentication processes). The provisioning request message 366 is sent by the mobile device 101 to wallet provider 210, which may generate a risk score (or perform a “risk check” or “risk analysis” to generate risk assessment data) at block 313 based upon the provisioning request message 366. This risk analysis may occur based upon the requesting user 107, account, card, mobile device 101, or any other data that is present in the provisioning request message 366 (e.g., a CVV2 value, ZIP Code, User Identifier, etc.) or is tied to the account of the user 107 submitting the provisioning request (e.g., previously registered/provisioned card data, determining how long the account has been open, how many cards the consumer uses in total or has used, a number of purchases in the past, etc.)." "[0083] In some embodiments, the risk of the request is determined (or “assigned”) by the service provider 230 at block 314 (e.g., based upon rules and/or data provided by the issuer 240 at an earlier time) to yield a token activation response 372A. However, in some embodiments the service provider 230 identifies the issuer 240 of the account (e.g., based upon the PAN), transmits a token activation request message 370 (which may include a risk value indicating the service provider assigned risk 314 and/or a risk value generated by the wallet provider 210) to the issuer 240 such that the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.")
As per claim 9,
Wong explicitly teaches:
wherein the authentication server transmits the notification indicating a fraudulent transaction prior to transmitting the [session identifier] and the encrypted funding primary account number.
(Wong US20220327527 at paras. 59-61, 91) ("[0060] To assist in understanding the depicted entities of FIG. 2, an exemplary flow for provisioning payment account credentials 207 according to some embodiments is described. A user 107 may send a request for provisioning by use of a mobile application 208 running on mobile device 101. For example, in a payment application 208C (e.g., digital wallet application), the user 107 may request provisioning of an account, credit card, or any other payment credentials for mobile device 101. The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information (e.g., a cryptogram such as a CVV2 for card verification based authentication processes, a ZIP code for geographic verification, etc.). The application provider 209 server computer 211 receives the request for provisioning message, and may perform a risk check or risk analysis for the requesting user 107, account, mobile device 101, or any other data that is present in the received request for provisioning message, or is tied to a user's account associated with the request for provisioning message. For example, the risk check may involve determining how many times the user's account has been provisioned and how many accounts are provisioned on mobile device 101. The risk check may, for example, indicate the likelihood that the request for provisioning is fraudulent. if the risk check indicates that the risk of provisioning is acceptable, then application provider 209 server computer 211 may send the request for provisioning to provisioning service module 225 executing at service provider 230 server computer 212. The request for provisioning message may include any of the information included in the message received from mobile device 101, and may include additional information determined by application provider 209 server computer 211, such as a primary account number (PAN) associated with the user's account and a reference number associated with the request for provisioning." "[0091] At block 326, the provisioning service module 225 prepares and sends a message 376 to the wallet provider 210 including the token (received from the token service module 222) along with a set of one or more provisioning scripts. In some embodiments, the this message 376 includes one or more of the token (which may be encrypted)")
Wong does not explicitly teach, however, Goldman does teach:
session identifier…
(Goldman US20180033089 at paras. 69-71) ("[0070] The analytics module 119 and/or the security system 112 uses one or more of the predictive models 122 to generate risk score data 121 for one or more risk categories 123, according to one embodiment. The risk categories 123 represent characteristics, features, and/or attributes of the authorized users 144 of the client system 140, of the suspicious client system 130, and/or of the potentially fraudulent user 134, according to one embodiment. The risk categories 123 have risk category identifiers that include, but are not limited to, a user system characteristics identifier (a.k.a., visitor ID or “VID”), an IP address identifier, and a user account identifier (a.k.a., auth ID), according to one embodiment. In other words, each of the predictive models 122 receives the system access data 113 (or other input data) and generates one risk score (represented by the risk score data 121) for each of the risk categories 123, according to one embodiment. To illustrate with an example, the analytics module 119 receives system access data 113 (representative of tens, hundreds, or thousands of characteristics or features of system access activities for a session), the analytics module 119 applies the system access data 113 to one of the predictive models 122, the predictive model generates a risk score of .72 (represented by the risk score data 121) for the IP address 132 of the suspicious client system 130, and the analytics module 119 and/or the security system 112 determines whether a risk score of .72 is a strong enough indication of a security threat to warrant performing one or more risk reduction actions." "[0100] At operation 306, the tax return preparation system 303 receives the request, initiates a session, determines and stores a session ID, a user system characteristics ID, and an IP address, according to one embodiment. In one embodiment, a session ID is a session identifier that is used to identify the session that is initiated when the first client system 301 requests the new user account, according to one embodiment. The user system characteristics ID is a user system characteristics identifier that is one example of a risk category, according to one embodiment. The user system characteristics ID is determined based on one or more of the operating system, the browser, the type of computing device, the IP address, and other characteristics of the first client system 301, according to one embodiment. Operation 306 proceeds to operation 307, according to one embodiment.")
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 Wong and Goldman, because it allows for an improved system for identifying and addressing potentially fraudulent activity in a financial system, providing an efficient user experience and, efficient use of human and non-human resources. (Goldman at Abstract and paras. 1-16).
As per claim 10,
Wong explicitly teaches:
wherein the authentication server determines the authentication process function request is not fraudulent prior to transmitting the [session identifier] and encrypted funding primary account number.
(Wong US20220327527 at paras. 59-61, 91) ("[0060] To assist in understanding the depicted entities of FIG. 2, an exemplary flow for provisioning payment account credentials 207 according to some embodiments is described. A user 107 may send a request for provisioning by use of a mobile application 208 running on mobile device 101. For example, in a payment application 208C (e.g., digital wallet application), the user 107 may request provisioning of an account, credit card, or any other payment credentials for mobile device 101. The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information (e.g., a cryptogram such as a CVV2 for card verification based authentication processes, a ZIP code for geographic verification, etc.). The application provider 209 server computer 211 receives the request for provisioning message, and may perform a risk check or risk analysis for the requesting user 107, account, mobile device 101, or any other data that is present in the received request for provisioning message, or is tied to a user's account associated with the request for provisioning message. For example, the risk check may involve determining how many times the user's account has been provisioned and how many accounts are provisioned on mobile device 101. The risk check may, for example, indicate the likelihood that the request for provisioning is fraudulent. if the risk check indicates that the risk of provisioning is acceptable, then application provider 209 server computer 211 may send the request for provisioning to provisioning service module 225 executing at service provider 230 server computer 212. The request for provisioning message may include any of the information included in the message received from mobile device 101, and may include additional information determined by application provider 209 server computer 211, such as a primary account number (PAN) associated with the user's account and a reference number associated with the request for provisioning." "[0091] At block 326, the provisioning service module 225 prepares and sends a message 376 to the wallet provider 210 including the token (received from the token service module 222) along with a set of one or more provisioning scripts. In some embodiments, the this message 376 includes one or more of the token (which may be encrypted)")
Wong does not explicitly teach, however, Goldman does teach:
session identifier…
(Goldman US20180033089 at paras. 69-71) ("[0070] The analytics module 119 and/or the security system 112 uses one or more of the predictive models 122 to generate risk score data 121 for one or more risk categories 123, according to one embodiment. The risk categories 123 represent characteristics, features, and/or attributes of the authorized users 144 of the client system 140, of the suspicious client system 130, and/or of the potentially fraudulent user 134, according to one embodiment. The risk categories 123 have risk category identifiers that include, but are not limited to, a user system characteristics identifier (a.k.a., visitor ID or “VID”), an IP address identifier, and a user account identifier (a.k.a., auth ID), according to one embodiment. In other words, each of the predictive models 122 receives the system access data 113 (or other input data) and generates one risk score (represented by the risk score data 121) for each of the risk categories 123, according to one embodiment. To illustrate with an example, the analytics module 119 receives system access data 113 (representative of tens, hundreds, or thousands of characteristics or features of system access activities for a session), the analytics module 119 applies the system access data 113 to one of the predictive models 122, the predictive model generates a risk score of .72 (represented by the risk score data 121) for the IP address 132 of the suspicious client system 130, and the analytics module 119 and/or the security system 112 determines whether a risk score of .72 is a strong enough indication of a security threat to warrant performing one or more risk reduction actions." "[0100] At operation 306, the tax return preparation system 303 receives the request, initiates a session, determines and stores a session ID, a user system characteristics ID, and an IP address, according to one embodiment. In one embodiment, a session ID is a session identifier that is used to identify the session that is initiated when the first client system 301 requests the new user account, according to one embodiment. The user system characteristics ID is a user system characteristics identifier that is one example of a risk category, according to one embodiment. The user system characteristics ID is determined based on one or more of the operating system, the browser, the type of computing device, the IP address, and other characteristics of the first client system 301, according to one embodiment. Operation 306 proceeds to operation 307, according to one embodiment.")
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 Wong and Goldman, because it allows for an improved system for identifying and addressing potentially fraudulent activity in a financial system, providing an efficient user experience and, efficient use of human and non-human resources. (Goldman at Abstract and paras. 1-16).
As per claim 12,
Wong explicitly teaches:
wherein the funding primary account number is encrypted prior to transmission.
(Wong US20220327527 at paras. 61, 73, 132) ("[0060] To assist in understanding the depicted entities of FIG. 2, an exemplary flow for provisioning payment account credentials 207 according to some embodiments is described. A user 107 may send a request for provisioning by use of a mobile application 208 running on mobile device 101. For example, in a payment application 208C (e.g., digital wallet application), the user 107 may request provisioning of an account, credit card, or any other payment credentials for mobile device 101. The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information (e.g., a cryptogram such as a CVV2 for card verification based authentication processes, a ZIP code for geographic verification, etc.). The application provider 209 server computer 211 receives the request for provisioning message, and may perform a risk check or risk analysis for the requesting user 107, account, mobile device 101, or any other data that is present in the received request for provisioning message, or is tied to a user's account associated with the request for provisioning message. For example, the risk check may involve determining how many times the user's account has been provisioned and how many accounts are provisioned on mobile device 101. The risk check may, for example, indicate the likelihood that the request for provisioning is fraudulent. if the risk check indicates that the risk of provisioning is acceptable, then application provider 209 server computer 211 may send the request for provisioning to provisioning service module 225 executing at service provider 230 server computer 212. The request for provisioning message may include any of the information included in the message received from mobile device 101, and may include additional information determined by application provider 209 server computer 211, such as a primary account number (PAN) associated with the user's account and a reference number associated with the request for provisioning.")
As per claim 21,
Wong does not explicitly teach, however, Goldman does teach:
wherein the one or more risk signals further comprises a device geolocation.
(Goldman US20180033089 at paras. 69-71) ("[0070] The analytics module 119 and/or the security system 112 uses one or more of the predictive models 122 to generate risk score data 121 for one or more risk categories 123, according to one embodiment. The risk categories 123 represent characteristics, features, and/or attributes of the authorized users 144 of the client system 140, of the suspicious client system 130, and/or of the potentially fraudulent user 134, according to one embodiment. The risk categories 123 have risk category identifiers that include, but are not limited to, a user system characteristics identifier (a.k.a., visitor ID or “VID”), an IP address identifier, and a user account identifier (a.k.a., auth ID), according to one embodiment. In other words, each of the predictive models 122 receives the system access data 113 (or other input data) and generates one risk score (represented by the risk score data 121) for each of the risk categories 123, according to one embodiment. To illustrate with an example, the analytics module 119 receives system access data 113 (representative of tens, hundreds, or thousands of characteristics or features of system access activities for a session), the analytics module 119 applies the system access data 113 to one of the predictive models 122, the predictive model generates a risk score of .72 (represented by the risk score data 121) for the IP address 132 of the suspicious client system 130, and the analytics module 119 and/or the security system 112 determines whether a risk score of .72 is a strong enough indication of a security threat to warrant performing one or more risk reduction actions." "[0063] The user system characteristics 141 include one or more of an operating system, a hardware configuration, a web browser, information stored in one or more cookies, the geographical history of use of the client system 140, the IP address 142, and other forensically determined characteristics/attributes of the client system 140, according to one embodiment." "[0064] The IP address 142 can be static, can be dynamic, and/or can change based on the location (e.g., a coffee shop) for which the client system 140 accesses the financial system 111, according to one embodiment. The financial system 111 and/or the security system 112 may use an IP address identifier to represent the IP address and/or additional characteristics of the IP address 142, according to one embodiment.")
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 Wong and Goldman, because it allows for an improved system for identifying and addressing potentially fraudulent activity in a financial system, providing an efficient user experience and, efficient use of human and non-human resources. (Goldman at Abstract and paras. 1-16).
Claims 11 and 18 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claims 16 and 20 are substantially similar to claim 3, thus, they are rejected on similar grounds.
Claim 13 is substantially similar to claim 8, thus, it is rejected on similar grounds.
Claim 14 is substantially similar to claim 9, thus, it is rejected on similar grounds.
Claim 15 is substantially similar to claim 10, thus, it is rejected on similar grounds.
Claims 2 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wong, U.S. Patent Application Publication Number 2022/0327527; in view of Goldman, U.S. Patent Application Publication Number 2018/0033089; in view of Hosp, U.S. Patent Application Publication Number 2015/0363754.
As per claim 2,
Wong explicitly teaches:
receives, from a token server, an eligibility request associated with the contactless card, and
(Wong US20220327527 at paras. 54-55, 61, 73-75, 90-91) ("[0074] The service provider 230, for the PAN (or for one or more of the one or more PANs provided in, identified by, or otherwise associated with the check account message 352) verifies the eligibility of the associated account for which credentials are to be provisioned. In some embodiments, the service provider 230 verifies the eligibility at block 304, but in some embodiments the service provider 230 transmits an account eligibility request message 354 to the issuer 240, and the issuer 240 will then verify the eligibility at block 306 and return an account eligibility response message 356 indicating the eligibility of the account(s). In some embodiments, the account eligibility request message 354 may include a risk value indicating a risk associated with the request, as generated by the service provider 230 or wallet provider 210, which allows the issuer 240 an additional factor to consider when verifying an eligibility of the request.")
transmit, to the token server after determining the contactless card is eligible, a notification indicating eligibility.
(Wong US20220327527 at paras. 54-55, 61, 73-75, 90-91) ("[0074] The service provider 230, for the PAN (or for one or more of the one or more PANs provided in, identified by, or otherwise associated with the check account message 352) verifies the eligibility of the associated account for which credentials are to be provisioned. In some embodiments, the service provider 230 verifies the eligibility at block 304, but in some embodiments the service provider 230 transmits an account eligibility request message 354 to the issuer 240, and the issuer 240 will then verify the eligibility at block 306 and return an account eligibility response message 356 indicating the eligibility of the account(s). In some embodiments, the account eligibility request message 354 may include a risk value indicating a risk associated with the request, as generated by the service provider 230 or wallet provider 210, which allows the issuer 240 an additional factor to consider when verifying an eligibility of the request.")
Wong and Goldman do not explicitly teach, however, Hosp does teach:
wherein the authentication server: receives, from the backend server, a request to establish a virtual card number (VCN) autofill procedure,
(Hosp US20150363754 at paras. 61-64) ("[0063] In some use-cases, e.g., where the recipient device 108 is a smartphone, the screen display of FIG. 4 may be augmented with an offer from the FI server computer 102 to the recipient device 108 to download a mobile app (e.g., a payment application) to facilitate the recipient's access to the new virtual payment account via either or both of online purchase transactions and in store (POS) transactions. The latter option may only be feasible if the recipient device 108 is equipped with contactless payments capabilities such as those referred to above with respect to elements 274, 276 and 278 shown in FIG. 2A. In a case where the recipient device/smartphone 108 is not equipped to perform instore/POS payment transactions, the/an app downloaded to the recipient device/smartphone 108 from the FI server computer 102 may simply facilitate the recipient's storing and/or retrieving the VCN in connection with online e-commerce transactions. For example, such an app may facilitate the user in auto-filling the payment information page with the VCN during the checkout phase of an online purchase transaction.")
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 Wong, Goldman, and Hosp, because it allows greater convenience in utilizing a payment card account system to support person-to-person payments. (Hosp at Abstract and paras. 2-12).
Claim 19 is substantially similar to claim 2, thus, it is rejected on similar grounds.
Claims 4, 7, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wong, U.S. Patent Application Publication Number 2022/0327527; in view of Goldman, U.S. Patent Application Publication Number 2018/0033089; in view of Lavender, U.S. Patent Application Publication Number 2017/0272253.
As per claim 4,
Wong and Goldman do not explicitly teach, however, Lavender does teach:
wherein the authentication process function request further comprises a wallet identifier associated with a digital wallet.
(Lavender US20170272253 at paras. 61-64) ("[0062] In some embodiments, the sender cryptogram can be used to verifiably associate additional sender information with the interaction. For example, additional inputs for the sender cryptogram can include information about the sender 111, such as sender contact information (e.g., a phone number or email address), a sender alias, a sender device ID, and/or the sender's digital wallet identifier. [0063] Similarly, in some embodiments, additional receiver information can be verifiably associated with the interaction through the sender cryptogram. For example, additional inputs for the sender cryptogram can include information about the receiver 121, such as a receiver name or alias, a receiver contact address (e.g., an email address or a phone number), and/or receiver account information (e.g., a receiver token). Some or all of the sender-identifying information and receiver-identifying can be hashed before being included in the interaction request or being used as cryptogram inputs.")
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 Wong, Goldman, and Lavender, because it provides a system to advantageously allow interactions to take place without requiring that a coordination computer (e.g., a digital wallet computer) store and maintain tokens or other account information associated with the sender or receiver. This improves operational efficiency and reduces security risk at the coordination computer. (Lavender at Abstract and paras. 2-12).
As per claim 7,
Wong and Goldman do not explicitly teach, however, Lavender does teach:
wherein the device phone number and the email address are hashed.
(Lavender US20170272253 at paras. 61-64) ("[0062] In some embodiments, the sender cryptogram can be used to verifiably associate additional sender information with the interaction. For example, additional inputs for the sender cryptogram can include information about the sender 111, such as sender contact information (e.g., a phone number or email address), a sender alias, a sender device ID, and/or the sender's digital wallet identifier. [0063] Similarly, in some embodiments, additional receiver information can be verifiably associated with the interaction through the sender cryptogram. For example, additional inputs for the sender cryptogram can include information about the receiver 121, such as a receiver name or alias, a receiver contact address (e.g., an email address or a phone number), and/or receiver account information (e.g., a receiver token). Some or all of the sender-identifying information and receiver-identifying can be hashed before being included in the interaction request or being used as cryptogram inputs.")
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 Wong, Goldman, and Lavender, because it provides a system to advantageously allow interactions to take place without requiring that a coordination computer (e.g., a digital wallet computer) store and maintain tokens or other account information associated with the sender or receiver. This improves operational efficiency and reduces security risk at the coordination computer. (Lavender at Abstract and paras. 2-12).
Claim 17 is substantially similar to claim 4, thus, it is rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on April 1, 2026 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1-4 and 6-21, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
Examiner disagrees, however, and notes that the claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate authentication and provision of a payment card to perform financial transactions. 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.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Regarding the applicant's argument that the amended features would integrate the abstract idea into a practical application, the examiner respectfully disagrees. In particular, the applicant argues that “that the specific technical implementation recited by claim 1 constitutes an improvement to at least transaction provisioning technology . . . to securely communicate, authenticate, and perform transactions with contactless cards.”
Examiner disagrees and notes that the additional elements of the computer system - a “A transaction provisioning system, comprising: an authentication server in data communication, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server:”, “a backend server”, “contactless card”, and “token server”, to perform the steps of “authenticating”, “decrypting”, “comparing”, and “assessing”, in all steps is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The claims at issue covers collecting, analyzing, and transmitting data to facilitate authentication and provision of a payment card to perform financial transactions. The claims invoke the “A transaction provisioning system, comprising: an authentication server in data communication, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server:”, “a backend server”, “contactless card”, and “token server”, to perform the steps of “authenticating”, “decrypting”, “comparing”, and “assessing” merely as tools to execute the abstract idea. 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 certain method of organizing human activity or mental process or mathematical calculation) does not integrate a judicial exception into a practical application. (MPEP 2106.05 (f))
Examiner notes that, the stated problems of unsecure card provisioning is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of performing a card authentication process is part of the abstract idea, as it is merely involves collecting, analyzing, and transmitting data to facilitate authentication and provision of a payment card to perform financial transactions. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea.
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the additional elements do not amount to an inventive concept. The additional elements of the computer system - “A transaction provisioning system, comprising: an authentication server in data communication, comprising: a processor, and a memory storing an expected authentication code for a contactless card, wherein the authentication server:”, “a backend server”, “contactless card”, and “token server”, to perform the steps of “authenticating”, “decrypting”, “comparing”, and “assessing”, are merely generic computer components performing their well-known basic functions of collecting, analyzing, and transmitting data to facilitate authentication and provision of a payment card to perform financial transactions. Per the specification, the recited computer elements are described only at a high level of generality, (see Spec. at paras. [0098], [0240]-[0245], [0248], [0255]). In view of the specification, the application of the computer elements are merely being applied to the abstract idea.
The other limitations which are simply supporting the abstract idea correspond to insignificant extra-solution activity which do not transform the abstract idea into a patent eligible subject matter. Also, the functionality here is already present in the recited hardware, which is merely routine and conventional. Collecting, analyzing, and transmitting data is routine and conventional. There is no technological problem or solution identified. This is merely a business solution to transfer data between devices. (MPEP 2106.05 (f))
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-4 and 6-21, Examiner notes that the arguments are moot in light of the new grounds for rejection.
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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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