IP Library › Granted Patent US 12,562,926
Granted Patent B2
US 12,562,926 · App. 17/984,081 · Granted Feb 24, 2026

Method to validate application programming interface (API) leveraging non fungible token (NFT)

Inventor: Shailendra Singh (Maharashtra, IN)
Assignee: Bank of America Corporation
H04L9/50H04L9/3236H04L63/102
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,562,926
App. No.
17/984,081
Granted
Feb 24, 2026
Kind
B2
Abstract

An architecture is disclosed for submission and recordation of application programmer interfaces (APIs) using non-fungible tokens (NFTs) inserted into a blockchain. The API-NFT pairings are validated by nodes of the network. The system automatically searches for and generate NFTs for APIs and/or intermediate layers on a computer network based on metadata associated with the API and a hash of the API/intermediate layer. The API-NFT pair binding ensures that developers/consumers are ingesting APIs that are secure and do not include malicious rules. Furthermore, performance monitoring of the API is performed using artificial intelligence (AI) and machine learning (ML), including long short term memory (LSTM) neural networks.

Claims (50)

1 . A system for constructing a smart contract that regulates access by a devOp user computer to application programmer interface (API) services through API-NFT (nonfungible token) bindings, the system comprising:

an API-NFT smart contract module configured to:

generate the smart contract for an API based on a NFT associated with the API;

assign a first rule to the smart contract related to registering the devOp user computer;

assign a second rule to the smart contract related to accessing API services, wherein the API services include API interfaces and method calls; and

assign a third rule to the smart contract related to onboarding policy firewall rules;

an API-NFT repository configured to:

store the smart contract generated by the API-NFT smart contract module; and

bind the API-NFT with the smart contract to authenticate access to the API services; and

an API-NFT orchestration module configured to enable or disable access by the devOp user computer to the API services associated with the smart contract based on rules assigned to the smart contract relating to regulating access through a distributed API gateway.

2 . The system of claim 1 , wherein the NFT associated with the API certifies a digital asset to be authentic using a cryptographic hash, and wherein the digital asset comprises the API, and wherein the NFT is an identifiable data block stored on a blockchain, and wherein the blockchain is a digital distributed ledger.

3 . The system of claim 1 , wherein the API-NFT repository is configured to store a plurality of smart contracts wherein each of the plurality of smart contracts corresponds to one or more API services published on a public computer network.

4 . The system of claim 1 , wherein the smart contract is configured to track monetization based on API consumption by the devOp user computer.

5 . The system of claim 1 , wherein the first rule related to registering the devOp user computer causes the API-NFT orchestration module to enable or disable access by the devOp user computer to the API services based on an authorization level of a devOp user logged into the devOp user computer.

6 . The system of claim 5 , wherein a first devOp user has a different authorization level than a second devOp user, and the devOp user computer is enabled access to API services for the first devOp user but not for the second devOp user.

7 . The system of claim 1 , wherein the API-NFT repository is configured to:

certify authenticity of the API using a cryptographic hash; and

enable the devOp user computer to consume the API through the distributed API gateway.

8 . The system of claim 1 , wherein the API-NFT bindings provide an authenticated, secure interface to an API service on a public network.

9 . A method comprising:

generating, by an API-NFT smart contract module in a system, a smart contract for an application programmer interface (API) based on an NFT associated with the API;

assigning, by the API-NFT smart contract module, a first rule to the smart contract related to registering a devOp user computer;

assigning, by the API-NFT smart contract module, a second rule to the smart contract related to accessing API services, wherein the API services include API interfaces and method calls;

assigning, by the API-NFT smart contract module, a third rule to the smart contract related to onboarding policy firewall rules;

storing, by an API-NFT repository in the system, the smart contract generated by the API-NFT smart contract module;

binding, by the API-NFT repository, the API-NFT with the smart contract to authenticate access to the API services, wherein the binding creates an API-NFT binding;

storing, in the API-NFT repository, the API-NFT binding;

certifying, by the API-NFT repository, authenticity of the API using a cryptographic hash;

enabling or disabling, by an API-NFT orchestration module, access by the devOp user computer to the API services associated with the smart contract based on rules assigned to the smart contract relating to regulating access through a distributed API gateway.

10 . The method of claim 9 , wherein the NFT associated with the API certifies the API to be authentic using a cryptographic hash, and wherein the NFT is an identifiable data block stored on a blockchain, and wherein the blockchain is a digital distributed ledger.

11 . The method of claim 9 , wherein the API-NFT binding provides an authenticated, secure interface to an API service on a public network.

12 . The method of claim 9 , further comprising:

storing, by the API-NFT repository, a plurality of smart contracts wherein each of the plurality of smart contracts corresponds to one or more API services published on a public computer network.

13 . The method of claim 9 , wherein the first rule related to registering the devOp user computer causes the API-NFT orchestration module to enable or disable access by the devOp user computer to the API services based on an authorization level of a devOp user logged into the devOp user computer.

14 . The method of claim 13 , wherein a first devOp user has a different authorization level than a second devOp user, and the devOp user computer is enabled access to API services for the first devOp user but not for the second devOp user.

15 . A non-transitory, tangible computer medium storing computer-executable instructions that, when executed by one or more processors, cause a system to:

generate, by an API-NFT smart contract module in the system, a smart contract for an application programmer interface (API) based on an NFT associated with the API;

assign, by the API-NFT smart contract module, a first rule to the smart contract related to registering a devOp user computer;

assign, by the API-NFT smart contract module, a second rule to the smart contract related to accessing API services, wherein the API services include API interfaces and method calls;

assign, by the API-NFT smart contract module, a third rule to the smart contract related to onboarding policy firewall rules;

store, by an API-NFT repository in the system, the smart contract generated by the API-NFT smart contract module;

bind, by the API-NFT repository, the API-NFT with the smart contract to authenticate access to the API services, wherein the binding creates an API-NFT binding; and

enable, by an API-NFT orchestration module, the devOp user computer to consume the API through a distributed API gateway.

16 . The non-transitory, tangible computer medium of claim 15 , further storing computer-executable instructions that, when executed by the one or more processors, cause the system to:

certify, by the API-NFT repository, authenticity of the API using a cryptographic hash.

17 . The non-transitory, tangible computer medium of claim 15 , wherein the NFT associated with the API certifies the API to be authentic using a cryptographic hash, and wherein the NFT is an identifiable data block stored on a blockchain, and wherein the blockchain is a digital distributed ledger.

18 . The non-transitory, tangible computer medium of claim 15 , further storing computer-executable instructions that, when executed by the one or more processors, cause the system to:

storing, in the API-NFT repository, the API-NFT binding.

19 . The non-transitory, tangible computer medium of claim 15 , wherein the first rule related to registering the devOp user computer causes the API-NFT orchestration module to enable access by the devOp user computer to the API services based on an authorization level of a devOp user logged into the devOp user computer.

20 . The non-transitory, tangible computer medium of claim 15 , wherein a first devOp user has a different authorization level than a second devOp user, and the devOp user computer is enabled access to API services for the first devOp user but not for the second devOp user.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Nov 9, 2022
From: SINGH, SHAILENDRA
To: BANK OF AMERICA CORPORATION
Reel/Frame 061712/0001 →
Continuity (1)
Related Publication 20240154825A1 · May 9, 2024
References Cited (17)
US 8843997B1 · Hare · 2014 [cited by applicant]
US 10956244B1 · Cho · 2021 [cited by applicant]
US 20200344233A1 · Lai et al. · 2020 [cited by applicant]
US 20220109562A1 · Feola et al. · 2022 [cited by applicant]
US 20220245574A1 · Cella et al. · 2022 [cited by applicant]
US 20220318618A1 · Guntar et al. · 2022 [cited by applicant]
US 20220327529A1 · Williams et al. · 2022 [cited by applicant]
US 20220343250A1 · Tremblay et al. · 2022 [cited by applicant]
US 20220351195A1 · Quigley et al. · 2022 [cited by applicant]
US 20220383303A1 · Mullen et al. · 2022 [cited by applicant]
US 20230006976A1 · Jakobsson et al. · 2023 [cited by applicant]
US 20230298001A1 · Jethmalani et al. · 2023 [cited by applicant]
US 20230353570A1 · Lee · 2023 [cited by examiner]
US 20240104173A1 · Tiseanu · 2024 [cited by examiner]
WO 2017173399A1 · 2017 [cited by applicant]
Dec. 5, 2020—NPL “How to implement Azure Kubernetes Service (AKS) in Cloud?,” Kubernetes Advocate, pp. 13. [cited by applicant]
May 17, 2021—NPL “High Integrity DEFI Data and Risk Stability,” Credmark, pp. 23. [cited by applicant]
Cited By (1)
US 12,730,915