Acknowledgments
Claims 13-14 have been amended.
Claims 1-12 and 19-20 have been cancelled. Claims 13-18 are pending and have been examined.
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 .
Response to Arguments
Regarding applicant’s arguments:
Applicant’s arguments, see pgs. 4-6, filed 12/03/2025, with respect to the rejections of claim 13 under Claim Rejection - 35 USC § 102(a)(2) that Ziade does not anticipate amended claim 13, specifically the amended limitation “only a known and registered FI can request the token be validated and wherein requests from retailers and users to authenticate the token are denied” are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Navarro (US 20230419309).
Claim Rejections - 35 USC § 102(a)(2)
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 13 and 15-16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Navarro (US 20230419309).
Regarding Claim 13, Navarro teaches a method (Paragraphs 0079 and 0034 teach FIGS. 4A-4C illustrate a process of verifying a transaction based on a blockchain-based security token according to example embodiments; a digital token (referred to herein as a security token) with KYC data embedded therein is committed to a blockchain ledger of a blockchain network; the KYC data may be learned or inferred from account activity within the user's digital wallet, fiat-based payment accounts (e.g., debit card, credit card, savings account, checking account, etc.), crypto accounts, and the like), comprising: identifying a token associated with a transaction from a payment manager of a financial institution (FI) server (Paragraphs 0079-0081 teach referring to FIG. 4A, illustrated is a process of a payment authorization request message being received via a newly-defined application programming interface (API) of a financial institution (FI) server which hosts one or more fiat-based payment accounts and crypto based payment accounts of a user of a user device, as well as a digital wallet of the user, and a security analysis model; the payment authorization request message from the user device may include a payment transaction to be performed such as a credit card transaction, a debit card transaction, a crypto account transaction, or the like, which is transmitted from a user device and received by a host platform (FI server); the payment authorization request message may be in a message format that is predefined for electronic payment networks such as ISO 8583 or ISO 20022 that is configured to be transferred along the rails of a cryptographic network such as a blockchain cryptocurrency network; in response, the FI server may identify an account based on a PAN, wallet ID, crypto account ID, or the like, within the request and a corresponding digital wallet hosted by the FI that includes the account contained therein), wherein only a known and registered FI can request the token be validated and wherein requests from retailers and users to authenticate the token are denied (Paragraphs 0079 and 0068 teach the API also provides access to a blockchain network where security tokens of different users may be stored and shared amongst financial institutions; FIG. 3A illustrates an example of a permissioned blockchain network, which features a distributed, decentralized peer-to-peer architecture; a blockchain user may initiate a transaction to the permissioned blockchain; the transaction can be a deploy, invoke, or query, and may be issued through a client-side application leveraging an SDK, directly through an API, etc; networks may provide access to a regulator, such as an auditor; a blockchain network operator manages member permissions, such as enrolling the regulator as an “auditor” and the blockchain user as a “client” (i.e., financial institution(s) are part of permissioned blockchain network)); verifying the token was previously registered (Paragraph 0081 teaches this information may then be used to perform a security analysis of the transaction request; in this example, the FI server may retrieve content from a digital token (security token) of a user corresponding to the user device from the blockchain network; here, the FI server may be a peer within the blockchain network and have access to and provide a gateway to the underlying blockchain ledger or it may be a client that accesses the blockchain ledger via an independent blockchain peer); using at least the token and at least a portion of real-time information associated with the transaction to identify an address to a smart contract on a blockchain (BC) (Paragraph 0082 teaches the FI server may compare the KYC data attributes embedded within the digital token retrieved from the blockchain network with spending attributes of the requested transaction to determine whether or not to authorize the transaction; for example, the FI server may execute the security analysis model which determines if the usage or the spending behavior does not comply with a profile of the user stored within the digital token, the FI server may transmit a notification to the user device requesting additional verification and/or providing a reason why the additional verification is being requested; here, the FI server may provide evidence of the change in spending behavior and request entry of a PIN, biometric, a security code, or the like; if such information is not provided, the FI server may deny the transaction; as another example, if the transaction details do not comply with the KYC data pulled from the blockchain network, the transaction may be auto-declined without requesting anything from the user); causing the smart contract to evaluate the real-time information in view of predefined conditions of the smart contract and provide an indication of authorization for the transaction corresponding to a transaction authorization or a transaction denial (Paragraphs 0054, 0059, and 0083 teach a process of embedding content from the security profile into a digital token, referred to herein as a security token; referring to FIG. 1C, a blockchain peer of the blockchain network may receive the security profile created by the process of FIG. 1B; here, the blockchain peer may be the same entity as the FI server, or a different entity; the blockchain peer may create the digital token, and embed KYC data attributes (e.g., spending data and usage data) from the security profile within a data container of the digital token, and add a token identifier and a user identifier; other data attributes may be included within the digital token; the digital token may be created by a blockchain smart contract or other program that writes the digital token, encrypts it, and then commits it to the blockchain ledger; a smart contract may be created via a high-level application and programming language, and then written to a block in the blockchain; the smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers); a transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied; the executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger; FIG. 4B illustrates a process of executing a transaction in response to a successful security analysis performed in the process of FIG. 4A; here, the FI server may execute the security analysis model which compares the KYC data attributes embedded within the digital token retrieved from the blockchain network with spending attributes of the requested transaction to determine whether or not to authorize the transaction; for example, the FI server may execute the security analysis model which determines that the usage and the spending behavior complies with the profile of the user stored within the digital token; in response, the FI server may execute the transaction via one or more of a payment network and a crypto network).
Regarding Claim 15, Navarro teaches all the limitations of claim 13 above; and Navarro further teaches receiving the indication of authorization back from the smart contract (Paragraphs 0058 and 0083 teach the smart contracts can themselves be used to identify rules associated with authorization and access requirements and usage of the ledger; for example, the smart contract (or chaincode executing the logic of the smart contract) may read blockchain data which may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer to generate results including alerts, determining liability, and the like, within a complex service scenario; the physical infrastructure may be utilized to retrieve any of the data or information described herein; for example, the FI server may execute the security analysis model which determines that the usage and the spending behavior complies with the profile of the user stored within the digital token); and providing the transaction authorization or transaction denial to the payment manager for determining whether to provide a payment for the transaction or not (Paragraph 0083 teaches in response, the FI server may execute the transaction via one or more of a payment network and a crypto network).
Regarding Claim 16, Navarro teaches all the limitations of claim 13 above; and Navarro further teaches wherein identifying further includes receiving the token from the payment manager (Paragraphs 0079-0080 teach a payment authorization request message being received via a newly-defined application programming interface (API) of a financial institution (FI) server which hosts one or more fiat-based payment accounts and crypto based payment accounts of a user of a user device, as well as a digital wallet of the user, and a security analysis model; the payment authorization request message from the user device may include a payment transaction to be performed such as a credit card transaction, a debit card transaction, a crypto account transaction, or the like, which is transmitted from a user device and received by a host platform (FI server); the payment authorization request message may be in a message format that is predefined for electronic payment networks such as ISO 8583, etc. which is configured to be transferred along the rails of an electronic payment network such as Banknet, etc.; as another example, the message format may be ISO 20022 that is configured to be transferred along the rails of a cryptographic network such as a blockchain cryptocurrency network; thus, the API is configured to receive and identify content within multiple types of payment network message formats).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 14 is rejected under 35 U.S.C. 103 as being unpatentable over Navarro (US 20230419309) in view of Diriye (US 20200118131).
Regarding Claim 14, Navarro teaches all the limitations of claim 13 above; however, Navarro does not explicitly teach determining from a transaction history of a customer registered to the token future changes to the predefined conditions of the smart contract; revising the predefined conditions for the smart contract based on the future changes; and updating the revised predefined conditions in the smart contract on the BC.
Diriye from same or similar field of endeavor teaches determining from a transaction history of a customer registered to the token future changes to the predefined conditions of the smart contract (Paragraph 0045 teaches a monitoring or collecting module may automatically consider transactions/materials purchased so far, and then predicts the likelihood of buying the next material M is related to one or more prohibited lists of items or ingredients; the method and system for tracking transactions associated with contracts may be used to create contextual factors including a location, the transacting parties, types of transactions, commodities/assets associated with the transactions, credit scores or financial histories of the transaction parties, etc.; thus, the system may use a database to detect or predict patterns from collected transactions and compare them with prohibited requirements); revising the predefined conditions for the smart contract based on the future changes (Claim 6 and Paragraphs 0042 and 0054 teach blockchain node updates a database with one or more of prohibited assets and prohibited transactions based on one or more rules, a context that corresponds to the request, and a financial score or financial history associated with one or more of the parties; the system may use various configurations of contracts for requested financial products, and the configurations may be based on user-specified constraints and context specifications; the system may learn what contract configurations to apply or compose for an individual or business, including analyzing characteristics or properties of the requested contract by analyzing the historical configurations of similar contracts and analyzing context information (e.g., including a location the contract is to be used at) using one or more trained machine learning models; one or more active learning models may be employed by a disclosed system so that it is able to learn from the experiences of many users in different geographies and among different cohorts or groups; a weighted voting system may be used to weight the various variables used in making decisions that determines if an alert is to be provided or a transaction or contract is deemed compliant; such inputs may include one or more of a history of possible problems, a risk value, or a location of users and various stakeholders, etc.); and updating the revised predefined conditions in the smart contract on the BC (Paragraph 0090 teaches the shared ledger and/or smart contract is updated to reflect modified rules in the smart contract).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified Navarro to incorporate the teachings of Diriye to determine from a transaction history of a customer registered to the token future changes to the predefined conditions of the smart contract; revise the predefined conditions for the smart contract based on the future changes; and update the revised conditions in the smart contract on the BC.
There is motivation to combine Diriye into Navarro because the functionality of a computing system is improved by enabling an automated means for creating asset transfer contracts and computing/monitoring the transactions and financial contracts for risk of non-compliance. This approach allows risk to be detected prior to execution and continuously store this enabling a more robust way to identify non-compliance and enable a trusted and verified data point for the transaction, transaction history, and compliance of stakeholders (Diriye Paragraph 0035). To summarize, the business challenges associated with banking include high operational costs for asset financing and lending, suboptimal contract decisions, and a lack of personalized/customized financial offerings to suit customer profiles. The present invention reduces these challenges by identifying the right smart contract, terms, conditions, costs, and fees (individuals and businesses have different contexts which might make one contract better suited than another), uses historic performance of past contract and loans for individuals and businesses we can create a more optimized process, helps the banks select better financing option, simulates the effects on its balance sheet and P&L, provides an easy-to-use interface for a user that relates to dimensions of risk, feedback, education, and more (Diriye Paragraph 0041).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Navarro (US 20230419309) in view of Crintea (US 20240062196).
Regarding Claim 17, Navarro teaches all the limitations of claim 13 above; however, Navarro does not explicitly teach wherein identifying further includes hashing certain portions of the real-time information received from the payment manager and identifying the token as being linked to a customer's payment card or a customer's device for a customer associated with the transaction.
Crintea from same or similar field of endeavor teaches wherein identifying further includes hashing certain portions of the real-time information received from the payment manager and identifying the token as being linked to a customer's payment card or a customer's device for a customer associated with the transaction (Paragraphs 0044 and 0047-0048 teach the customer sends a transaction message from a customer account on for the current transaction to the payment processor and to the supplier including a hash of transaction information from a previous transaction of the customer with the payment processor, a hash of transaction information from the current transaction and an encryption of transaction information for the current transaction including a state of the transaction; the encryption is an asymmetric public key/private key encryption with one public key provided to the payment processor by the customer and wherein the key verifies the authenticity of a different portion of the encrypted transaction information for the current transaction; the payment processor receives the transaction message from the customer for the current transaction including a hash of transaction information from a previous transaction of the customer with the payment processor, a hash of transaction information from the current transaction and an encryption of transaction information for the current transaction including a state of the transaction; the payment processor compares the hash of the transaction information from the previous transaction with a stored hash of the transaction information from the previous transaction in order to authenticate the customer).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified Navarro to incorporate the teachings of Crintea for identifying further to include hashing certain portions of the real-time information received from the payment manager and identifying the token as being linked to a customer's payment card or a customer's device for a customer associated with the transaction.
There is motivation to combine Crintea into Navarro because this comparison prevents fraud, since only the actual customer will have the hash of the previous transaction. Preferably, hashes are only available to the customer and payment provider. In addition, a shared secret is sent via an RSA channel, time bound to a specific amount to account for transaction time drift between the two messaged, on which only the customer and payment processor have knowledge of. It is an advantage of the present invention that in the event that the hashes do become available to a 3rd party, that 3rd party will still need to have access to the secret sharing part (Crintea Paragraph 0048).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Navarro (US 20230419309) in view of Diriye (US 20200118131) in further view of Crintea (US 20240062196).
Regarding Claim 18, the combination of Navarro and Crintea teaches all the limitations of claim 17 above; however, the combination does not explicitly teach wherein identifying further includes using a hashed value for the hashed certain portions and obtaining the token from the BC.
Diriye from same or similar field of endeavor teaches wherein identifying further includes using a hashed value for the hashed certain portions and obtaining the token from the BC (Paragraph 0067 teaches a chaincode may include the code interpretation of a smart contract, with additional features; the chaincode may be program code deployed on a computing network, where it is executed and validated by chain validators together during a consensus process; the chaincode receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor; if the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Navarro and Crintea to incorporate the teachings of Diriye for identifying to further include using a hashed value for the hashed certain portions and obtaining the token from the BC.
There is motivation to combine Diriye into the combination of Navarro and Crintea because of the same reasons listed above for claim 14.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gaur et al. (US 20220172198) teaches an example operation may include one or more of receiving, via a payment network, a request to detokenize a payment token to process a payment transaction between a source and a target, detokenizing the payment token based on mapping data stored in a token vault, transmitting information about the detokenized payment token to a computing device associated with the request, generating a settlement token that comprises identifiers of the source and the target and an identifier of the payment token, and transmitting the settlement token to a blockchain on a blockchain settlement network which is parallel to the payment network.
Angelos et al. (US 20220005023) teaches a method that utilizes a mapping between a blockchain address and a payment credential. In some embodiments, the mapping may have been previously generated based on blockchain data (e.g., one or more blockchain tokens) associated with a blockchain address and a previously provided set of conditions. An authorization request message is later received that includes the payment credential. The blockchain address may be retrieved from the mapping and it may be determined whether the set of conditions have been met. One or more operations may be executed based on determining the set of conditions have been met.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights