DETAILED ACTION
Status of Application
This action is a Non-Final Rejection. This action is in response to the application filed on September 6, 2024.
Claims 1-20 are pending and rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 7, 2025 has been considered by the examiner.
Claim Interpretation
Applicant should be aware that there is claim language that does not serve to differentiate the claims from the prior art and/or provide an additional element that can be a consideration for eligibility1. See MPEP 2103(c).
Nonfunctional Descriptive Material
Nonfunctional descriptive material is generally not given patentable weight. See MPEP 2111.05. Any difference related merely to the meaning and information conveyed through labels (i.e., the type of the item) which does not explicitly alter or impact the steps of the method is nonfunctional descriptive material and does not patentably distinguish the claimed invention from the prior art in terms of patentability.
The following limitations include nonfunctional descriptive material:
Claim 1: provide, with the third communication interface, a third data packet indicating an interaction response to the second communication interface, wherein the third data packet includes the MFA preferences associated with the remuneration vehicle owner from the third memory. Claims 11 and 17 recite a similar limitation. (The content of the third data packet is nonfunctional descriptive material.)
Claim 20: wherein the third data packet includes a transaction that is encrypted by the electronic processor. (The content of the third data packet is nonfunctional descriptive material.)
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 5-7 and 13 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 5 recites “wherein the second electronic processor is configured to: … automatically enroll the remuneration vehicle owner associated with the remuneration vehicle device in MFA based on the MFA preferences associated with the remuneration vehicle owner of the third data packet.” Claims 7 and 13 recite a similar limitation. At a high level, it appears that claim 5 is stating that the merchant device automatically enrolls the cardholder/user in MFA based on MFA preferences (that the server receives from the cardholder/user and sends to the merchant device, per claim 1). However, before the transaction has commenced, a cardholder provides MFA preferences to the server. Regarding enrollment, the Specification recites:
[0045] The merchant device 135 may enroll the cardholder in MFA 318 based on the received MFA preferences 116. For example, the electronic processor 210 of the merchant device 135 may execute the application 218 to enroll the cardholder in MFA according to their MFA preferences 116. In some embodiments, the MFA preferences 116 may include data corresponding to a confirmation of MFA enrollment and an OTP type preference (e.g., email address or phone number).
[0059] The electronic processor 210 of the merchant device 135 enrolls the cardholder in MFA based on the MFA preferences 116 (block 704). For example, the electronic processor 210 may execute the application 218 to enroll the cardholder in MFA according to the MFA preferences 116 when the electronic processor 201 of the cardholder device 130 executes the application 208 upon launching the application 208 (e.g., when a user selects a tile corresponding to the application 208 on the GUI 204). In some embodiments, the electronic processor 210 of the merchant device 135 executes the application 218 to enroll the cardholder in MFA including an OTP that is a text message to the cardholder’s phone number. Alternatively, in some embodiments, the electronic processor 210 of the merchant device 135 executes the application 218 to enroll the cardholder in MFA including an OTP that is an email to the cardholder’s email address.
The Specification does not sufficiently describe what is meant by “enroll” as claimed. It is unclear whether “enroll” is meant to be interpreted, for example, to mean that the merchant uses the MFA preferences to require MFA for that transaction or whether the user is being enrolled in a new MFA program.
Additionally, paragraph 0045 of the Specification states that “[i]n some embodiments, the MFA preferences 116 may include data corresponding to a confirmation of MFA enrollment and an OTP type preference (e.g., email address or phone number).” This shows that an enrollment occurs prior to the transaction. If there is an alternative embodiment where enrollment is performed by the merchant and does not occur until after the merchant receives the MFA preferences, the Specification does not describe which MFA preferences the enrollment by the Merchant is based on.
Furthermore, the Specification refers to “enroll[ing] the cardholder in MFA” but it does not explain what this means. For example, the Specification does not explain whether the cardholder is enrolled in MFA performed by the merchant or whether the cardholder is enrolled with respect to the card issuer or other entity. Claims 5, 7, and 13 cannot be properly interpreted in light of the other claims and Specification. Applicant should either amend the claims or show where the Specification describes the enrollment limitations.
Claim Rejections - 35 USC § 112(b)
The following is a quotation 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5-7, 13, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 5 recites “wherein the second electronic processor is configured to: … automatically enroll the remuneration vehicle owner associated with the remuneration vehicle device in MFA based on the MFA preferences associated with the remuneration vehicle owner of the third data packet.” Claims 7 and 13 recite a similar limitation. At a high level, it appears that claim 5 is stating that the merchant device automatically enrolls the cardholder/user in MFA based on MFA preferences (that the server receives from the cardholder/user and sends to the merchant device, per claim 1). However, before the transaction has commenced, a cardholder provides MFA preferences to the server. Regarding enrollment, the Specification recites:
[0045] The merchant device 135 may enroll the cardholder in MFA 318 based on the received MFA preferences 116. For example, the electronic processor 210 of the merchant device 135 may execute the application 218 to enroll the cardholder in MFA according to their MFA preferences 116. In some embodiments, the MFA preferences 116 may include data corresponding to a confirmation of MFA enrollment and an OTP type preference (e.g., email address or phone number).
[0059] The electronic processor 210 of the merchant device 135 enrolls the cardholder in MFA based on the MFA preferences 116 (block 704). For example, the electronic processor 210 may execute the application 218 to enroll the cardholder in MFA according to the MFA preferences 116 when the electronic processor 201 of the cardholder device 130 executes the application 208 upon launching the application 208 (e.g., when a user selects a tile corresponding to the application 208 on the GUI 204). In some embodiments, the electronic processor 210 of the merchant device 135 executes the application 218 to enroll the cardholder in MFA including an OTP that is a text message to the cardholder’s phone number. Alternatively, in some embodiments, the electronic processor 210 of the merchant device 135 executes the application 218 to enroll the cardholder in MFA including an OTP that is an email to the cardholder’s email address.
It is unclear what is meant by “enroll” as claimed because it appears that the user is already enrolled in MFA when he or she provides MFA preferences to the server. For example, it is unclear whether “enroll” is meant to be interpreted to mean that the merchant uses the MFA preferences to require MFA for that transaction.
Additionally, paragraph 0045 of the Specification states that “[i]n some embodiments, the MFA preferences 116 may include data corresponding to a confirmation of MFA enrollment and an OTP type preference (e.g., email address or phone number).” This shows that enrollment occurs prior to the transaction. If there is an alternative embodiment where enrollment is performed by the merchant and does not occur until after the merchant receives the MFA preferences, it is not clear which MFA preferences the enrollment by the Merchant is based on. Claims 5, 7, and 13 are indefinite because they cannot be properly interpreted in light of the other claims and Specification. Applicant should either amend the claims or show where the Specification describes the enrollment limitations. For purposes of examination, the claimed enrollment is interpreted to mean that the merchant initiates and/or implements the MFA process.
Claim 20 recites “wherein the third data packet includes a transaction that is encrypted by the electronic processor.” It appears that the third data packet is an interaction response including the MFA preferences sent from the server to the merchant device. It is not clear what is meant by “transaction” as recited and how a transaction itself is in the third data packet and is encrypted. Paragraph 0042 of the Specification states:
[0042] The issuer server 104 may provide a transaction response 312 to the payment server 120. For example, the transaction response 312 may include at least one of the cardholder’s personal information, the cardholder’s MFA preferences 116, an authorization request response, and a notice that the cardholder has sufficient funds for the item. In some embodiments, the transaction response 312 is encrypted. In some embodiments, the authorization request response may be a sub-element under the cardholder’s personal data in the transaction response 312 that ensures predetermined security and encryption are applied the cardholder’s personal information. For example, the authorization request response may not be encrypted and the cardholder’s personal information may be encrypted so the personal information is not unnecessarily viewed (e.g., by the merchant).
If the disclosed transaction response is the claimed interaction response and if this paragraph describes claim 20, Applicant should amend the claims so that it is clear what data is encrypted. For purposes of examination, claim 20 interpreted to mean that transaction data is encrypted.
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 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Yes, with respect to claims 1-10, which recite a system and, therefore, are directed to the statutory class of machine or manufacture.
Yes, with respect to claims 11-16, which recite a method and, therefore, are directed to the statutory class of process.
Yes, with respect to claims 17-20, which recite a non-transitory computer readable medium and, therefore, are directed to the statutory class of manufacture.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims (Claims 1-10 and 20 are representative) identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
1. A system for electronically communicating multi-factor authentication (MFA) data, the system comprising:
a remuneration vehicle device including a first communication interface, a first electronic processor, and a first memory;
a third-party device including a second communication interface, a second electronic processor, and a second memory; and
a server including a third communication interface, a third electronic processor, and a third memory, the third electronic processor configured to:
receive, with the third communication interface, a first data packet indicating MFA preferences associated with a remuneration vehicle owner from the first communication interface,
store the MFA preferences associated with the remuneration vehicle owner in the third memory,
receive, with the third communication interface, a second data packet indicating an interaction request by the remuneration vehicle owner from the second communication interface, and
provide, with the third communication interface, a third data packet indicating an interaction response to the second communication interface,
wherein the third data packet includes the MFA preferences associated with the remuneration vehicle owner from the third memory.
2. The system of claim 1, wherein the first data packet includes at least one of an automatic MFA enrollment preference, a one-time-password (OTP) type preferences, a phone number, and an email address.
3. The system of claim 1, wherein the server is one of a payment processor server and an issuer server.
4. The system of claim 1, wherein the remuneration vehicle device, the third-party device, and the server communicate over a network.
5. The system of claim 1, wherein the second electronic processor is configured to:
receive, with the second communication interface, the third data packet, and
automatically enroll the remuneration vehicle owner associated with the remuneration vehicle device in MFA based on the MFA preferences associated with the remuneration vehicle owner of the third data packet.
6. The system of claim 5 wherein the third electronic processor is further configured to:
receive, with the third communication interface, a fourth data packet indicating a second interaction request from a fourth communication interface of a second third-party device that is different from the third-party device, and
provide, with the third communication interface, a fifth data packet indicating a second interaction response to the fourth communication interface,
wherein the fifth data packet includes the MFA preferences associated with the remuneration vehicle owner from the third memory.
7. The system of claim 6, wherein a fourth electronic processor of the second third-party device is configured to:
receive, with the fourth communication interface, the fifth data packet, and
enroll the remuneration vehicle owner associated with the remuneration vehicle device in MFA based on the MFA preferences associated with the remuneration vehicle owner of the fifth data packet.
8. The system of claim 1, wherein the interaction request is a credit card transaction request including first credit card data.
9. The system of claim 8, wherein the third electronic processor is further configured to:
receive, with the third communication interface, a fourth data packet indicating a second interaction request, wherein the second interaction request is a second credit card transaction request including second credit card data, and
determine MFA preferences associated with the remuneration vehicle owner based on the second credit card data.
10. The system of claim 9, wherein the first credit card data includes a first unique card identifier that matches a unique cardholder identifier associated with the remuneration vehicle owner and the second credit card data includes a second unique card identifier that matches the unique cardholder identifier.
20. The non-transitory computer-readable medium of claim 17, wherein the third data packet includes a transaction that is encrypted by the electronic processor.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to user authentication for a transaction. This type of method of organizing human activity is a fundamental economic practice because it includes mitigating risk and a commercial interaction such as legal obligations, sales activities or behaviors, and business relations. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The computing components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only programmed general purpose computing devices (i.e., claimed remuneration vehicle device, third-party device, and server) are needed to implement the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 8-12, and 14-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Telle et al., U.S. Patent Application Publication Number 2012/0011066 A1.
Claim 1:
Telle discloses:
a remuneration vehicle device including a first communication interface, a first electronic processor, and a first memory (see at least Telle, Figure 6, item 114 and associated text).
a third-party device including a second communication interface, a second electronic processor, and a second memory; and (see at least Telle, Figure 6, item 410 and associated text).
a server including a third communication interface, a third electronic processor, and a third memory, the third electronic processor configured to: (see at least Telle, Figure 6, item 112 (interchange computer system), 301 (server computer device) and associated text).
receive, with the third communication interface, a first data packet indicating MFA preferences associated with a remuneration vehicle owner from the first communication interface, (see at least Telle, paragraph 0027 (“For example, the user may define a telephone number to which an OTP should be transmitted as a short message service (SMS) message, which may also be referred to as a text message or simply a text.”); paragraph 0081 (“In the process illustrated by flowchart 500, prior to the item purchase process, interchange computer system 112 (e.g., the access control server) receives 505 contact information, such as a mobile telephone number and/or an email address, for the cardholder. For example, the contact information may be received 505 from the cardholder computer system and/or from a computer system associated with the cardholder's issuing bank. Interchange computer system 112 associates 510 the contact information with the cardholder in the database.”)).
store the MFA preferences associated with the remuneration vehicle owner in the third memory, (see at least Telle, paragraph 0081 (“In the process illustrated by flowchart 500, prior to the item purchase process, interchange computer system 112 (e.g., the access control server) receives 505 contact information, such as a mobile telephone number and/or an email address, for the cardholder. For example, the contact information may be received 505 from the cardholder computer system and/or from a computer system associated with the cardholder's issuing bank. Interchange computer system 112 associates 510 the contact information with the cardholder in the database.”)).
receive, with the third communication interface, a second data packet indicating an interaction request by the remuneration vehicle owner from the second communication interface, and (see at least Telle, paragraph 0082 (“The cardholder subsequently accesses the merchant computer system to identity one or more items to purchase. The cardholder finishes selecting items to purchase and initiates the check-out procedure by selecting a check-out option provided by the merchant computer system. The cardholder device (e.g., shopping device 420) transmits a purchase request to the merchant store server, initiating a financial transaction. The merchant store server notifies the MPI device of the purchase request. In response, a verify enrollment request (VEReq) message is transmitted by the MPI device. The verify enrollment request is received 515 by the directory server, which is associated with interchange computer system 112, from the MPI device. In operation, when a cardholder indicates an intention to use a check-out option, the MPI device is utilized by the merchant to communicate an account number associated with the user to the directory server.”)).
provide, with the third communication interface, a third data packet indicating an interaction response to the second communication interface, wherein the third data packet includes the MFA preferences associated with the remuneration vehicle owner from the third memory (see at least Telle, paragraph 0084 (“If the account number is verified, the directory server transmits 525 a positive VERes message to the MPI device. The positive VERes message indicates that authentication is available for the financial transaction.”)).
Claim 2:
Telle further discloses:
wherein the first data packet includes at least one of an automatic MFA enrollment preference, a one-time-password (OTP) type preferences, a phone number, and an email address (see at least Telle, paragraph 0081 (“In the process illustrated by flowchart 500, prior to the item purchase process, interchange computer system 112 (e.g., the access control server) receives 505 contact information, such as a mobile telephone number and/or an email address, for the cardholder. For example, the contact information may be received 505 from the cardholder computer system and/or from a computer system associated with the cardholder's issuing bank. Interchange computer system 112 associates 510 the contact information with the cardholder in the database.”)).
Claim 3:
Telle further discloses:
wherein the server is one of a payment processor server and an issuer server (see at least Telle, Figure 6, item 112 (interchange computer system) and associated text; paragraph 0054).
Claim 4:
Telle further discloses:
wherein the remuneration vehicle device, the third-party device, and the server communicate over a network (see at least Telle, Figure 6 and associated text; paragraph 0024).
Claim 8:
Telle further discloses:
wherein the interaction request is a credit card transaction request including first credit card data (see at least Telle, paragraph 0021; paragraph 0026 (“The financial transaction is performed by a user of a financial transaction card, such as a credit card, debit card, or other financial transaction card.”); paragraph 0082 (“The cardholder subsequently accesses the merchant computer system to identity one or more items to purchase. The cardholder finishes selecting items to purchase and initiates the check-out procedure by selecting a check-out option provided by the merchant computer system. The cardholder device (e.g., shopping device 420) transmits a purchase request to the merchant store server, initiating a financial transaction. The merchant store server notifies the MPI device of the purchase request. In response, a verify enrollment request (VEReq) message is transmitted by the MPI device. The verify enrollment request is received 515 by the directory server, which is associated with interchange computer system 112, from the MPI device. In operation, when a cardholder indicates an intention to use a check-out option, the MPI device is utilized by the merchant to communicate an account number associated with the user to the directory server.”)).
Claim 9:
Telle further discloses:
wherein the third electronic processor is further configured to: receive, with the third communication interface, a fourth data packet indicating a second interaction request, wherein the second interaction request is a second credit card transaction request including second credit card data, and (see at least Telle, paragraph 0021; paragraph 0026 (“The financial transaction is performed by a user of a financial transaction card, such as a credit card, debit card, or other financial transaction card.”); paragraph 0082 (“The cardholder subsequently accesses the merchant computer system to identity one or more items to purchase. The cardholder finishes selecting items to purchase and initiates the check-out procedure by selecting a check-out option provided by the merchant computer system. The cardholder device (e.g., shopping device 420) transmits a purchase request to the merchant store server, initiating a financial transaction. The merchant store server notifies the MPI device of the purchase request. In response, a verify enrollment request (VEReq) message is transmitted by the MPI device. The verify enrollment request is received 515 by the directory server, which is associated with interchange computer system 112, from the MPI device. In operation, when a cardholder indicates an intention to use a check-out option, the MPI device is utilized by the merchant to communicate an account number associated with the user to the directory server.”)).
determine MFA preferences associated with the remuneration vehicle owner based on the second credit card data (see at least Telle, paragraph 0084 (“If the account number is verified, the directory server transmits 525 a positive VERes message to the MPI device. The positive VERes message indicates that authentication is available for the financial transaction.”); paragraph 0086 (“The access control server (ACS) 440 receives 530 the PAReq message. In response to the PAReq message, interchange computer system 112 generates 535 a one-time password (OTP) for the financial transaction. Specifically, the ACS 440 generates the OTP at least in part by generating a sequence of random characters. The ACS transmits 540 the one-time password to the cardholder via the messaging provider 415 using contact information associated with the cardholder in the database. In the exemplary embodiment, the one-time password is transmitted to the cardholder via a communication medium that is different from the communication medium used by the cardholder to initiate the transaction with the merchant. For example, the cardholder may submit a purchase request to the merchant via the Internet (e.g., using a web browser and/or HTTP), and the one-time password may be transmitted to a mobile device associated with the cardholder via a short message service (SMS) message.”); paragraph 0087).
Claim 10:
Telle further discloses:
wherein the first credit card data includes a first unique card identifier that matches a unique cardholder identifier associated with the remuneration vehicle owner and the second credit card data includes a second unique card identifier that matches the unique cardholder identifier (see at least Telle, paragraph 0083 (“The directory server determines 520, by itself or by forwarding the VEReq message to the access control server, whether cardholder authentication is available for the corresponding account number. In embodiments where a static number is utilized, a corresponding static number is maintained in a database on the directory server. In embodiments utilizing a user-specific account number, the account number provided by the MPI device is compared to a collection of account numbers stored within the interchange computer system database of enrolled user-specific account numbers. The collection of enrolled account numbers in the database is either populated when a user enrolls their specific account in the authentication program or, in the case of static numbers, the list is populated by the merchant, the directory server, and/or the authentication control server.”); paragraph 0084 (“If the account number is not verified (e.g., the account number is not included in the collection of enrolled account numbers), a negative verify enrollment response (VERes) message is transmitted 522 to the MPI device by the directory server. The MPI device may continue processing the transaction without authentication or may terminate processing of the transaction. If the account number is verified, the directory server transmits 525 a positive VERes message to the MPI device. The positive VERes message indicates that authentication is available for the financial transaction.”)).
Claim 11:
Claim 11 is rejected using the same rationale that was used for the rejection of claim 1.
Claim 12:
Claim 12 is rejected using the same rationale that was used for the rejection of claim 3.
Claim 14:
Claim 14 is rejected using the same rationale that was used for the rejection of claim 8.
Claim 15:
Claim 15 is rejected using the same rationale that was used for the rejection of claim 9.
Claim 16:
Claim 16 is rejected using the same rationale that was used for the rejection of claim 10.
Claim 17:
Claim 17 is rejected using the same rationale that was used for the rejection of claim 1.
Claim 18:
Claim 18 is rejected using the same rationale that was used for the rejection of claim 2.
Claim 19:
Claim 19 is rejected using the same rationale that was used for the rejection of claim 3.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 5-7, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Telle et al., U.S. Patent Application Publication Number 2012/0011066 A1 and Mehta et al., U.S. Patent Application Publication Number 2022/0108314 A1.
Claim 5:
Telle further teaches:
wherein the second electronic processor is configured to: receive, with the second communication interface, the third data packet, and (see at least Telle, paragraph 0084 (“If the account number is verified, the directory server transmits 525 a positive VERes message to the MPI device. The positive VERes message indicates that authentication is available for the financial transaction.”)).
Telle does not explicitly teach, but Mehta, however, does teach:
automatically enroll the remuneration vehicle owner associated with the remuneration vehicle device in MFA based on the MFA preferences associated with the remuneration vehicle owner of the third data packet (see at least Mehta, paragraph 0045 (“Next, in one example implementation, the merchant 102 is configured to solicit the OTP from the user 110, via the virtual merchant location (and, potentially, additional information about the user 110 such as a name, birth year, etc. for purpose of further authentication, for example, if not done when soliciting the hash key 302). As such, the communication device 114, as configured by the virtual merchant location, solicits the OTP (and additional information) from the user 110. In the meantime, the communication device 114 is configured to receive the OTP from the issuer 108 and to display the OTP to the user 110. Consequently, the user 110 is able to provide the OTP at the virtual merchant location, via the communication device 114. The user 110 may further be permitted to provide the additional information at the virtual merchant location, via the communication device 114. The communication device 114, as configured by the virtual merchant location, then submits the OTP (and additional information) to the merchant 102. The merchant 102 is then configured, in this implementation, to generate and transmit an authorization request for the transaction, which includes the hash key 302, the additional information for the user 110 (e.g., the user's name, etc.), and the OTP as provided by the user 110 (e.g., included in a defined or unused data element (DE), etc.). The authorization request (e.g., an ISO 8583 message, etc.) is transmitted to the payment network 106, via the acquirer 104 (along the payment rails associated with the payment network 106).”)).
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 incorporate Mehta’s method of a merchant soliciting and receiving an OTP from a user with Telle’s method of using an OTP to authenticate the identity of a cardholder in a financial transaction. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of having the merchant make sure that the transaction is secure and unlikely to be fraudulent before completing the transaction.
Claim 6:
Claim 6 further recites:
wherein the third electronic processor is further configured to: receive, with the third communication interface, a fourth data packet indicating a second interaction request from a fourth communication interface of a second third-party device that is different from the third-party device, and provide, with the third communication interface, a fifth data packet indicating a second interaction response to the fourth communication interface, wherein the fifth data packet includes the MFA preferences associated with the remuneration vehicle owner from the third memory.
These limitations are repeating steps from claim 1 and are rejected for the same reason as above. 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 incorporate this second iteration of the process with Telle’s method of using an OTP to authenticate the identity of a cardholder in a financial transaction. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of proceeding with a second transaction (i.e., second interaction). Accounts are usually used for more than one transaction. Additionally, it is obvious to repeat steps. See In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a “web” which lies in the joint, and a plurality of “ribs” projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced.).
Claim 7:
Claim 7 further recites:
wherein a fourth electronic processor of the second third-party device is configured to: receive, with the fourth communication interface, the fifth data packet, and enroll the remuneration vehicle owner associated with the remuneration vehicle device in MFA based on the MFA preferences associated with the remuneration vehicle owner of the fifth data packet.
These limitations are repeating steps from claim 5 and are rejected for the same reason as above. 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 incorporate this second iteration of the process with Telle’s method of using an OTP to authenticate the identity of a cardholder in a financial transaction. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of proceeding with a second transaction (i.e., second interaction). Accounts are usually used for more than one transaction. Additionally, it is obvious to repeat steps. See In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a “web” which lies in the joint, and a plurality of “ribs” projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced.).
Claim 13:
Claim 13 is rejected using the same rationale that was used for the rejection of claim 5.
Claim 20:
Telle further teaches:
wherein the third data packet includes a transaction (see at least Telle, paragraph 0084 (“If the account number is verified, the directory server transmits 525 a positive VERes message to the MPI device. The positive VERes message indicates that authentication is available for the financial transaction.”)).
Telle does not explicitly teach, but Mehta, however, does teach:
that is encrypted by the electronic processor (see at least Mehta, Table 1; paragraph 0033; paragraph 0044).
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 incorporate Mehta’s encryption with Telle’s method of using an OTP to authenticate the identity of a cardholder in a financial transaction. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of securing the transaction data and reducing the likelihood of fraud.
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Verma et al., U.S. Patent Application Publication Number 2024/0073029 A1. This reference teaches generating and using OTPs for transactions.
Shenoy, Deepak. “You Can Opt Out of OTP for Small Transactions, But You Should Not,” https://premium.capitalmind.in/2016/12/you-can-opt-out-of-otp-for-small-transactions-but-you-should-not/ (Dec. 7, 2016). This reference discusses OTP preferences such as requiring OTP for transactions greater than a specified amount.
MasterCard SecureCode Merchant Implementation Guide (June 17, 2014). This reference discusses Mastercard’s SecureCode, which provides a way to authenticate cardholders at the time of purchase using an OTP. [This document was found via a google search but is encrypted and could not be attached to the Office action. This document belongs to Applicant and should be available to Applicant. It is also available at the following link: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjQns7EhpaSAxUvM9AFHYe8IxkQFnoECC0QAQ&url=https%3A%2F%2Fwww.mastercard.us%2Fcontent%2Fdam%2Fmccom%2Fen-us%2Fdocuments%2FSMI_Manual.pdf&usg=AOvVaw3Drh6YbhpMq6Xu2usQXSaE&opi=89978449 ]
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
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, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
1 See MPEP 2106.04(d)(2) (“Examiners should keep in mind that in order to qualify as a "treatment" or "prophylaxis" limitation for purposes of this consideration, the claim limitation in question must affirmatively recite an action that effects a particular treatment or prophylaxis for a disease or medical condition. An example of such a limitation is a step of "administering amazonic acid to a patient" or a step of "administering a course of plasmapheresis to a patient." If the limitation does not actually provide a treatment or prophylaxis, e.g., it is merely an intended use of the claimed invention or a field of use limitation, then it cannot integrate a judicial exception under the "treatment or prophylaxis" consideration. For example, a step of "prescribing a topical steroid to a patient with eczema" is not a positive limitation because it does not require that the steroid actually be used by or on the patient, and a recitation that a claimed product is a "pharmaceutical composition" or that a "feed dispenser is operable to dispense a mineral supplement" are not affirmative limitations because they are merely indicating how the claimed invention might be used.”)