IP Library Granted Patent US 12,333,532
Granted Patent B2
US 12,333,532 · App. 18/676,678 · Granted Jun 17, 2025

Method and system for zero-knowledge and identity based key management for decentralized applications

Inventors: Vijay Madisetti (Alpharetta, GA); Arshdeep Bahga (Chandigarh, IN)
Assignee: Vijay Madisetti
G06Q20/3829H04L9/14H04L63/061G06F21/33G06F21/6245G06F2221/2115G06Q2220/00H04L9/0643H04L9/3236H04L9/3297H04L9/50H04L2463/061
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,333,532
App. No.
18/676,678
Granted
Jun 17, 2025
Kind
B2
Abstract

A method for qualifying a validator server used in zero-knowledge transactions including receiving hashed transactions between a prover client and a verifier server from the prover client and hashed transactions between the prover client and the verifier server, accessing the hashed transactions an enforcement node, analyzing the first and second pluralities of hashed transactions by the enforcement node, and qualifying or disqualifying the verifier server by the enforcement node responsive to analyzing the first and second pluralities of hashed transactions.

Claims (56)

1. A method for qualifying a validator server used in zero-knowledge transactions comprising:

receiving at a prover client a first plurality of transactions from a verifier server;

generating by the prover client a hashed transaction for each transaction of the first plurality of transactions by applying a hashing function to each transaction of the first plurality of transactions, each hashed transaction comprising a secret-protected assertion, the hashed transactions collectively defined as the first plurality of hashed transactions;

transmitting the first plurality of hashed transactions to a smart contract on a blockchain network;

receiving at a smart contract the first plurality of hashed transactions;

receiving at the smart contract a second plurality of hashed transactions between the prover client and the verifier server, at least one of the hashed transactions of the second plurality of hashed transactions comprising the secret-protected assertion;

accessing each of the first plurality of hashed transactions and the second plurality of hashed transactions on the smart contract by an enforcement node;

analyzing the first and second pluralities of hashed transactions by the enforcement node; and

responsive to the analyzing of the first and second pluralities of hashed transactions, by the enforcement node, qualifies or disqualifies the mismatches of transmitted interaction state logs.

2. The method of claim 1 wherein:

analyzing the first and second pluralities of hashed transactions comprises identifying one or more mismatched transactions comprised by the first plurality of hashed transactions or the second plurality of hashed transactions; and

responsive to identifying one or more mismatched transactions, transmitting by the enforcement node to the smart contract the verifier server is disqualified.

3. The method of claim 1 wherein:

analyzing the first and second pluralities of hashed transactions comprises identifying one or more additional transactions comprised by the second plurality of hashed transactions indicating a transaction that involves a third party other than the prover client; and

responsive to identifying one or more additional transactions, transmitting by the enforcement node to the smart contract the verifier server is disqualified.

4. The method of claim 1 wherein analyzing the first and second pluralities of hashed transactions comprises:

verifying a consistency of the hashed transactions of each of the first and second pluralities of hashed transactions; and

responsive to verifying the consistency of the hashed transactions, transmitting by the enforcement node to the smart contract the verifier server is qualified.

5. The method of claim 1 further comprising:

receiving at the verifier server a second plurality of transactions from the prover client;

generating by the verifier server a hashed transaction record for each transaction of the second plurality of transactions by applying a hashing function to each transaction of the second plurality of transaction records, the hashed transactions being collectively defined as the second plurality of hashed transactions; and

transmitting the second plurality of hashed transactions to the smart contract.

6. The method of claim 1 wherein the verifier server has no knowledge of the secret-protected assertion.

7. A method for qualifying a validator server used in zero-knowledge transactions comprising:

accessing each of a first plurality of hashed transactions received from a prover client and a second plurality of hashed transactions received from a verifier server stored on a smart contract deployed on a blockchain network by an enforcement node;

analyzing the first and second pluralities of hashed transactions by the enforcement node;

responsive to identifying one or more mismatched transactions comprised by the first plurality of hashed transactions or the second plurality of hashed transactions, transmitting by the enforcement node to the smart contract the verifier server is disqualified;

responsive to identifying one or more additional transactions comprised by the second plurality of hashed transactions indicating a transaction that involves a third party other than the prover client, transmitting by the enforcement node to the smart contract the verifier server is disqualified; and

responsive to verifying a consistency of the hashed transactions of each of the first and second pluralities of hashed transactions, transmitting by the enforcement node to the smart contract the verifier server is qualified.

8. The method of claim 7 further comprising:

receiving at the smart contract the first plurality of hashed transactions between the prover client and the verifier server from the prover client, each hashed transaction of the first plurality of hashed transactions comprising a secret-protected assertion; and

receiving at the smart contract the second plurality of hashed transactions between the prover client and the verifier server, at least one of the hashed transactions of the second plurality of hashed transactions comprising the secret-protected assertion.

9. The method of claim 8 further comprising:

receiving at the prover client a first plurality of transactions from the validator server;

generating by the prover client a hashed transaction for each transaction of the first plurality of transactions by applying a hashing function to each transaction of the first plurality of transactions, the hashed transactions being collectively defined as the first plurality of hashed transactions; and

transmitting the first plurality of hashed transactions to the smart contract.

10. The method of claim 8 further comprising:

receiving at the verifier server a second plurality of transactions from the prover client;

generating by the verifier server a hashed transaction record for each transaction of the second plurality of transactions by applying a hashing function to each transaction of the second plurality of transaction records, the hashed transactions collectively defined as the second plurality of hashed transactions; and

transmitting the second plurality of hashed transactions to the smart contract.

11. A method for qualifying a validator server used in zero-knowledge transactions comprising:

receiving at a smart contract on a blockchain network a first plurality of hashed transactions between a prover client and a verifier server from the prover client, each transaction of the first plurality of transactions comprising a secret-protected assertion;

receiving at the smart contract a second plurality of hashed transactions between the prover client and the verifier server, at least one of the hashed transactions of the second plurality of hashed transactions comprising the secret-protected assertion;

accessing each of the first plurality of hashed transactions and the second plurality of hashed transactions on the smart contract by an enforcement node;

analyzing the first and second pluralities of hashed transactions by the enforcement node;

responsive to identifying one or more mismatched transactions comprised by the first plurality of hashed transactions or the second plurality of hashed transactions, transmitting by the enforcement node to the smart contract the verifier server is disqualified;

responsive to identifying one or more additional transactions comprised by the second plurality of hashed transactions indicating a transaction that involves a third party other than the prover client, transmitting by the enforcement node to the smart contract the verifier server is disqualified; and

responsive to verifying a consistency of the hashed transactions of each of the first and second pluralities of hashed transactions, transmitting by the enforcement node to the smart contract the verifier server is qualified.

12. The method of claim 11 further comprising:

receiving at the prover client a first plurality of transactions from the validator server;

generating by the prover client a hashed transaction for each transaction of the first plurality of transactions by applying a hashing function to each transaction of the first plurality of transactions, the hashed transactions collectively defined as the first plurality of hashed transactions; and

transmitting the first plurality of hashed transactions to the smart contract.

13. The method of claim 11 further comprising:

receiving at the verifier server a second plurality of transactions from the prover client;

generating by the verifier server a hashed transaction record for each transaction of the second plurality of transactions by applying a hashing function to each transaction of the second plurality of transaction records, the hashed transactions collectively defined as the second plurality of hashed transactions; and

transmitting the second plurality of hashed transactions to the smart contract.

Assignments (2)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Mar 18, 2026
From: MADISETTI, VIJAY
To: VM INNOVATIONS I, LLC
Reel/Frame 075116/0289 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Mar 5, 2025
From: BAHGA, ARSHDEEP
To: MADISETTI, VIJAY
Reel/Frame 070414/0469 →
Continuity (9)
Continuation 18303963 · Apr 20, 2023
Continuation 17654600 · Mar 14, 2022
Division 17457983 · Dec 7, 2021
Continuation In Part 15830099 · Dec 4, 2017
Provisional Application 63271123 · Oct 23, 2021
Provisional Application 63257603 · Oct 20, 2021
Provisional Application 63257145 · Oct 19, 2021
Provisional Application 62479966 · Mar 31, 2017
Related Publication 20250014024A1 · Jan 9, 2025
References Cited (18)
US 10142312B2 · Johnsrud · 2018 [cited by examiner]
US 20050166263A1 · Nanopoulos · 2005 [cited by examiner]
US 20150269539A1 · MacGregor · 2015 [cited by examiner]
US 20160050199A1 · Ganesan · 2016 [cited by examiner]
US 20160085955A1 · Lerner · 2016 [cited by examiner]
US 20160162897A1 · Feeney · 2016 [cited by examiner]
US 20170277909A1 · Kraemer · 2017 [cited by examiner]
US 20170352012A1 · Hearn · 2017 [cited by examiner]
US 20180088928A1 · Smith · 2018 [cited by examiner]
US 20180122006A1 · Kraemer · 2018 [cited by examiner]
US 20180367305A1 · Gouget · 2018 [cited by examiner]
EP 3296913B1 · 2020 [cited by examiner]
WO WO2014201059A1 · 2014 [cited by examiner]
Yu et al, “Fair deposits against double-spending for Bitcoin transactions”, 2017 IEEE Conference on Dependable and Secure Computing, Aug. 7-10, 2017, pp. 44-51 (Year: 2017). [cited by examiner]
U.S. Appl. No. 18/303,963, filed Apr. 20, 2023. [cited by applicant]
U.S. Appl. No. 17/654,600, filed Mar. 14, 2022. [cited by applicant]
U.S. Appl. No. 17/457,983, filed Dec. 7, 2022. [cited by applicant]
U.S. Appl. No. 15/830,099, filed Dec. 4, 2017. [cited by applicant]