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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on Mar 12, 2026 has been entered.
Status of the Claims
The following is a Non Final Office Action in response to applicant’s amendments filed on
Mar 12, 2026.
Claim 1, 3 and 5 are amended.
Claim 2 is cancelled.
Claims 1 and 3-5 are pending.
Claim Objections
Claims 1 and 5 are objected to because of the following informalities:
Regarding claim 1, the recited “the tokens encoded in UTF-8. UTF-16, or UTF-32 is transmitted…” should be amended to “the tokens encoded in UTF-8. UTF-16, or UTF-32 are transmitted …” as the recitation of “the tokens encoded in UTF-8. UTF-16, or UTF-32 is transmitted …” is grammatically incorrect.
Regarding claim 5, the recited “wherein the sender device is connected to the receiver device via NFC to transmit tokens, and are connected to the token manager…” should be amended to “wherein the sender device is connected to the receiver device via NFC to transmit tokens, and is connected to the token manager…” as the recitation of “wherein the sender device is connected to the receiver device via NFC to transmit tokens, and are connected to the token manager…” is grammatically incorrect.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1 and 5, the claims recite “transmitting, by the token manager, via the internet network, tokens to the sender device” in lines 12 &13 and further recites “…transmitting the tokens to the sender device” on line 26 as part of the “generating” step. It is not clear whether both recitation of transmitting tokens to the send device refer to the same or different transmission step/tokens. Therefore, the claim is indefinite and rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. For the purpose of compact prosecution, Examiner is interpreting both transmitting steps as referring to the same transmission step.
Claims 3-4 are also rejected as they depend from claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Grendon (US 2019/0188704 A1), in view of Li (US 20190340602 A1), in further view of Haque (US 20180300717 A1), in further view of Ikechi (Blockchain Adoption in Rural Area: The role of Internet Penetration, August 2020).
Regarding claim 1, Grendon teaches:
transmitting, by the sender device, coins from (Grendon ¶0020, In the system 100, a sender 104 may want to transfer an amount of currency to a recipient 106 using a trust-based system… The sender 104 may provide the processing server 102 with at least the amount being transferred for retrieval by the recipient 106. In some cases, the sender 104 may also provide a password or other data that will be used in the generation of a digital token to serve as authentication for the recipient 106. Grendon ¶0021, In other cases, the sender 104 may have a computing device, such as a cellular phone, smart phone, smart watch, wearable computing device, implantable computing device, etc., which the sender 104 may use to transmit the password or other data to the processing server 102 via any suitable transmission method ( e.g., Bluetooth, near field communication, local area network, radio frequency, etc.). Grendon ¶0022, In addition to providing the first broker with the transaction amount to be transferred, the sender 104 may also provide payment to the first broker. Payment may be made using any suitable format and method. For instance, the sender 104 may provide cash, a check, a credit card, debit card, or any other suitable payment instrument. In some embodiments, the first broker may be an issuing financial institution that issued a transaction account to the sender 104 that is used for payment of the transaction amount. In such embodiments, the sender 104 may provide the issuing financial institution with the transaction amount and any authentication data, where the issuing financial institution may then debit the appropriate transaction account accordingly. In embodiments where the sender 104 utilizes a computing device and the first broker is an issuing financial institution, the sender 104 may use an electronic wallet application program executed by the computing device that is associated with the issuing financial institution for selection of a transaction account and/or payment of the transaction amount to the first broker. Grendon ¶0049, In step 302, the sender 104 may request a trust based transaction from the processing server 102 (e.g., via an input device 210 interfaced therewith, the sender's computing device, a user of the processing server 102 such as the first broker, etc.). In step 304, the receiving device 202 ( e.g., or input device 210, as applicable) of the processing server 102 may receive a transaction request. The transaction request may include at least a transaction amount, and an identification value associated with the intended recipient broker. Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. See Fig 3, 302)
after performing a mining process in the management device, performing the coin transmission transaction on the blockchain and (Grendon ¶0023, Following submission of the transaction amount, and any additional data, the processing server 102 may generate a digital token. The digital token may be a data value that is unique to the trust-based transaction being conducted between the sender 104 and recipient 106. The digital token may be any type of data value generated using any suitable method. For instance, the digital token may be a public key or private key of a cryptographic key pair generated using a suitable key generation algorithm, or may be a hash value generated via hashing data with a suitable hashing algorithm. For example, in cases where the sender 104 provides data to the processing server 102 for use as a security value, such as a public key or a password, the digital token may be generated via hashing the security value. In some instance, the security value may be combined with additional data, such as a nonce, for additional security. Grendon ¶0051, In step 310, the generation module 222 of the processing server 102 may generate a secure token, also referred to herein as a digital token. ¶0052, In step 318, the transmitting device 224 of the processing server 102 may electronically transmit data suitable for use in a transaction data value in the blockchain to a node 114 using any suitable method. The data may include at least the secure token, a blockchain address associated with the recipient broker system 108 (e.g., included in the transaction request or identified based on data included therein), and the transaction amount. In step 320, the node 114 may receive the data. In step 322, the node 114 may generate the transaction data value and, if applicable, a new block header and block that includes the transaction data value. In step 324, the transaction may be added to the blockchain via the validation and addition of the newly generated block, or the providing of the transaction data value to a different node 114 for inclusion in a newly generated block that is validated and added to the blockchain. See Fig 3, 310-324)
transmitting, by the token manager, via the internet network, tokens to the sender device; (Grendon ¶0024, The processing server 102 may be configured to provide the digital token to the sender 104, such as to the computing device associated with the sender 104. In some embodiments, the digital token may be electronically transmitted by the processing server 102 to the sender's computing device using any suitable method. In other embodiments, the processing server 102 may provide the data used to generate the digital token ( e.g., the security value, nonce, algorithm information) to the sender's computing device, where the sender's computing device may be configured to generate the digital token independently using the provided data. Grendon ¶0051, In step 312, the transmitting device 224 of the processing server 102 may electronically transmit the secure token to the sender 104 (e.g., via a computing device associated therewith). Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. See Fig 3, 312-314)
transmitting, by the sender device, the tokens from the sender device to the receiver device via NFC rather than the Internet network (Grendon ¶0025, Once the sender 104 receives the digital token, the sender 104 is free to provide the digital token to the recipient 106 using any suitable method… In an exemplary embodiment, the sender 104 may use a computing device to electronically transmit the digital token ( e.g., or data used in the generation thereof) to the recipient 106 via a computing device thereof in an encrypted format. Grendon ¶0051, in step 316, may transmit the token to the recipient 106 (e.g., via computing devices associated with each customer) using any suitable method. In an exemplary embodiment, the secure token may be encrypted prior to transmission to the recipient 106. ¶0036, In some instances, the receiving device 202 may be configured to receive data from sender and recipient computing devices, recipient broker systems 108, other processing servers 102, nodes 114, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc. )
transmitting, by the receiver device, the tokens to the token manager via the internet network, and (Grendon ¶0019, As any broker in a trust-based system may both accept and distribute funds, the processing server 102 may be configured to perform the functions of both a sender broker and a recipient broker with respect to the systems and methods as discussed herein. Grendon ¶0055, In step 414, the recipient 106 may request payment from the recipient broker system 108, which may include electronically transmitting the secure token, and any other necessary data, to the recipient broker system 108 using any suitable method. In step 416, the recipient broker system 108 may receive the payment request. Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art.)
performing the mining process, and then transmitting the coins to an (Grendon ¶0056, In step 418, the recipient broker system 108 may verify the secure token supplied by the recipient 106. The verification may include a comparison of the secure token provided by the recipient 106 with the secure token stored in the corresponding transaction data value added to the blockchain. In cases where the sender broker provided its own secure token, the verification may further include a comparison of the secure token provided by the recipient 106 to the sender broker's secure token. If the secure token is verified (e.g., it matches the other secure tokens), then, in step 420, the recipient broker system 108 (e.g., or the recipient broker depending on payment method) may process payment of the transaction amount stored in the transaction data value to the recipient 106. Grendon ¶0062, the payment data may include at least a primary account number, and processing the payment for the transaction may include electronically transmitting, by the transmitting device of the processing server, a transaction message including at least the primary account number and transaction amount for a payment transaction to a payment network, and receiving, by the receiving device of the processing server, an authorization response for the payment transaction indicating approval of the payment transaction.)
generating, by the token manager of the management device, the tokens by combining sender address and transaction hash information after receiving the coins from the sender device, and (¶0051, In step 310, the generation module 222 of the processing server 102 may generate a secure token, also referred to herein as a digital token. The generation module 222 may use any suitable method for the generation of the secure token. In cases where the transaction request includes a password or other security value, the secure token may use such a value in the generation thereof. ¶0059, In step 508, a digital token may be generated by a generation module ( e.g., the generation module 222) of the processing server, wherein the digital token is unique to the proposed trustbased transaction.)
transmitting the tokens to the sender device (Grendon ¶0024, The processing server 102 may be configured to provide the digital token to the sender 104, such as to the computing device associated with the sender 104. In some embodiments, the digital token may be electronically transmitted by the processing server 102 to the sender's computing device using any suitable method. In other embodiments, the processing server 102 may provide the data used to generate the digital token ( e.g., the security value, nonce, algorithm information) to the sender's computing device, where the sender's computing device may be configured to generate the digital token independently using the provided data. Grendon ¶0051, In step 312, the transmitting device 224 of the processing server 102 may electronically transmit the secure token to the sender 104 (e.g., via a computing device associated therewith). Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. See Fig 3, 312-314)
Grendon does not explicitly disclose an encrypted coin account, i.e., that the coin account is encrypted, however Grendon does describe encryption techniques that are commonly used to secure digital assets and user data. (Grendon ¶0005, The digital token, or data used to generate the token, is encrypted and exchanged between customers and brokers, where only the second customer and second broker, as authorized parties, are able to decrypt and generate the correct digital token.)
Given that the method is well-known for protecting sensitive information, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the account in Grendon’s invention by encrypting it applying the encryption techniques disclose on Grendon’s invention in order to provide a more secure account.
Grendon does not disclose, however Li teaches:
wherein transmitting the tokens from the sender device to the receiver device includes: the sender device initiating a handshake, the receiver device sending an acknowledgment and approval, (¶0024, In response to detecting the NFC signal, the NFC controller 113 of the portable device 110 may launch or activate the APP 112. In step 302, handshake may next take place between the portable device 110 and the POS 100 to establish an NFC connection. In one embodiment, the portable device 110 may transmit a hello message to the POS 100. The hello message can be any combination of greeting, capabilities, characteristics, certificate or handshake signal that can be used to facilitate the NFC connection session. Following establishment of the NFC connection session, the portable device 110 and the POS device 100 may communicate further. ¶0027, The user A's portable device 110 then emits NFC signals to seek out other nearby NFC-enabled device. When the user B's portable device 110 detects the NFC signal radiated by the user A's portable device 110, the NFC controller 113 of the user B's portable device 110 may launch or activate the APP 112, and then the establishment of the NFC connection in step 702 may begin with an initiation handshake. The user A's portable device 110 and the user B's portable device 110 may exchange device profiles, as in step 702. The device profiles may include a variety of information regarding the capabilities of the user A's portable device 110 and the user B's portable device 110.)
the receiver device transmitting a token amount to the sender device, (¶0027, Thus, in step 704, the user A's portable device 110 sends a transfer request to the user B's portable device 110. The transfer request represents a request from the user A's portable device 110 to the user B's portable device 110 to transfer at least one reward point between the user A's account and the user B's account of one specific vendor. The transfer request may also indicate the amount of reward points transferred.)
the sender device confirming the token amount, (¶0027, Then the user A's portable device 110 may receive an approval from the user B's portable device 110 as in step 706. In one embodiment, the user A's portable device 110 and the user B's portable device 110 may also exchange information related to their respective accounts as in steps 704 and 706.)
wherein when transmitting the tokens from the sender device to the receiver device, the tokens encoded in UTF-8, UTF-16, or UTF-32 is transmitted using NFC and NFC provides secure on-demand access through an NFC based host card emulation (HCE) function when transmitting the tokens. (¶0020, To transfer data between the portable device 110 and the POS 100, the data is represented based on a well-defined NFC format called NFC Data Exchange Format (NDEF). ¶0021, FIG. 2 illustrates format of an NDEF message Tag Length Value (TLV) data 200. The NDEF message TLV data 200 may comprise the NDEF message. The NDEF message TLV data 200 may comprise flags that indicate the start and stop of data. For example, type field value 0x03 provides the starting point, value of length field is equal to the size in bytes of the NDEF message, value field stores the NDEF message, and a terminator TLV with type field value equal to 0xEF indicates the last TLV block of data. The NDEF message may comprise a plurality of records. FIG. 2 shows three records, i.e. record 1, record 2, and record 3. The NDEF message is a binary message format designed to encapsulate application-defined payloads into a single message construct. Each NDEF message may comprise a sequence of records with each record consisting of at least two parts, a header 201 and payload data 202. The header 201 may comprise data representing a wide variety of address, control, and similar information, such as for example, an identifier field 203, a length field 204, and a type field 205. The identifier field 203 is an optional field, which may allow applications to identify payload carried within any specific NDEF record. In one embodiment, the identifier field 203 may comprise five-bit flags and a three-bit Type Name Form (TNF) field 207. Each bit of the flags can indicate the specific information associated with the context data, and the TNF field value indicates the format of the type field 205 value. Value in the length field 204 indicates length of the payload that is encapsulated in a record. In one embodiment, the length field 204 may further comprise the type length field 208 and the payload length field 209. Value in the type length field 208 indicates length of the type field 205, and value in the payload length field 209 indicates length of the payload data 202. The length of the payload data 202 may be one byte for short records and may be four bytes for normal records. Value in the type field 205 indicates type of data being carried in the payload data 202. The type information may be used by the receiving application to decide processing mechanism to be adopted.)
the receiver device removing, from the sender device, the tokens sent from the sender devic(¶0027, Upon successfully completing the transfer request, the user A's portable device 110 may inform the backend server 120 about the amount of reward points transferred, the updated balance amount, and the user B's information. Accordingly, the backend server 120 may subtract the amount of reward points from the user A's account and deliver the amount of reward points to the user B's account. The NFC connection can then be terminated as in step 710.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the teaching of Grendon by incorporating Li’s teaching. One of ordinary skills in the art would have been motivated in order to enhance the system security by ensuring the sender and receiver are both aware and agree to the transfer conditions before transferring the token.
The combination of Grendon and Li do not disclose, however Haque teaches:
the sender device transmitting the tokens, (Haque ¶0027, At block 208, a copy of the token may be sent from the first device 102 to the second device 130, for example via a wireless connection such as Bluetooth or near field communication (NFC) protocol. WiFi, Zigbee, or any of a number of other wireless connections may be used, but if higher power implementations of these networks are used, the associated longer range of the connection may increase the risk of eavesdropping.)
the receiver device confirming a value and authority of the tokens, (Haque ¶0028, In an embodiment, the token may be or include a certificate, such as an X.509 compliant certificate that includes the public key of the authority 100 and/or a confirmation reference. At block 212, the second device 130 may confirm the payload, for example, by the use of a simple checksum or by comparing some or all of the payload to a known, expected value.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Grendon and Li by incorporating Haque’s teaching. One of ordinary skills in the art would have been motivated in order to ensure that the token is valid and meets the transfer conditions prior to completing the transaction.
The combination of Grendon, Li and Haque do not disclose, however Ikechi teaches:
within a specific time after receiving the tokens from the token manager via the internet network (P.3 col 2, The use of token: In this process a token is generated using internet connection. The generated token can then be used during an offline period (without connection to Internet) and the token can then be retrieved in the presence of an internet connection. With this method, blockchain transactions can still be done without instant connection to the Internet. see Fig 3.)
wherein the receiver device can transmit the tokens only to the token manager, (P.3 Fig 3. The architecture shows that the receiver can only transmit the tokens to the token manager.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Grendon, Li and Haque by incorporating Ikechi’s teaching. One of ordinary skills in the art would have been motivated in order to enhance transaction security, prevent unauthorized transfers and allow a trusted entity (i.e. toke manager) to control the verification and payment of the transfer transaction.
Regarding claim 5, Grendon discloses:
a sender device and a receiver device each equipped with near field communication (NFC) and capable of accessing an internet network; and (¶0021, In other cases, the sender 104 may have a computing device, such as a cellular phone, smart phone, smart watch, wearable computing device, implantable computing device, etc., which the sender 104 may use to transmit the password or other data to the processing server 102 via any suitable transmission method ( e.g., Bluetooth, near field communication, local area network, radio frequency, etc.) ¶0031, The recipient 106 may provide the recipient broker (e.g., through the recipient broker system 108) with their digital token. For instance, the recipient 106 may use a computing device to electronically transmit the digital token to the recipient broker system 108 using any suitable method, such as near field communication, Bluetooth, radio frequency, etc. ¶0036, The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some instances, the receiving device 202 may be configured to receive data from sender and recipient computing devices, recipient broker systems 108, other processing servers 102, nodes 114, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc.)
a management device that includes a token manager having a process for converting crypto coins and offline shared tokens, the management device being connected to the sender device and the receiver device via the internet network, wherein (¶0036, The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some instances, the receiving device 202 may be configured to receive data from sender and recipient computing devices, recipient broker systems 108, other processing servers 102, nodes 114, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc.)
the sender device is connected to the receiver device via NFC to transmit tokens, and are connected to the token manager via the internet network, to transmit coins to the token manager, and receive tokens from the token manager to transmit the tokens to the receiver device via NFC, wherein (¶0021, In other cases, the sender 104 may have a computing device, such as a cellular phone, smart phone, smart watch, wearable computing device, implantable computing device, etc., which the sender 104 may use to transmit the password or other data to the processing server 102 via any suitable transmission method ( e.g., Bluetooth, near field communication, local area network, radio frequency, etc.) ¶0036, The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some instances, the receiving device 202 may be configured to receive data from sender and recipient computing devices, recipient broker systems 108, other processing servers 102, nodes 114, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc.)
the receiver device receives tokens from the sender device via NFC and (Grendon ¶0025, Once the sender 104 receives the digital token, the sender 104 is free to provide the digital token to the recipient 106 using any suitable method… In an exemplary embodiment, the sender 104 may use a computing device to electronically transmit the digital token ( e.g., or data used in the generation thereof) to the recipient 106 via a computing device thereof in an encrypted format. Grendon ¶0051, in step 316, may transmit the token to the recipient 106 (e.g., via computing devices associated with each customer) using any suitable method. In an exemplary embodiment, the secure token may be encrypted prior to transmission to the recipient 106. ¶0036, In some instances, the receiving device 202 may be configured to receive data from sender and recipient computing devices, recipient broker systems 108, other processing servers 102, nodes 114, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc. )
transmits the tokens to the token manager via the internet network, and (Grendon ¶0019, As any broker in a trust-based system may both accept and distribute funds, the processing server 102 may be configured to perform the functions of both a sender broker and a recipient broker with respect to the systems and methods as discussed herein. Grendon ¶0055, In step 414, the recipient 106 may request payment from the recipient broker system 108, which may include electronically transmitting the secure token, and any other necessary data, to the recipient broker system 108 using any suitable method. In step 416, the recipient broker system 108 may receive the payment request. Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art.)
receives coins from the token manager; wherein (Grendon ¶0056, In step 418, the recipient broker system 108 may verify the secure token supplied by the recipient 106. The verification may include a comparison of the secure token provided by the recipient 106 with the secure token stored in the corresponding transaction data value added to the blockchain. In cases where the sender broker provided its own secure token, the verification may further include a comparison of the secure token provided by the recipient 106 to the sender broker's secure token. If the secure token is verified (e.g., it matches the other secure tokens), then, in step 420, the recipient broker system 108 (e.g., or the recipient broker depending on payment method) may process payment of the transaction amount stored in the transaction data value to the recipient 106. Grendon ¶0062, the payment data may include at least a primary account number, and processing the payment for the transaction may include electronically transmitting, by the transmitting device of the processing server, a transaction message including at least the primary account number and transaction amount for a payment transaction to a payment network, and receiving, by the receiving device of the processing server, an authorization response for the payment transaction indicating approval of the payment transaction.)
the token manager receives coins from the sender device, (Grendon ¶0020, In the system 100, a sender 104 may want to transfer an amount of currency to a recipient 106 using a trust-based system… The sender 104 may provide the processing server 102 with at least the amount being transferred for retrieval by the recipient 106. In some cases, the sender 104 may also provide a password or other data that will be used in the generation of a digital token to serve as authentication for the recipient 106. Grendon ¶0021, In other cases, the sender 104 may have a computing device, such as a cellular phone, smart phone, smart watch, wearable computing device, implantable computing device, etc., which the sender 104 may use to transmit the password or other data to the processing server 102 via any suitable transmission method ( e.g., Bluetooth, near field communication, local area network, radio frequency, etc.). Grendon ¶0022, In addition to providing the first broker with the transaction amount to be transferred, the sender 104 may also provide payment to the first broker. Payment may be made using any suitable format and method. For instance, the sender 104 may provide cash, a check, a credit card, debit card, or any other suitable payment instrument. In some embodiments, the first broker may be an issuing financial institution that issued a transaction account to the sender 104 that is used for payment of the transaction amount. In such embodiments, the sender 104 may provide the issuing financial institution with the transaction amount and any authentication data, where the issuing financial institution may then debit the appropriate transaction account accordingly. In embodiments where the sender 104 utilizes a computing device and the first broker is an issuing financial institution, the sender 104 may use an electronic wallet application program executed by the computing device that is associated with the issuing financial institution for selection of a transaction account and/or payment of the transaction amount to the first broker. Grendon ¶0049, In step 302, the sender 104 may request a trust based transaction from the processing server 102 (e.g., via an input device 210 interfaced therewith, the sender's computing device, a user of the processing server 102 such as the first broker, etc.). In step 304, the receiving device 202 ( e.g., or input device 210, as applicable) of the processing server 102 may receive a transaction request. The transaction request may include at least a transaction amount, and an identification value associated with the intended recipient broker. Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. See Fig 3, 302)
performs a mining process, and then (Grendon ¶0023, Following submission of the transaction amount, and any additional data, the processing server 102 may generate a digital token. The digital token may be a data value that is unique to the trust-based transaction being conducted between the sender 104 and recipient 106. The digital token may be any type of data value generated using any suitable method. For instance, the digital token may be a public key or private key of a cryptographic key pair generated using a suitable key generation algorithm, or may be a hash value generated via hashing data with a suitable hashing algorithm. For example, in cases where the sender 104 provides data to the processing server 102 for use as a security value, such as a public key or a password, the digital token may be generated via hashing the security value. In some instance, the security value may be combined with additional data, such as a nonce, for additional security. Grendon ¶0051, In step 310, the generation module 222 of the processing server 102 may generate a secure token, also referred to herein as a digital token. ¶0052, In step 318, the transmitting device 224 of the processing server 102 may electronically transmit data suitable for use in a transaction data value in the blockchain to a node 114 using any suitable method. The data may include at least the secure token, a blockchain address associated with the recipient broker system 108 (e.g., included in the transaction request or identified based on data included therein), and the transaction amount. In step 320, the node 114 may receive the data. In step 322, the node 114 may generate the transaction data value and, if applicable, a new block header and block that includes the transaction data value. In step 324, the transaction may be added to the blockchain via the validation and addition of the newly generated block, or the providing of the transaction data value to a different node 114 for inclusion in a newly generated block that is validated and added to the blockchain. See Fig 3, 310-324)
transmits tokens to the sender device, and (Grendon ¶0024, The processing server 102 may be configured to provide the digital token to the sender 104, such as to the computing device associated with the sender 104. In some embodiments, the digital token may be electronically transmitted by the processing server 102 to the sender's computing device using any suitable method. In other embodiments, the processing server 102 may provide the data used to generate the digital token ( e.g., the security value, nonce, algorithm information) to the sender's computing device, where the sender's computing device may be configured to generate the digital token independently using the provided data. Grendon ¶0051, In step 312, the transmitting device 224 of the processing server 102 may electronically transmit the secure token to the sender 104 (e.g., via a computing device associated therewith). Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. See Fig 3, 312-314)
receives the tokens from the receiver device and transmits coins, wherein (Grendon ¶0019, As any broker in a trust-based system may both accept and distribute funds, the processing server 102 may be configured to perform the functions of both a sender broker and a recipient broker with respect to the systems and methods as discussed herein. Grendon ¶0055, In step 414, the recipient 106 may request payment from the recipient broker system 108, which may include electronically transmitting the secure token, and any other necessary data, to the recipient broker system 108 using any suitable method. In step 416, the recipient broker system 108 may receive the payment request. Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art.)
after receiving coins from the sender device, the token manager generates tokens by combining a sender address and transaction hash information, and (¶0051, In step 310, the generation module 222 of the processing server 102 may generate a secure token, also referred to herein as a digital token. The generation module 222 may use any suitable method for the generation of the secure token. In cases where the transaction request includes a password or other security value, the secure token may use such a value in the generation thereof. ¶0059, In step 508, a digital token may be generated by a generation module ( e.g., the generation module 222) of the processing server, wherein the digital token is unique to the proposed trustbased transaction.)
transmits the tokens to the sender device, wherein (Grendon ¶0024, The processing server 102 may be configured to provide the digital token to the sender 104, such as to the computing device associated with the sender 104. In some embodiments, the digital token may be electronically transmitted by the processing server 102 to the sender's computing device using any suitable method. In other embodiments, the processing server 102 may provide the data used to generate the digital token ( e.g., the security value, nonce, algorithm information) to the sender's computing device, where the sender's computing device may be configured to generate the digital token independently using the provided data. Grendon ¶0051, In step 312, the transmitting device 224 of the processing server 102 may electronically transmit the secure token to the sender 104 (e.g., via a computing device associated therewith). Grendon ¶0067, The network may be any network suitable for performing the functions as disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. See Fig 3, 312-314)
Grendon does not disclose, however Li teaches:
when transmitting tokens from the sender device to the receiver device, the sender device initiates a handshake, the receiver device sends an acknowledgment and approval, (¶0024, In response to detecting the NFC signal, the NFC controller 113 of the portable device 110 may launch or activate the APP 112. In step 302, handshake may next take place between the portable device 110 and the POS 100 to establish an NFC connection. In one embodiment, the portable device 110 may transmit a hello message to the POS 100. The hello message can be any combination of greeting, capabilities, characteristics, certificate or handshake signal that can be used to facilitate the NFC connection session. Following establishment of the NFC connection session, the portable device 110 and the POS device 100 may communicate further. ¶0027, The user A's portable device 110 then emits NFC signals to seek out other nearby NFC-enabled device. When the user B's portable device 110 detects the NFC signal radiated by the user A's portable device 110, the NFC controller 113 of the user B's portable device 110 may launch or activate the APP 112, and then the establishment of the NFC connection in step 702 may begin with an initiation handshake. The user A's portable device 110 and the user B's portable device 110 may exchange device profiles, as in step 702. The device profiles may include a variety of information regarding the capabilities of the user A's portable device 110 and the user B's portable device 110.)
the receiver device transmits a token amount to the sender device, (¶0027, Thus, in step 704, the user A's portable device 110 sends a transfer request to the user B's portable device 110. The transfer request represents a request from the user A's portable device 110 to the user B's portable device 110 to transfer at least one reward point between the user A's account and the user B's account of one specific vendor. The transfer request may also indicate the amount of reward points transferred.)
the sender device confirms the token amount, (¶0027, Then the user A's portable device 110 may receive an approval from the user B's portable device 110 as in step 706. In one embodiment, the user A's portable device 110 and the user B's portable device 110 may also exchange information related to their respective accounts as in steps 704 and 706.)
the receiver device removes, from the sender device, the tokens sent from the sender device, and the receiver device confirms receipt and ends the transaction. (¶0027, Upon successfully completing the transfer request, the user A's portable device 110 may inform the backend server 120 about the amount of reward points transferred, the updated balance amount, and the user B's information. Accordingly, the backend server 120 may subtract the amount of reward points from the user A's account and deliver the amount of reward points to the user B's account. The NFC connection can then be terminated as in step 710.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the teaching of Grendon by incorporating Li’s teaching. One of ordinary skills in the art would have been motivated in order to enhance the system security by ensuring the sender and receiver are both aware and agree to the transfer conditions before transferring the token.
The combination of Grendon and Li do not disclose, however Haque teaches:
the sender device transmits the tokens, (Haque ¶0027, At block 208, a copy of the token may be sent from the first device 102 to the second device 130, for example via a wireless connection such as Bluetooth or near field communication (NFC) protocol. WiFi, Zigbee, or any of a number of other wireless connections may be used, but if higher power implementations of these networks are used, the associated longer range of the connection may increase the risk of eavesdropping.)
the receiver device confirms a value and authority of the token, (Haque ¶0028, In an embodiment, the token may be or include a certificate, such as an X.509 compliant certificate that includes the public key of the authority 100 and/or a confirmation reference. At block 212, the second device 130 may confirm the payload, for example, by the use of a simple checksum or by comparing some or all of the payload to a known, expected value.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Grendon and Li by incorporating Haque’s teaching. One of ordinary skills in the art would have been motivated in order to ensure that the token is valid and meets the transfer conditions prior to completing the transaction.
The combination of Grendon, Li and Haque do not disclose, however Ikechi teaches:
the sender device must transmit the tokens to the receiver device within a specific time after receiving the tokens from the token manager, (P.3 col 2, The use of token: In this process a token is generated using internet connection. The generated token can then be used during an offline period (without connection to Internet) and the token can then be retrieved in the presence of an internet connection. With this method, blockchain transactions can still be done without instant connection to the Internet. see Fig 3.)
the tokens transmitted by the receiver device can be transmitted only to the token manager, and wherein (P.3 Fig 3. The architecture shows that the receiver can only transmit the tokens to the token manager.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Grendon, Li and Haque by incorporating Ikechi’s teaching. One of ordinary skills in the art would have been motivated in order to enhance transaction security, prevent unauthorized transfers and allow a trusted entity (i.e. toke manager) to control the verification and payment of the transfer transaction.
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Grendon, Li, Haque and Ikechi as applied to claim 1 above, in further view of Park (KR 20210025303 A).
Regarding claim 3, the combination of Grendon, Li, Haque and Ikechi do not disclose, however Park teaches:
the receiver device is given a predetermined first time (Tr) to claim the value of the tokens, and if the sender device does not transmit the tokens within the predetermined second time (Ts), after a predetermined third time (Tt), unclaimed coins are returned to the encrypted coin account of the sender. (Park Page 4 ¶14, When the first token is not used within a predetermined deadline or when the first token is not switched to the second token, the platform providing server 130 May dissipate at least a portion of the first token issued to each of the account of the customer terminal 110 and the account of the delivery article terminal 120. Park Page 5 ¶12, The token issue-unit 220 May receive the first token from the platform providing server 130 to the account of the customer terminal 110 based on the provided platform activity. Here, when the first token issued to the account of the customer terminal 110 is not used within a predetermined deadline (for example, one year) or when the first token is not exchanged with the second token, at least part of the first token may disappear. Park Page 10 ¶4, When the first token is not used within a predetermined deadline (e.g. year 1) or when the first token is not switched to the second token, the token management unit 1230 May dissipate at least a portion of the first token issued to each of the account of the customer terminal 110 and the account of the delivery article terminal 120.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Grendon, Li, Haque and Ikechi by incorporating Park’s teaching. One of ordinary skills in the art would have been motivated in order to ensure transaction efficiency by making sure that unused tokens are properly processed and returned to the sender.
Further, the claimed limitation “if the sender device does not transmit the tokens within the predetermined second time (Ts), after a predetermined third time (Tt), unclaimed coins are returned to the encrypted coin account of the sender.” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Regarding claim 4, the combination of Grendon, Li, Haque and Ikechi do not disclose, however Park teaches:
the token manager completes all transactions related to the tokens created during one coin-token conversion, and then returns the balance of unused tokens to the encrypted coin account of the sender. (Park Page 1 ¶6, An objective of the present invention is to provide a server, a customer terminal, and a delivery article terminal for providing a platform for delivery of an item to exchange a first token with a second token that can be used like general currency, to pay a delivery fee of the item to the customer, and to use the first token in a promotion for delivery of the item to the delivery article. Park Page 4 ¶2, The customer terminal 110 May request the platform providing server 130 to exchange the first token with the second token, and may receive the exchanged second token from the platform providing server 130… The platform providing server 130 May receive a request for an exchange from the customer terminal 110 and the delivery article terminal 120 to the second token of the first token, and may pay the exchanged second token to the account of the customer terminal 110 and the account of the delivery article terminal 120, respectively. Park Page 5 ¶6, That is, the subtraction amount according to the type of the delivery accident recorded in the smart contract is subtracted from the deposit, so that the ownership of the remaining first token may be changed to the account of the delivery article terminal 120. Park Page 10 ¶2, Equation 1 is configured to have a structure in which about 40% of the hold-out of the first token that is to be discounted from among the second tokens prepared for every month is distributed in a constant-divided manner according to the aggregate of all tokens through the conversion application. Here, if the overall profit of the delivery platform increases, the reward may also be increased to the first token, so that the participants of the delivery platform may hold the first token and induce active participation in order to activate it. Park Page 10 ¶3, The token management unit 1230 May receive a request for an exchange from the customer terminal 110 and the delivery article terminal 120 to the second token of the first token, and may pay the exchanged second token to the account of the customer terminal 110 and the account of the delivery article terminal 120, respectively.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Grendon, Li, Haque and Ikechi by incorporating Park’s teaching. One of ordinary skills in the art would have been motivated in order to improve efficiency, security and user experience by returning any unused token balance to the sender after all conversions are processed.
Response to arguments
Claim Objections
Claim objections in the previous final action dated 09/22/2025 are withdrawn in light of the
claim amendments.
Claim Rejections – 35 U.S.C. § 112
Claim rejections 35 U.S.C. § 112 in the previous final action dated 09/22/2025 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 103
The applicant presents several arguments with respect to claim rejections 35 U.S.C. § 103 in the previous final action dated 09/22/2025.
First, the applicant asserts that the claim invention employs different communication networks for different legs of the transaction (i.e. internet communication between the token manager and the sender/receiver devices and NFC for the communication between the sender and the receiver devices). The applicant further argues that Grendon employs an opposite communication architecture in which the sender communicates through NFC with the processing device and the recipient can use both the internet and short range communication interchangeably. The applicant further states that the transaction in Grendon operates online and does not presuppose any face to face meeting between the parties. The examiner has carefully considered the above arguments/assertions and respectfully disagrees. Grendon explicitly states that the receiving device of the processing server (i.e. token manager) may receive data from the receiver and/or sender device via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc. (¶0036). Further, Grendon does teach that the recipient can communicate via different communication methods which is exactly what is required on the instant claim. As recited the claim recites that the recipient device communicates with the sender device via NFC and with the token manager via internet. Therefore, the claim broadly teaches a recipient device capable of using either communication methods (i.e. internet or NFC) interchangeably or selectively based on the transaction. Furthermore, even though the art does not explicitly mention any face to face meeting between participants, the ability of the participants to perform transactions via short range communication or NFC implies that the parties must be within close proximity as short range communication technologies operate only when the devices are within a short range.
Second, the applicant argues that in the instant claims token manager cannot directly send tokens to the receiver device and only the sender device can send tokens to the receiver device. In contract, in Grendon, both the sender and the processing server can send tokens to the recipient. The examiner has carefully considered the above arguments/assertions and respectfully disagrees. The instant claims does not restrict the receiver device to receive tokens exclusively from the sender device and does not prevent it from being configured to receive tokens from other devices or sources outside of the recited “sender”.
Third, the applicant asserts that the receiver device can only send tokens to the token manager and the prior art employs a dual transaction structure where the receiver sends tokens to a processing server (i.e. token manger) and a broker system. The applicant further states that the examiner acknowledges that “that Grendon's receiver (106) transacts through the broker system (108), and suggests this arrangement would be a simple modification for one of ordinary skill, the claimed invention achieves transaction safety without any broker system.” The examiner has carefully considered the above arguments/assertions and respectfully disagrees. Grendon does not recite the receiver device sending tokens to two different entities (i.e. processor and broker) instead ¶0031 recites the receiver device sending tokens to the broker 108. Further, Grendon on ¶0019 states that “the processing server 102 may be configured to perform the functions of both a sender broker and a recipient broker with respect to the systems and methods as discussed herein.” Therefore, the disclosure of Grendon means that the processor and the broker are not necessarily two separate entities but it could be one single entity. As a result all tokens transmitted from the receiver can ultimately be handled by a single entity (i.e. token manager) meeting the claim limitation that “the receiver device can transmit tokens only to the token manager”. Furthermore, applicant’s assertion regarding the alleged examiner acknowledgement above is not supported by the record. At no point the examiner has acknowledged “that Grendon's receiver (106) transacts through the broker system (108), and suggests this arrangement would be a simple modification for one of ordinary skill, the claimed invention achieves transaction safety without any broker system”. Rather, the examiner has simply examined the prior art and explained how the art teaches the claim limitations under the broadest reasonable interpretation. Therefore, applicants assertion is based on a mischaracterization of the examiner’s position.
Fourth, applicant’s arguments presented with respect to Kurani have been considered but are moot because the new ground of rejection does not rely on this reference.
Finally, the applicant asserts that “one of ordinary skill in the art would not have been motivated to combine the five cited references to arrive at the claimed invention” and that “this integrated architecture represents a synergistic solution to the problem of enabling offline cryptocurrency transactions that cannot be derived from a piecemeal combination of the cited references, each of which addresses a different problem in a different technological context”. The examiner has carefully considered the applicant’s assertions above and respectfully disagrees. References do not need to address the same exact problem to be combined. The cited references are in the same general field and teach complementary features that can be predictably combined. The rejection is based on using known techniques together to achieve expected results and not on an improper piecemeal combination of cited references as asserted by the applicant.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 2018/0032977 A1 to Samel et el. discloses: A method and system for transferring funds from a sender account to a receiver account, comprising: generating a token in one of a sender device or a receiver device, the token comprising data of either the sender account or the receiver account; transmitting, to the other of the sender device or the receiver device, the token for inclusion of data of the other of the sender account or the receiver account, wherein the transmission of the token occurs in response to the sender device being in proximity to the receiver device; including, into the token, data of the other of the sender account and the receiver account; and forwarding the token to a payment network system administering the transfer of funds from the sender account to the receiver account.
US 2020/0396065 A1 to Gutierrez-Sheris discloses: An improved electronic system implements and applies different types of Fitness Gradient Consensus methodologies, including hash distance and bucket consensus variations within a digital blockchain by calculating the highest fitness value among competing blocks or blockchain segments in order to resolve conflicts and allocate the rewards associated with building new blocks. The improved consensus system applies conflict resolution formulas to incentivize every block-building node in a blockchain network to share every block it generates, as soon as it completes construction, in order to improve chances of a reward, resulting in enhanced blockchain speed and security. The hash distance consensus utilizes a hash distance scalar value as part of its fitness metric, and the bucket consensus assigns tokens to buckets and calculates an aggregate value of the assigned tokens as part of the consensus. A trust-butverify variant increases transactional throughput and reduces linearity and other computational constraints. The system also utilizes novel record types, such as token genesis, transfer, transaction, trade order, settlement, proposition, determination, and pattern linkage records to facilitate the automation of financial, commercial and legal processes.
US 2020/0074464 A1 to Trevethan discloses: There may be provided a computer-implemented method. It may be implemented using a blockchain network such as, for example, the Bitcoin network. The computer-implemented method includes: i) attaching a digital asset of a first party to an exchange platform by: a) computing a first shared key associated with the digital asset using a key of the first party and a first key of the exchange platform; and b) depositing the digital asset to a blockchain network by: 1) generating a funding transaction payable to any party from the digital asset using the first shared key; and 2) broadcasting the funding transaction to the blockchain network; and ii) reassociating the digital asset from the first party to the second party by: a) computing a second key of the exchange platform using a key of the second party such that: 1) the key of the first party becomes invalid; and 2) a second shared key associated with the digital asset that is computed from the key of the second party and the second key of the exchange platform is equal to the first shared key associated with the digital asset; and b) replacing the first key of the exchange platform with a second key of the exchange platform.
US 20090192935 A1 to Griffin et al. discloses: A one step method for transferring money from a sender to a recipient includes entering information relating to the transfer into a near field communication (NFC) enabled data communication device of the sender and then placing the sender's device in close proximity to a NFC enabled data communication device of the recipient. The sender's device is operable when placed in contact with or close proximity to the recipient's device to 1) establish an NFC link between the two devices, 2) gather information relating to the recipient from the recipient's device via the NFC link, and 3) transmit the information relating to the transfer and the recipient to a third party service provider via another network, such as the Internet, and thereby cause the service provider to transfer the money from a funding account of the sender to a receiving account of the recipient.
US 20120101944 A1 to Lin et al. discloses: Various techniques are provided for the gifting between multiple electronic devices of media content provided by an online digital media provider. An offer and acceptance of a selected gift file is accomplished between a gifter device and a receiving giftee device using a near-field communication (NFC) connection. If a connection to the online provider is available, the gifter device may transmit a gift request by which the gifter's account is charged for the gift file. Thereafter, a gift file created using DRM keys associated with the giftee's account may be downloaded to the giftee device. If a network connection is unavailable, the giftee device may transfer a locked gift file and a corresponding gift license to the giftee device using a peer-to-peer connection. The giftee device may authenticate the license and unlock the gift file once a connection to the online provider is available.
US 20130311313 A1 to Laracey discloses: Embodiments of the present invention relate to systems, methods, processes, computer program code, and means for employing the near field communication ("NFC") functionality of mobile devices for use in payment transactions.
US 20160224977 A1 to Sabba et al. discloses: Embodiments are directed to a method comprising, obtaining, by a first device, a first token, the first token associated with an amount of funds and a funds availability starting date. After the first token is obtained by the first device, the first device generates a second token linked to the first token and second token generation data. The second token generation data may include evidence that the second token was generated by the first device, and not another device. The second token generation data could be a first device identifier and the second token generation details, or could be a hashed value of the first device identifier and the second token generation details. The method also includes provisioning, by the first device, the second token and the second token generation data to the second device.
US 20160381010 A1 to Bhandari et al. discloses: A system is configured for detecting a point of sale, receiving a personal identification number (PIN), generating a PIN based key using a message digest of the PIN, decrypting a data encryption key (DEK) using the PIN based key, and generating a DEK based dynamic key using the PIN based key. The system may also decrypt a session key using the DEK based dynamic key, generate a cryptogram from the session key, and send the cryptogram to the point of sale.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached on (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.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights