DETAILED ACTION
Response to Amendment
The amendment filed on September 5, 2025 has been entered. Applicant has amended claims 15, 25 and 27. Claims 15, 18-21 and 24-28 remain pending, where claim 28 has been withdrawn from consideration as being directed to a non-elected invention. Accordingly, claims 15, 18-21 and 24-27 have been examined and currently stand rejected.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Claim Interpretation
Intended Use/Result Language:
The claim 15, 21 and 27 phrase which recites “to authorize the point-of-sale terminal to perform the payment transaction” is merely a recited intended use/result of why the user’s terminal sends the signature to the point-of-sale terminal.
These phrases are given little to no patentable weight because the limitation, or portion thereof, does not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
Claim Scope:
Claim 27 recites, in the last limitation, “wherein the point-of-sale terminal is configured to perform the payment transaction based on the authorization.” Examiner notes that claim 27 is directed to actions/steps performed by the user’s terminal (or its processors), and this “wherein” clause is describing actions attributed to the point-of-sale terminal. Furthermore, this limitation fails to affect how any of the positively recited steps are performed. Accordingly, this limitation will not distinguish the claimed invention from the prior art.
Claim Rejections - 35 USC § 103
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 pre-AIA 35 U.S.C. 103(a) 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.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 15, 18-19, 21, 24-25 and 27 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cox (US 2009/0104888 A1) in view of Hammad et al. (US 2012/0136796 A1) (“Hammad”) in view of Yeager (US 2013/0054474 A1), whose cited portions are supported by provisional application No. 61/573,476, filed on Sep. 6, 2011, and provisional application No. 61/575,846, filed on Aug. 30, 2011.
Regarding Claim 15: Cox discloses:
Claims 15: A method for performing a payment transaction in a secure manner by a user's terminal without direct communication of the user's terminal and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction, the method comprising:
receiving by a user interface in the user's terminal, authentication by a user for performing a payment transaction in a secure manner by the user's terminal (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.);
retrieving data of a trust card of a payment application from a safe memory area in the user's terminal, the trust card comprising at least a trust card related identifier (See at least Cox [0035]; [0053-0054]; [0068]; [0075]. Where a user’s terminal/apparatus (i.e., mobile device) retrieves data of a trust card (i.e., information related to a payment vehicle) of a payment application (i.e., of a mobile wallet) from a safe memory area in the user's terminal (i.e., from a memory area of the mobile device. Examiner considers the memory area of the mobile device, described by Cox, to be “safe” since a password/pin/biometric feature/etc. is needed in order to gain access to this area.), the data of the trust card (i.e., the information related to the payment vehicle) comprising at least a trust card related identifier (i.e., an account number, e.g., a PAN).);
forming a security code (See at least Cox [0044]; [0060]; [0074]; [0078]. Where the user’s terminal/apparatus (i.e., mobile device) forms (i.e., generates) a security code (i.e., password, e.g., onetime password).);
establishing, by the user's terminal operating in a Near Field Communication (NFC) card emulation mode, an NFC protocol connection with a point-of-sale terminal (See at least Cox [0004]; [0008]; [0011]; [0036]. Cox discloses establishing, by the user's terminal (i.e., by the mobile device) operating in a Near Field Communication (NFC) card emulation mode (i.e., operating in an NFC mode that communicates account information to a merchant at a point of sale device), an NFC protocol connection with a point-of-sale terminal (i.e., POS device).);
sending, by the user's terminal, the security code and the trust card related identifier to the point-of-sale terminal over the Near Field Communication (NFC) protocol connection (See at least Cox [0049]; [0075-0077]; [0080-0082]. Cox discloses sending, by the user’s terminal/apparatus (i.e., mobile device), the security code (i.e., password) and the trust card related identifier (i.e., account number, e.g., PAN) to the point-of-sale terminal (i.e., to the POS device) over a Near Field Communication (NFC) protocol connection (i.e., through NFC transponders).).
Cox further indicates that since transmissions involving the account information include sensitive financial data such as account numbers, a cryptography module may also be provided to allow encryption of data sent and received by the mobile device via the NFC module. Cox [0066]. However, Cox does not explicitly disclose, but Hammad teaches:
receiving by the user's terminal data from the point-of-sale terminal over the Near Field Communication (NFC) protocol connection (See at least Hammad [0070]; [0131-0132]; [0142]; Fig. 12 Step P7. Hammad teaches receiving by the user's terminal (i.e., mobile device) data (i.e., a nonce) from the point-of-sale terminal (i.e., from the merchant access device) over the Near Field Communication (NFC) protocol connection (i.e., over the near field communications connection).);
signing by the user's terminal the data with a private key of the trust card to form a signature (See at least Hammad [0132]; [0135]. Hammad teaches signing by the user's terminal (i.e., by the mobile device) the data (i.e., the nonce) with a private key of the trust card (i.e., with a consumer’s private key) to form a signature.);
sending, by the user’s terminal over the NFC protocol connection, the signature to the point-of-sale terminal to authorize the point-of-sale terminal to perform the payment transaction (See at least Hammad [0070]; [0132]; [0135]; [0142-0143]; [0148]; Fig. 12 Step P13. Hammad teaches sending, by the user’s terminal (i.e., by the mobile device) over the NFC protocol connection (i.e., over the near field communications connection), the signature (i.e., the signed nonce) to the point-of-sale terminal (i.e., to the merchant access device) to authorize the point-of-sale terminal to perform the payment transaction (i.e., to authorize the merchant access device to process the transaction).).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using a cryptography module to encrypt data sent and received by the mobile device, to include the teachings of Hammad, in order to maintain confidentiality of transmitted data and to secure the transaction against replay attacks (Hammad [0132]).
Both Cox and Hammad disclose the use of NFC communications for exchanging messages between the user’s terminal (e.g., mobile device) and the point-of-sale terminal (e.g., POS device, merchant access device). See e.g., Cox [0004]; [0008]; [0011]; [0036] and Hammad [0070]; [0132]. Cox and Hammad differ, in part, from the claimed invention because neither Cox nor Hammad explicitly indicate: where the payment transaction is performed without direct communication of the user's terminal and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction; where the NFC protocol connection is configured to exchange Application Protocol Data Unit (APDU) command and response messages; or where the messages sent between the user’s terminal and the point-of-sale terminal are sent/received via APDU commands and responses. Yeager, on the other hand, teaches:
where the payment transaction is performed without direct communication of the user's terminal and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction (See at least Yeager [0211] “Card risk management is described by the card having enough logic and information about the transaction at the point-of-sale to approve or decline the transaction without consulting an application system or remote processing server. An example of performing card risk management logic using unpredictable data is: A point-of-sale interrogates a secure element or mobile device and during the process, it indicates to the mobile device it will not be forwarding credential data immediately for authorization of a transaction. This is sometimes called an "offline transaction".”;
the NFC protocol connection being configured to exchange Application Protocol Data Unit (APDU) command and response messages (See at least Yeager [0216] “This interrogation may be carried out over near field communication (NFC) on both the point-of-sale and mobile device. The data protocol layer within this interrogation may be configured for ISO7816-4 and follow APDU command and response formats.”; Fig. 24.);
sending and receiving messages between the user’s terminal and the point-of-sale terminal via an APDU command/response sequence over the NFC protocol connection (See at least Yeager [0046-0048]; [0052-0058]; [0216]; Fig. 1; Fig. 24. Yeager teaches sending and receiving messages between the user’s terminal (i.e., mobile device) and the point-of-sale terminal (i.e., point-of-sale) via an APDU command/response sequence (i.e., APDU communication, e.g., command APDU, response APDU) over the NFC protocol connection.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using NFC communications to exchange messages, to include the teachings of Yeager, in order to allow a mobile device with NFC functionality to pretend to be (or emulate) a card and to exchange information between the mobile device and a point-of-sale via a standard protocol (e.g., APDU) (Yeager [0046-0047]).
Additionally, while Hammad discloses sending data from the point-of-sale to the user’s terminal, signing the data with a private key of the trust card, and sending/returning the signed data back to the point-of-sale in order to authorize the payment transaction, neither Cox nor Hammad explicitly disclose that the data used in authorizing the transaction (i.e., the data sent between the user’s terminal and the POS) is “random” data.
Yeager, on the other hand, further teaches where the user’s terminal receives random data (i.e., an unpredictable number, e.g., a random sequence of numbers) from the point of sale, modifies the random data with a key (i.e., permanent cryptographic key), and then sends the modified response (e.g., a cryptogram) back to the point of sale to authorize the payment request. Yeager [0205-0208].
In view of the teachings provided by Yeager, it would have been obvious to one of ordinary skill in the art at the time the invention was made to include receiving, by the user's terminal, random data from the point-of-sale terminal, and signing by the user's terminal the random data with a private key. One of skill in the art would have been motivated to include these features in order to allow the user’s terminal to verify itself to the point-of-sale by returning an expected result that is based on the unpredictable number. Additionally, it would have been obvious to one of ordinary skill in the art at the time the invention was made to substitute Hammad’s data (i.e., the nonce) with the unpredictable data (i.e., a random sequence of numbers) taught by Yeager as this is merely a simple substitution of the type of data used in the payment verification process.
Regarding Claims 18 and 24: The combination of Cox, Hammad and Yeager discloses the method according to claim 15 and the apparatus according to claim 21. Cox further discloses:
displaying, by the user's terminal, payment data to the user (See at least Cox [0033]; [0054]; [0077]; [0082]. Where payment data (i.e., information related to the transaction(s), e.g., a transaction history) is displayed by the user’s terminal (i.e., mobile device) to the user (e.g., when the user is provided with an electronic receipt).),
storing the payment data on the safe memory area (See at least Cox [0033]; [0077]; [0082]. Where the payment data (i.e., information related to the transaction(s)) is stored on the safe memory area (i.e., in the memory, e.g., when the electronic receipt is stored).), and
adjusting a payment limit in the safe memory area according to the payment data (See at least Cox [0050]; [0058]. Where a payment limit (i.e., balance information, e.g., a current balance level) in the safe memory area (i.e., in the mobile wallet stored in memory) is adjusted (i.e., updated) according to the payment data (i.e., according to the information related to the transaction(s), e.g., transaction history).).
Regarding Claim 19: The combination of Cox, Hammad and Yeager discloses the method according to claim 15. Cox further discloses:
receiving, by the user's terminal, a pin code entered by a user of the user's terminal (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.); and
using the pin code as the authentication by the user (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.).
Regarding Claim 21: Cox discloses an apparatus comprising at least one processor, a memory and a computer program code in the memory, the computer program code being configured, when run in the at least one processor, to cause the apparatus to (See at least Cox [0065]; Fig. 3. at least one processor = wireless-device controller; memory = memory; computer program code = software stored in memory):
receive by a user interface in the apparatus an authentication provided by a user for performing a payment transaction in a secure manner by the apparatus (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.);
retrieve data of a trust card of a payment application from a safe memory area in the apparatus, the data of the trust card comprising at least a trust card related identifier (See at least Cox [0035]; [0053-0054]; [0068]; [0075]. Where the apparatus (i.e., mobile device) retrieves data of a trust card (i.e., information related to a payment vehicle) of a payment application (i.e., of a mobile wallet) from a safe memory area in the apparatus (i.e., from a memory area of the mobile device. Examiner considers the memory area of the mobile device, described by Cox, to be “safe” since a password/pin/biometric feature/etc. is needed in order to gain access to this area.), the data of the trust card (i.e., the information related to the payment vehicle) comprising at least a trust card related identifier (i.e., an account number, e.g., a PAN).);
form a security code as a one-time security code (See at least Cox [0044]; [0060]; [0074]; [0078]. Where the user’s terminal/apparatus (i.e., mobile device) forms (i.e., generates) a security code (i.e., password, e.g., onetime password) as a one-time security code.);
establishing, by the apparatus operating in a Near Field Communication (NFC) card emulation mode, an NFC protocol connection with a point-of-sale terminal (See at least Cox [0004]; [0008]; [0011]; [0036]. Cox discloses establishing, by the user's terminal (i.e., by the mobile device) operating in a Near Field Communication (NFC) card emulation mode (i.e., operating in an NFC mode that communicates account information to a merchant at a point of sale device), an NFC protocol connection with a point-of-sale terminal (i.e., POS device).);
send, over the NFC protocol connection, the security code and the trust card related identifier to the point-of-sale terminal (See at least Cox [0049]; [0075-0077]; [0080-0082]. Cox discloses sending, by the apparatus (i.e., mobile device) over a Near Field Communication (NFC) protocol connection (i.e., through NFC transponders), the security code (i.e., password) and the trust card related identifier (i.e., account number, e.g., PAN) to the point-of-sale terminal (i.e., to the POS device).).
Cox further indicates that since transmissions involving the account information include sensitive financial data such as account numbers, a cryptography module may also be provided to allow encryption of data sent and received by the mobile device via the NFC module. Cox [0066]. However, Cox does not explicitly disclose, but Hammad teaches:
receiving data from the point-of-sale terminal over the Near Field Communication (NFC) protocol connection (See at least Hammad [0070]; [0131-0132]; [0142]; Fig. 12 Step P7. Hammad teaches receiving by the apparatus (i.e., mobile device) data (i.e., a nonce) from the point-of-sale terminal (i.e., from the merchant access device) over the Near Field Communication (NFC) protocol connection (i.e., over the near field communications connection).);
signing the data with a private key of the trust card to form a signature (See at least Hammad [0132]; [0135]. Hammad teaches signing by the apparatus (i.e., by the mobile device) the data (i.e., the nonce) with a private key of the trust card (i.e., with a consumer’s private key) to form a signature.);
sending, over the NFC protocol connection, the signature to the point-of-sale terminal to authorize the point-of-sale terminal to perform the payment transaction (See at least Hammad [0070]; [0132]; [0135]; [0142-0143]; [0148]; Fig. 12 Step P13. Hammad teaches sending, by the apparatus (i.e., by the mobile device) over the NFC protocol connection (i.e., over the near field communications connection), the signature (i.e., the signed nonce) to the point-of-sale terminal (i.e., to the merchant access device) to authorize the point-of-sale terminal to perform the payment transaction (i.e., to authorize the merchant access device to process the transaction).).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using a cryptography module to encrypt data sent and received by the mobile device, to include the teachings of Hammad, in order to maintain confidentiality of transmitted data and to secure the transaction against replay attacks (Hammad [0132]).
Both Cox and Hammad disclose the use of NFC communications for exchanging messages between the user’s terminal/apparatus (e.g., mobile device) and the point-of-sale terminal (e.g., POS device, merchant access device). See e.g., Cox [0004]; [0008]; [0011]; [0036] and Hammad [0070]; [0132]. Cox and Hammad differ, in part, from the claimed invention because neither Cox nor Hammad explicitly indicate: where the payment transaction is performed without direct communication of the apparatus and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction; where the NFC protocol connection is configured to exchange Application Protocol Data Unit (APDU) command and response messages; or where the messages sent between the apparatus and the point-of-sale terminal are sent/received via APDU commands and responses. Yeager, on the other hand, teaches:
where the payment transaction is performed without direct communication of the apparatus and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction (See at least Yeager [0211] “Card risk management is described by the card having enough logic and information about the transaction at the point-of-sale to approve or decline the transaction without consulting an application system or remote processing server. An example of performing card risk management logic using unpredictable data is: A point-of-sale interrogates a secure element or mobile device and during the process, it indicates to the mobile device it will not be forwarding credential data immediately for authorization of a transaction. This is sometimes called an "offline transaction".”;
the NFC protocol connection being configured to exchange Application Protocol Data Unit (APDU) command and response messages (See at least Yeager [0216] “This interrogation may be carried out over near field communication (NFC) on both the point-of-sale and mobile device. The data protocol layer within this interrogation may be configured for ISO7816-4 and follow APDU command and response formats.”; Fig. 24.);
sending and receiving messages between the apparatus and the point-of-sale terminal via an APDU command/response sequence over the NFC protocol connection (See at least Yeager [0046-0048]; [0052-0058]; [0216]; Fig. 1; Fig. 24. Yeager teaches sending and receiving messages between the apparatus (i.e., mobile device) and the point-of-sale terminal (i.e., point-of-sale) via an APDU command/response sequence (i.e., APDU communication, e.g., command APDU, response APDU) over the NFC protocol connection.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using NFC communications to exchange messages, to include the teachings of Yeager, in order to allow a mobile device with NFC functionality to pretend to be (or emulate) a card and to exchange information between the mobile device and a point-of-sale via a standard protocol (e.g., APDU) (Yeager [0046-0047]).
Additionally, while Hammad discloses sending data from the point-of-sale to the apparatus, signing the data with a private key of the trust card, and sending/returning the signed data back to the point-of-sale in order to authorize the payment transaction, neither Cox nor Hammad explicitly disclose that the data used in authorizing the transaction (i.e., the data sent between the apparatus and the POS) is “random” data.
Yeager, on the other hand, further teaches where the user’s terminal receives random data (i.e., an unpredictable number, e.g., a random sequence of numbers) from the point of sale, modifies the random data with a key (i.e., permanent cryptographic key), and then sends the modified response (e.g., a cryptogram) back to the point of sale to authorize the payment request. Yeager [0205-0208].
In view of the teachings provided by Yeager, it would have been obvious to one of ordinary skill in the art at the time the invention was made to include receive random data from the point-of-sale terminal, and sign the random data with a private key. One of skill in the art would have been motivated to include these features in order to allow the user’s terminal/apparatus to verify itself to the point-of-sale by returning an expected result that is based on the unpredictable number. Additionally, it would have been obvious to one of ordinary skill in the art at the time the invention was made to substitute Hammad’s data (i.e., the nonce) with the unpredictable data (i.e., a random sequence of numbers) taught by Yeager as this is merely a simple substitution of the type of data used in the payment verification process.
Regarding Claim 25: The combination of Cox, Hammad and Yeager discloses the apparatus according to claim 21. Cox further discloses the memory comprising computer program code configured, when run in the at least one processor, to cause the apparatus to:
receive a pin code entered by the user on the user interface of the apparatus (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.); and
use the pin code as the authentication by the user (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.).
Regarding Claim 27: Cox discloses a non-transitory computer program product for making a payment, the computer program product comprising computer software code stored on a non-volatile computer-readable medium, the computer software code, when run in at least one processor, causing a user's terminal to (See at least Cox [0065]; Fig. 3):
receive by a user interface of the user's terminal an authentication provided by a user for performing a payment transaction in a secure manner by the user's terminal (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.);
retrieving data of a trust card of a payment application from a safe memory area in the user's terminal, the trust card comprising at least a trust card related identifier (See at least Cox [0035]; [0053-0054]; [0068]; [0075]. Where a user’s terminal/apparatus (i.e., mobile device) retrieves data of a trust card (i.e., information related to a payment vehicle) of a payment application (i.e., of a mobile wallet) from a safe memory area in the user's terminal (i.e., from a memory area of the mobile device. Examiner considers the memory area of the mobile device, described by Cox, to be “safe” since a password/pin/biometric feature/etc. is needed in order to gain access to this area.), the data of the trust card (i.e., the information related to the payment vehicle) comprising at least a trust card related identifier (i.e., an account number, e.g., a PAN).);
establishing, by the user's terminal/[apparatus] operating in a Near Field Communication (NFC) card emulation mode, an NFC protocol connection with a point-of-sale terminal (See at least Cox [0004]; [0008]; [0011]; [0036]. Cox discloses establishing, by the user's terminal (i.e., by the mobile device) operating in a Near Field Communication (NFC) card emulation mode (i.e., operating in an NFC mode that communicates account information to a merchant at a point of sale device), an NFC protocol connection with a point-of-sale terminal (i.e., POS device).);
forming a security code as a one-time security code (See at least Cox [0044]; [0060]; [0074]; [0078]. Where the user’s terminal/apparatus (i.e., mobile device) forms (i.e., generates) a security code (i.e., password, e.g., onetime password) as a one-time security code.);
send, over the Near Field Communication (NFC) protocol connection, the security code and the trust card related identifier to the point-of-sale terminal over the Near Field Communication (NFC) protocol connection (See at least Cox [0049]; [0075-0077]; [0080-0082]. Cox discloses sending, by the user’s terminal/apparatus (i.e., mobile device) over the Near Field Communication (NFC) protocol connection, the security code (i.e., password) and the trust card related identifier (i.e., account number, e.g., PAN) to the point-of-sale terminal (i.e., to the POS device) over a Near Field Communication (NFC) protocol connection (i.e., through NFC transponders).).
Cox further indicates that since transmissions involving the account information include sensitive financial data such as account numbers, a cryptography module may also be provided to allow encryption of data sent and received by the mobile device via the NFC module. Cox [0066]. However, Cox does not explicitly disclose, but Hammad teaches:
receiving data from the point-of-sale terminal over the Near Field Communication (NFC) protocol connection (See at least Hammad [0070]; [0131-0132]; [0142]; Fig. 12 Step P7. Hammad teaches receiving by the user's terminal (i.e., mobile device) data (i.e., a nonce) from the point-of-sale terminal (i.e., from the merchant access device) over the Near Field Communication (NFC) protocol connection (i.e., over the near field communications connection).);
signing the data with a private key of the trust card to form a signature (See at least Hammad [0132]; [0135]. Hammad teaches signing by the user's terminal (i.e., by the mobile device) the data (i.e., the nonce) with a private key of the trust card (i.e., with a consumer’s private key) to form a signature.);
sending, over the NFC protocol connection, the signature to the point-of-sale terminal to authorize the point-of-sale terminal over the NFC protocol connection to authorize the point-of-sale terminal to perform the payment (See at least Hammad [0070]; [0132]; [0135]; [0142-0143]; [0148]; Fig. 12 Step P13. Hammad teaches sending, by the user’s terminal (i.e., by the mobile device) over the NFC protocol connection (i.e., over the near field communications connection), the signature (i.e., the signed nonce) to the point-of-sale terminal (i.e., to the merchant access device) to authorize the point-of-sale terminal to perform the payment transaction (i.e., to authorize the merchant access device to process the transaction).); and
wherein the point-of-sale terminal is configured to perform the payment transaction based on the authorization (See at least Hammad [0143-0146]; [0148]; Fig. 13 steps P14-P15; Fig. 14 step P16. Hammad teaches wherein the point-of-sale terminal (i.e., the merchant access device) is configured to perform the payment transaction (e.g., by generating and/or sending an authorization request message to the payment processing network) based on the authorization.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using a cryptography module to encrypt data sent and received by the mobile device, to include the teachings of Hammad, in order to maintain confidentiality of transmitted data and to secure the transaction against replay attacks (Hammad [0132]).
Both Cox and Hammad disclose the use of NFC communications for exchanging messages between the user’s terminal/apparatus (e.g., mobile device) and the point-of-sale terminal (e.g., POS device, merchant access device). See e.g., Cox [0004]; [0008]; [0011]; [0036] and Hammad [0070]; [0132]. Cox and Hammad differ, in part, from the claimed invention because neither Cox nor Hammad explicitly indicate: where the payment transaction is performed without direct communication of the user’s terminal and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction; where the NFC protocol connection is configured to exchange Application Protocol Data Unit (APDU) command and response messages; or where the messages sent between the apparatus and the point-of-sale terminal are sent/received via APDU commands and responses. Yeager, on the other hand, teaches:
where the payment transaction is performed without direct communication of the user’s terminal and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction (See at least Yeager [0211] “Card risk management is described by the card having enough logic and information about the transaction at the point-of-sale to approve or decline the transaction without consulting an application system or remote processing server. An example of performing card risk management logic using unpredictable data is: A point-of-sale interrogates a secure element or mobile device and during the process, it indicates to the mobile device it will not be forwarding credential data immediately for authorization of a transaction. This is sometimes called an "offline transaction".”;
the NFC protocol connection being configured to exchange Application Protocol Data Unit (APDU) command and response messages (See at least Yeager [0216] “This interrogation may be carried out over near field communication (NFC) on both the point-of-sale and mobile device. The data protocol layer within this interrogation may be configured for ISO7816-4 and follow APDU command and response formats.”; Fig. 24.);
sending and receiving messages between the apparatus and the point-of-sale terminal via an APDU command/response sequence over the NFC protocol connection (See at least Yeager [0046-0048]; [0052-0058]; [0216]; Fig. 1; Fig. 24. Yeager teaches sending and receiving messages between the apparatus (i.e., mobile device) and the point-of-sale terminal (i.e., point-of-sale) via an APDU command/response sequence (i.e., APDU communication, e.g., command APDU, response APDU) over the NFC protocol connection.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using NFC communications to exchange messages, to include the teachings of Yeager, in order to allow a mobile device with NFC functionality to pretend to be (or emulate) a card and to exchange information between the mobile device and a point-of-sale via a standard protocol (e.g., APDU) (Yeager [0046-0047]).
Additionally, while Hammad discloses sending data from the point-of-sale to the user’s terminal, signing the data with a private key of the trust card, and sending/returning the signed data back to the point-of-sale in order to authorize the payment transaction, neither Cox nor Hammad explicitly disclose that the data used in authorizing the transaction (i.e., the data sent between the user’s terminal and the POS) is “random” data.
Yeager, on the other hand, further teaches where the user’s terminal receives random data (i.e., an unpredictable number, e.g., a random sequence of numbers) from the point of sale, modifies the random data with a key (i.e., permanent cryptographic key), and then sends the modified response (e.g., a cryptogram) back to the point of sale to authorize the payment request. Yeager [0205-0208].
In view of the teachings provided by Yeager, it would have been obvious to one of ordinary skill in the art at the time the invention was made to include receive random data from the point-of-sale terminal, and sign the random data with a private key. One of skill in the art would have been motivated to include these features in order to allow the user’s terminal/apparatus to verify itself to the point-of-sale by returning an expected result that is based on the unpredictable number. Additionally, it would have been obvious to one of ordinary skill in the art at the time the invention was made to substitute Hammad’s data (i.e., the nonce) with the unpredictable data (i.e., a random sequence of numbers) taught by Yeager as this is merely a simple substitution of the type of data used in the payment verification process.
Claims 20 and 26 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cox in view of Hammad in view of Yeager, as applied above, and further in view of Akiyama et al. (US 5,428,684 A) (“Akiyama”).
Regarding Claims 20 and 26: The combination of Cox, Hammad and Yeager discloses the method according to claim 15 and the apparatus according to claim 21. Cox further discloses receiving, by the user's terminal, a password entered by a user of the user's terminal (See at least Cox [0067-0068] “The display device 380 and the input device 382 may be used to request and receive a password, PIN, biometric feature, etc, in order to gain access to information within the mobile wallet 376 and/or in order to transmit account information and/or passwords to a POS device 110.”.).
Cox further discloses that the user’s terminal/apparatus (i.e., mobile device) can be used to form (i.e., generate) the security code (i.e., password, e.g., onetime password). Cox [0044]; [0060]; [0074]; [0078]. Cox also expresses a desire to use encryption when sending or receiving sensitive financial data. Cox [0066]. However, Cox does not explicitly disclose combining the password and a secret of the payment application to form the security code. Akiyama, on the other hand, teaches combining the password and a secret of the payment application to form the security code (See at least Akiyama Col. 6 lines 44-68; Col. 8 lines 1-11. Where the password (i.e., Password (PW)) and a secret of the payment application (i.e., a parameter, e.g., the first parameter) are combined (i.e., via the use of an operating function, e.g., by addition) to form the security code (i.e., the result).). Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify Cox’s method of using a mobile wallet application to generate a onetime password, to include the teachings of Akiyama, in order to identify and access a session key from the memory of the user device that corresponds to the generated result (Akiyama Col. 7 lines 29-45; Col. 8 lines 23-39).
Response to Arguments
Claim Rejections – 35 U.S.C. § 101
Applicant's arguments with respect to 35 U.S.C. § 101 (Alice) rejection, have been fully considered were found to be persuasive. Amendment, pp. 8-12. Examiner contends that the claims continue to recite an abstract idea (e.g., collecting and sending authentication and payment information as part of a payment transaction), however Examiner agrees with applicant’s remarks that the additional elements integrate any abstract idea into a practical application. Specifically, the claim is tied to a particular machine, namely an NFC-enabled user terminal operating in card emulation mode, and relies on defined data structures, namely Application Protocol Data Unit (APDU) command and response messages, to carry cryptographic challenges and signatures. By employing these technical features, claim 15 directly addresses the problem of enabling secure offline payment transactions when no server connection to a payment system operator is available.
In view of applicant’s arguments, and the current claim amendments, the 35 U.S.C. 101 rejection in withdrawn.
Claim Rejections – 35 U.S.C. § 103(a)
Applicant indicates that Claim 15 requires a specific cryptographic sequence: (i) the user terminal must receive random data from the point-of-sale (POS) terminal over an NFC protocol connection, (ii) the terminal must sign that random data with a private key of the trust card, and (iii) the terminal must return the resulting signature to the POS over NFC to authorize the transaction. Applicant alleges that neither Cox nor Hammad disclose this sequence. Amendment, pp. 12-13. Examiner respectfully disagrees. Hammad teaches receiving by the user's terminal (i.e., mobile device) data (i.e., a nonce) from the point-of-sale terminal (i.e., from the merchant access device) over the Near Field Communication (NFC) protocol connection (i.e., over the near field communications connection). Hammad [0070]; [0131-0132]; [0142]; Fig. 12 Step P7. Hammad teaches signing by the user's terminal (i.e., by the mobile device) the data (i.e., the nonce) with a private key of the trust card (i.e., with a consumer’s private key) to form a signature. Hammad [0132]; [0135]. Hammad teaches sending, by the user’s terminal (i.e., by the mobile device) over the NFC protocol connection (i.e., over the near field communications connection), the signature (i.e., the signed nonce) to the point-of-sale terminal (i.e., to the merchant access device) to authorize the point-of-sale terminal to perform the payment transaction (i.e., to authorize the merchant access device to process the transaction). Hammad [0070]; [0132]; [0135]; [0142-0143]; [0148]; Fig. 12 Step P13.
Applicant points out (Amendment, p. 13.), and Examiner acknowledges, that Hammad differs from the claimed invention, in part, because the data received, signed and returned in Hammad is not explicitly disclosed as being “random” data. Examiner has added an additional reference, Yeager, to the prior art rejection to teach that it was known in the art to send random data (e.g., a random number) as part of a cryptographic challenge. Yeager [0205-0208]. Examiner also notes that the claimed invention never utilizes the “random data” beyond signing and returning the signed data. The fact that the data is “random” has no effect on how the positively recited steps of receiving, signing, and sending the data are performed. While the claimed invention recites an intended use of the signature/signed data (e.g., to authorize the payment transaction), Applicant is not positively reciting any steps where the random data is used and/or where the signed response is verified (e.g., to ensure that it contains the correct/random data).
Applicant argues that neither Cox nor Hammad discloses signing POS-provided random data with the private key of a trust card. Amendment, p. 13. Examiner respectfully disagrees. Hammad teaches signing by the user's terminal (i.e., by the mobile device) the data (i.e., the nonce) with a private key of the trust card (i.e., with a consumer’s private key) to form a signature. Hammad [0132]; [0135]. Applicant attempts to draw a distinction between the claimed invention and Hammad by stating that Hammad does not involve a “secure element private key”, however the difference identified by applicant is merely a difference in the name of the key. That is, Hammad still receives data from POS, signs the data with a private key, and then returns the signed data to the POS. Simply because applicant calls their private key by a particular name (e.g., private key of a trust card), or by a name different from that of the prior art, will not distinguish the claimed invention from the prior art.
Applicant argues that Neither Cox nor Hammad disclose offline authorization. Amendment, p. 13. Examiner agrees, however it is noted that the amendment pertaining to offline authorization fails to alter how any of the positively recited steps are performed. Examiner notes that neither Cox nor Hammad require an online connection to a server in order to perform the steps recited in the claimed invention. Applicant is not positively reciting any of the authorization steps, rather the claimed invention merely uses the user’s terminal to send signed data back to the POS for the intended use/result of authorizing the payment transaction. The claimed invention is claimed entirely from the perspective of the user’s terminal/apparatus, and the only steps the user’s terminal performs beyond the receiving and sending of data is forming a security code, establishing an NFC connection and signing random data. The claimed invention fails to utilize the security code and it also fails to utilize the signed random data. It is further noted that the newly added Yeager reference discloses that it was known in the art to approve or decline a transaction without consulting an application system or remote processing server (i.e., “where the payment transaction is performed without direct communication of the user's terminal and a point-of-sale terminal with a server of a payment system operator for authorization of the payment transaction”). Yeager [0211].
Applicant argues that the claimed architecture provides technical benefits absent in Cox or Hammad. Amendment, p. 15. This argument is unpersuasive. The claimed invention is largely directed to a user’s device that sends and receives data over a known type of connection (i.e., NFC) using an industry standardized format (i.e., APDU). The claimed invention fails to utilize any of the data it sends or receives beyond the simple step of signing random data with a key. Examiner fails to find any indication that the manner the claimed invention sends, receives and signs data offers any technological benefit.
Applicant argues that “Even if one of skill attempted to combine Cox and Hammad, the resulting system would still depend on server verification.” Amendment, p. 15. This argument is unpersuasive as applicant is arguing features that are not found within the claimed invention. That is, while the claimed invention sends signed data to the POS for the intended use/result of authorizing a transaction, the claimed invention is not positively reciting a step where the POS authorizes the transaction without communicating with the payment server in order to authorize the transaction. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
For the above reasons, and for those set forth in the 35 U.S.C. § 103(a) rejection seen above, all claims remain rejected under 35 U.S.C. § 103(a).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure is cited in the Notice of References Cited (PTO-892). The additional cited art further establishes the state of the art prior to the effective filling date of Applicant’s claimed invention.
Sarkissian et al. (US 2009/0070268 A1) discloses a method for generating a code representative of a currency value according to one embodiment includes generating a first code, and combining a security code with the first code for creating a larger composite code, the composite code being associated with a predetermined currency value. Sarkissian [0003].
Wilson (US 2011/0031310 A1) discloses where random data (i.e., data item, e.g., a transaction-specific message comprising a transaction-specific random data string) is received by the user’s terminal (i.e., computing device, e.g., personal computer and/or mobile telephone) from the point-of-sale terminal (i.e., from the merchant/merchant server, e.g., via the merchant application). Wilson [0024-0026]; [0029-0031]; [0045]; [0066-0068]; [0102]; [0105]; Wilson Claims 45 and 48. Wilson also discloses where the user's terminal signs (i.e., signs, e.g., digitally signs) the random data (i.e., data item, e.g., a transaction-specific message comprising a transaction-specific random data string) with a private key of the trust card (i.e., with a private key associated with a payment card) to form a signature, and sends the signature (i.e., signed data item) to the point-of-sale terminal (i.e., to the merchant/merchant server) to authorize the point-of-sale terminal to perform the payment transaction (i.e., to effect the transaction). Wilson [0024-0026]; [0029-0031]; [0045]; [0066-0068]; [0102]; [0105]; Wilson Claims 45 and 48.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON FENSTERMACHER whose telephone number is (571)270-3511. The examiner can normally be reached Monday - Friday 9:00 AM to 5:30 PM ET, Alternate Fridays Off.
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, Patrick McAtee can be reached at 571-272-7575. 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.
/J.F./Examiner, Art Unit 3698 December 12, 2025
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights