DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first
inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the response filed on April 3, 2026.
Claims 1, 2 and 19 were amended.
Claim(s) 1-20 are currently pending and have been examined.
This action is made Final.
Response to Arguments
Applicant argued that Examiner’s 101 rejection was improper because the claimed invention is not a commercial or legal interaction. Examiner disagrees. Applicant’s claimed invention is clearly directed towards executing an overdraft transaction and recording the transaction on a blockchain. This is a commercial interaction. The fact that encryption technology is used does not change the fundamental nature of the commercial transaction claimed. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that Examiner’s 101 rejection was improper because the claimed invention integrates the judicial exception into a practical application and is directed to an improvement to the technical field associated with encryption and tracing techniques for transactions. Examiner disagrees. Applicant’s claimed invention does not integrate the judicial exception into a practical application because the additional limitations of a computer and a computer program product are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Encryption and tracing techniques are not improved by the claimed invention because Applicant has not shown that any technological limitations in encryption or tracing techniques were overcome by the claimed invention. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art did not teach or suggest “issuing a first overdraft token computed based on a user identifier of a given user, an initial overdraft value, a first serial number, and an encryption key that is shared with the given user”. Examiner disagrees. The Agrawal reference discloses the transfer of tokens from one key to another that is tied to an overdraft value and a user account, which teaches or suggests issuing a first overdraft token computed based on a user identifier of a given user, an initial overdraft value, a first serial number, and an encryption key that is shared with the given user. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art did not teach or suggest “generating a first zero-knowledge proof proving that said initial overdraft value is equal to a maximal value of credit granted to said given user”. Examiner disagrees. The Agrawal reference discloses the use of a zero-knowledge proof to validate a transfer. Argrawal also discloses requirements to ensure overdraft safety and privacy (see Agrawal: pgh 129). These disclosures teach or suggest “generating a first zero-knowledge proof proving that said initial overdraft value is equal to a maximal value of credit granted to said given user”. Therefore, Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the prior art did not teach or suggest “computing an overdraft transaction based on the first overdraft token and the first zero-knowledge proof and signing the computed overdraft transaction using a secret key that is not shared with the given user”. Examiner disagrees. The Agrawal reference discloses transactions that include a private key, zero knowledge proofs, and a signature (see Agrawal: pgh 200). Agrawal also discloses token usage in overdraft-protected transactions. Therefore, Agrawal teaches or suggests “computing an overdraft transaction based on the first overdraft token and the first zero-knowledge proof and signing the computed overdraft transaction using a secret key that is not shared with the given user”. Examiner finds Applicant’s argument non-persuasive.
Applicant argued that the dependent claims are patentable for at least the same reasons as independent claims 1 and 19. Examiner disagrees. Independent claims 1 and 19 are not patentable in their current form. For this reason, the dependent claims cannot be patentable based on the patentability of claims 1 and 19. Therefore, Examiner finds Applicant’s argument non-persuasive.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim(s) 1-20 are directed to a system, method, or product, which are/is one of the statutory categories of invention. (Step 1: YES).
The Examiner has identified product claim 19 as the claim that represents the claimed invention for analysis and is similar to independent method Claim 1. Claim 19 recites the following limitations:
[a computer program product for managing user overdrafts in a privacy-preserving manner, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor associated with a computerized system to cause the computerized system to perform a method comprising:]
generating a first serial number and an encryption key based on an overdraft request from a given user;
issuing a first overdraft token computed based on a user identifier of the given user, an initial overdraft value, the first serial number, and the encryption key that is shared with the given user;
generating a first zero-knowledge proof proving that said initial overdraft value is equal to a maximal value of credit granted to said given user;
computing an overdraft transaction based on the first overdraft token and the first zero-knowledge proof and signing the computed overdraft transaction using a secret key that is not shared with the given user; and
submitting the overdraft transaction to a blockchain.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity because the limitations recite commercial or legal interactions. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a commercial or legal interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The computer program product in Claim 19 is just applying generic computer components to the recited abstract limitations. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. Claim(s) 1 is also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims recite an abstract idea)
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of a computer program product. The computer hardware/software is/are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, claim(s) 1 and 19 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, these additional elements do not change the outcome of the analysis when considered separately and as an ordered combination. Thus, claim(s) 1 and 19 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-18 and 20 further define the abstract idea that is present in their respective independent claim(s) 1 and 19 and thus correspond to certain methods of organizing human activity and hence are abstract for the reasons presented above. Dependent claims 2-18 and 20 do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, dependent claims 2-18 and 20 are directed to an abstract idea. Thus, claim(s) 1-20 are not patent-eligible.
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.
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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal (US 2019/0164153) in view of Lounegov (US 2022/0138843) in view of Szamel (US 2009/0076951).
Regarding claim(s) 1 and 19:
Agrawal teaches:
A computer program product for managing user overdrafts in a privacy-preserving manner, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor associated with a computerized system to cause the computerized system to perform a method comprising: (Agrawal: col 44, lines 1-10, “The software code may be stored as a series of instructions, or commands on a computer readable medium…”)
generating a first serial number and an encryption key [based on an overdraft request] from a given user; (Agrawal: pgh 19, “Record information can also include multiple data packets…A record identifier can be a number, title, or other data value used for identifying a record.”; pgh 30, “A user operating a user device…may initiate a transaction by generating a cryptographically signed message and sending the message to blockchain network)
issuing a first overdraft token computed based on a user identifier of the given user, an initial overdraft value, the first serial number, and the encryption key that is shared with the given user; (Agrawal: col 13, lines 10-15, “The transfer function is used to transfer an amount of tokens from one public key to another.”)
generating a first zero-knowledge proving of that said initial overdraft value is equal to a maximal value of credit granted to said given user; (Agrawal: col 23, lines 20-25, “Each transfer and burn transaction in Zether contains a ZK-proof which ensures that the transfer is valid without revealing the reasons why it’s valid.”)
computing an overdraft transaction based on the first overdraft token and the first zero-knowledge proof and signing the computed overdraft transaction using a secret key that is not shared with the given user; and (Agrawal: col 4, lines 10-15, “A digital signature may be a unique data value generated from a message/data and a private key using an encrypting algorithm.”)
Agrawal does not teach, however, Lounegov teaches:
submitting the overdraft transaction to a blockchain. (Lounegov: pgh 20, “At step 309, a link or other association may be created between the blockchain or IVATR and a recod in the core database relating to the deposit transaction.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Agrawal to include the teachings of Lounegov because there is a need for more convenient, efficient and secure ways of using blockchain or other independently verifiable records to perform banking functions (Lounegov: pgh 3). Agrawal/Lounegov does not teach, however, Szamel teaches:
…based on an overdraft request… (Szamel: pgh 63, “…the financial instructions can relate to various financial transactions normally relevant to financial institutions, including for example…overdraft, line of credit, letters of credit…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Agrawal/Lounegov to include the teachings of Szamel because there is a need “…therefore for solutions that provide a technology enabled means for customers to create instructions to financial institutions that is low cost, simple to use…” (Szamel: pgh 44)
Regarding claim(s) 2:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 1. Agrawal further teaches:
wherein the overdraft transaction is signed by an authorized overdraft issuer using said secret key, and (Agrawal: col 12, lines 20-30, “…using the account secret key, the sender must sign both the nonce and an address…in the case of confidential transfers…”)
wherein said secret key is associated with said authorized overdraft issuer, and (Agrawal: col 20, lines 45-50, “CreateTransferTx is used to transfer money from one account to another amongst a set of account. It takes a secret key…”)
wherein, at the blockchain, validating the submitted overdraft transaction by checking that, the submitted overdraft transaction is signed by said authorized overdraft issuer, and the first zero-knowledge proof is a valid zero-knowledge proof. (Agrawal: col 4, lines 10-15, “…a validation algorithm employing a public kay may be used to verify the signature; col 19, lines 25-30, “Signatures can be built from Fiat-Shamir transformed NIZK proofs.”)
Regarding claim(s) 3:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 1. Agrawal further teaches:
wherein the method further comprises: given a balance token issued for said given user, wherein the balance token has been obtained based on the user identifier, a balance value, and a first seed, generating a transfer token based on a transfer beneficiary identifier, a transfer value, and a second seed, and (Agrawal: col 13, lines 10-15, “The Transfer function is used to transfer an amount of tokens from one public key to another.”)
computing a second serial number as a verifiable random function of a secret key of the given user and the first seed. (Agrawal: col 38, lines 35-40, “To ensure that exactly 1 participant wins, the lottery drawings are uncorrelated by appending the serialized public key pk when computing the lottery drawings…”)
Regarding claim(s) 4:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 3. Agrawal further teaches:
wherein the method further comprises: generating a second overdraft token based on the user identifier, a residual credit value, a third serial number, and the encryption key, (Agrawal: col 6, lines 30-40, “…a smart contract, can be executed either individually, by other smart contracts, or invoke other smart contracts to exchange confidential amounts of a token…”)
wherein the residual credit value has been obtained based on the initial overdraft value minus a difference between said transfer value and said balance value; and (Agrawal: col 16, lines 25-30, “The Burn function may validate the balance…”)
computing two cyphertexts thanks to the encryption key, the cyphertexts including a first cyphertext encrypting the residual credit value, and a second cyphertext encrypting the third serial number. (Agrawal: col 16, lines 25-30, “…update platform smart contract state by adding a ciphertext…”)
Regarding claim(s) 5:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 4. Agrawal further teaches:
randomizing the balance token and the first overdraft token to respectively obtain a randomized balance token and a randomized, first overdraft token. (Agrawal: col 8, lines 1-10, “This randomness can be stored on-chain…”)
Regarding claim(s) 6:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 5. Agrawal further teaches:
wherein further comprising: generating one or more second zero-knowledge proofs showing that: the randomized balance token and the randomized, first overdraft token correspond to randomized versions of each of the balance token and the first overdraft token as stored in the blockchain; (Agrawal: col 8, lines 5-10, “…if the recipient is unable to recover the randomness…then the recipient cannot spend the UTXO later.”)
the randomized, first overdraft token encodes the first serial number; (Agrawal: col 8, lines 10-15, “One solution may require sender to encrypt the randomness under recipient’s public key…”)
each of the second serial number, the first cyphertext, and the second cyphertext, is correctly computed; (Agrawal: col 16, lines 40-45, “…a first balance ciphertext representing a first balance of the first account; a second entry having a second public key associated with a second account, and a second ciphertext representing a second balance of the second account…”)
a sum of the balance value as in the randomized balance token and the initial overdraft value as in the randomized, first overdraft token matches a sum of the transfer value as in the transfer token and the residual credit value as in the second overdraft token; the residual credit value as in the second overdraft token is less than or equal to said maximal value of credit; and (Agrawal: col 41, lines 60-65, “Transfer and burn transaction are then generated with respect to this new state of the accounts, which will match with the state ZSC…”)
the user identifier as in the second overdraft token corresponds to the user identifier as in each of the randomized balance token and the randomized, first overdraft token. (Agrawal: col 9, lines 25-30, “At the end of every epoch, pending transfers are rolled over into the corresponding accounts.”)
Regarding claim(s) 7:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 6. Agrawal further teaches:
wherein the one or more second zero-knowledge proofs are generated as a single zero-knowledge proof. (Agrawal: col 32, lines 15-20, “The sigma protocol is complete, honest-verifier zero-knowledge…”)
Regarding claim(s) 8:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 6. Agrawal further teaches:
generating a transfer transaction based on the first serial number, the second serial number, the randomized balance token, the transfer token, the randomized, first overdraft token, the second overdraft token, each of the two cyphertexts, and the one or more second zero-knowledge proofs; (Agrawal: col 16, lines 40-45, “…a first balance ciphertext representing a first balance of the first account; a second entry having a second public key associated with a second account, and a second ciphertext representing a second balance of the second account…”)
anonymously signing the transfer transaction using the secret key of the given user; and (Agrawal: col 26, lines 50-55, “Since the transfer is anonymous, all accounts are treated in the same way; some balance is added to each one of them.”)
submitting the transfer transaction, as signed, to the blockchain. (Agrawal: col 37, lines 45-50, “He then forwards the transaction and the signature to PC which checks both and, if valid, submits the transaction to ZSC.”)
Regarding claim(s) 9:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 8. Agrawal further teaches:
validating the transfer transaction at the blockchain by checking that: each of the first serial number and second serial number does not appear in previous transactions recorded in the blockchain in respect of the given user, the one or more second zero-knowledge proofs are valid zero-knowledge proofs, and the signed overdraft transaction, as submitted to the blockchain, is compatible with the user identifier as in the randomized balance token and the randomized, first overdraft token. (Agrawal: col 5, lines 20-30, “Once a validation node has received the message, the validation node may distribute the message to the other validation nodes in a blockchain network.”)
Regarding claim(s) 10:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 8. Agrawal further teaches:
tracing overdraft-related operations based on the first serial number. (Agrawal: col 6, lines 60-65, “the Ethereum blockchain tracks the state of every account. State changes are initiated through transactions coming from EOAs.”)
Regarding claim(s) 11:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 10. Agrawal further teaches:
wherein tracing the overdraft-related operations further comprises: locating the first serial number in the blockchain and accordingly retrieving the transfer transaction from the blockchain; (Agrawal: col 16, lines 25-30, “…update platform smart contract state by adding a ciphertext…”)
decrypting, thanks to the encryption key, each of the two cyphertexts to obtain a first decrypted value and a second decrypted value, (Agrawal: col 3, lines 55-60, “…a decryption algorithm that transforms encrypted information back to the original data.”)
storing the first decrypted value, and (Agrawal: col 5, lines 40-45, “…every new transaction spends one or more UTXOs…”)
obtaining, from the second decrypted value, the third serial number, so as to be able to retrieve the second overdraft token. (Agrawal: col 3, lines 5-10, “A record can include a record identifier…”)
Regarding claim(s) 12:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 9. Agrawal further teaches:
given a further transfer token generated for said given user, wherein the further transfer token has been obtained based on the user identifier, a further transfer value, and a third seed, generating a balance update token based on the user identifier, a fourth seed, and the further transfer value minus a difference between said transfer value and said balance value, and computing a fourth serial number as a verifiable random function of the secret key of the given user and the third seed. (Agrawal: col 5, lines 20-30, “Once a validation node has received the message, the validation node may distribute the message to the other validation nodes in a blockchain network.”)
Regarding claim(s) 13:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 12. Agrawal further teaches:
generating a third overdraft token computed based on the user identifier, said maximal value of credit, a fifth serial number, and the encryption key; and (Agrawal: col 13, lines 10-15, “The transfer function is used to transfer an amount of tokens from one public key to another.”)
computing two additional cyphertexts thanks to the encryption key, the additional cyphertexts including a first additional cyphertext encrypting said maximal value of credit, and a second additional cyphertext encrypting the fifth serial number. (Agrawal: col 41, lines 60-65, “Transfer and burn transaction are then generated with respect to this new state of the accounts, which will match with the state ZSC…”)
Regarding claim(s) 14:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 13. Agrawal further teaches:
randomizing the further transfer token to obtain a randomized, further transfer token; and (Agrawal: col 16, lines 40-45, “…a first balance ciphertext representing a first balance of the first account; a second entry having a second public key associated with a second account, and a second ciphertext representing a second balance of the second account…”)
randomizing the second overdraft token to obtain a randomized, second overdraft token. (Agrawal: col 41, lines 60-65, “Transfer and burn transaction are then generated with respect to this new state of the accounts, which will match with the state ZSC…”)
Regarding claim(s) 15:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 14. Agrawal further teaches:
generating one or more third zero-knowledge proofs showing that: the randomized, further transfer token and the randomized, second overdraft token correspond to randomized versions of each of the further transfer token and the second overdraft token as stored in the blockchain; the randomized, second overdraft token encodes the third serial number; (Agrawal: col 13, lines 10-15, “The transfer function is used to transfer an amount of tokens from one public key to another.”)
each of the fourth serial number, the first additional cyphertext, and the second additional cyphertext, is corrected computed; (Agrawal: col 16, lines 25-30, “…update platform smart contract state by adding a ciphertext…”)
a sum of values encoded in the randomized, second overdraft token and the randomized, further transfer token matches a sum of values as in the balance update token and the maximal value of credit as in the third overdraft token; the maximal value as in the third overdraft token is less than or equal to the maximal value of credit as initially granted to the given user; and (Agrawal: col 41, lines 60-65, “Transfer and burn transaction are then generated with respect to this new state of the accounts, which will match with the state ZSC…”)
the user identifier as in the third overdraft token corresponds to the user identifier as in each of the randomized, second overdraft token, the randomized, further transfer token, and the balance update token. (Agrawal: col 41, lines 60-65, “Transfer and burn transaction are then generated with respect to this new state of the accounts, which will match with the state ZSC…”)
Regarding claim(s) 16:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 15. Agrawal further teaches:
wherein the one or more third zero-knowledge proofs are generated as a single zero-knowledge proof. (Agrawal: col 32, lines 15-20, “The sigma protocol is complete, honest-verifier zero-knowledge…”)
Regarding claim(s) 17:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 15. Agrawal further teaches:
computing a funding transaction based on the third serial number, the fourth serial number, the randomized, further transfer token, the balance update token, the randomized, second overdraft token, the third overdraft token, each of the two additional cyphertexts, and the one or more third zero-knowledge proofs, (Agrawal: col 41, lines 60-65, “Transfer and burn transaction are then generated with respect to this new state of the accounts, which will match with the state ZSC…”)
anonymously signing the funding transaction using the secret key of said given user, and (Agrawal: col 26, lines 50-55, “Since the transfer is anonymous, all accounts are treated in the same way; some balance is added to each one of them.”)
submitting the funding transaction, as signed, to the blockchain. (Agrawal: col 37, lines 45-50, “He then forwards the transaction and the signature to PC which checks both and, if valid, submits the transaction to ZSC.”)
Regarding claim(s) 18:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 17. Agrawal further teaches:
wherein the method further comprises, at the blockchain, validating the funding transaction by checking that: each of the third serial number and fourth serial number does not appear before in any transaction previously recorded in respect of the given user; (Agrawal: col 4, lines 10-15, “…a validation algorithm employing a public kay may be used to verify the signature; col 19, lines 25-30, “Signatures can be built from Fiat-Shamir transformed NIZK proofs.”)
the one or more third zero-knowledge proofs are valid zero-knowledge proofs, and the signed overdraft transaction, as submitted to the blockchain, is compatible with the user identifier as in the randomized, further transfer token and the randomized, second overdraft token. (Agrawal: col 4, lines 10-15, “…a validation algorithm employing a public kay may be used to verify the signature; col 19, lines 25-30, “Signatures can be built from Fiat-Shamir transformed NIZK proofs.”)
Regarding claim(s) 20:
The combination of Agrawal/Lounegov/Szamel, as shown in the rejection above, discloses the limitations of claim 19. Agrawal further teaches:
wherein the computerized system is a system of an authorized overdraft issuer and (Agrawal: col 3, lines 45-50, “a network node may be associated with…a bank…”)
said secret key is a secret key of said authorized overdraft issuer, (Agrawal: col 4, lines 10-15, “A digital signature may be a unique data value generated from a message/data and a private key using an encrypting algorithm.”)
whereby the overdraft transaction is signed by said authorized overdraft issuer, in operation. (Agrawal: col 37, lines 45-50, “He then forwards the transaction and the signature to PC which checks both and, if valid, submits the transaction to ZSC.”)
Conclusion
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure. Komandur (US 2020/0151686) discloses a system and method for cross-border blockchain platform.
THIS ACTION IS MADE FINAL. 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 of 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN O PRESTON whose telephone number is (571)270-3918. The examiner can normally be reached 12:00 pm - 8:00 pm.
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, Michael W Anderson can be reached on 571-270-0508. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOHN O PRESTON/Examiner, Art Unit 3693
June 8, 2026
/Mike Anderson/ Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights