DETAILED ACTION
This is a non-final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 23.
Claims 21-23 are canceled.
Applicant elects group I: Claims 1-15 without transverse.
Claims 16-20 are not elected.
Claims 1 -15 are pending and have been examined on the merits.
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 .
Election/Restrictions
Claims 16-20 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected group, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 5/8/2026.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-15 are rejected under 35 U.S.C. 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea) and does not provide an integration of the recited abstract idea into a practical application nor include an inventive concept that is “significantly more” than the recited abstract idea to which the claim is directed. MPEP §2106.
In determining subject matter eligibility in an Alice rejection under 35 U.S.C. §101, it is first determined at Step 1 whether the claims are directed to one of the four statutory categories of an invention (i.e., a process, a machine, a manufacture, or a composition of matter). MPEP §2106.03. Here, it is determined that claims 1-14 are directed to a method. Claim 15 is directed to a machine. Under a Step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more enumerated categories of patent ineligible subject matter that amounts to a judicial exception to patentability. MPEP §2106.04. Here, independent claim 1 recites (Abstract idea bolded):
A method of conducting a transaction comprising:
transmitting, by a computer, a verification request comprising a wallet account identifier associated with a digital wallet to a smart contract on a blockchain network or a smart contract application associated with the smart contract, wherein the smart contract or the smart contract application verifies the wallet account identifier using a blockchain on the blockchain network;
receiving, by the computer from the smart contract on the blockchain network or the smart contract application, a verification response verifying the wallet account identifier; and
initiating transmitting to an authorizing entity computer, an authorization request message comprising a credential associated with the wallet account identifier, wherein the authorizing entity computer authorizes the authorization request message.
Here, the claims are directed to the abstract idea, or combination of abstract ideas of verifying payment account information and routing a transaction for authorization. This concept/abstract idea, which is seen above, falls within the Certain Methods of Organizing Human Activity grouping because it describes a commercial or legal interaction. Accordingly, it is determined that the claims recite an abstract idea since they fall within one or more of the three enumerated categories of patent ineligible subject matter.
Since it is determined that the claim(s) contain a judicial exception, it must then be determined, under Step 2A, Prong 2, whether the judicial exception is integrated into a practical application of the exception. MPEP §2106.04. Here, claim 1 recites the additional elements of: “computer”, “digital”, “smart”, “blockchain”, and “blockchain network.” Therefore, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Under the Step 2B analysis, it is determined whether the recited additional elements amount to something “significantly more” than the recited abstract idea to which the claims are directed (i.e., provide an inventive concept). MPEP §2106.05. As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s): “computer”, “digital”, “smart”, “blockchain”, and “blockchain network” to implement the abstract idea amounts to simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. That is, simply implementing the abstract idea on a generic computer or merely using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Accordingly, taken alone, the additional elements do not amount to significantly more than a judicial exception. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
Independent claim 15 is similar to claim 1 and is rejected under 35 U.S.C. §101 as not being patent eligible.
Dependent claims 2-14 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) (BOLDED) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent Claim 2 recites “The method of claim 1, wherein the computer is a token service computer, and wherein the method further comprises, before transmitting the wallet account identifier: receiving, by the token service computer from an access device, the authorization request message comprising the wallet account identifier; and after transmitting the authorization request message: receiving, by the token service computer, an authorization response message from the authorizing entity computer; and transmitting, by the token service computer, the authorization response message to the access device.” This limitation is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)). Therefore, when the limitation is considered individually and as a whole in combination with the independent claim from which it depends, the claim does not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 3 recites “The method of claim 1, wherein the method further comprises,
before transmitting the wallet account identifier: receiving, by the computer from a user device of a first user, a value transfer message comprising the wallet account identifier, a value, and a credential of a second user.” This limitation is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)). Therefore, when the limitation is considered individually and as a whole in combination with the independent claim from which it depends, the claim does not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 4 recites “The method of claim 3, wherein initiating transmitting to the authorizing entity computer, the authorization request message comprising the credential associated with the wallet account identifier comprises transmitting by the computer the authorization request message to a token service computer, which exchanges the wallet account identifier for the credential, and then transmits the authorization request message to the authorizing entity computer with the credential.” This limitation is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)). Therefore, when the limitation is considered individually and as a whole in combination with the independent claim from which it depends, the claim does not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 5 recites “The method of claim 1, wherein initiating transmitting to the authorizing entity computer, the authorization request message comprising the credential associated with the wallet account identifier comprises transmitting to the authorizing entity computer, the authorization request message comprising the credential associated with the wallet account identifier.” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 6 recites “The method of claim 1, wherein the smart contract verifies the wallet account identifier by determining that the wallet account identifier is on the blockchain.” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 7 recites “The method of claim 1, wherein transmitting the wallet account identifier to the smart contract on the blockchain network comprises transmitting the wallet account identifier to the smart contract on the blockchain network via the smart contract application.” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 8 recites “The method of claim 7, wherein the smart contract application is on a cloud server computer.” This limitation merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, when the limitation is considered individually and as a whole in combination with the independent claim from which it depends, the claim does not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 9 recites “The method of claim 1, wherein the computer is a token service computer, and wherein the method further comprises, before transmitting the wallet account identifier: receiving, by the token service computer from an access device operated by a resource provider computer, the authorization request message comprising the wallet account identifier; and after transmitting the authorization request message: receiving, by the token service computer, an authorization response message from the authorizing entity computer; and transmitting, by the token service computer, the authorization response message to the access device.” This limitation merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, when the limitation is considered individually and as a whole in combination with the independent claim from which it depends, the claim does not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 10 recites “The method of claim 1, wherein the authorization request message is an ISO 8583 message.” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 11 recites “The method of claim 1, wherein the blockchain network is a public blockchain network.” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 12 recites “The method of claim 1, wherein the authorization request message comprises a transaction type indicator. ” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 13 recites “The method of claim 12, wherein the transaction type indicator indicates that the transaction is to be conducted with the credential.” The claim elaborates on the abstract idea without reciting any new additional elements. Therefore, when the limitations are considered individually and as a whole in combination with the independent claim from which they depend, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claim 14 recites “The method of claim 1, wherein the computer comprises a database comprising transaction type indicators including a first transaction type indicator indicating that a transaction is conducted using the credential and a second transaction type indicator indicating that a transaction is a transaction that is recorded on the blockchain.” This limitation merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, when the limitation is considered individually and as a whole in combination with the independent claim from which it depends, the claim does not recite additional elements that amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ho (US11062302B1), in view of Chen (US20210264444A1), and in further view of Laxminarayanan (US20160119296A1).
Regarding Claims 1 and 15. Ho – which like the current invention is directed to mobile wallet provisioning and payment transactions - teaches:
A method of conducting a transaction and a token service computer comprising:
Ho - The mobile wallet transaction circuit 120 facilitates operation of a mobile wallet, which the mobile wallet user (e.g., a business owner or employee, a consumer, etc.) may utilize to conduct payment transactions (Column 4, lines 65-67).
a processor; and
Ho - a processor (Column 5, line 23).
a computer readable medium comprising code, executed by the processor for performing operations comprising:
Ho – machine-readable media for configuring the hardware to execute the functions described herein (Column 17, lines 34-35).
transmitting, by a computer, a verification request comprising a wallet account identifier associated with a digital wallet…
Ho - the user may provide an identifier associated with the mobile wallet provider, mobile wallet account, device, and/or the user in order to identify the provider associated with the mobile wallet account (Column 15, lines 31-35). At 310, the mobile wallet provider computing system 106 sends the provisioning request (i.e., the payment account information and the mobile wallet address information) to a token service provider (Column 14, lines 6-9).
Ho does not teach, however Chen – which like the current invention is directed to digital wallets, smart contracts, and blockchain-based verification of wallet/token history - discloses:
…to a smart contract on a blockchain network or a smart contract application associated with the smart contract,
Chen - A genesis smart contract (or chaincode contract) will create all tokens within a genesis wallet and send them to the wallet that represents the first entity in the supply chain. When the first entity is finished with their part in the supply chain, they transfer the token to the next wallet owned by the next entity in the supply chain (¶ 0087). The wallets could be created independently by entities, such as through Ledger, Metamask, and MEW and registered on a smart contract that maintains a record for every entity for a specific supply chain process (¶ 0097). The token information is first sent from the UI application 112 to the product verification module 132 (¶ 0100).
wherein the smart contract or the smart contract application verifies the wallet account identifier using a blockchain on the blockchain network;
Chen - The product verification system may attempt to determine a token corresponding to a particular instance of a product based on the code. For example, the product verification system may use a hash table or a “chain explorer” (a UI interface attached with an archive node of the blockchain which would contain all historical data of the chain) to map the code to a corresponding token…If a token is determined based on the code, the product verification system may traverse the product blockchain to access data associated with the token (¶ 0021). (2) The token transaction history is retrieved from the indexed database linked to a blockchain explorer. The transaction data includes all previous wallets the token was transferred from (¶ 0102).
receiving, by the computer from the smart contract on the blockchain network or the smart contract application, a verification response verifying the wallet account identifier; and
Chen - if the product verification system authenticates the instance of the product, the product verification system may provide the user device access to the data associated with the corresponding token retrieved from the product blockchain. For example, the product verification system may transmit an authentication success notification to the user device (¶ 0024). (4) The product verification module 132 sends the retrieved information to the UI application 112 of the user device 110 (¶ 0104).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho with the smart contract verification techniques of Chen because doing so would have predictably improved trust, traceability, and validation of wallet linked transaction data by using known blockchain verification techniques.
The combination of Ho and Chen does not disclose, however Laxminarayan – which like the current invention is directed to payment tokenization and authorization processing -discloses:
initiating transmitting to an authorizing entity computer, an authorization request message comprising a credential associated with the wallet account identifier, wherein the authorizing entity computer authorizes the authorization request message.
Laxminarayanan - At step S306, the access device 122 may send the authorization request message including the token to the transaction processing network computer 114 (¶ 0098). map an account identifier to a token and store the mapping in the token vault with relevant domain restrictions; provision a token from the token vault (¶ 0062). the token requesting party 116 may process the authorization request, for example, to determine a risk associated with the authorization request and/or whether there are sufficient funds to pay for the transaction. Based on the processing, the token requesting party 116 may determine whether the authorization request should be approved or denied (¶ 0100).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 2. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the computer is a token service computer, and wherein the method further comprises, before transmitting the wallet account identifier: receiving, by the token service computer from an access device, the authorization request message comprising the wallet account identifier; and
Laxminarayanan - The token server computer 101 may generate (or determine) a token for each one of the account identifiers received from a computer operated by the token requesting party 116…The token vault 102 may also store a mapping between each token and the account identifier identifying the account represented by the token (¶ 0058).
after transmitting the authorization request message: receiving, by the token service computer, an authorization response message from the authorizing entity computer; and
Laxminarayanan - The token vault 102 may also store a mapping between each token and the account identifier identifying the account represented by the token. The token vault 102 may also be used by the transaction processing network computer 114 to de-tokenize the token and convert the token to the account number represented by the token when a transaction authorization is processed through the transaction processing network computer 114. The token vault 102 may also manage all domain restrictions associated with each token provisioned (¶ 0058).
transmitting, by the token service computer, the authorization response message to the access device.
Laxminarayanan - The token vault 102 may also store a mapping between each token and the account identifier identifying the account represented by the token. The token vault 102 may also be used by the transaction processing network computer 114 to de-tokenize the token and convert the token to the account number represented by the token when a transaction authorization is processed through the transaction processing network computer 114. The token vault 102 may also manage all domain restrictions associated with each token provisioned (¶ 0058).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 3. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the method further comprises, before transmitting the wallet account identifier: receiving, by the computer from a user device of a first user, a value transfer message comprising the wallet account identifier, a value, and a credential of a second user.
Chen - When production of the products begins, the product verification system may transfer the tokens to a digital wallet associated with a first entity in the supply chain process of the product (¶ 0012).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 4. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 3, wherein initiating transmitting to the authorizing entity computer, the authorization request message comprising the credential associated with the wallet account identifier comprises transmitting by the computer the authorization request message to a token service computer, which exchanges the wallet account identifier for the credential, and then transmits the authorization request message to the authorizing entity computer with the credential.
Laxminarayanan - The token server computer 101 may generate (or determine) a token for each one of the account identifiers received from a computer operated by the token requesting party 116. The generated tokens may be stored at a token vault 102. The token vault 102 may also store a mapping between each token and the account identifier identifying the account represented by the token. The token vault 102 may also be used by the transaction processing network computer 114 to de-tokenize the token and convert the token to the account number represented by the token when a transaction authorization is processed through the transaction processing network computer 114. The token vault 102 may also manage all domain restrictions associated with each token provisioned (¶ 0058).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 5. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein initiating transmitting to the authorizing entity computer, the authorization request message comprising the credential associated with the wallet account identifier comprises transmitting to the authorizing entity computer, the authorization request message comprising the credential associated with the wallet account identifier.
Laxminarayanan - The tokens and corresponding encryption keys may be used in tokenized transactions processed by the transaction processing network computer (¶ 0059).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 6. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the smart contract verifies the wallet account identifier by determining that the wallet account identifier is on the blockchain.
Chen - Upon receiving a request for authenticating an item, a code provided with the item is scanned. A token corresponding to an instance of a product is determined based on the code. The product verification system traverses a blockchain to access data associated with the token. The item is authenticated based on the data. Additional content provided by the supply chain and/or the manufacturer of the instance of the product may be presented on a user device in response to authenticating the item (Abstract).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 7. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein transmitting the wallet account identifier to the smart contract on the blockchain network comprises transmitting the wallet account identifier to the smart contract on the blockchain network via the smart contract application.
Chen - The present disclosure includes methods and systems for providing instant authentication of a product and enhanced user experience with the product via blockchain technologies (¶ 0012).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 8. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 7, wherein the smart contract application is on a cloud server computer.
Chen - FIG. 8 is a block diagram of a system for implementing a device according to an embodiment of the present disclosure (¶ 0011).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 9. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the computer is a token service computer, and wherein the method further comprises, before transmitting the wallet account identifier: receiving, by the token service computer from an access device operated by a resource provider computer, the authorization request message comprising the wallet account identifier; and after transmitting the authorization request message: receiving, by the token service computer, an authorization response message from the authorizing entity computer; and
Laxminarayanan - The token server computer 101 may generate (or determine) a token for each one of the account identifiers received from a computer operated by the token requesting party 116. The generated tokens may be stored at a token vault 102. The token vault 102 may also store a mapping between each token and the account identifier identifying the account represented by the token. The token vault 102 may also be used by the transaction processing network computer 114 to de-tokenize the token and convert the token to the account number represented by the token when a transaction authorization is processed through the transaction processing network computer 114. The token vault 102 may also manage all domain restrictions associated with each token provisioned (¶ 0058).
transmitting, by the token service computer, the authorization response message to the access device.
Laxminarayanan - The token server computer 101 may generate (or determine) a token for each one of the account identifiers received from a computer operated by the token requesting party 116. The generated tokens may be stored at a token vault 102. The token vault 102 may also store a mapping between each token and the account identifier identifying the account represented by the token. The token vault 102 may also be used by the transaction processing network computer 114 to de-tokenize the token and convert the token to the account number represented by the token when a transaction authorization is processed through the transaction processing network computer 114. The token vault 102 may also manage all domain restrictions associated with each token provisioned (¶ 0058).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 10. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the authorization request message is an ISO 8583 message.
Laxminarayanan - The authorization request message may be an electronic message that is sent to the transaction processing network computer 114 and/or an issuer of the user account to request authorization for a transaction using the account. An authorization request message, according to some embodiments, may comply with a message type defined by the International Organization for Standardization (ISO) 8583 standard, which is a standard for systems that exchange electronic transaction information associated with payments made by users using a user device (which could be a mobile communication device). The authorization request message may include an issuer account identifier that may be associated with a user device or a user account (¶ 0096).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 11. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the blockchain network is a public blockchain network.
Chen - The transfer of the tokens to the wallet associated with the first entity causes a new transaction block to be recorded in a product blockchain structure (also referred to as a “blockchain” or a “ledger”) (¶ 0013).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 12. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the authorization request message comprises a transaction type indicator.
Laxminarayanan - The token vault 102 may also manage all domain restrictions associated with each token provisioned (¶ 0058).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 13. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 12, wherein the transaction type indicator indicates that the transaction is to be conducted with the credential.
Laxminarayanan - The tokens and corresponding encryption keys may be used in tokenized transactions processed by the transaction processing network computer (¶ 0059).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Regarding Claim 14. The combination of Ho, Chen, and Laxminarayanan further discloses:
The method of claim 1, wherein the computer comprises a database comprising transaction type indicators including a first transaction type indicator indicating that a transaction is conducted using the credential and a second transaction type indicator indicating that a transaction is a transaction that is recorded on the blockchain.
Chen - The transfer of the tokens to the wallet associated with the first entity causes a new transaction block to be recorded in a product blockchain structure (also referred to as a “blockchain” or a “ledger”). The new transaction block indicates a transfer of the corresponding tokens from the manufacturer (or the product verification system) to the first entity. In some embodiments, the product blockchain structure is generated by the product verification system and is associated with the product or products produced by the manufacturer such that any transactions (e.g., transfer of tokens) associated with instances of the product or products produced by the manufacturers will be recorded in the product blockchain structure. In some embodiments, the product blockchain structure is not associated with any particular product or manufacturer, and any transactions associated with any products may be recorded in the product blockchain structure or as metadata associated with the corresponding tokens (¶ 0013).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the mobile wallet transaction and provisioning system of Ho and the smart contract verification techniques of Chen with the tokenized authorization of Laxminarayanan because doing so allows the system to send an authorization request message including a token associated with the wallet account identifier and determines whether an approval or denial should take place in a conventional payment authorization flow.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Bloy (US20220277297A1) - A computer system for provisioning a data transfer method is disclosed, comprising a processor, and a communications module and a memory coupled to the processor. The memory stores instructions that, when executed by the processor, cause the computer system to: receive a provisioning request for a data transfer method; send, to a server associated with the data transfer method, a request, based on the provisioning request, for assignment of a data transfer identifier; receive, from the server, the data transfer identifier responsive to the request for assignment of the data transfer identifier; obtain a data transfer token corresponding to the data transfer identifier by: sending, to a token service provider, a request for the token comprising the data transfer identifier; receiving, from the token service provider, a data transfer token in response to the request for the token; and, send a reply to the provisioning request comprising the token.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C STEVENSON whose telephone number is (571)270-7280. The examiner can normally be reached on Monday-Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights