DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 10/09/2025.
Claims 1, 9 and 20 are amended.
Claims 2, 3 and 10 are cancelled.
Claims 1, 4-9 and 11-20 are pending.
Claims 1, 4-9 and 11-20 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 10/09/2025 have been fully considered but they are not persuasive.
Note: Applicant is entitled to a single invention, Independent claims 1, 9 and 20 recite separate inventions.
101
Applicant argues “the additional limitations of amended Claim 1 reflect the improvement to a computer device or to a technological field by encrypting the secure cardholder identification, which the cardholder inputs into the cardholder-trusted device and is transmitted to the merchant device via the acquirer application system to process the requested transaction between the merchant device and the cardholder-trusted device.” Examiner disagrees.
First, generating keys are themselves abstract, as they are mathematical formulations and some do not require the use of a computing device. Secondly, it is unclear the improvement to technology that is achieved when information is encrypted and decrypted. For example, though not an improvement to technology, encrypting information can add to the security of the information. In Applicant’s arguments, there is the regurgitation of the conclusion that “aim 3 is not directed to a judicial exception because the additional limitations at steps (d), (e), and (f) reflect an improvement to a computer or to a technological field. That is, the "disclosed system detects network intrusions and takes real-time remedial actions, including dropping suspicious packets and blocking traffic from suspicious source addresses.” The key pair and their recitations in the claims do not achieve “an improvement to a computer or to a technological field”. Additionally, the use of keys, encrypting and decrypting information are recited and used in a well-understood, routine and conventional practice. For example, encrypting information with a public key and then using a private key of that key pair to decrypt the information is standard, well-understood, routine and conventional in the field.
Applicant’s claims are not direct at a technical problem but more towards efficiency of a business process “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology.” MPEP 2106.05(a) (II). The subject matter rejection is retained.
112
Neither Applicant’s amendments or arguments address the rejection. The disclosure discusses the cardholder device opening an entry display page. The disclosure does not provide written description for the device generating a secure entry display page in an application , receiving a secure entry page and a key or generating the secure entry page for display. The disclosure does not provide support for the claimed limitation. The rejection is maintained.
103
Granbery teaches generating, at a merchant device, an encryption key pair comprising a first key and a second key (¶ 28, 40, 43; claim 15)
Granbery – merchant device 107 may generate a merchant device (MD) public key 223 and a merchant device (MD) private key 224 using an asymmetric encryption algorithm. (¶ 28)
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-9 and 11-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claims 1 and 20 are directed to an article of manufacture, and claim 9 is directed to a method.
Analysis: Step 2a (Prong 1) – Identifying an Abstract Idea
The claims recite the steps of “generate … key pair… send, to an acquirer application system, a request for a transaction identifier (ID) for a transaction …obtain, from the acquirer application system, the transaction ID … display, at the merchant device, an element … receive, from the acquirer application system, the secure cardholder identification …receive, from the merchant device, a request …obtain the transaction ID …send, to the merchant device, the transaction ID… receive, from the cardholder-trusted device, the secure cardholder identification; and send, to the merchant device, the secure cardholder identification … receive the element associated with the transaction ID; … establish a secure transmission connection … generate a secure entry display page… encrypt the secure cardholder identification input…. and send, to the acquirer application system, the secure cardholder identification.” The claim recites an abstract idea that is directed towards certain methods of organizing human activity, in this case, the fundamental economic principle of transmitting and receiving transaction information for a financial transaction.
101 Analysis: Step 2a (Prong 2) – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application.
With regard to “generate a secure entry display page… encrypt the secure cardholder identification input…”, according to the disclosure(¶ 61), “In some embodiments where the unique transaction ID component is represented as a string of alphanumeric characters, a manual entry of the alphanumeric characters by a user on the device could perform the same function as a scan of a QR code. The unique transaction ID component may include information that causes the trusted cardholder device 130 to open a secure PIN (or other secure cardholder identification) entry display page served by the back-end server 140 in a browser or other application on the trusted cardholder device 130… In some embodiments, the secure PIN entry display page may be an example of prompting 204 a cardholder device 120 for a secure cardholder identification….” The device does not generate a display page, rather the page is displayed on the device to receive the user’s input. Displaying a page in an insignificant extra-solution activity of a generic device and therefore, not an additional element.
Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)). Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications.
101 Analysis - Step 2b
Viewed as a whole, instructions/method claims recite the concept of a fundamental economic practice as performed by a generic computer.
Claims 4-8, and 11-19 recite more steps directed at the abstract idea in the transmission and receipt of information between the parties towards a transaction.
The method claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Instead, the claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 4-8, and 11-19 are also rejected.
Claim Rejections - 35 USC § 112
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 1, 4-9 and 11-20 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.
Claims 1, 9 and 20 recite “generate, by the acquirer application system, a secure entry display page associated with the transaction ID to request a secure cardholder identification and send the secure entry display page and the first key to the cardholder- trusted device during a secure transmission connection between the acquirer application system and the cardholder-trusted device:… the secure entry display page and the first key received during the secure transmission connection …generate a secure entry display page for display in an application on the cardholder- trusted device….” According to the disclosure(¶ 61), “In some embodiments where the unique transaction ID component is represented as a string of alphanumeric characters, a manual entry of the alphanumeric characters by a user on the device could perform the same function as a scan of a QR code. The unique transaction ID component may include information that causes the trusted cardholder device 130 to open a secure PIN (or other secure cardholder identification) entry display page served by the back-end server 140 in a browser or other application on the trusted cardholder device 130… In some embodiments, the secure PIN entry display page may be an example of prompting 204 a cardholder device 120 for a secure cardholder identification….” The disclosure discusses the cardholder device opening an entry display page. The disclosure does not provide written description for the device generating a secure entry display page in an application , receiving a secure entry page and a key or generating the secure entry page for display. The disclosure does not provide support for the claimed limitation. Dependent claims 4-8, and 11-19 are also rejected.
The following is a quotation of 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 1, 4-9 and 11-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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 , 9 and 20 recite “generate, by the acquirer application system, a secure entry display page associated with the transaction ID to request a secure cardholder identification and send the secure entry display page and the first key to the cardholder- trusted device… wherein the at least one cardholder-trusted device processor is configured to:… display the secure entry display page…during the secure transmission connection established between the acquirer application system and the cardholder-trusted device based on the element associated with the transaction ID received by the cardholder-trusted device….” The claim limitations are unclear and indefinite. First, the limitations are convoluted, it is unclear whether Applicant is claiming the card-holder trusted device received the element or the transaction ID, as neither data were recited to be received by the cardholder trusted device. The claims are unclear and indefinite. Dependent claims 4-8, and 11-19 are also rejected.
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 1, 4-9 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Halldorsdottir (EP 2688026) (“Halldorsdottir”), in view of Metral (US 2016/0267458) (“Metral”) and further in view of Granbery et al. (US 20130080331) (“Granbery”).
Regarding claim 1, Halldorsdottir discloses at least one merchant device processor configured to execute instructions; at least one merchant device memory storing a sequence of instructions which, when executed by the at least one merchant device processor, perform a method of verifying an electronic identity wherein the at least one merchant device processor is configured to: (¶ 1-7, 29, 37, 38, 102, 105)
Halldorsdottir – the transaction terminal is a conventional transaction terminal of the kind used to read magnetic stripe cards, chip cards, or NFC cards. A merchant provides the transaction terminal for allowing the customer to perform transactions using a customer mobile device for obtaining the merchant’s goods or services (¶ 37)
send, to an acquirer application system, a request for a transaction identifier (ID) for a transaction between a merchant device and a cardholder-trusted device (¶ 1-5, 29, 49, 57, 102, 105, 109)
Halldorsdottir –In many cases the transaction terminal transmits the transaction request directly to the Merchant Bank’s Processor… The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 5, 49)
obtain, from the acquirer application system, the transaction ID for the transaction in response to the request (¶ 1-5, 29, 49, 102, 105)
Halldorsdottir – responding to the second transaction request by the bank and in doing so responding to the first transaction request, and providing a transaction response, the transaction response comprising: k. the first transaction terminal ID, m. an approval of the first transaction request, xv. sending the transaction response to the transaction terminal. (¶ 29)
display, at the merchant device, an element associated with the obtained transaction ID, wherein the transaction ID is a unique transaction ID associated, at the acquirer application system, with the transaction between the merchant device and the cardholder-trusted device (¶ 1-5, 29, 43, 85-87, 90-95, 120)
Claim Interpretation – According to the disclosure(¶ 59), with regards to the “element”, “In some embodiments, the QR code may be an example of an element, associated with the transaction ID, that is generated by the electronic transaction component or module 114, or the merchant application 112, on the merchant device 110.”
Halldorsdottir – . displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode….The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 49, 93)
receive, from the acquirer application system via the cardholder-trusted device, an encrypted secure cardholder identification associated with the transaction (¶ 1-5, 29, 44, 66- 68, 81, 102, 105, 143-146)
Halldorsdottir – The transaction response may comprise further information such as a time stamp, an accounts statement for an account associated with the customer transaction information, etc… The transaction response may be sent to the transaction terminal by the bank…The customer transaction information may be stored as an encrypted file, or in an e-wallet or encrypted structure. (¶ 66, 67, 81)
receive, by the merchant device, a payment card information for the transaction between the merchant device and the cardholder-trusted device and process, by the merchant device in response to a decrypted secure cardholder identification, the transaction based on the payment card information (¶ 1-5, 29, 44, 66- 68, 81, 102, 105, 143-146)
Halldorsdottir – The customer mobile device 50 includes an executable application 60. The application further comprises the customers card number 123 456 stored as an encrypted file 62….The application 60 then generates the transaction authorization 52, including the transaction terminal ID, T-ID and the customer's card information 123 456 read from the encrypted file 62, and sends the transaction authorization 52 to the server 40… The password may be used to decrypt/encrypt the customer transaction information on the customer mobile device or in the remote digital wallet. (¶ 46, 143, 146)
at least one acquirer application system processor configured to execute instructions; at least one acquirer application system memory storing a sequence of instructions which, when executed by the at least one processor, perform a method of verifying the electronic identity; wherein the at least one acquirer application system processor is configured to: (¶ 1-5, 29, 40, 43, 102, 108)
Halldorsdottir – The server may be separate from the bank, but is preferably operated and comprised by the bank. The server may be or comprise a mobile transaction processor. The server may be specific for a specific merchant or a specific merchant’s bank. (¶ 43)
receive, from the merchant device by the acquirer application system, the request for the transaction ID for the transaction between the merchant device and the cardholder-trusted device; (¶ 1-5, 29, 49, 102, 105)
Halldorsdottir –In many cases the transaction terminal transmits the transaction request directly to the Merchant Bank’s Processor… the first transaction request comprising: e. a first transaction terminal ID identifying the transaction terminal, f. a mobile transaction identification information identifying the server as the recipient of the first transaction request, and g. a first amount, (¶ 5, 29)
generate, by the acquirer application system, the transaction ID in response to the request for the transaction ID from the at least one merchant device (¶ 1-5, 29, 49, 54, 55, 61)
Halldorsdottir –. responding to the second transaction request by the bank and in doing so responding to the first transaction request, and providing a transaction response, the transaction response comprising: k. the first transaction terminal ID, m. an approval of the first transaction request, xv. sending the transaction response to the transaction terminal… Thus, the transaction terminal ID may also include a merchant ID. Thus, for forming the transaction pair, the server can additionally analyze the first transaction request and the transaction authorization to, in addition to the transaction terminal ID, also determine a merchant ID and use the merchant ID, together with the transaction terminal ID, for forming the transaction pair… The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶29, 49)
send, to the merchant device, the transaction ID (¶ 1-5, 29, 54, 102, 105)
Halldorsdottir – . responding to the second transaction request by the bank and in doing so responding to the first transaction request, and providing a transaction response, the transaction response comprising: k. the first transaction terminal ID, m. an approval of the first transaction request, xv. sending the transaction response to the transaction terminal… (¶ 29)
generate, by the acquirer application system, a secure entry display page associated with the transaction ID to request a secure cardholder identification and send the secure entry display page to the cardholder- trusted device during a secure transmission connection between the acquirer application system and the cardholder-trusted device (Abstract; ¶ 44, 90-95, 133-135,148-156)
Claim Interpretation – According to the disclosure(¶ 61), “In some embodiments where the unique transaction ID component is represented as a string of alphanumeric characters, a manual entry of the alphanumeric characters by a user on the device could perform the same function as a scan of a QR code. The unique transaction ID component may include information that causes the trusted cardholder device 130 to open a secure PIN (or other secure cardholder identification) entry display page served by the back-end server 140 in a browser or other application on the trusted cardholder device 130… In some embodiments, the secure PIN entry display page may be an example of prompting 204 a cardholder device 120 for a secure cardholder identification…”
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The password 68 may be the PIN associated with the customer's card information 123 456 or the application 60 may prompt the customer to enter the PIN before the transaction authorization 52 is sent to the server 40. In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26…The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, … The customer mobile device scans the information on the QR code and prompts the customer to select a card information. The customer mobile device connects to the server and transmits the QR code information and the card information. The server may prompt the customer to confirm the purchase amount and may ask for a PIN. (Abstract; ¶ 44, 93, 148, 149, 156)
receive, from the cardholder-trusted device, the secure cardholder identification from an application displaying the secure entry display page, the secure cardholder identification comprising a PIN or a digital representation of a biometric identifier associated with a card for the transaction; and (¶ 29, 44, 53, 59, 63, 64, 102, 133-136)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The second transaction request may also be… as is contained in a conventional transaction request, in particular the customer transaction information needed for being processed by the bank… a PIN code associated with the customer card information… the QR-code 70 is recorded 72 by the application 60 (not shown) resident on the customer mobile device 50 similarly to fig. 8. The user 2 inputs a PIN associated with the customer's card number 123 456 into the transaction terminal 20 as indicated by the arrow 68I, which PIN is then included in a modified first transaction request 22I sent to the bank 30. (¶ 44, 63, 153)
send, to the merchant device, the encrypted secure cardholder identification; and (¶ 1-5, 29, 66- 68, 81, 143-146, 155)
Halldorsdottir – The transaction response may comprise further information such as a time stamp, an accounts statement for an account associated with the customer transaction information, etc… The transaction response may be sent to the transaction terminal by the bank…The customer mobile device 50 includes an executable application 60. The application further comprises the customers card number 123 456 stored as an encrypted file 62. (¶ 66, 67, 143)
at least one cardholder-trusted device processor configured to execute instructions; and at least one cardholder-trusted device memory storing a sequence of instructions which, when executed by the at least one processor, perform a method of verifying the electronic identity; wherein the at least one cardholder-trusted device processor is configured to: (¶ 1-5, 29, 43, 45, 81-83, 98-101)
Halldorsdottir –The application, customer mobile device, or the digital wallet may, in addition to the customer transaction information, store further customer transaction information associated with different means of performing transactions, such as different payment cards. (¶ 45)
receive, by the cardholder-trusted device, the element associated with the transaction ID from the merchant device (¶ 1-5, 29, 43, 85-87, 90-95, 120)
Claim Interpretation – According to the disclosure(¶ 61), “The cardholder may obtain (e.g., access/receive) 822 the unique transaction ID component (e.g., by scanning a QR code) using the trusted cardholder device 130. ”
Halldorsdottir – displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode. (¶ 93)
display the secure entry display page in an application on the cardholder-trusted device for inputting the secure cardholder identification, the secure entry display page (Abstract; ¶ 44, 90-95, 133-135,148-156)
Claim Interpretation – According to the disclosure(¶ 61), “In some embodiments where the unique transaction ID component is represented as a string of alphanumeric characters, a manual entry of the alphanumeric characters by a user on the device could perform the same function as a scan of a QR code. The unique transaction ID component may include information that causes the trusted cardholder device 130 to open a secure PIN (or other secure cardholder identification) entry display page served by the back-end server 140 in a browser or other application on the trusted cardholder device 130… In some embodiments, the secure PIN entry display page may be an example of prompting 204 a cardholder device 120 for a secure cardholder identification…”
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The password 68 may be the PIN associated with the customer's card information 123 456 or the application 60 may prompt the customer to enter the PIN before the transaction authorization 52 is sent to the server 40. In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26…The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, … The customer mobile device scans the information on the QR code and prompts the customer to select a card information. The customer mobile device connects to the server and transmits the QR code information and the card information. The server may prompt the customer to confirm the purchase amount and may ask for a PIN. (Abstract; ¶ 44, 93, 148, 149, 156)
encrypt, by the cardholder-trusted device, the secure cardholder identification received as input into the secure entry display page; and (¶ 44, 52, 56, 81, 148-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted. The communication may for example be made using https and/or SSL/TLS… In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26. (¶ 44, 148)
send, to the acquirer application system via the secure transmission connection, the secure cardholder identification (Abstract; ¶ 44, 63, 148-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, …The second transaction request may also be… as is contained in a conventional transaction request, in particular the customer transaction information needed for being processed by the bank (¶ 44, 63, 149)
wherein the transaction between the merchant device and the cardholder-trusted device is authorized by at least one of the acquirer application system or the merchant device based on validating the decrypted secure cardholder identification from the cardholder-trusted device(Abstract; ¶ 44, 63, 148-156)
Halldorsdottir –The application 60 then prompts the customer 2 for the PIN, the customer enters the PIN, and the PIN is sent to the server 40, where after the method proceeds as described above with reference to figures 2-7 with the addition that the PIN is submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26. (¶ 150)
Halldorsdottir does not disclose and the first key of the encryption key pair, and the first key, encrypted with the first key, and the first key received during the secure transmission connection established between the acquirer application system and the cardholder-trusted device based on the element associated with the transaction ID received by the cardholder-trusted device; of the application with the first key, wherein the secure cardholder information is decrypted using the second key of the encryption key pair.
Metral teaches and the first key of the encryption key pair, and the first key, encrypted with the first key, and the first key received during the secure transmission connection established between the acquirer application system and the cardholder-trusted device based on the element associated with the transaction ID received by the cardholder-trusted device; of the application with the first key, wherein the secure cardholder information is decrypted using the second key of the encryption key pair (¶ 15, 58, 73-78, 83).
Metral - when a payment processor provides a registry of keys to allow users to securely exchange mobile payment data with respective merchants 190. In an example, mobile payment system 130 of a payment service provider or another third-party provides a registry of public keys that allow smart devices to securely communicate with near field communication (NFC) terminals 192 of merchants 190 … Further, client machine 102A then may use the public key to encrypt and securely communicate data to merchant 190 and/or terminals 192 associated with merchant 190…. users may encrypt data using the public key of merchant 190, then merchant 190 or another party with access to a corresponding private key may use the private key to unencrypt such data. (¶ 73, 74, 78)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Halldorsdottir and Metral in order to provide further protection for user information in a transaction (Metral; ¶ 15).
Neither Halldorsdottir nor Metral teaches generate, at the merchant device, an encryption key pair comprising a first key and a second key.
Granbery teaches generate, at the merchant device, an encryption key pair comprising a first key and a second key; (¶ 28, 40, 43; claim 15)
Granbery – merchant device 107 may generate a merchant device (MD) public key 223 and a merchant device (MD) private key 224 using an asymmetric encryption algorithm. (¶ 28)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Halldorsdottir. Metral and Granbery in order to reduce potential financial loss for merchants (Granbery; ¶ 5).
Regarding claims 4 and 12, Metral teaches wherein: the at least one acquirer application system processor is further configured to: obtain a public key; and send, to the cardholder-trusted device, the public key; and the at least one cardholder-trusted device processor is further configured to: receive, from the acquirer application system, the public key; and prior to sending the secure cardholder identification to the acquirer application system, encrypt the secure cardholder identification with the public key (¶ 15, 38, 73-85).
Regarding claims 5, 13 and 14, Metral teaches wherein: the at least one merchant device processor is further configured to: send, to the acquirer application, a public key; the at least one acquirer application system processor is further configured to: receive, from the merchant device, the public key; and send, to the cardholder-trusted device, the public key; and the at least one cardholder-trusted device processor is further configured to: receive, from the acquirer application, the public key; and prior to sending the secure cardholder identification to the acquirer application, encrypt the secure cardholder identification with the public key (¶ 15, 38, 73-85).
Regarding claims 6, 15 and 16, Halldorsdottir discloses wherein: the at least one acquirer application system processor is further configured to: generate the element associated with the transaction ID; and send, to the merchant device, the element associated with the transaction ID; and the at least one merchant device processor is further configured to: receive the element associated with the transaction ID from the acquirer application (¶ 90-95, 120, 127, 129).
Regarding claims 7 and 17, Halldorsdottir discloses wherein: the at least one acquirer application system processor is further configured to: receive, from the cardholder-trusted device, a request for a secure session for the transmission of the secure cardholder identification; and send, to the cardholder-trusted device, a request for the secure cardholder identification; and the at least one cardholder-trusted device processor is further configured to: send, to the acquirer application, the request for the secure session for the transmission of the secure cardholder identification; receive, from the acquirer application, the request for the secure cardholder identification; and receive an input comprising the secure cardholder identification (¶ 29, 43-45, 49, 63-68, 102, 105, 155, 156).
Regarding claim 8, Halldorsdottir discloses the at least one merchant device processor is further configured to: send, to the acquirer application, a merchant credentials validation request message; receive, from the acquirer application, a validation response message; receive, from the acquirer application, a validation request message; send, to the acquirer application, a transaction authorization request message; and receive, from the acquirer application, a transaction authorization response message; the at least one acquirer application system processor is further configured to: receive, from the merchant device, the merchant credentials validation request message; transmit, to the merchant device, the validation response message; receive, from the cardholder-trusted device, a secure two-way communication request message; transmit, to the cardholder-trusted device, an open uniform resource locator (URL) response message; receive, from the cardholder-trusted device, the validation request message; transmit, to the merchant device, the validation request message; receive, from the merchant device, the transaction authorization request message; and transmit, to the merchant device, the transaction authorization response message; and the at least one cardholder-trusted device processor is further configured to: send, to the acquirer application, the secure two-way communication request message; receive, from the acquirer application, the open URL response message; and send, to the acquirer application, the validation request message (¶ 1-5, 29, 43-68, 91-95, 102, 111-113, 116, 131-136, 151; claim 11).
Regarding claim 9, discloses sending, from the merchant device to an acquirer application, a request for a transaction identifier (ID) for a transaction between the merchant device and a cardholder-trusted device (¶ 1-5, 29, 49, 57, 102, 105, 109)
Halldorsdottir –In many cases the transaction terminal transmits the transaction request directly to the Merchant Bank’s Processor… The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 5, 49)
obtaining, at the acquirer application, the transaction ID; generating, at the acquirer application, the transaction ID in response to the request for the transaction ID from the merchant device; receiving, at the merchant device from the acquirer application, the transaction ID (¶ 1-5, 29, 49, 54, 55, 61, 102, 105)
Claim Interpretation – unclear the difference in these claims between ‘obtaining’ and ‘generating’.
Halldorsdottir – responding to the second transaction request by the bank and in doing so responding to the first transaction request, and providing a transaction response, the transaction response comprising: k. the first transaction terminal ID, m. an approval of the first transaction request, xv. sending the transaction response to the transaction terminal… Thus, the transaction terminal ID may also include a merchant ID. Thus, for forming the transaction pair, the server can additionally analyze the first transaction request and the transaction authorization to, in addition to the transaction terminal ID, also determine a merchant ID and use the merchant ID, together with the transaction terminal ID, for forming the transaction pair… The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶29, 49)
displaying, at the merchant device, an element associated with the obtained transaction identifier ID, wherein the transaction ID is associated, at the acquirer application, with the transaction between the merchant device and the cardholder-trusted device (¶ 1-5, 29, 43, 85-87, 90-95, 120)
Claim Interpretation – According to the disclosure(¶ 59), with regards to the “element”, “In some embodiments, the QR code may be an example of an element, associated with the transaction ID, that is generated by the electronic transaction component or module 114, or the merchant application 112, on the merchant device 110.”
Halldorsdottir – . displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode….The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 49, 93)
receiving, at the cardholder-trusted device, the element associated with the transaction ID (¶ 1-5, 29, 44, 66- 68, 81, 102, 105 )
Halldorsdottir – The transaction response may comprise further information such as a time stamp, an accounts statement for an account associated with the customer transaction information, etc… The transaction response may be sent to the transaction terminal by the bank (¶ 66, 67)
a secure transmission connection between the cardholder-trusted device and the acquirer application in response to the cardholder-trusted device receiving the element associated with the transaction ID from the merchant device (Abstract; ¶ 44, 66-68, 90-95, 133-135)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode…. A customer wishing to perform a transaction with the transaction terminal generates and sends a transaction authorization comprising the transaction terminal ID and customer transaction information, such as customer payment card information, to the server. (Abstract; ¶ 44, 93)
displaying, at the cardholder-trusted device based on information associated with the received element associated with the transaction ID, a secure entry display page in an application for inputting a secure cardholder identification, the secure entry display page and (Abstract; ¶ 44, 90-95, 133-135,148-156)
Claim Interpretation – According to the disclosure(¶ 61), “In some embodiments where the unique transaction ID component is represented as a string of alphanumeric characters, a manual entry of the alphanumeric characters by a user on the device could perform the same function as a scan of a QR code. The unique transaction ID component may include information that causes the trusted cardholder device 130 to open a secure PIN (or other secure cardholder identification) entry display page served by the back-end server 140 in a browser or other application on the trusted cardholder device 130… In some embodiments, the secure PIN entry display page may be an example of prompting 204 a cardholder device 120 for a secure cardholder identification…”
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The password 68 may be the PIN associated with the customer's card information 123 456 or the application 60 may prompt the customer to enter the PIN before the transaction authorization 52 is sent to the server 40. In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26…The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, … The customer mobile device scans the information on the QR code and prompts the customer to select a card information. The customer mobile device connects to the server and transmits the QR code information and the card information. The server may prompt the customer to confirm the purchase amount and may ask for a PIN. (Abstract; ¶ 44, 93, 148, 149, 156)
sending, to the acquirer application via the secure transmission connection, the secure cardholder identification input into the secure entry display page, the secure cardholder identification comprising at least a PIN associated with a card to be used for the transaction (Abstract; ¶ 29, 44, 53, 59, 63, 64, 102, 133-136, 148-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, …The second transaction request may also be… as is contained in a conventional transaction request, in particular the customer transaction information needed for being processed by the bank (¶ 44, 63, 149)
encrypting, by the cardholder-trusted device, the secure cardholder identification received as input into the secure entry display page; and (¶ 44, 52, 56, 81, 143-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted. The communication may for example be made using https and/or SSL/TLS… In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26. (¶ 44, 148)
receiving, at the merchant device from the acquirer application, the encrypted secure cardholder identification; and(¶ 1-5, 29, 44, 52, 56, 66- 68, 81, 148-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, …The second transaction request may also be… as is contained in a conventional transaction request, in particular the customer transaction information needed for being processed by the bank (¶ 44, 63, 149)
processing, by the merchant device, the transaction based on the decrypted secure cardholder identification and the card for the transaction (¶ 1-5, 29, 44, 66- 68, 81, 102, 105, 143-146)
Halldorsdottir – The customer mobile device 50 includes an executable application 60. The application further comprises the customers card number 123 456 stored as an encrypted file 62….The application 60 then generates the transaction authorization 52, including the transaction terminal ID, T-ID and the customer's card information 123 456 read from the encrypted file 62, and sends the transaction authorization 52 to the server 40… The password may be used to decrypt/encrypt the customer transaction information on the customer mobile device or in the remote digital wallet. (¶ 46, 143, 146)
wherein the transaction between the merchant device and the cardholder-trusted device is authorized by at least one of the acquirer application of an acquirer application system or the merchant device based on validating the decrypted secure cardholder identification from the cardholder-trusted device (Abstract; ¶ 44, 46, 63, 81, 143-156)
Halldorsdottir –The application 60 then prompts the customer 2 for the PIN, the customer enters the PIN, and the PIN is sent to the server 40, where after the method proceeds as described above with reference to figures 2-7 with the addition that the PIN is submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26…The password may be used to decrypt/encrypt the customer transaction information on the customer mobile device or in the remote digital wallet. (¶ 46, 150)
wherein the element is generated by at least one of the at least one merchant device or the at least one acquirer application, and (¶ 1-5, 29, 43, 85-87, 90-95, 120)
Claim Interpretation – According to the disclosure(¶ 59), with regards to the “element”, “In some embodiments, the QR code may be an example of an element, associated with the transaction ID, that is generated by the electronic transaction component or module 114, or the merchant application 112, on the merchant device 110.”
Halldorsdottir – . displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode…The barcode may be a one-dimensional barcode, but is preferably a two-dimensional barcode such as a QR-code… the QR code may be dynamically generated by the transaction terminal. (¶ 93-95)
Halldorsdottir does not disclose and the first key, establishing a secure transmission connection, the first key received during the secure transmission connection, of the application with the first key, wherein the secure cardholder information is decrypted using the second key of the encryption key pair.
Metral teaches and the first key, establishing a secure transmission connection, the first key received during the secure transmission connection, of the application with the first key, wherein the secure cardholder information is decrypted using the second key of the encryption key pair (¶ 15, 58, 73-78, 83).
Metral - when a payment processor provides a registry of keys to allow users to securely exchange mobile payment data with respective merchants 190. In an example, mobile payment system 130 of a payment service provider or another third-party provides a registry of public keys that allow smart devices to securely communicate with near field communication (NFC) terminals 192 of merchants 190 … Further, client machine 102A then may use the public key to encrypt and securely communicate data to merchant 190 and/or terminals 192 associated with merchant 190…. users may encrypt data using the public key of merchant 190, then merchant 190 or another party with access to a corresponding private key may use the private key to unencrypt such data. (¶ 73, 74, 78)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Halldorsdottir and Metral in order to provide further protection for user information in a transaction (Metral; ¶ 15).
Neither Halldorsdottir nor Metral teaches generate, at a merchant device, an encryption key pair comprising a first key and a second key.
Granbery teaches generate, at a merchant device, an encryption key pair comprising a first key and a second key; (¶ 28, 40, 43; claim 15)
Granbery – merchant device 107 may generate a merchant device (MD) public key 223 and a merchant device (MD) private key 224 using an asymmetric encryption algorithm. (¶ 28)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Halldorsdottir, Metral and Granbery in order to reduce potential financial loss for merchants (Granbery; ¶ 5).
Regarding claim 18, Halldorsdottir discloses wherein the request for a secure session comprises at least one of: receiving, at the acquirer application from the cardholder-trusted device, a request associated with a uniform resource locator (URL); or receiving, at the acquirer application from the cardholder-trusted device, a request associated with a cardholder account form the cardholder-trusted device (¶ 43-49, 90-95, 130-136; claim 11).
Regarding claim 19, Halldorsdottir discloses receiving, at the acquirer application from the merchant device, a merchant credentials validation request message; transmitting, from the acquirer application to the merchant device, a validation response message; receiving, at the acquirer application from the cardholder-trusted device, a secure two-way communication request message; transmitting, from the acquirer application to the cardholder-trusted device, an open URL response message; receiving, at the acquirer application from the cardholder-trusted device, a validation request message; transmitting, from the acquirer application to the merchant device, the validation request message; receiving, at the acquirer application from the merchant device, a transaction authorization request message; and transmitting, from the acquirer application to the merchant device, the transaction authorization response message (¶ 1-5, 29, 43-68, 91-95, 102, 111-113, 116, 131-136, 151; claim 11).
Regarding claim 20, sending, from the merchant device to an acquirer application, a request for a transaction identifier (ID) for a transaction between the merchant device and a cardholder-trusted device (¶ 1-5, 29, 49, 57, 102, 105, 109)
Halldorsdottir –In many cases the transaction terminal transmits the transaction request directly to the Merchant Bank’s Processor… The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 5, 49)
obtaining, at the acquirer application, the transaction ID; generating, at the acquirer application, the transaction ID in response to the request for the transaction ID from the merchant device; receiving, at the merchant device from the acquirer application, the transaction ID (¶ 1-5, 29, 49, 54, 55, 61, 102, 105)
Claim Interpretation – unclear the difference in these claims between ‘obtaining’ and ‘generating’.
Halldorsdottir – responding to the second transaction request by the bank and in doing so responding to the first transaction request, and providing a transaction response, the transaction response comprising: k. the first transaction terminal ID, m. an approval of the first transaction request, xv. sending the transaction response to the transaction terminal… Thus, the transaction terminal ID may also include a merchant ID. Thus, for forming the transaction pair, the server can additionally analyze the first transaction request and the transaction authorization to, in addition to the transaction terminal ID, also determine a merchant ID and use the merchant ID, together with the transaction terminal ID, for forming the transaction pair… The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 29, 49)
displaying, at the merchant device, an element associated with the received transaction ID, wherein the transaction ID is associated with the transaction between the merchant device and the cardholder-trusted device by the acquirer application (¶ 1-5, 29, 43, 85-87, 90-95, 120)
Claim Interpretation – According to the disclosure(¶ 59), with regards to the “element”, “In some embodiments, the QR code may be an example of an element, associated with the transaction ID, that is generated by the electronic transaction component or module 114, or the merchant application 112, on the merchant device 110.”
Halldorsdottir – . displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode….The transaction terminal ID, or the first transaction request and the transaction authorization may additionally include further information, such as a time stamp or order number included in both the first transaction request and the transaction authorization, for being determined by the server and used for forming the transaction pair. (¶ 49, 93)
receiving, at the cardholder-trusted device, the element associated with the transaction ID displayed by the merchant device (¶ 1-5, 29, 44, 66- 68, 81, 102, 105 )
Halldorsdottir – The transaction response may comprise further information such as a time stamp, an accounts statement for an account associated with the customer transaction information, etc… The transaction response may be sent to the transaction terminal by the bank (¶ 66, 67)
a secure transmission connection between the cardholder-trusted device and the acquirer application in response to the cardholder-trusted device receiving the element associated with the transaction ID from the merchant device (Abstract; ¶ 44, 66-68, 90-95, 133-135)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… displaying a barcode by the transaction terminal, the barcode comprising the second transaction terminal ID, the second amount and/or the address, and the customer mobile device comprising an optical sensor for reading the barcode…. A customer wishing to perform a transaction with the transaction terminal generates and sends a transaction authorization comprising the transaction terminal ID and customer transaction information, such as customer payment card information, to the server. (Abstract; ¶ 44, 93)
generate a secure entry display page for display in an application on the cardholder- trusted device for inputting a secure cardholder identification in response to receiving the element associated with the transaction ID (Abstract; ¶ 44, 90-95, 133-135,148-156)
Claim Interpretation – According to the disclosure(¶ 61), “In some embodiments where the unique transaction ID component is represented as a string of alphanumeric characters, a manual entry of the alphanumeric characters by a user on the device could perform the same function as a scan of a QR code. The unique transaction ID component may include information that causes the trusted cardholder device 130 to open a secure PIN (or other secure cardholder identification) entry display page served by the back-end server 140 in a browser or other application on the trusted cardholder device 130… In some embodiments, the secure PIN entry display page may be an example of prompting 204 a cardholder device 120 for a secure cardholder identification…”
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The password 68 may be the PIN associated with the customer's card information 123 456 or the application 60 may prompt the customer to enter the PIN before the transaction authorization 52 is sent to the server 40. In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26…The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, … The customer mobile device scans the information on the QR code and prompts the customer to select a card information. The customer mobile device connects to the server and transmits the QR code information and the card information. The server may prompt the customer to confirm the purchase amount and may ask for a PIN. (Abstract; ¶ 44, 93, 148, 149, 156)
encrypting, at the cardholder-trusted device, the secure cardholder identification input into the secure entry display page from the acquirer application via the secure transmission connection (¶ 44, 52, 56, 81, 148-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted. The communication may for example be made using https and/or SSL/TLS… In this case, the PIN is included in the transaction authorization 52 and submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26. (¶ 44, 148)
receiving, at the acquirer application from the cardholder-trusted device via the secure transmission connection, the encrypted secure cardholder identification, the secure cardholder identification comprising at least a PIN associated with a card for the transaction; and (¶ 29, 44-46, 53, 59, 63, 64, 81, 102, 133-136, 143-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The second transaction request may also be… as is contained in a conventional transaction request, in particular the customer transaction information needed for being processed by the bank… a PIN code associated with the customer card information… the QR-code 70 is recorded 72 by the application 60 (not shown) resident on the customer mobile device 50 similarly to fig. 8. The user 2 inputs a PIN associated with the customer's card number 123 456 into the transaction terminal 20 as indicated by the arrow 68I, which PIN is then included in a modified first transaction request 22I sent to the bank 30… The customer mobile device 50 includes an executable application 60. The application further comprises the customers card number 123 456 stored as an encrypted file 62. (¶ 44, 63, 143, 153)
receiving, at the merchant device from the acquirer application, the encrypted secure cardholder identification (Abstract; ¶ 44-46, 63, 81, 143-156)
Halldorsdottir –The communication between the customer mobile device and the server, i.e. the transaction authorization, should be encrypted or otherwise made secure so that the customer transaction information is not easily intercepted… The customer 2 inputs the PIN, in this alternative embodiment indicated by the arrow 78. The PIN is then sent to the server 40, …The second transaction request may also be… as is contained in a conventional transaction request, in particular the customer transaction information needed for being processed by the bank… The customer mobile device 50 includes an executable application 60. The application further comprises the customers card number 123 456 stored as an encrypted file 62. (¶ 44, 63, 143, 149)
wherein the transaction between the merchant device and the cardholder-trusted device is authorized by at least one of an acquirer application system or the merchant device based on validating the decrypted secure cardholder identification from the cardholder-trusted device (Abstract; ¶ 44-46, 63, 143-156)
Halldorsdottir –The application 60 then prompts the customer 2 for the PIN, the customer enters the PIN, and the PIN is sent to the server 40, where after the method proceeds as described above with reference to figures 2-7 with the addition that the PIN is submitted to the authorization process 36 for authenticating the user 2 for generating the first transaction response 26… The password may be used to decrypt/encrypt the customer transaction information on the customer mobile device or in the remote digital wallet (¶ 46, 150)
Halldorsdottir does not disclose and the first key of the encryption key pair, establishing a secure transmission connection, with the first key, the first key received, wherein the secure cardholder identification is decrypted using the second key of the encryption key pair.
Metral teaches and the first key of the encryption key pair, establishing a secure transmission connection, with the first key, the first key received, wherein the secure cardholder identification is decrypted using the second key of the encryption key pair (¶ 15, 58, 73-78, 83).
Metral - when a payment processor provides a registry of keys to allow users to securely exchange mobile payment data with respective merchants 190. In an example, mobile payment system 130 of a payment service provider or another third-party provides a registry of public keys that allow smart devices to securely communicate with near field communication (NFC) terminals 192 of merchants 190 … Further, client machine 102A then may use the public key to encrypt and securely communicate data to merchant 190 and/or terminals 192 associated with merchant 190…. users may encrypt data using the public key of merchant 190, then merchant 190 or another party with access to a corresponding private key may use the private key to unencrypt such data. (¶ 73, 74, 78)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Halldorsdottir and Metral in order to provide further protection for user information in a transaction (Metral; ¶ 15).
Neither Halldorsdottir nor Metral teaches generating, at a merchant device, an encryption key pair comprising a first key and a second key.
Granbery teaches generating, at a merchant device, an encryption key pair comprising a first key and a second key (¶ 28, 40, 43; claim 15)
Granbery – merchant device 107 may generate a merchant device (MD) public key 223 and a merchant device (MD) private key 224 using an asymmetric encryption algorithm. (¶ 28)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Halldorsdottir, Metral and Granbery in order to reduce potential financial loss for merchants (Granbery; ¶ 5).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pourfallah et al. (US 2012/0253852)
Mendes (EP 2779064)
Yang (US 20140129445)
Rose et al (WO 2010141456)
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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, NEHA H PATEL can be reached on (571) 270-1492. 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699