- DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is the first office action on the merits in response to the application filed on
09/03/2025.
Claims 1-20 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Subject Matter Eligibility Criteria – Step 1:
Claims 1-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Subject Matter Eligibility Criteria – Step 2A – Prong One:
Regarding Prong One of Step 2A of the Alice/Mayo test, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. MPEP 2106.04(II)(A)(1). An “abstract idea” judicial exception is subject matter that falls within at least one of the following groups: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts. MPEP 2106.04(a).
Representative independents claims 1, 10, and 17 include limitations that recite at least one abstract idea.
Claim 1 is directed to the abstract idea of “receiving, by a user portable electronic device, a request from a merchant portable electronic device to provide the PIN, wherein the request to provide the PIN is based on a transaction initiated using a payment card and the merchant portable electronic device; receiving, by a PIN entry application executed by the user portable electronic device, a user input to approve the request from the merchant portable electronic device; generating, by the PIN entry application executed by the user portable electronic device, an encrypted binary large object (BLOB) based on the PIN; and communicating, by the user portable electronic device, the encrypted BLOB to the merchant portable electronic device, wherein the merchant portable electronic device is configured to communicate the encrypted BLOB to a transaction service provider server for decryption” Under its broadest reasonable interpretation, this claim is managing and authenticating payment transactions using a PIN entry, receiving user approval and PIN information, communicating encrypted PIN data, and authorizing the transaction, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Claim 10 is directed to the abstract idea of “receiving, by a transaction service provider server, a first transaction authentication request from an acquirer server, wherein the first transaction authentication request comprises the encrypted BLOB communicated to the merchant portable electronic device; mapping, by the transaction service provider server, the transaction to a token; retrieving, by the transaction service provider server, a dynamic key based on the token; decrypting, by the transaction service provider server, the encrypted BLOB to determine the PIN; and sending, by the transaction service provider server, a second transaction authentication request to an issuer server, wherein the issuer server determines whether to authenticate the transaction based on the PIN.” Under its broadest reasonable interpretation, this claim is managing and authenticating payment transactions using a PIN entry, receiving user approval and PIN information, communicating encrypted PIN data, and authorizing the transaction, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Claim 17 is directed to the abstract idea of “reading, by a merchant portable electronic device, a payment card to initiate a transaction; determining, by a point-of-sale application executed by the merchant portable electronic device, that the transaction requires a PIN; communicating, by the merchant portable electronic device, a request to a user portable electronic device to provide the PIN, receiving, by the merchant portable electronic device, an encrypted binary large object (BLOB) from the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the PIN; and communicating , by the merchant portable electronic device, a transaction authorization request comprising the encrypted BLOB to a transaction service provider server for decryption.” Under its broadest reasonable interpretation, this claim is managing and authenticating payment transactions using a PIN entry, receiving user approval and PIN information, communicating encrypted PIN data, and authorizing the transaction, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Dependent Claims:
Claim 2 recites: wherein the transaction is a tap-to-phone transaction; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 3 recites: receiving, by the user portable electronic device, the PIN; receiving, by the user portable electronic device, a passcode; receiving, by the user portable electronic device, a user biometric authentication; or a combination thereof; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 7 recites: enrolling, by the PIN entry application executed by the user portable electronic device, the payment card to the PIN entry application based on a user input; and receiving, by the PIN entry application executed by the user portable electronic device, the token and the dynamic key provisioned by the transaction service provider server; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 8 recites: storing, by the PIN entry application executed by the user portable electronic device, the PIN to a memory of the user portable electronic device; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 11 recites: determining, by the transaction service provider server, that the transaction is a tap- to-phone transaction (TTP) based on a TTP transaction identifier comprised in the first transaction authentication request; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 14 recites: extracting, by the transaction service provider server, a personal authentication number (PAN) from the first transaction authentication request, wherein mapping the transaction to the token is based on the PAN; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 18 recites: transmitting, by the merchant portable electronic device, a first transaction authorization comprising the encrypted BLOB to a payment gateway server, wherein the payment gateway server transmits a second transaction authorization comprising the encrypted BLOB to an acquirer server, and wherein the acquirer server transmits a third transaction authorization comprising the encrypted BLOB to the transaction service provider server; or transmitting, by the merchant portable electronic device, a first transaction authorization comprising the encrypted BLOB to an acquire server, and wherein the acquirer server transmits a second transaction authorization comprising the encrypted BLOB to the transaction service provider server; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Subject Matter Eligibility Criteria – Step 2A – Prong Two:
Claims 1, 10, and 17 recites to a user portable electronic device, merchant portable electronic device, transaction service provider server, acquirer server, and an issuer server, as additional elements to the judicial exception in the preamble. Viewed individually and in combination, these additional elements do not integrate the abstract idea into a practical application because they are used to implement the abstract idea of managing and authenticating payment transactions using a PIN entry, receiving user approval and PIN information, communicating encrypted PIN data, and authorizing the transaction. The claims do not recite to a particular improvement to the functioning of the user portable electronic device, merchant portable electronic device, server, encryption technology, or payment network itself. Therefore, at Step 2A.2, these additional elements do not act in combination to integrate the abstract idea into a practical application.
Dependent Claims:
Claim 2 recites: wherein the transaction is a tap-to-phone transaction. These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 3 recites: wherein the data type is a Boolean data type, an integer data type, a decimal data type, a string data type date and time data type, an object data type, and/or a pointer data type.; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 4 recites: wherein communicating the encrypted BLOB to the merchant portable electronic device comprises: generating, by the PIN entry application executed by the user portable electronic device, a quick response (QR) code based on the encrypted BLOB; and displaying, by a display screen of the user portable electronic device, the QR code, wherein the QR code is readable by the merchant portable electronic device; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 5 recites: generating, by the PIN entry application executed by the user portable electronic device, at least one of a near field communication (NFC) data exchange format message comprising the encrypted BLOB, a sound comprising the encrypted BLOB, a Bluetooth message comprising the encrypted BLOB, a WiFi message comprising the encrypted BLOB, or a combination thereof; and transmitting, by the user portable electronic device, the at least one of the near field communication (NFC) data exchange format message comprising the encrypted BLOB, the sound comprising the encrypted BLOB, the Bluetooth message comprising the encrypted BLOB, the WiFi message comprising the encrypted BLOB, or a combination thereof to the merchant portable electronic device; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 6 recites: generating, by the PIN entry application executed by the user portable electronic device, the encrypted BLOB based on a token provisioned by the transaction service provider server and a dynamic key provisioned by the transaction service provider server, wherein the transaction service provider server is configured to decrypt the encrypted BLOB based on the token and the dynamic key.; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 9 recites: wherein the encrypted BLOB is configured according to International Organization for Standardization (ISO) PIN block format; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 12 recites: provisioning, by the transaction service provider server, the token and the dynamic key to the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the token and the dynamic key; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 13 recites: wherein sending the second transaction authentication request to the issuer server comprises: encrypting, by the transaction service provider server, the PIN to generate a re- encrypted PIN; and sending, by the transaction service provider server, the re-encrypted PIN to the issuer server, wherein the issuer server is configured to decrypt the re-encrypted PIN; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 15 recites: mapping, by the HSM, the transaction to a token; retrieving, by the HSM, the dynamic key based on the token; and decrypting, by the HSM, the encrypted BLOB to determine the PIN; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 16 recites: wherein the encrypted BLOB is configured according to International Organization for Standardization (ISO) PIN block format; These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 19 recites: capturing, by a camera of the merchant portable electronic device, an image of a quick response (QR) code, wherein the QR code is generated by the user portable electronic device based on the encrypted BLOB, and wherein the QR code is displayed by a display screen of the user portable electronic device; and extracting, by the point-of-sale application executed by the merchant portable electronic device, the encrypted BLOB based on the image of the QR code. These limitations are additional elements that do not integrate the abstract idea into a practical application.
Claim 20 recites: receiving, by the merchant portable electronic device, a wireless communication comprising the encrypted BLOB from the user portable electronic device, wherein the wireless communication comprises at least one of a near field communication (NFC) data exchange format message, a sound, a Bluetooth message, a WiFi message, or a combination thereof. These limitations are additional elements that do not integrate the abstract idea into a practical application.
Step 2B:
Viewed as a whole, the instructions/claims do not include additional elements that amount to significantly more than the abstract idea. The additional elements, including the user portable electronic device, merchant portable electronic device, transaction service provider server, acquirer server, and an issuer server are recited to perform generic computer functions such as managing and authenticating payment transactions using a PIN entry, receiving user approval and PIN information, communicating encrypted PIN data, and authorizing the transaction. The claims do not recite to a specific technical improvement to the user portable electronic device, merchant portable electronic device, transaction service provider server, acquirer server, and an issuer server. Therefore, the claims amount to no more than instructions to apply the abstract idea using generic computing components, and do not provide an inventive concept under Step 2B. Therefore, the claim is not patent eligible.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Glendenning et al. (US 20130191290 A1), in view of Park et al. (US 20160253651 A1), and further in view of Ziat et al. (US 20160063490 A1).
7. Regarding Claim 1, Glendenning discloses a method for securely providing a personal identification number (PIN), the method comprising:
receiving, by a user portable electronic device, a request from a merchant portable electronic device to provide the PIN, wherein the request to provide the PIN is based on a transaction initiated using a payment card and the merchant portable electronic device,(Para. 0019-0026, The method may further comprise receiving an account selection request from the user of the customer transceiver device. The account selection request may be received via a user interface of either device. In an embodiment in which the account selection request is received via a user interface of the customer transceiver device the method may further comprise transmitting the user selected account selection to the merchant device over the data connection. In an embodiment in which the account selection request is received via a user interface of the merchant device the method may further comprise storing data representative of the user selected account in the memory of the merchant device. The method may further comprise transmitting data representative of the user selected account over the data connection to the customer transceiver device…The method may further comprise retrieving the transaction request data, said transaction request data comprising an amount for the transaction, and at least one of a currency code, a time stamp, data representative of the user selected account, and a customer identifier such as a PIN or biometric and a merchant identifier value. The step of the merchant device transmitting a first data package to the customer transceiver device over the data connection may be preceded by the customer transceiver device requesting the unique merchant identifier and transaction request data. The first data package may further comprise a unique dynamic value…the customer transceiver device forming a merchant authentication request, the merchant authentication request requesting from the merchant transceiver device (1) a signed certificate of the issuer which holds as a minimum the unique (merchant) identifier and merchant public key and (2) a signature of the unique dynamic value using the merchant's secure module's private key; the customer transceiver device receiving from the merchant device a second data package comprising the issuer's signed certificate and a signature of the unique dynamic value using the merchant's secure module's private key.)
generating, by the PIN entry application executed by the user portable electronic device, an encrypted binary large object (BLOB) based on the PIN; and communicating, by the user portable electronic device, the encrypted BLOB to the merchant portable electronic device, (Para. 0028-0039, The step of authenticating the legitimacy of the merchant device enables the consumer transceiver device to ensure that it is communicating with an authentic merchant device (one that has been issued by an approved issuer within a defined scheme). It also ensures that the unique identification number provided as part of the transaction request is the same as that signed by the issuer in the signed secure module certificate…the transceiver device comprising: an interface module to enable data communication with other transceiver devices; a processor coupled to a memory, the memory storing processor control code to selectively control the processor, when running to (1): retrieve from memory a unique merchant identifier; enable the interface module to transmit the unique merchant identifier and transaction request data to another of said devices; receive from the other of said devices a cryptogram, the cryptogram having been generated from a secret key, a counter, the unique merchant identifier and the transaction request data; and form an authorisation request comprising the cryptogram, merchant identifier and transaction data, and submitting said authorisation request to at least one of an issuer and an acquirer to facilitate authorisation and processing of said transaction request data; or (2) receive a unique merchant identifier and transaction request data from another of said devices; retrieve from memory a counter value and a stored secret key; generate a cryptogram using the retrieved secret key, the retrieved counter value together with the received unique merchant identifier and transaction request data; and transmitting the cryptogram to the other of said devices for subsequent forwarding of an authorisation request to one of an issuer and an acquirer to facilitate authorisation and processing of said transaction request data.)
Glendenning does not explicitly disclose receiving, by a PIN entry application executed by the user portable electronic device, a user input to approve the request from the merchant portable electronic device.
However, Park teaches receiving, by a PIN entry application executed by the user portable electronic device, a user input to approve the request from the merchant portable electronic device, (Para. 0009-0014, Note that the connection information may be communicated via a near-field-communication protocol when the electronic device and the other electronic device are proximate to each other. Moreover, communication via the connection may involve a communication protocol that is other than the near-field communication protocol (such as Bluetooth®, Wi-Fi® or a cellular-telephone communication protocol). Furthermore, establishing the connection and providing the signed blob may occur concurrently. Additionally, the server may be associated with a third party that is other than users of the electronic device and the other electronic device. For example, the third party may include a provider of the electronic device. Alternatively, the third party may include a payment network that processes payment for the financial transaction, and the payment may be processed using the information. Note that the information may include the signed transaction blob. Alternatively, the secure element may decrypt the signed transaction blob using an encryption key associated with the other electronic device, and may extract the information. In some embodiments, prior to receiving the transaction amount, the secure element: receives authentication information associated with a user of the electronic device; and authenticates the user based on the authentication information and stored authentication information. Moreover, the secure element may receive, via the interface circuit, confirmation that the financial transaction was completed from the server. Then, the secure element may provide, via the interface circuit, the confirmation to the other electronic device using the connection.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate PIN entry features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include receiving, by a PIN entry application executed by the user portable electronic device, a user input to approve the request from the merchant portable electronic device result in an improved invention because applying said technique protects the PIN before it is sent through the merchant device to the transaction service provider, thus improving the overall security of the invention.
Glendenning as modified does not explicitly disclose wherein the merchant portable electronic device is configured to communicate the encrypted BLOB to a transaction service provider server for decryption.
However, Ziat teaches wherein the merchant portable electronic device is configured to communicate the encrypted BLOB to a transaction service provider server for decryption, 0007-0008,The described embodiments relate to an electronic device that includes: an antenna; an interface circuit that wirelessly communicates with another electronic device (e.g., using near-field communication and another communication protocol); and a secure element. During operation, the secure element: receives a transaction amount associated with a financial transaction; generates, using an encryption key associated with the secure element, a signed blob based on the transaction amount, a merchant identifier and, optionally, a transaction identifier; and communicates, via the interface circuit, connection information between the electronic device and the other electronic device. Moreover, the secure element: establishes, via the interface circuit, a connection between the electronic device and the other electronic device based on the connection information; provides, via the interface circuit, the signed blob to the other electronic device; and receives, via the interface circuit, a signed transaction blob from the other electronic device using the connection, where the signed transaction blob includes the transaction amount, the merchant identifier, financial-account information that specifies a financial account (such as one associated with a credit card) and, optionally, the transaction identifier. Then, the secure element provides, via the interface circuit, information associated with the signed transaction blob to a server to conduct the financial transaction. In some embodiments, the secure element: provides, via the interface circuit, the signed blob to the server; and prior to providing the signed blob, receives, via the interface circuit, a confirmation from the server that the electronic device is authorized to conduct the financial transaction.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate encrypted object features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the merchant portable electronic device is configured to communicate the encrypted BLOB to a transaction service provider server for decryption result in an improved invention because applying said technique protects the PIN before it is sent through the merchant device to the transaction service provider, thus improving the overall security of the invention.
8. Regarding Claim 2, Glendenning as modified does not explicitly disclose wherein the transaction is a tap-to-phone transaction.
However, Ziat teaches wherein the transaction is a tap-to-phone transaction, (Para. 0012-0014, Note that the information may include the signed transaction blob. Alternatively, the secure element may decrypt the signed transaction blob using an encryption key associated with the other electronic device, and may extract the information. In some embodiments, prior to receiving the transaction amount, the secure element: receives authentication information associated with a user of the electronic device; and authenticates the user based on the authentication information and stored authentication information. Moreover, the secure element may receive, via the interface circuit, confirmation that the financial transaction was completed from the server. Then, the secure element may provide, via the interface circuit, the confirmation to the other electronic device using the connection.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate transaction features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the transaction is a tap-to-phone transaction result in an improved invention because applying said technique will allow the merchant portable device to act as a payment acceptance device, thus improving the overall convenience of the invention.
9. Regarding Claim 3, Glendenning discloses wherein receiving the user input comprises at least one of: receiving, by the user portable electronic device, the PIN; receiving, by the user portable electronic device, a passcode; receiving, by the user portable electronic device, a user biometric authentication; or a combination thereof, (Para. 0008-0014, A method for securing payment data for transmission over open communication networks is provided, the method comprising: establishing a data connection between a first and a second transceiver device, the first transceiver device configured as a merchant device and the second transceiver device configured as a customer transceiver device; the merchant device transmitting a first data package to the customer transceiver device over the data connection, the first data package comprising a unique merchant identifier and transaction request data; the merchant device receiving a cryptogram from the customer transceiver device, the cryptogram having been generated using a secret key, a counter value together with the received unique merchant identifier and the transaction request data; and forming an authorisation request comprising the received cryptogram, the merchant identifier and transaction request data and submitting said authorisation request to at least one of an issuer and an acquirer to facilitate processing said authorisation data to the issuer for authorisation. The open network may be a mobile or an Internet Protocol (IP) network. Ensuring that the merchant device transmits the unique merchant identifier to the customer transceiver device, for inclusion in the cryptogram, binds the merchant and the consumer to the transaction and minimises the number of exchanges involved in authorisation of a transaction. This is principally due to the acquirer no longer being required to verify the authenticity of the merchant, only that it is a valid merchant. Advantageously the opportunity for third party fraud is substantially reduced.)
10. Regarding Claim 4, Glendenning does not explicitly disclose wherein communicating the encrypted BLOB to the merchant portable electronic device comprises: generating, by the PIN entry application executed by the user portable electronic device, a quick response (QR) code based on the encrypted BLOB; and displaying, by a display screen of the user portable electronic device, the QR code, wherein the QR code is readable by the merchant portable electronic device.
However, Park teaches wherein communicating the encrypted BLOB to the merchant portable electronic device comprises: generating, by the PIN entry application executed by the user portable electronic device, a quick response (QR) code based on the encrypted BLOB; and displaying, by a display screen of the user portable electronic device, the QR code, wherein the QR code is readable by the merchant portable electronic device, (Para. 2085-2086, The controller 5860 may control the overall operations of the electronic device 5800. In this case, the controller 5860 may be functionally connected to the elements of the electronic device 5800 in order to thereby control the elements of the electronic device 5800. In addition, the controller 5860 may receive commands or data from the elements of the electronic device 5800 in order to thereby process the same. In this case, the controller 5860 may perform various functions. For example, the controller 5860 may include a function processor for each function. In addition, the function processor may be an application processor (AP). According to an embodiment of the present disclosure, the controller 5860 may execute the payment management function and the payment execution function. According to an embodiment of the present disclosure, the electronic device 5800 may include the display unit 5830 and the controller 5860 that is functionally connected to the display unit 5830. The controller 5860 may be configured to: display images of the electronic cards, usage information, and a payment module on the screen; detect the selection of the payment module; and execute the payment with the electronic card.; and Para. 0360, the electronic device 3110 may use various communication connections in transferring the token and/or cryptogram to the POS device 3120. The communication connections may include, for example, NFC, MST, barcode, or QR code.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate PIN entry features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein communicating the encrypted BLOB to the merchant portable electronic device comprises: generating, by the PIN entry application executed by the user portable electronic device, a quick response (QR) code based on the encrypted BLOB; and displaying, by a display screen of the user portable electronic device, the QR code, wherein the QR code is readable by the merchant portable electronic device result in an improved invention because applying said technique allows the merchant device to receive the encrypted data by scanning the user device screen, thus improving the overall security of the invention.
11. Regarding Claim 5, Glendenning discloses wherein communicating the encrypted BLOB to the merchant portable electronic device comprises: generating, by the PIN entry application executed by the user portable electronic device, at least one of a near field communication (NFC) data exchange format message comprising the encrypted BLOB, a sound comprising the encrypted BLOB, a Bluetooth message comprising the encrypted BLOB, a WiFi message comprising the encrypted BLOB, or a combination thereof, (Para. 0014-0019, Ensuring that the merchant device transmits the unique merchant identifier to the customer transceiver device, for inclusion in the cryptogram, binds the merchant and the consumer to the transaction and minimises the number of exchanges involved in authorisation of a transaction. This is principally due to the acquirer no longer being required to verify the authenticity of the merchant, only that it is a valid merchant. Advantageously the opportunity for third party fraud is substantially reduced. The step of establishing a data connection between the first and second transceiver devices may comprise establishing a contactless connection or a contact connection. The contactless connection may utilise NFC, Bluetooth, WiFi, SMS, another like contactless technology or a combination thereof The contact connection may utilise electrical connectivity as is well known by those skilled in the art. The method may further comprise selectively configuring the first and second transceiver devices as a merchant device and a customer transceiver device respectively. Optionally, the first and second transceiver devices may be respectively configured as a customer transceiver device and a merchant device. In either embodiment, the counter value is preferably stored in a secure area of the customer transceiver device. The method may further comprise maintaining a counter embodied in the customer transceiver device. The method may further comprise the customer transceiver device generating the cryptogram. In addition to utilising the secret key, the counter value, the received unique merchant identifier and the transaction request data, other relevant data may be included, including, but not limited to data associated with a transceiver device's technical capability.
The method may further comprise receiving an account selection request from the user of the customer transceiver device. The account selection request may be received via a user interface of either device. In an embodiment in which the account selection request is received via a user interface of the customer transceiver device the method may further comprise transmitting the user selected account selection to the merchant device over the data connection. In an embodiment in which the account selection request is received via a user interface of the merchant device the method may further comprise storing data representative of the user selected account in the memory of the merchant device. The method may further comprise transmitting data representative of the user selected account over the data connection to the customer transceiver device.)
and transmitting, by the user portable electronic device, the at least one of the near field communication (NFC) data exchange format message comprising the encrypted BLOB, the sound comprising the encrypted BLOB, the Bluetooth message comprising the encrypted BLOB, the WiFi message comprising the encrypted BLOB, or a combination thereof to the merchant portable electronic device, (Para. 0040-0043, Advantageously, in accordance with embodiments of the invention, the transceiver device is able to be selectively configured to be operable as either a merchant device/terminal or a customer device/terminal. The transceiver device may be incorporated into a mobile communication device such as a mobile phone, cell phone or iPhone. Optionally, the transceiver device may be separated from but in communication with a mobile communication device. Optionally, the transceiver device may be incorporated into a point of sale device (POS) or separated from but in communication with a POS. In still other arrangements the transceiver device may be integrated into a personal computing device (such as a laptop, PDA, pager) or a device that is separated from but in communication with a personal computing device. The interface module may be in the form of a contact interface module, a contactless interface module or a dual contact and contactless interface module. In an embodiment utilising a contactless interface module, the interface module preferably incorporates the requisite mechanisms to enable the transfer of data between two devices (such as ISO 7816, NFC, Bluetooth, Wi-Fi, SMS etc). For example, one such contactless interface module may comprise a transponder and an antenna. The transaction request data may comprise an amount for the transaction, and at least one (or more) of a currency code, a time stamp and a customer identifier such as a PIN or biometric and any other relevant data.)
12. Regarding Claim 6, Glendenning discloses wherein generating the encrypted BLOB based on the PIN comprises: generating, by the PIN entry application executed by the user portable electronic device, the encrypted BLOB based on a token provisioned by the transaction service provider server and a dynamic key provisioned by the transaction service provider server, wherein the transaction service provider server is configured to decrypt the encrypted BLOB based on the token and the dynamic key, (Para. 0056-0060, The memory unit 16 of the merchant transceiver device 10 securely stores the unique merchant identifier which identifies the merchant to whom the amount of the transaction is to be credited. The merchant identifier is embedded into the memory of the device 10 during the issuing process, and a copy is retained securely by the acquirer. The memory unit 16 of the customer transceiver device 22 securely stores the user's primary account number (“PAN”), the users personal identification number (“PIN”), an application transaction counter (ATC) and a secret key. The secret key is embedded into the memory of the device 22 during the issuing process, and a copy is retained securely by the issuer 30. The merchant device 10 communicates with an acquirer 28 and/or an issuer 30 over a network 26. The device may be attached to the network in any suitable manner known in the art. The network 26 may include any type of delivery system including, but not limited to a local area network, wide area network, telephone network, and/or any wired communications network configured to transfer data. FIG. 4 illustrates steps of a method 40 for securing transactions over open networks. The method may be implemented by the system illustrated in FIG. 3. The method comprises the general steps of preliminary transaction processing—step 42, discovery processing—step 44, application selection step—46, application processing—step 48, and transaction authorisation—step 50.The preliminary transaction processing step 42 involves the merchant device 10, collating the variable data (which includes the transaction amount and the currency code) and static transaction data which is required to be sent to the customer device 22. In addition the CIM 12 is enabled for communications with customer device 22. The discovery processing in step 44 follows the preliminary transaction processing in step 42. Once the customer's device 22 is within range of the merchant device 10, communication is established via the device's respective CIMs 12. The merchant device 10 energizes its CIM 12 and establishes a connection with the customer device 22 via its CIM 12. If the merchant device 10 detects multiple contactless devices within its field of range then merchant device 10 may indicate this condition to the holder of the customer device 22 and request that only a single device be presented for the transaction.)
13. Regarding Claim 7, Glendenning does not explicitly disclose further comprising: enrolling, by the PIN entry application executed by the user portable electronic device, the payment card to the PIN entry application based on a user input; and receiving, by the PIN entry application executed by the user portable electronic device, the token and the dynamic key provisioned by the transaction service provider server.
However, Park teaches further comprising: enrolling, by the PIN entry application executed by the user portable electronic device, the payment card to the PIN entry application based on a user input; and receiving, by the PIN entry application executed by the user portable electronic device, the token and the dynamic key provisioned by the transaction service provider server, (Para. 1514-1516, the trusted application may check whether the REE 1810 has an integrity. The electronic device may store, in the TEE 1820, information on whether the REE 1810 has an integrity. According to a booting sequence in the case of an REE 1810 booting that supports the TEE 1820, when a boot loader is executed, the TEE 1820 may be first booted and the REE 1810 is then booted. When the TEE 1820 is booted, the integrity information of the REE 1810 is identified in the TEE 1820, and the identified information may be reported to a user after the REE 1810 booting. If the image of REE 1810 has been damaged due to hacking or rooting, the REE 1810 may determine that the integrity thereof is problematic. When the integrity is problematic, the REE 1810 may be prohibited to access the TEE. For example, when the payment relay module 1841 tries to transfer a message or command to the TEE 1820 through the security environment driver module 1853, a kernel of the TEE 1820 may disregard the message or command or deny receiving the message. According to an embodiment of the present disclosure, the payment module 1821 may be an application installed by a bank or card company (e.g., VISA® card or MasterCard®). There may be at least one payment module. If a user, in a wearable device, accesses the payment service server or token server, using the payment management module 1831, and approves installation of the payment module 1821, the token server may perform an operation associated with the installation. For example, the payment management module 1831 may acquire a card number and valid term information of a plastic card through OCR, and perform a card registration operation for installing the payment module 1821 in the server. The payment management module 1831 may connect to the token server in the network through the payment relay module 1841 having connection information of the token server according to each card/bank company to receive an installation file, and the payment relay module 1841 may transfer the information to the TEE 1820 to install the payment module 1821. There may be a plurality of payment modules 1821 of the TEE 1820. Each payment module 1821 is unable to exchange data within the TEE 1820 and may be configured in an isolated form. According to an embodiment of the present disclosure, the payment module 1821 may be an application to be used for data communication with the payment service server. The payment module 1821 may include information of a credit card, a debit card, a membership card, etc. The payment module 1821 may communicate with another external electronic device through encryption. The encryption process may be different according to the card manufacturing company having transferred the payment module. The server may control the state of the payment module. For example, the server may activate, temporarily stop, re-activate, or delete the payment module.; and Para. 1851, As opposed to the method of displaying all of the cards registered in a terminal and enabling a user to select a card, Simple pay uses a method of displaying some of the cards and enabling a user to select a card. As shown in FIG. P106-003, a user may select, through an application setting, a card that is capable of executing payment through Simple pay. The number of cards that a user may use in Simple pay is limited. When the user desires to use more than the limitation, it is reported that the number of cards exceeds the maximum number of registered cards through a pop-up message. When cards are displayed for registration in Simple pay, all of the cards are displayed by being categorized based on a type of card, and the cards displayed in the form of a combo box may be supported to enable a user to select a plurality of cards.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate PIN entry features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include enrolling, by the PIN entry application executed by the user portable electronic device, the payment card to the PIN entry application based on a user input; and receiving, by the PIN entry application executed by the user portable electronic device, the token and the dynamic key provisioned by the transaction service provider server in an improved invention because applying said technique will link the user’s card to the secure PIN entry application before transactions occur, thus improving the overall security of the invention.
14. Regarding Claim 8, Glendenning discloses further comprising: storing, by the PIN entry application executed by the user portable electronic device, the PIN to a memory of the user portable electronic device, (Para. 0008-0012, A method for securing payment data for transmission over open communication networks is provided, the method comprising: establishing a data connection between a first and a second transceiver device, the first transceiver device configured as a merchant device and the second transceiver device configured as a customer transceiver device; the merchant device transmitting a first data package to the customer transceiver device over the data connection, the first data package comprising a unique merchant identifier and transaction request data; the merchant device receiving a cryptogram from the customer transceiver device, the cryptogram having been generated using a secret key, a counter value together with the received unique merchant identifier and the transaction request data; and forming an authorisation request comprising the received cryptogram, the merchant identifier and transaction request data and submitting said authorisation request to at least one of an issuer and an acquirer to facilitate processing said authorisation data to the issuer for authorisation.; and Para. 0020-0021, the method may further comprise retrieving a predetermined default account. The predetermined default account may be stored to memory in the customer transceiver device. The method may further comprise retrieving the transaction request data, said transaction request data comprising an amount for the transaction, and at least one of a currency code, a time stamp, data representative of the user selected account, and a customer identifier such as a PIN or biometric and a merchant identifier value.)
15. Regarding Claim 9, Glendenning discloses wherein the encrypted BLOB is configured according to International Organization for Standardization (ISO) PIN block format, (Para. 0040-0043, the transceiver device is able to be selectively configured to be operable as either a merchant device/terminal or a customer device/terminal. The transceiver device may be incorporated into a mobile communication device such as a mobile phone, cell phone or iPhone. Optionally, the transceiver device may be separated from but in communication with a mobile communication device. Optionally, the transceiver device may be incorporated into a point of sale device (POS) or separated from but in communication with a POS. In still other arrangements the transceiver device may be integrated into a personal computing device (such as a laptop, PDA, pager) or a device that is separated from but in communication with a personal computing device. The interface module may be in the form of a contact interface module, a contactless interface module or a dual contact and contactless interface module. In an embodiment utilising a contactless interface module, the interface module preferably incorporates the requisite mechanisms to enable the transfer of data between two devices (such as ISO 7816, NFC, Bluetooth, Wi-Fi, SMS etc). For example, one such contactless interface module may comprise a transponder and an antenna. The transaction request data may comprise an amount for the transaction, and at least one (or more) of a currency code, a time stamp and a customer identifier such as a PIN or biometric and any other relevant data.)
15. Regarding Claim 10, Glendenning discloses method for authenticating a transaction, wherein the transaction is initiated using a payment card and a merchant portable electronic device, wherein the transaction requires authentication based on a personal identification number (PIN), and wherein an encrypted binary large object (BLOB) generated by a user portable electronic device based on the PIN is communicated to the merchant portable electronic device for authenticating the transaction, the method comprising: receiving, by a transaction service provider server, a first transaction authentication request from an acquirer server, wherein the first transaction authentication request comprises the encrypted BLOB communicated to the merchant portable electronic device, and sending, by the transaction service provider server, a second transaction authentication request to an issuer server, wherein the issuer server determines whether to authenticate the transaction based on the PIN, (Para. 0003-0005, The network includes the card issuers and the merchant acquirers plus the cardholders (customers) and the merchants. The card issuer distributes cards to consumers, bills them, and collects payment from them. The merchant acquirer recruits merchants to accept cards and provides the front-end service of routing the transaction to the network's processing facilities. The acquirer is responsible for delivering the transaction to the appropriate card issuer so that the customer is billed and the merchant receives funds for the purchase. The transactions process typically has two major parts. The first is authorisation, and the second is clearing and settlement. Authorisation is the process of obtaining permission from the bank that issued the card to accept the transaction and card detail for payment. Authorisation begins when a consumer presents his or her card to the merchant for a purchase (1). Traditionally, securing of the transaction occurs for authorisation which happens at the point of sale, though more recently transactions are being done in “card not present” situations (for example, online). In recent years, chip and contactless technologies have become increasingly widespread. With particular reference to the payment industry, contact and contactless transactions have advantages over traditional magnetic stripe technologies as chip based technologies have the ability to store and process data more securely. In contact and contactless situations, merchants usually obtain the transaction information for authorisation electronically, either by having the consumer swipe or insert the card through a terminal at the point of sale or by bringing the card into the vicinity of a terminal or reader. Having obtained card information, the merchant's terminal compiles an authorisation request containing the card information, the transaction amount and the merchant's identification number and sends the authorisation request to the acquirer (2). The acquirer reads the information and sends the authorisation request to the specific issuing bank through a clearing card network (3). The issuing bank conducts a series of checks for fraud and verifies that the cardholder's available funds or credit line is sufficient to cover the purchase before returning a response (4), either granting or denying authorisation. The merchant acquirer receives the response and relays it to the merchant (5).)
Glendenning does not explicitly disclose mapping, by the transaction service provider server, the transaction to a token; retrieving, by the transaction service provider server, a dynamic key based on the token.
However, Park teaches mapping, by the transaction service provider server, the transaction to a token; retrieving, by the transaction service provider server, a dynamic key based on the token, (Para. 0344-0350, According to an embodiment of the present disclosure, the token service interface may transfer a request associated with the token received from the electronic device to the token server, and transfer a response to the request, received from the token server, to the electronic device. Further, the token service interface 2941 may manage, for example, the security of a channel functionally connected to the token server. According to an embodiment of the present disclosure, the push gateway module 2943 may perform a path function for transferring a message associated with the token from the token server to the electronic device. According to an embodiment of the present disclosure, the data management module 2945 may manage data (e.g., card information or user information) used in the token requester server 2940. Further, the data management module 2945 may provide, for example, a mapping table including card information (e.g., PAN), payment application information, a user, or an electronic device. For example, the data management module 2945 may store, in the form of a table, at least one among a PAN, payment application information, user information, device information, and token information. According to an embodiment of the present disclosure, the token requester server 2940 may identify the mapping table related to the token, using the data management module 2945. Also, the payment service server 2930 may include information related to an electronic device or account. For example, the payment system may perform user authentication, using the mapping table and the information related to an electronic device or account. FIG. 30 is a block diagram of a server 3000 of a payment system according to an embodiment of the present disclosure. Referring to FIG. 30, a token server 3010 may perform the issuance or management of a token. The token server 3010 may include, for example, a token requester interface 3020, a tokenization service module 3030, or a financial server interface 3040. According to an embodiment of the present disclosure, the token requester interface 3020 may include an interface for receiving a request for the issuance of a token from the token requester server 2940.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate token features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include mapping, by the transaction service provider server, the transaction to a token; retrieving, by the transaction service provider server, a dynamic key based on the token in an improved invention because applying said technique keeps sensitive information, such as, PIN processing within a controlled server, thus improving the overall security of the invention.
Glendenning as modified does not explicitly disclose decrypting, by the transaction service provider server, the encrypted BLOB to determine the PIN.
However, Ziat teaches decrypting, by the transaction service provider server, the encrypted BLOB to determine the PIN, (Para. 0007-0009, The described embodiments relate to an electronic device that includes: an antenna; an interface circuit that wirelessly communicates with another electronic device (e.g., using near-field communication and another communication protocol); and a secure element. During operation, the secure element: receives a transaction amount associated with a financial transaction; generates, using an encryption key associated with the secure element, a signed blob based on the transaction amount, a merchant identifier and, optionally, a transaction identifier; and communicates, via the interface circuit, connection information between the electronic device and the other electronic device. Moreover, the secure element: establishes, via the interface circuit, a connection between the electronic device and the other electronic device based on the connection information; provides, via the interface circuit, the signed blob to the other electronic device; and receives, via the interface circuit, a signed transaction blob from the other electronic device using the connection, where the signed transaction blob includes the transaction amount, the merchant identifier, financial-account information that specifies a financial account (such as one associated with a credit card) and, optionally, the transaction identifier. Then, the secure element provides, via the interface circuit, information associated with the signed transaction blob to a server to conduct the financial transaction. In some embodiments, the secure element: provides, via the interface circuit, the signed blob to the server; and prior to providing the signed blob, receives, via the interface circuit, a confirmation from the server that the electronic device is authorized to conduct the financial transaction. Note that the connection information may be communicated via a near-field-communication protocol when the electronic device and the other electronic device are proximate to each other. Moreover, communication via the connection may involve a communication protocol that is other than the near-field communication protocol (such as Bluetooth®, Wi-Fi® or a cellular-telephone communication protocol).
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate encrypted object features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include decrypting, by the transaction service provider server, the encrypted BLOB to determine the PIN result in an improved invention because applying said technique keeps sensitive information, such as, PIN processing within a controlled server, thus improving the overall security of the invention.
17. Regarding Claim 11, Glendenning as modified does not explicitly disclose further comprising: determining, by the transaction service provider server, that the transaction is a tap- to-phone transaction (TTP) based on a TTP transaction identifier comprised in the first transaction authentication request.
However, Ziat teaches further comprising: determining, by the transaction service provider server, that the transaction is a tap- to-phone transaction (TTP) based on a TTP transaction identifier comprised in the first transaction authentication request, (Para. 0029-0031, In order to facilitate conducting a financial transaction via wireless communication between an electronic device (such as a smartphone) and another electronic device (such as another smartphone), a secure element in the electronic device may generate, using an encryption key associated with the secure element, a signed blob based on a transaction amount, a merchant identifier and, optionally, a transaction identifier. Then, the electronic device communicates connection information between the electronic device and the other electronic device. Moreover, the electronic device may establish a connection between the electronic device and the other electronic device based on the connection information, and may concurrently provide the signed blob to the other electronic device. After receiving a signed transaction blob from the other electronic device using the connection (which includes information needed to conduct the financial transaction), the electronic device provides the information to a server to conduct the financial transaction. In this way, the financial-transaction technique implemented by the electronic device may provide a flexible and simple approach for conducting secure, wireless financial transactions with other electronic devices. In particular, the electronic device may function as a mobile point-of-sale terminal, and may allow the financial transaction to be conducted even when, initially, there is no connection between the electronic device and the other electronic device. For example, the connection information and the signed blob may be conveyed in packets transmitted and received by radios in the electronic device and the other electronic device using a near-field communication protocol (from the NFC Forum of Wakefield, Mass.), and the subsequent communication (after the connection is established) may use a different communication protocol, such as: Bluetooth® or Bluetooth Low Energy® (from the Bluetooth Special Interest Group of Kirkland, Wash.), an Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (which is sometimes referred to as Wi-Fi®), a cellular-telephone communication protocol (e.g., a 3G/4G network such as UMTS, LTE, etc.) and/or another communication protocol. (In the discussion that follows, near-field communication and Bluetooth are used as illustrative examples.) The convenience and security offered by this financial-transaction technique may improve the user experience, which may encourage more mobile financial transactions and, thus, may increase commercial activity. The communication between the electronic device and the other electronic device is shown in FIG. 1, which presents a block diagram illustrating electronic devices 110 wirelessly communicating. In particular, these electronic devices may wirelessly communicate during a financial transaction. For example, the financial transaction may initiate when a user of electronic device 110-1 (such as a cellular telephone) may provide a transaction amount associated with the financial transaction to electronic device 110-1. For example, the user may enter the transaction amount via a user interface (such as a physical keyboard, a virtual keyboard displayed on a multi-touch screen, etc.).
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate transaction features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include determining, by the transaction service provider server, that the transaction is a tap- to-phone transaction (TTP) based on a TTP transaction identifier comprised in the first transaction authentication request result in an improved invention because applying said technique will allow the user device to generate the encrypted objects users server controlled credentials, thus improving the overall security of the invention.
18. Regarding Claim 12, Glendenning does not explicitly disclose further comprising: provisioning, by the transaction service provider server, the token and the dynamic key to the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the token and the dynamic key.
However, Park teaches further comprising: provisioning, by the transaction service provider server, the token and the dynamic key to the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the token and the dynamic key, (Para. 0255-0260, According to an embodiment of the present disclosure, the payment manager 1840 may include, for example, the payment relay module 1841, a biometric information management module 1843, and a security environment relay module 1846. The payment relay module 1841 may relay a card or information (e.g., token) corresponding to the card to the payment application 1830, kernel, or payment server 710. The payment relay module 1841 may perform off-line payment through a communication module (e.g., an NFC module or an MST module). A payment method using the NFC may be operated through a POS device, and a payment method using the MST may be operated by a user input. Further, the payment relay module 1841 may perform on-line payment through a communication module (e.g., a cellular module, an RF module, or a WiFi module). According to an embodiment of the present disclosure, the payment relay module 1841 may perform state management (e.g., card/token life cycle management) of a card or information (e.g., a token) corresponding to the card. The payment relay module 1841 may provide at least one API associated with payment to the payment application 1830. According to an embodiment of the present disclosure, the payment relay module 1841 may further include at least one interface provided by system services associated with a payment, and system service interfaces, which provide security UIs for a payment service for access to a payment module, trustzone-based integrity measurement architecture (TIMA) for kernel integrity authentication, fingerprint recognition result inquiry (e.g., supporting both a security and a non-security mode), and PIN or PAN input. The payment relay module 1841 may include an encryption library in order to transfer a message or command to the TEE 1820. The payment relay module 1841 may send or receive a message or command with the TEE 1820 through the encryption library. According to an embodiment of the present disclosure, the payment relay module 1841 may include a card management function which provides addition, deletion, or update of a card, as a general card management function. The payment relay module 1841 may include a first payment SDK or a second payment SDK. The first SDK (e.g., a Samsung SDK) may be embedded in an electronic device. The second SDK may be provided by a card company or bank and may be installed in an electronic device. From the first payment SDK or second SDK, the payment relay module 1841 may select a payment SDK corresponding to card information. Further, the payment relay module may set a basic card or select another card other than the basic card. According to an embodiment of the present disclosure, the payment relay module 1841 may transmit, to the payment server 710, messages, such as token provisioning, token replenishment, token suspension, token resume, and token disposal, as a general token and key management function. According to an embodiment of the present disclosure, the payment module 1821 may acquire a token and a token cryptogram from the electronic device or another external electronic device. A key (e.g., a limited use key (LUK) or single used key) capable of generating the token or token cryptogram may be stored in the REE 1810 or TEE 1820. Moreover, if the token and the key are stored in the REE 1810, the payment module of the TEE may encrypt and store the token and key, using the key (e.g., device root key (DRK)) of the TEE 1820. If the electronic device performs payment, the payment relay module 1841 may acquire the encrypted token in a decrypted state through the payment module. If the token or key capable of generating the token cryptogram is stored in the TEE 1820, the electronic device may store the token or key in an encrypted form, using the key of the TEE 1820.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate dynamic key features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include provisioning, by the transaction service provider server, the token and the dynamic key to the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the token and the dynamic key result in an improved invention because applying said technique will allow the user device to generate the encrypted BLOB using server controlled credentials, thus improving the overall security of the invention.
19. Regarding Claim 13, Glendenning discloses sending, by the transaction service provider server, the re-encrypted PIN to the issuer server, wherein the issuer server is configured to decrypt the re-encrypted PIN, (Para. 0040-0043, Advantageously, in accordance with embodiments of the invention, the transceiver device is able to be selectively configured to be operable as either a merchant device/terminal or a customer device/terminal. The transceiver device may be incorporated into a mobile communication device such as a mobile phone, cell phone or iPhone. Optionally, the transceiver device may be separated from but in communication with a mobile communication device. Optionally, the transceiver device may be incorporated into a point of sale device (POS) or separated from but in communication with a POS. In still other arrangements the transceiver device may be integrated into a personal computing device (such as a laptop, PDA, pager) or a device that is separated from but in communication with a personal computing device. The interface module may be in the form of a contact interface module, a contactless interface module or a dual contact and contactless interface module. In an embodiment utilising a contactless interface module, the interface module preferably incorporates the requisite mechanisms to enable the transfer of data between two devices (such as ISO 7816, NFC, Bluetooth, Wi-Fi, SMS etc). For example, one such contactless interface module may comprise a transponder and an antenna. The transaction request data may comprise an amount for the transaction, and at least one (or more) of a currency code, a time stamp and a customer identifier such as a PIN or biometric and any other relevant data.)
Glendenning as modified does not explicitly disclose wherein sending the second transaction authentication request to the issuer server comprises: encrypting, by the transaction service provider server, the PIN to generate a re- encrypted PIN.
However, Ziat teaches wherein sending the second transaction authentication request to the issuer server comprises: encrypting, by the transaction service provider server, the PIN to generate a re- encrypted PIN, (Para. 0038-0041, Note that creating the signed transaction blob may or may not involve decrypting the signed blob (thus, electronic device 110-2 may or may not have access to a decryption key corresponding to the encryption key). Consequently, the signed transaction blob may include the signed blob or may include information associated with the signed blob that is extracted by the merchant payment applet and/or the secure element on electronic device 110-2. Furthermore, creating the signed transaction blob may involve encryption of at least a portion of the transaction blog using an encryption key associated with electronic device 110-2 (such as an encryption key associated with a provider of the secure element, a security domain in the secure element and/or the counterparty payment applet), and may be signed using a digital signature that is specific to electronic device 110-2 and/or components in electronic device 110-2 (such as the secure element). Note that, in general, the encryption key associated with electronic device 110-2 may (or may not) be different than the encryption key associated with electronic device 110-1. Next, the counterparty payment applet may communicate the signed transaction blob to electronic device 110-1 via radio 112-2 using the connection. Furthermore, the merchant payment applet may communicate the signed transaction blob to a server 116 to conduct the financial transaction. (However, in embodiments where the communication occurs via a Wi-Fi connection or a cellular-telephone network, electronic device 110-2 may communicate the signed transaction blob to server 116.) Note that the communication with server 116 may occur via radio 112-1 and, more generally, via an interface circuit or a network interface circuit. Thus, the communication with the server may involve wireless communication, wired communication and/or optical communication, and may use the same and/or different communication protocols than those used between electronic devices 110. In general, the communication with server 116 may occur via a network 118, such as: the Internet, a wireless local area network, an Ethernet network, an intranet, an optical network, etc. Server 116 may be associated with a third party that is other than users of electronic devices 110. For example, the third party may include a provider of electronic device 110-1 and/or electronic device 110-2. Alternatively, the third party may include a payment network 120. After receiving the signed transaction blob, server 116 provides the information included in the signed transaction blob to payment network 120. (Alternatively, electronic device 110-1 may provide the signed transaction blob to payment network 120.) In response, payment network 120 and/or financial institution 122 (such as a bank, which may be an issuer of the credit card or financial vehicle being used to pay for the financial transaction) may process or complete the financial transaction using the information included in the signed transaction blob. For example, after successful verification of the financial account and the user of electronic device 110-2 (or counterparty), the financial account may be debited for the financial amount and electronic device 110-2 may be notified by payment network 120 and/or financial institution 122 that payment is approved. In particular, confirmation that the financial transaction was successfully completed may be communicated to electronic device 110-1 via network 118. Then, the merchant payment applet in electronic device 110-1 may communicate the confirmation to the counterparty payment applet in electronic device 110-2 via radios 112 using the connection. (Alternatively, if a Wi-Fi connection or a cellular-telephone network is available, payment network 120 and/or financial institution 122 may communicate the confirmation to electronic device 110-2.) The application executed by the processor on electronic device 110-2 may display the confirmation on a display so that the user of electronic device 110-2 is alerted. In some embodiments, the confirmation may include digital-receipt information, such as: a status of the financial transaction (e.g., the financial transaction is complete), the merchant identifier, the financial amount of the financial transaction, an itemized list of one or more purchased items, links (such as URLs) to information associated with products, advertising, discounts (such as coupons) for future purchases of at least one item, discounts for future purchases from the merchant in the financial transaction, accounting information (which can be used to account for expenses, such as an expense report), and sales-tax and/or income-tax information (which can be used to determine an income-tax return).
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate encrypted object features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein sending the second transaction authentication request to the issuer server comprises: encrypting, by the transaction service provider server, the PIN to generate a re- encrypted PIN result in an improved invention because applying said technique will secure the PIN after it is decrypted or processed by transaction service provider, thus improving the overall security of the invention.
20. Regarding Claim 14, Glendenning as modified does not explicitly disclose further comprising: extracting, by the transaction service provider server, a personal authentication number (PAN) from the first transaction authentication request, wherein mapping the transaction to the token is based on the PAN.
However, Ziat teaches further comprising: extracting, by the transaction service provider server, a personal authentication number (PAN) from the first transaction authentication request, wherein mapping the transaction to the token is based on the PAN, (Para. 0040-0042, Server 116 may be associated with a third party that is other than users of electronic devices 110. For example, the third party may include a provider of electronic device 110-1 and/or electronic device 110-2. Alternatively, the third party may include a payment network 120. After receiving the signed transaction blob, server 116 provides the information included in the signed transaction blob to payment network 120. (Alternatively, electronic device 110-1 may provide the signed transaction blob to payment network 120.) In response, payment network 120 and/or financial institution 122 (such as a bank, which may be an issuer of the credit card or financial vehicle being used to pay for the financial transaction) may process or complete the financial transaction using the information included in the signed transaction blob. For example, after successful verification of the financial account and the user of electronic device 110-2 (or counterparty), the financial account may be debited for the financial amount and electronic device 110-2 may be notified by payment network 120 and/or financial institution 122 that payment is approved. In particular, confirmation that the financial transaction was successfully completed may be communicated to electronic device 110-1 via network 118. Then, the merchant payment applet in electronic device 110-1 may communicate the confirmation to the counterparty payment applet in electronic device 110-2 via radios 112 using the connection. (Alternatively, if a Wi-Fi connection or a cellular-telephone network is available, payment network 120 and/or financial institution 122 may communicate the confirmation to electronic device 110-2.) The application executed by the processor on electronic device 110-2 may display the confirmation on a display so that the user of electronic device 110-2 is alerted. In some embodiments, the confirmation may include digital-receipt information, such as: a status of the financial transaction (e.g., the financial transaction is complete), the merchant identifier, the financial amount of the financial transaction, an itemized list of one or more purchased items, links (such as URLs) to information associated with products, advertising, discounts (such as coupons) for future purchases of at least one item, discounts for future purchases from the merchant in the financial transaction, accounting information (which can be used to account for expenses, such as an expense report), and sales-tax and/or income-tax information (which can be used to determine an income-tax return). Note that server 116, payment network 120 and/or financial institution 122 may have access to the decryption key(s) needed to decrypt and extract the information from the signed transaction blob. While we refer to entities such as ‘payment network 120,’ and ‘financial institution 122,’ this is done for ease of description. What is meant by payment network 120, etc., is hardware (server computers and related networking equipment) under the control of and/or otherwise performing actions on behalf of such entities.
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate encrypted object features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include extracting, by the transaction service provider server, a personal authentication number (PAN) from the first transaction authentication request, wherein mapping the transaction to the token is based on the PAN result in an improved invention because applying said technique will identify the correct token associated with the payment account, thus improving the overall performance of the invention.
21. Regarding Claim 15, Glendenning as modified does not explicitly wherein the transaction service provider server comprises a hardware security module (HSM), the method further comprising: mapping, by the HSM, the transaction to a token; retrieving, by the HSM, the dynamic key based on the token; and decrypting, by the HSM, the encrypted BLOB to determine the PIN.
However, Ziat teaches wherein the transaction service provider server comprises a hardware security module (HSM), the method further comprising: mapping, by the HSM, the transaction to a token; retrieving, by the HSM, the dynamic key based on the token; and decrypting, by the HSM, the encrypted BLOB to determine the PIN, (Para. 0357-0361,FIG. 31 is a block diagram of a signal flow 3100 of token payment according to an embodiment of the present disclosure. Referring to FIG. 31, the payment system may include an electronic device 3110, a payment server 3170, a token server 3150, a POS device 3120, a financial server 3160, a purchase server (acquirer) 3130, or a payment network 3140. The electronic device 3110 may include, for example, a payment application 3111, a payment manager 3113, or a security area (e.g. a security module or TEE) 3115. The POS device 3120 may include, for example, a sales time point information management system. The POS device 3120 may be, for example, a combination of functions of a cash register and a computer electronic device, and a user can perform a payment function using the POS device 3120. The financial server 3160 may include, for example, a bank or financial company for issuing a card, and may perform identification of the card. Further, the financial server may proceed with the approval of the card at the time of payment. The purchase server 3130 may include, for example, a bank or financial company that purchases a transaction sheet for the paid card transaction. The payment network 3140 may include, for example, a card network. According to an embodiment of the present disclosure, the electronic device 3110 may transfer a token and/or encryption information (e.g., cryptogram) to the POS device 3120. For example, the token may be stored in the electronic device 3110. Further, the token may be stored in an encrypted area (e.g., security module or TEE 3115). For example, the electronic device 3110 may generate encryption information, using a key received from the outside or a key generated by the electronic device 3110. The security information may include a cryptogram. Further, the electronic device 3110 may transfer the cryptogram and/or the token to the POS device 3120. According to an embodiment of the present disclosure, the electronic device 3110 may use various communication connections in transferring the token and/or cryptogram to the POS device 3120. The communication connections may include, for example, NFC, MST, barcode, or QR code. According to an embodiment of the present disclosure, the POS device 3120 may transfer at least one among the token, the encryption information, and the payment information to the purchase server 3130. For example, the POS device 3120 may transfer, to the purchase server 3130, the token received by the electronic device 3110 and/or the cryptogram, and the payment information (e.g., payment details) acquired by the POS device 3120. Further, the payment information may be, for example, acquired from the POS device 3120 or received from an external device, and may include payment details relating to a payment function requested by the user. Further, the payment information may include, for example, payment history performed using the payment system.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate secure module features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the transaction service provider server comprises a hardware security module (HSM), the method further comprising: mapping, by the HSM, the transaction to a token; retrieving, by the HSM, the dynamic key based on the token; and decrypting, by the HSM, the encrypted BLOB to determine the PIN result in an improved invention because applying said technique will keep sensitive information within the secure module, thus improving the overall security of the invention.
22. Regarding Claim 16, Glendenning discloses wherein the encrypted BLOB is configured according to International Organization for Standardization (ISO) PIN block format, (Para. 0040-0043, Advantageously, in accordance with embodiments of the invention, the transceiver device is able to be selectively configured to be operable as either a merchant device/terminal or a customer device/terminal. The transceiver device may be incorporated into a mobile communication device such as a mobile phone, cell phone or iPhone. Optionally, the transceiver device may be separated from but in communication with a mobile communication device. Optionally, the transceiver device may be incorporated into a point of sale device (POS) or separated from but in communication with a POS. In still other arrangements the transceiver device may be integrated into a personal computing device (such as a laptop, PDA, pager) or a device that is separated from but in communication with a personal computing device. The interface module may be in the form of a contact interface module, a contactless interface module or a dual contact and contactless interface module. In an embodiment utilising a contactless interface module, the interface module preferably incorporates the requisite mechanisms to enable the transfer of data between two devices (such as ISO 7816, NFC, Bluetooth, Wi-Fi, SMS etc). For example, one such contactless interface module may comprise a transponder and an antenna. The transaction request data may comprise an amount for the transaction, and at least one (or more) of a currency code, a time stamp and a customer identifier such as a PIN or biometric and any other relevant data.)
23. Regarding Claim 17, Glendenning discloses a method for securely receiving a personal identification number (PIN), (Para. 0004-0006, The transactions process typically has two major parts. The first is authorisation, and the second is clearing and settlement. Authorisation is the process of obtaining permission from the bank that issued the card to accept the transaction and card detail for payment. Authorisation begins when a consumer presents his or her card to the merchant for a purchase (1). Traditionally, securing of the transaction occurs for authorisation which happens at the point of sale, though more recently transactions are being done in “card not present” situations (for example, online). In recent years, chip and contactless technologies have become increasingly widespread. With particular reference to the payment industry, contact and contactless transactions have advantages over traditional magnetic stripe technologies as chip based technologies have the ability to store and process data more securely. In contact and contactless situations, merchants usually obtain the transaction information for authorisation electronically, either by having the consumer swipe or insert the card through a terminal at the point of sale or by bringing the card into the vicinity of a terminal or reader. Having obtained card information, the merchant's terminal compiles an authorisation request containing the card information, the transaction amount and the merchant's identification number and sends the authorisation request to the acquirer (2). The acquirer reads the information and sends the authorisation request to the specific issuing bank through a clearing card network (3). The issuing bank conducts a series of checks for fraud and verifies that the cardholder's available funds or credit line is sufficient to cover the purchase before returning a response (4), either granting or denying authorisation. The merchant acquirer receives the response and relays it to the merchant (5). Acquirer banks, merchants and consumers are demanding that transactions over the internet and other open networks are more secure. Whilst current contact and contactless transactions offer increased security over traditional magnetic stripe technology they do not sufficiently address the level of security required to secure a transaction over the internet or other open networks.)
determining, by a point-of-sale application executed by the merchant portable electronic device, that the transaction requires a PIN, (Para. 0017-0022, The method may further comprise maintaining a counter embodied in the customer transceiver device. The method may further comprise the customer transceiver device generating the cryptogram. In addition to utilising the secret key, the counter value, the received unique merchant identifier and the transaction request data, other relevant data may be included, including, but not limited to data associated with a transceiver device's technical capability. The method may further comprise receiving an account selection request from the user of the customer transceiver device. The account selection request may be received via a user interface of either device. In an embodiment in which the account selection request is received via a user interface of the customer transceiver device the method may further comprise transmitting the user selected account selection to the merchant device over the data connection. In an embodiment in which the account selection request is received via a user interface of the merchant device the method may further comprise storing data representative of the user selected account in the memory of the merchant device. The method may further comprise transmitting data representative of the user selected account over the data connection to the customer transceiver device. Optionally, the method may further comprise retrieving a predetermined default account. The predetermined default account may be stored to memory in the customer transceiver device. The method may further comprise retrieving the transaction request data, said transaction request data comprising an amount for the transaction, and at least one of a currency code, a time stamp, data representative of the user selected account, and a customer identifier such as a PIN or biometric and a merchant identifier value. The step of the merchant device transmitting a first data package to the customer transceiver device over the data connection may be preceded by the customer transceiver device requesting the unique merchant identifier and transaction request data.)
communicating, by the merchant portable electronic device, a request to a user portable electronic device to provide the PIN, (Para. 0017-0027, The method may further comprise maintaining a counter embodied in the customer transceiver device. The method may further comprise the customer transceiver device generating the cryptogram. In addition to utilising the secret key, the counter value, the received unique merchant identifier and the transaction request data, other relevant data may be included, including, but not limited to data associated with a transceiver device's technical capability. The method may further comprise receiving an account selection request from the user of the customer transceiver device. The account selection request may be received via a user interface of either device. In an embodiment in which the account selection request is received via a user interface of the customer transceiver device the method may further comprise transmitting the user selected account selection to the merchant device over the data connection. In an embodiment in which the account selection request is received via a user interface of the merchant device the method may further comprise storing data representative of the user selected account in the memory of the merchant device. The method may further comprise transmitting data representative of the user selected account over the data connection to the customer transceiver device. Optionally, the method may further comprise retrieving a predetermined default account. The predetermined default account may be stored to memory in the customer transceiver device. The method may further comprise retrieving the transaction request data, said transaction request data comprising an amount for the transaction, and at least one of a currency code, a time stamp, data representative of the user selected account, and a customer identifier such as a PIN or biometric and a merchant identifier value. The step of the merchant device transmitting a first data package to the customer transceiver device over the data connection may be preceded by the customer transceiver device requesting the unique merchant identifier and transaction request data. The first data package may further comprise a unique dynamic value. The method may further comprise authenticating the legitimacy of the merchant device including: the customer transceiver device forming a merchant authentication request, the merchant authentication request requesting from the merchant transceiver device (1) a signed certificate of the issuer which holds as a minimum the unique (merchant) identifier and merchant public key and (2) a signature of the unique dynamic value using the merchant's secure module's private key; the customer transceiver device receiving from the merchant device a second data package comprising the issuer's signed certificate and a signature of the unique dynamic value using the merchant's secure module's private key; the customer transceiver device verifying the issuer's signed certificate using a certification authority's public key, and once verified, authenticating against stored records the signed unique dynamic value using the merchant public key.)
Glendenning as modified does not explicitly disclose receiving, by the merchant portable electronic device, an encrypted binary large object (BLOB) from the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the PIN.
However, Park teaches receiving, by the merchant portable electronic device, an encrypted binary large object (BLOB) from the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the PIN, (Para. 0008-0018, A method for securing payment data for transmission over open communication networks is provided, the method comprising: establishing a data connection between a first and a second transceiver device, the first transceiver device configured as a merchant device and the second transceiver device configured as a customer transceiver device; the merchant device transmitting a first data package to the customer transceiver device over the data connection, the first data package comprising a unique merchant identifier and transaction request data; the merchant device receiving a cryptogram from the customer transceiver device, the cryptogram having been generated using a secret key, a counter value together with the received unique merchant identifier and the transaction request data; and forming an authorisation request comprising the received cryptogram, the merchant identifier and transaction request data and submitting said authorisation request to at least one of an issuer and an acquirer to facilitate processing said authorisation data to the issuer for authorisation. The open network may be a mobile or an Internet Protocol (IP) network. Ensuring that the merchant device transmits the unique merchant identifier to the customer transceiver device, for inclusion in the cryptogram, binds the merchant and the consumer to the transaction and minimises the number of exchanges involved in authorisation of a transaction. This is principally due to the acquirer no longer being required to verify the authenticity of the merchant, only that it is a valid merchant. Advantageously the opportunity for third party fraud is substantially reduced. The step of establishing a data connection between the first and second transceiver devices may comprise establishing a contactless connection or a contact connection. The contactless connection may utilise NFC, Bluetooth, WiFi, SMS, another like contactless technology or a combination thereof The contact connection may utilise electrical connectivity as is well known by those skilled in the art. The method may further comprise selectively configuring the first and second transceiver devices as a merchant device and a customer transceiver device respectively. Optionally, the first and second transceiver devices may be respectively configured as a customer transceiver device and a merchant device. In either embodiment, the counter value is preferably stored in a secure area of the customer transceiver device. The method may further comprise maintaining a counter embodied in the customer transceiver device. The method may further comprise the customer transceiver device generating the cryptogram. In addition to utilising the secret key, the counter value, the received unique merchant identifier and the transaction request data, other relevant data may be included, including, but not limited to data associated with a transceiver device's technical capability.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate object features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include receiving, by the merchant portable electronic device, an encrypted binary large object (BLOB) from the user portable electronic device, wherein the user portable electronic device generates the encrypted BLOB based on the PIN result in an improved invention because applying said technique will prevent the merchant device from directly accessing the PIN, thus improving the overall security of the invention.
Glendenning as modified does not explicitly disclose the method comprising: reading, by a merchant portable electronic device, a payment card to initiate a transaction.
However, Ziat teaches the method comprising: reading, by a merchant portable electronic device, a payment card to initiate a transaction, (Para. 0005-0006, With the development of mobile communication technologies, an electronic device can perform various data communication functions as well as voice call functions. An electronic device, for example, a mobile device or a user device, may provide various services through various applications. An electronic device may provide network-based communication services such as multimedia services, for example, a music service, a dynamic image service, a digital broadcasting service, a call, wireless Internet, short message service (SMS), a multimedia messaging service (MMS), and the like. Further, an electronic device has evolved from a simple communication medium to a device having various functions, such as communication, circulation, the Internet, or payment, and may be used in all of the circulation industrial field. an electronic device may provide, for example, a mobile payment scheme through the electronic device by a payment function. An electronic device may enable, for example, payment using the electronic device from a payment scheme using cash or a card (e.g., credit card, debit card, membership card). An electronic device may provide, for example, a function of paying for, using the electronic device, a service or the purchase of goods on-line or off-line (e.g., making a payment after buying a product or food in an actual shop or restaurant) using a mobile payment service. Further, an electronic device may have, for example, a communication function for receiving or transmitting payment information. However, a user must execute a mobile payment application, and select a card in the executed application so as to execute the mobile payment. A user may be able to use a mobile payment after executing the above described complicated procedure.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning as modified to the known invention of Ziat would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate transaction features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include reading, by a merchant portable electronic device, a payment card to initiate a transaction result in an improved invention because applying said technique will prevent the merchant device from directly accessing the PIN, thus improving the overall security of the invention.
24. Regarding Claim 18, Glendenning discloses wherein communicating the transaction authorization request comprising the encrypted BLOB to a transaction service provider server for decryption comprises one of (Para. 0024-0039, The method may further comprise authenticating the legitimacy of the merchant device including: the customer transceiver device forming a merchant authentication request, the merchant authentication request requesting from the merchant transceiver device (1) a signed certificate of the issuer which holds as a minimum the unique (merchant) identifier and merchant public key and (2) a signature of the unique dynamic value using the merchant's secure module's private key; the customer transceiver device receiving from the merchant device a second data package comprising the issuer's signed certificate and a signature of the unique dynamic value using the merchant's secure module's private key; the customer transceiver device verifying the issuer's signed certificate using a certification authority's public key, and once verified, authenticating against stored records the signed unique dynamic value using the merchant public key. The step of authenticating the legitimacy of the merchant device enables the consumer transceiver device to ensure that it is communicating with an authentic merchant device (one that has been issued by an approved issuer within a defined scheme). It also ensures that the unique identification number provided as part of the transaction request is the same as that signed by the issuer in the signed secure module certificate. In a second aspect the invention is a transceiver device operable to secure payment data for transmission over open communication networks, the transceiver device comprising: an interface module to enable data communication with other transceiver devices; a processor coupled to a memory, the memory storing processor control code to selectively control the processor, when running to (1): retrieve from memory a unique merchant identifier; enable the interface module to transmit the unique merchant identifier and transaction request data to another of said devices; receive from the other of said devices a cryptogram, the cryptogram having been generated from a secret key, a counter, the unique merchant identifier and the transaction request data; and form an authorisation request comprising the cryptogram, merchant identifier and transaction data, and submitting said authorisation request to at least one of an issuer and an acquirer to facilitate authorisation and processing of said transaction request data; or (2) receive a unique merchant identifier and transaction request data from another of said devices; retrieve from memory a counter value and a stored secret key; generate a cryptogram using the retrieved secret key, the retrieved counter value together with the received unique merchant identifier and transaction request data; and transmitting the cryptogram to the other of said devices for subsequent forwarding of an authorisation request to one of an issuer and an acquirer to facilitate authorisation and processing of said transaction request data.)
or transmitting, by the merchant portable electronic device, a first transaction authorization comprising the encrypted BLOB to an acquire server, and wherein the acquirer server transmits a second transaction authorization comprising the encrypted BLOB to the transaction service provider server, (Para. 0028-0039, The step of authenticating the legitimacy of the merchant device enables the consumer transceiver device to ensure that it is communicating with an authentic merchant device (one that has been issued by an approved issuer within a defined scheme). It also ensures that the unique identification number provided as part of the transaction request is the same as that signed by the issuer in the signed secure module certificate. In a second aspect the invention is a transceiver device operable to secure payment data for transmission over open communication networks, the transceiver device comprising: an interface module to enable data communication with other transceiver devices; a processor coupled to a memory, the memory storing processor control code to selectively control the processor, when running to (1): retrieve from memory a unique merchant identifier; enable the interface module to transmit the unique merchant identifier and transaction request data to another of said devices; receive from the other of said devices a cryptogram, the cryptogram having been generated from a secret key, a counter, the unique merchant identifier and the transaction request data; and form an authorisation request comprising the cryptogram, merchant identifier and transaction data, and submitting said authorisation request to at least one of an issuer and an acquirer to facilitate authorisation and processing of said transaction request data; or (2) receive a unique merchant identifier and transaction request data from another of said devices; retrieve from memory a counter value and a stored secret key; generate a cryptogram using the retrieved secret key, the retrieved counter value together with the received unique merchant identifier and transaction request data; and transmitting the cryptogram to the other of said devices for subsequent forwarding of an authorisation request to one of an issuer and an acquirer to facilitate authorisation and processing of said transaction request data.)
25. Regarding Claim 19, Glendenning does not explicitly disclose wherein receiving the encrypted binary large object (BLOB) from the user portable electronic device comprises: capturing, by a camera of the merchant portable electronic device, an image of a quick response (QR) code, wherein the QR code is generated by the user portable electronic device based on the encrypted BLOB, and wherein the QR code is displayed by a display screen of the user portable electronic device; and extracting, by the point-of-sale application executed by the merchant portable electronic device, the encrypted BLOB based on the image of the QR code.
However, Park teaches wherein receiving the encrypted binary large object (BLOB) from the user portable electronic device comprises: capturing, by a camera of the merchant portable electronic device, an image of a quick response (QR) code, wherein the QR code is generated by the user portable electronic device based on the encrypted BLOB, and wherein the QR code is displayed by a display screen of the user portable electronic device; and extracting, by the point-of-sale application executed by the merchant portable electronic device, the encrypted BLOB based on the image of the QR code, (Para. 2083-2086, The sensor unit 5840 may detect at least one of the peripheral state of the electronic device 5800 or the state of the electronic device 5800. The sensor unit 5840 may include one or more sensors. According to an embodiment of the present disclosure, the sensor unit 5840 may include a fingerprint sensor for detecting a user's fingerprint in the electronic device 5800. For example, the fingerprint sensor 141 may be positioned on the front side of the electronic device 5800 as shown in FIG. 59. In this case, the fingerprint sensor may be provided at the bottom of the display unit 5830 in the electronic device 5800. In addition, the fingerprint sensor may be coupled with the input unit 5820 of the electronic device 5800. For example, the fingerprint sensor may include at least one of an optical fingerprint sensor, which may capture the fingerprint of the user of the electronic device 5800 in the form of an image, the ultrasonic fingerprint sensor, a capacitive fingerprint sensor, a semiconductor fingerprint sensor for detecting the electric conductivity, or a heart rate sensor. The storage unit 5850 may store operational programs of the electronic device 5800. According to an embodiment of the present disclosure, the storage unit 5850 may store programs to control the payment management function and the payment execution function. The payment management function may be an application to manage one or more electronic cards and card information corresponding thereto. The payment execution function may be a mini-application to smoothly support the interaction between the user of the electronic device 5800 and the payment management function. In addition, the storage unit 5850 may store data that is generated during the execution of the programs. In addition, the storage unit 5850 may store the card information corresponding to one or more electronic cards. For example, the electronic cards may include at least one of: a payment card for payment; a service card for using the membership services; a gift card for goods exchange; or a personal identification card for identification. The controller 5860 may control the overall operations of the electronic device 5800. In this case, the controller 5860 may be functionally connected to the elements of the electronic device 5800 in order to thereby control the elements of the electronic device 5800. In addition, the controller 5860 may receive commands or data from the elements of the electronic device 5800 in order to thereby process the same. In this case, the controller 5860 may perform various functions. For example, the controller 5860 may include a function processor for each function. In addition, the function processor may be an application processor (AP). According to an embodiment of the present disclosure, the controller 5860 may execute the payment management function and the payment execution function. According to an embodiment of the present disclosure, the electronic device 5800 may include the display unit 5830 and the controller 5860 that is functionally connected to the display unit 5830. The controller 5860 may be configured to: display images of the electronic cards, usage information, and a payment module on the screen; detect the selection of the payment module; and execute the payment with the electronic card.)
One of ordinary skill in the art would have recognized that applying the known technique of Glendenning to the known invention of Park would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate QR code features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein receiving the encrypted binary large object (BLOB) from the user portable electronic device comprises: capturing, by a camera of the merchant portable electronic device, an image of a quick response (QR) code, wherein the QR code is generated by the user portable electronic device based on the encrypted BLOB, and wherein the QR code is displayed by a display screen of the user portable electronic device; and extracting, by the point-of-sale application executed by the merchant portable electronic device, the encrypted BLOB based on the image of the QR code result in an improved invention because applying said technique provide a visual and option when wireless communication is unavailable, thus improving the overall security of the invention.
26. Regarding Claim 20, Glendenning discloses wherein receiving the encrypted BLOB from the user portable electronic device comprises: receiving, by the merchant portable electronic device, a wireless communication comprising the encrypted BLOB from the user portable electronic device, wherein the wireless communication comprises at least one of a near field communication (NFC) data exchange format message, a sound, a Bluetooth message, a WiFi message, or a combination thereof, (Para. 0040-0043, Advantageously, in accordance with embodiments of the invention, the transceiver device is able to be selectively configured to be operable as either a merchant device/terminal or a customer device/terminal. The transceiver device may be incorporated into a mobile communication device such as a mobile phone, cell phone or iPhone. Optionally, the transceiver device may be separated from but in communication with a mobile communication device. Optionally, the transceiver device may be incorporated into a point of sale device (POS) or separated from but in communication with a POS. In still other arrangements the transceiver device may be integrated into a personal computing device (such as a laptop, PDA, pager) or a device that is separated from but in communication with a personal computing device. The interface module may be in the form of a contact interface module, a contactless interface module or a dual contact and contactless interface module. In an embodiment utilising a contactless interface module, the interface module preferably incorporates the requisite mechanisms to enable the transfer of data between two devices (such as ISO 7816, NFC, Bluetooth, Wi-Fi, SMS etc). For example, one such contactless interface module may comprise a transponder and an antenna. The transaction request data may comprise an amount for the transaction, and at least one (or more) of a currency code, a time stamp and a customer identifier such as a PIN or biometric and any other relevant data.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Multi-point Authentication for Payment Transactions (US 20160275500 A1) teaches Authentication includes receiving an indication of physical possession of a payment card by a merchant and receiving a purchase request for an authorization of an exchange from the payment account of the cardholder to the merchant. Authentication includes assigning a randomized transaction identifier to the request for the authorization of the exchange. The method also includes transmitting the request for the authorization of the exchange from the payment account of the cardholder to the merchant and receiving the assigned randomized transaction identifier and a randomized authentication identifier associated with the randomized transaction identifier from a payment association, the payment association determining whether the request for the authorization of the exchange is valid. Authentication includes transmitting a copy of the randomized authentication identifier to the mobile device and receiving validation that the transmitted copy of the randomized authentication identifier from the mobile device matches the randomized authentication identifier.
In addition to the foregoing, other aspects are described in the claims, drawings, and text. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-5pm.
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 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.
/D.L.K./Examiner, Art Unit 3699
Prosecution Insights