DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 01/21/2026.
In the instant Amendment: Claims 1, 2, 3, 5, 6-11, 13-15, 17, 19 have been amended, claims 4, 12, 18, 20 have been cancelled, claims 21-23 newly added. Claims 1-3, 5-11, 13-17, 19, 21-23 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants' arguments in the instant Amendment, filed on 01/21/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: Tax, Sundararajan and Rand fail to disclose “wherein the data descriptor is encoded in a terse format to fit within a specific descriptor length, wherein the information includes a sender identifier” and “decoding the data descriptor using terse coding” of amended claim 1. See Remarks at 12.
The examiner respectfully disagrees because these arguments are not persuasive.
With respect to the “encoding” and “decoding” of data descriptors, the Specification ¶¶ [0034], [0039] explain that “[i]n an embodiment, the data descriptor may be encoded in a terse format to fit within a specific descriptor length (e.g., 22 characters)… in some embodiments, the data descriptor may be encoded in a terse format to fit within a specific descriptor length. In this scenario, verification service 227 may need to decode the data descriptor using terse coding…” (emphasis added). In other words, the Specification generally teaches about “encoding” original data into a shorter data formats, and then “decoding” such shortened/compressed data formats before further processing.
Similarly, Rand et al. teaches about compressing original data into shorter data length, and then decompress such compressed data before further data processing:
In one aspect, the present application provides methods and systems for compressing transaction identifiers, and for identifying a full transaction identifier from a compressed identifier.
The transaction identifier 302 is a fixed-length pseudorandom number. In the case of SHA256, the resulting number is a 32-byte number. A compressed transaction identifier (CID) 304 may be generated in two parts: by creating a prefix 306 and concatenating that with a truncated portion 308 of the transaction identifier 302.
It will be appreciated that although this example process uses three possible compressed ID lengths (CID, ECID, XCID) other implementations may have more possible lengths or fewer possible lengths. Moreover, the lengths of the CID, ECID, and XCID values in these examples are one example set of lengths. Different lengths may be used in other implementations.
The structure of the compressed identifiers, with a prefix constructed to have a generally equiprobable distribution, and the structure of the data model for storing data to decompress/resolve CIDs, provide resiliency to attack vectors and enable fast highly concurrent memory access for resolving CIDs.
See Rand ¶¶ [0063], [0065], [0105], [0106] (emphasis added).
Here, in order to conserve bandwidth, Rand explains that transaction identifiers can be compressed into shorter data lengths. During subsequent data processing, these compressed transaction identifiers can be decompressed. Furthermore, Tax et al. explains that sender’s public keys can become its public address for a blockchain transaction. See Tax ¶¶ [0101], [0103]. Accordingly, the combination of Tax in view of Sundararajan and Rand teaches “wherein the data descriptor is encoded in a terse format to fit within a specific descriptor length, wherein the information includes a sender identifier” and “decoding the data descriptor using terse coding” of amended claim 1.
In conclusion, applicant’s argument is unpersuasive and the rejection of amended claims 1 is maintained. Rejection of claims 9 and 17, which recite similar matters, is similarly maintained.
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 discloses as set forth in section 102 of this title, 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-3, 5-11, 13-17, 19, 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Tax et al. (“Tax,” US 20240232858, published July 11, 2024) in view of Sundararajan (“Sundararajan,” US 20240187233, published June 6, 2024) and Rand et al. (“Rand,” US 20230421402, published Dec. 28, 2023).
Regarding claim 1, Tax discloses A computer-implemented method for a secured data transaction, the method comprising:
receiving, by a server system, transaction data and a data descriptor, the data descriptor including information about the transaction data and a digital signature of the data descriptor (Tax FIG. 8, [0150], [0176]. Accordingly, the request received at the touchless transfer server 100 may reference any one or a combination of: the base amount of the transaction, the transaction identifier, the hash, the digital signature, the random data, the point-of-sale identifier, and/or the merchant identifier. The customer device 150 may send the signature to the issuer system 124 in a message 844, which may be referred to as a challenge response message. The challenge response message may include other data in addition to the signature. For example, the NFT identifier may be included.),
wherein the information includes a sender identifier (Tax [0101], [0103]. The customer device 150 may send a message 514 to the issuer system 124 after the key pair is generated. The message 514 includes the public key. The message 514 is received in association with an account. For example, the message 514 may include the unique identifier that is associated with a particular account at the issuer system 124. At 516, the issuer system 124 uses the received public key to mint and/or create a new NFT. The issuer system 124 assigns ownership of the NFT to a public address which is derived from the received public key (i.e., the public key received in the message 514).);
looking up, by the server system, a public key based on the data descriptor; determining, by the server system, whether the digital signature of the data descriptor was signed by a private key corresponding to the public key (Tax [0177]. The issuer system 124 receives the challenge response message 844 and, more specifically, the signature. The issuer system 124 then verifies the response at an operation 846. More specifically, the issuer system 124 verifies the signature using the public key that is stored in the provisioning data in association with the NFT identifier. The issuer system 124 verifies that the signature was generated using the private key that forms a key paid with the public key. After this verification, it has been effectively proven that the customer owns the private key that is related to the public key. At this point, the authentication request received in the message 830 may be said to have been authenticated.);
in accordance with the determination that the digital signature of the data descriptor was signed by the private key corresponding to the public key, allowing, by the server system, [the receipt of the transaction data] (Tax FIG. 8, [0177]- [0178]. The issuer system 124 verifies that the signature was generated using the private key that forms a key paid with the public key. After this verification, it has been effectively proven that the customer owns the private key that is related to the public key. At this point, the authentication request received in the message 830 may be said to have been authenticated. After the authentication request has been authentication (e.g., after the verification has been successfully performed at the operation 846), the issuer system 124 enables, at an operation 848, an operation that was not available and not enabled prior to authenticating the authentication request. That is, the operation that is enabled is an operation that was not able to be performed prior to verification of the signature. In some instances, the operation 848 may enable an account operation. For example, the operation 848 may enable a login to an account. In some implementations, the operation 848 may enable a transaction to be performed that could not have been performed in the same manner prior to the operation 848.).
Tax does not explicitly disclose: allowing, by the server system, the receipt of the transaction data.
However, in an analogous art, Sundararajan discloses a method, comprising the step of: allowing, by the server system, the receipt of the transaction data (Sundararajan [0130], [0142]-[0143]. After receiving the verification response message from the service provider computer 112, the network processing computer 108 can determine whether or not the verification response message indicates that the digital signature is authentic and that the NFT is assigned to (e.g., owned by) the user of the user device 102. At step 11, the resource provider computer 104 can provide the authorization response message or the indication of whether or not the interaction is authorized to the user device 102. At the end of the day or any other suitable time after the transaction is authorized, a clearing and settlement process can occur between the transport computer 106, the network processing computer 108, and the authorizing entity computer 110.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Sundararajan and Tax to include the steps of: allowing, by the server system, the receipt of the transaction data. One would have been motivated to provide users with a means for granting a transaction after a verification of digital signature. (See Sundararajan [0143].)
Tax and Sundararajan do not explicitly disclose: wherein the data descriptor is encoded in terse format to fit within a specific descriptor length; decoding the data descriptor using terse coding.
However, in an analogous art, Rand discloses a method, comprising the step of:
wherein the data descriptor is encoded in terse format to fit within a specific descriptor length (Rand [0063], [0065], [0105]. In one aspect, the present application provides methods and systems for compressing transaction identifiers, and for identifying a full transaction identifier from a compressed identifier. The transaction identifier 302 is a fixed-length pseudorandom number. In the case of SHA256, the resulting number is a 32-byte number. A compressed transaction identifier (CID) 304 may be generated in two parts: by creating a prefix 306 and concatenating that with a truncated portion 308 of the transaction identifier 302. It will be appreciated that although this example process uses three possible compressed ID lengths (CID, ECID, XCID) other implementations may have more possible lengths or fewer possible lengths. Moreover, the lengths of the CID, ECID, and XCID values in these examples are one example set of lengths. Different lengths may be used in other implementations.);
decoding the data descriptor using terse coding (Rand [0105]-[0106]. It will be appreciated that although this example process uses three possible compressed ID lengths (CID, ECID, XCID) other implementations may have more possible lengths or fewer possible lengths. Moreover, the lengths of the CID, ECID, and XCID values in these examples are one example set of lengths. Different lengths may be used in other implementations. The structure of the compressed identifiers, with a prefix constructed to have a generally equiprobable distribution, and the structure of the data model for storing data to decompress/resolve CIDs, provide resiliency to attack vectors and enable fast highly concurrent memory access for resolving CIDs.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Rand, Tax and Sundararajan to include the steps of: the data descriptor is encoded in a terse format to fit within a specific descriptor length; the method further comprises: decoding the data descriptor using terse coding. One would have been motivated to provide users with a means for conserving network bandwidth during electronic financial transactions. (See Rand [0105].)
Regarding claim 2, Tax, Sundararajan and Rand disclose the method of claim 1. Tax further discloses in accordance with the determination that the digital signature of the data descriptor was not signed by the private key corresponding to the public key, blocking, by the server system, the receipt of the transaction data (Tax [0179]. If the verification at the operation 846 were to fail or if the response message 844 was not received, the issuer system 124 would not perform the operation 848 so that the operation remains disabled/unavailable. The verification operation may be said to fail if the issuer system determines that the signature was not generated using the private key associated with the stored public key. Additionally or alternatively, the verification operation may be said to fail if the issuer system is unable to determine that the signature was generated using the private key associated with the stored public key.).
Regarding claim 3, Tax, Sundararajan and Rand disclose the method of claim 1. Sundararajan further discloses
receiving, by the server system, another transaction data and another data descriptor, the another data descriptor including information about the another transaction data and a digital signature of the another data descriptor (Sundararajan [0117] - [0118], [0120]. The interaction request message can include a contract address of “0x05da517B1bf9999B7762EaEfa8372341A1a47559,” a token identifier of “3914,” and a digital signature formed using the user private key. The interaction request message can also include data relating to the selected item (e.g., an item name of “digital_file_003”, an amount of $5, etc.). After receiving the interaction request message, the resource provider computer 104 can generate an authorization request message comprising the contract address, the token identifier, and the digital signature. The authorization request message can also include an amount, as determined from the one or more selected resources, a date, a time, and/or other data utilized to verify, process, authenticate, and/or authorize the interaction. At step 3, after receiving the authorization request message, the transport computer 106 can provide the authorization request message to the network processing computer 108.);
determining, by the server system, whether the another data descriptor is same as the data descriptor (Sundararajan [0127]. For example, the service provider computer 112 can look up the NFT and the smart contract on the NFT blockchain 114 using the contract address and the token identifier. For example, the service provider computer 112 can search the NFT blockchain 114 for the contract address of “0x05da517B1bf9999B7762EaEfa8372341A1a47559”. After finding the smart contract, the service provider computer 112 can identify the NFT associated with the smart contract with the token identifier of “3914”.); and
in accordance with the determination that the another data descriptor is same as the data descriptor, blocking, by the server system, the receipt of the another transaction data (Sundararajan [0123]. In some embodiments, the network processing computer 108 can determine whether or not the contract address and the token identifier are expired based on the stored expiry date. For example, the network processing computer 108 can determine if the current date of (e.g., Jan. 15, 2025) exceeds the expiry date (e.g., Jun. 25, 2025). If the contract address and the token identifier are expired, then the server computer 502 can generate and provide an authorization response message to the resource provider computer 104 that indicates that the interaction is not authorized.).
The motivation is the same as that of claim 1 above.
Regarding claim 5, Tax, Sundararajan and Rand disclose the method of claim 1.
Tax further discloses looking up the public key comprises: looking up, by the server system, a public key corresponding to the sender identifier (Tax [0166]. For example, at an operation 832, the issuer system 124 may retrieve provisioning data. The provisioning data may be retrieved from memory associated with the issuer system 124. The provisioning data may be or include an NFT identifier and a public key. The NFT identifier and the public key may be retrieved based on the unique identifier associated with the account. Put differently, the issuer system 124 retrieves the NFT identifier and the public key associated with the identified account (as identified at operation 828).).
Regarding claim 6, Tax, Sundararajan and Rand disclose the method of claim 1.
Tax further discloses:
receiving, by the server system, the public key (Tax [0100]-[0101]. The provisioning may include, for example, an operation 512. During operation 512, the customer device 150 may generate a key pair within a secure area of the customer device 150. For example, the key pair may be generated within a trusted execution environment (TEE). The key pair may be, for example, a Rivest-Shamir-Adleman (RSA) key pair or an Elliptic-curve cryptography (ECC) key pair. The key pair may include a private key and a public key. The customer device 150 may send a message 514 to the issuer system 124 after the key pair is generated. The message 514 may be sent over a secure channel such as, for example, over a secure hyper text transfer protocol (HTTP) interface. The message 514 includes the public key.);
assigning, by the server system, the sender identifier corresponding to the public key (Tax [0103]. At 516, the issuer system 124 uses the received public key to mint and/or create a new NFT. The issuer system 124 assigns ownership of the NFT to a public address which is derived from the received public key (i.e., the public key received in the message 514). This may be performed according to the Ethereum Request for Comments 20 (ERC-20) standard. The NFT token content may include various data. For example, it may include an identifier such as an NFT identifier (NFT-id) and the public blockchain address of the owner that is assigned ownership of the NFT.); and
sending, by the server system, the sender identifier (Tax [0105]. While not illustrated in FIG. 5 , in order to perform the operation 516, the issuer system 124 may communicate with one or more external systems. For example, the issuer system 124 may communicate with one or more nodes of the blockchain network on which the NFT is created/minted and/or on which ownership of the NFT is assigned.).
Regarding claim 7, Tax, Sundararajan and Rand disclose the method of claim 1.
Tax further discloses wherein the data descriptor includes at least one of: a transaction identifier, a date, or an amount (Tax [0144]. For example, the hash may be generated based on any one or a combination of: the link/web address, the base amount of the transaction, the point-of-sale terminal identifier and/or a merchant identifier, the transaction identifier and/or the random data.).
Regarding claim 8, Tax, Sundararajan and Rand disclose the method of claim 1.
Tax further discloses wherein the public key and the private key corresponding to the public key form a public-private key pair (Tax [0100]. The provisioning may include, for example, an operation 512. During operation 512, the customer device 150 may generate a key pair within a secure area of the customer device 150. For example, the key pair may be generated within a trusted execution environment (TEE). The key pair may be, for example, a Rivest-Shamir-Adleman (RSA) key pair or an Elliptic-curve cryptography (ECC) key pair. The key pair may include a private key and a public key.).
Regarding claim 9, claim 9 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 1. Claim 9 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 2. Claim 10 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 3. Claim 11 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 5. Claim 13 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 6. Claim 14 is similar to claim 6 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 7. Claim 15 is similar to claim 7 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a non-transitory computer readable storage medium corresponding to the method of claim 8. Claim 16 is similar to claim 8 and is therefore rejected under similar rationale.
Regarding claim 17, Tax discloses
A computer-implemented method for a secured data transaction, the method comprising:
generating [, by a service provider system, ] a public-private key pair having a public key and a private key corresponding to the public key (Tax [0100]. The provisioning may include, for example, an operation 512. During operation 512, the customer device 150 may generate a key pair within a secure area of the customer device 150. For example, the key pair may be generated within a trusted execution environment (TEE). The key pair may be, for example, a Rivest-Shamir-Adleman (RSA) key pair or an Elliptic-curve cryptography (ECC) key pair. The key pair may include a private key and a public key.);
generating, by the service provider system, a data descriptor including information about transaction data to be sent by the service provider system (Tax [0144]-[0145]. The machine-readable code may encode security or verification data. For example, the machine-readable code may encode a hash. The touchless transfer server 100 may generate the hash based on other data encoded in the machine-readable code. For example, the hash may be generated based on any one or a combination of: the link/web address, the base amount of the transaction, the point-of-sale terminal identifier and/or a merchant identifier, the transaction identifier and/or the random data. The machine-readable code may be digitally signed by the touchless transfer server 100 and/or may encode a digital signature.),
wherein the information includes the sender identifier (Tax [0101], [0103]. The customer device 150 may send a message 514 to the issuer system 124 after the key pair is generated. The message 514 includes the public key. The message 514 is received in association with an account. For example, the message 514 may include the unique identifier that is associated with a particular account at the issuer system 124. At 516, the issuer system 124 uses the received public key to mint and/or create a new NFT. The issuer system 124 assigns ownership of the NFT to a public address which is derived from the received public key (i.e., the public key received in the message 514).);
signing, by the service provider system, the data descriptor using the private key, to produce a digital signature of the data descriptor (Tax [0144]-[0145]. The machine-readable code may encode security or verification data. For example, the machine-readable code may encode a hash. The touchless transfer server 100 may generate the hash based on other data encoded in the machine-readable code. For example, the hash may be generated based on any one or a combination of: the link/web address, the base amount of the transaction, the point-of-sale terminal identifier and/or a merchant identifier, the transaction identifier and/or the random data. The machine-readable code may be digitally signed by the touchless transfer server 100 and/or may encode a digital signature.);
adding, by the service provider system, the digital signature of the data descriptor to the data descriptor (Tax [0145]-[0146]. The machine-readable code may be digitally signed by the touchless transfer server 100 and/or may encode a digital signature. For example, any one or a combination of: the hash, the base amount of the transaction, the point-of-sale terminal identifier, the merchant identifier, the transaction identifier, the random data and/or the digital signature may be encoded as parameters, such as URL parameters, for the URL.); and
sending, by the service provider system to the server system, the transaction data and the encoded data descriptor (Tax [0145]-[0146]. The machine-readable code may be digitally signed by the touchless transfer server 100 and/or may encode a digital signature. For example, any one or a combination of: the hash, the base amount of the transaction, the point-of-sale terminal identifier, the merchant identifier, the transaction identifier, the random data and/or the digital signature may be encoded as parameters, such as URL parameters, for the URL.).
Tax does not explicitly disclose: generating, by a service provider system, a public-private key pair having a public key;
sending, by the service provider system to a server system, the public key and a request to register the public key; and
receiving, by the service provider system from the server system, a sender identifier corresponding to the public key.
However, in an analogous art, Sundararajan discloses a method, comprising the step of:
generating, by a service provider system, a public-private key pair having a public key (Sundararajan [0093]. The NFT request message can include a first address associated with a user of the user device 102 and a second address associated with an entity. The first address can be the user public key. The second address can be a server computer public key. For example, if the server computer 502 is an authorizing entity computer, then the second address can be an authorizing entity public key, whereas, if the server computer 502 is a processing network computer, then the second address can be a processing network public key.);
sending, by the service provider system to a server system, the public key and a request to register the public key (Sundararajan [0050], [0093], [0098]. Along with this benefit, the interaction can be registered in distributed public ledger. The NFT request message can include a first address associated with a user of the user device 102 and a second address associated with an entity. The first address can be the user public key. The second address can be a server computer public key. For example, if the server computer 502 is an authorizing entity computer, then the second address can be an authorizing entity public key, whereas, if the server computer 502 is a processing network computer, then the second address can be a processing network public key. At step 2, after receiving the NFT request message, or otherwise deciding to provision an NFT to the user device 102, the server computer 502 can provide the NFT request message to the service provider computer 112 that is associated with a blockchain network (not shown in FIG. 5 ) that manages NFTs, or it can generate the NFT request message upon receiving an instruction to do so from the user device 102.); and
receiving, by the service provider system from the server system, a sender identifier corresponding to the public key (Sundararajan [0100]-[0102]. The service provider computer 112 can generate a NFT response message comprising the NFT identifying data. The obtained NFT can be identified by NFT identifying data comprising a contract address and a token identifier. The NFT response message can indicate that ownership of the NFT is assigned to the first address and the second address. At step 3, after recording ownership of the NFT to the first address and the second address, the service provider computer 112 can provide the NFT response message to the server computer 502. The server computer 502 can receive the NFT response message comprising the NFT identifying data comprising the contract address and the token identifier that identifies the NFT.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Sundararajan and Tax to include the steps of: sending, by the service provider system to a server system, the public key and a request to register the public key; and receiving, by the service provider system from the server system, a sender identifier corresponding to the public key. One would have been motivated to provide users with a means for granting a NFT transaction after a verification of digital signature. (See Sundararajan [0143].)
Tax and Sundararajan do not explicitly disclose: encoding, by the service provider system, the data descriptor in a terse format to fit within a specific descriptor length.
However, in an analogous art, Rand discloses a method, comprising the step of: encoding, by the service provider system, the data descriptor in a terse format to fit within a specific descriptor length (Rand [0063], [0065], [0105]. In one aspect, the present application provides methods and systems for compressing transaction identifiers, and for identifying a full transaction identifier from a compressed identifier. The transaction identifier 302 is a fixed-length pseudorandom number. In the case of SHA256, the resulting number is a 32-byte number. A compressed transaction identifier (CID) 304 may be generated in two parts: by creating a prefix 306 and concatenating that with a truncated portion 308 of the transaction identifier 302. It will be appreciated that although this example process uses three possible compressed ID lengths (CID, ECID, XCID) other implementations may have more possible lengths or fewer possible lengths. Moreover, the lengths of the CID, ECID, and XCID values in these examples are one example set of lengths. Different lengths may be used in other implementations.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Rand, Tax and Sundararajan to include the steps of: encoding, by the service provider system, the data descriptor in a terse format to fit within a specific descriptor length. One would have been motivated to provide users with a means for conserving network bandwidth during electronic financial transactions. (See Rand [0105].)
Regarding claim 19, Tax, Sundararajan and Rand disclose the method of claim 17. Tax further discloses wherein the data descriptor includes a sender identifier and at least one of: a transaction identifier, a date, or an amount (Tax [0103]. At 516, the issuer system 124 uses the received public key to mint and/or create a new NFT. The issuer system 124 assigns ownership of the NFT to a public address which is derived from the received public key (i.e., the public key received in the message 514). This may be performed according to the Ethereum Request for Comments 20 (ERC-20) standard. The NFT token content may include various data. For example, it may include an identifier such as an NFT identifier (NFT-id) and the public blockchain address of the owner that is assigned ownership of the NFT.).
Regarding claim 21, Tax, Sundararajan and Rand disclose the method of claim 1. Tax further discloses wherein the sender identifier corresponds to a previously registered user (Tax FIG. 7, [0163], [0166]. In response to receiving an authentication request and, in a least some implementations, an identification of an account, the customer device 150 sends a message 830 to the issuer system 124. The message is or includes an authentication request. The authentication request may include a unique identifier. The unique identifier may be an identifier associated with the identified account. For example, at an operation 832, the issuer system 124 may retrieve provisioning data. The provisioning data may be retrieved from memory associated with the issuer system 124. The provisioning data may be or include an NFT identifier and a public key. The NFT identifier and the public key may be retrieved based on the unique identifier associated with the account.).
Regarding claim 22, Tax, Sundararajan and Rand disclose the method of claim 1. Tax further discloses wherein the data descriptor further comprises metadata specifying one or more of a transaction data type, a merchant identifier, and a user identifier (Tax [0111], [0144]. [T]he issuer system 124 sending the one or more token parameters, such as the unique identifier (e.g., PAN), expiry date, and security code (e.g., CVV) to the customer device 150 or by sending a tokenized representation of a virtual payment card to the customer device 150. For example, the hash may be generated based on any one or a combination of: the link/web address, the base amount of the transaction, the point-of-sale terminal identifier and/or a merchant identifier, the transaction identifier and/or the random data.).
Regarding claim 23, Tax, Sundararajan and Rand disclose the method of claim 1. Tax further discloses wherein the information about the transaction data includes one or more of a transaction identifier, [a transaction date,] and a transaction amount (Tax [0144]. For example, the hash may be generated based on any one or a combination of: the link/web address, the base amount of the transaction, the point-of-sale terminal identifier and/or a merchant identifier, the transaction identifier and/or the random data.).
Sundararajan further discloses a transaction date (Sundararajan [0030], [0118]. Each block in the blockchain can contain also include a timestamp and a link to a previous block. The authorization request message can also include an amount, as determined from the one or more selected resources, a date, a time, and/or other data utilized to verify, process, authenticate, and/or authorize the interaction.).
The motivation is the same as that of claim 1 above.
Conclusion
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439
Prosecution Insights