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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/23/2026 is being considered by the examiner.
Status of the Claims
The following is a Final rejection in response to applicant’s amendments filed on 03/25/2026.
Claims 1-18 are cancelled.
Claim 19 is amended.
Claims 19-38 are pending.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35
U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
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 19-36 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 19-38 are directed to a method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 19 recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim
elements recite additional elements according to MPEP 2106.04(a).
A method of minting non-fungible tokens comprising: generating a non-fungible token (NFT) minting request from an activation programming interface (API) request queue;
sending the NFT minting request directly to a microservices server; wherein the microservices server is a dedicated minter; the dedicated minter dedicated to a single blockchain, wherein the only function of the dedicated minter is to be in persistent communication with the API request queue and requests between the API request queue and the dedicated minter being made at least once every ten seconds, and wherein, to maximize effectiveness of the dedicated minter, only packages necessary to the operation thereof are installed thereon
minting at least one NFT responsive to the NFT minting request to a house wallet controlled by the dedicated minter;
generating an API response indicating one of a successful minting event or a failed minting event; and
displaying the response to a user.
Claim 19, recites (i.e., sets forth or describes) of a method for processing minting requests. The claim achieves this by receiving a transaction request from a queue, routing the request to a request handler, the handler generating the token based on the transaction request, generate a notification of the transaction outcome and send it to the requestor. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. (i.e., fundamental economic practices).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a non-fungible tokens, an activation programming interface (API), a microservices server, a dedicated minter and a single blockchain merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claim 20-38 have also been analyzed for subject matter eligibility. However, claims 20-38 also fail to recite patent eligible subject matter for the following reasons:
Claim 20 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
transferring the at least one NFT from the house wallet to a digital wallet controlled by the user when the API response indicates a successful minting event.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 21 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
minting the digital wallet controlled by the user;
creating a digital wallet key;
encrypting a first part of the digital wallet key with a first cipher;
encrypting a second part of the digital wallet key with a second cipher;
storing the first part of the digital wallet key in a minter database on a network separate from the dedicated minter;
transferring the second part of the digital wallet key to the digital wallet;
generating at least one wallet retrieval phrase;
encrypting the at least one wallet retrieval phrase with the first cipher; and
storing the at least one wallet retrieval phrase in the minter database.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 22 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
encrypting a third part of the digital wallet key with the second cipher; and
storing the third part of the digital wallet key in a native application separate from the digital wallet.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 23 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the first cipher further comprises an activation programming interface (API) cipher.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 24 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the second cipher further comprises a server cipher.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 25 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the NFT minting request further comprises: an API index identifier;
a receiving wallet index identifier;
a user index identifier;
a receiving wallet public key; and
an NFT creation information file.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 26 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
minting the at least one NFT on a commercial blockchain.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 27 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
minting the at least one NFT further comprises a smart contract.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 28 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
minting the at least one NFT further comprises at least one terminal command
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 29 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
minting the at least one NFT further comprises a combination of at least smart contract and at least one terminal command.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 30 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the at least one NFT further comprises an image of a tangible item.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 31 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the at least one NFT further comprises one of a photograph, video, 3D image, and a drawing.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 32 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
minting a first NFT containing the image of the tangible item; and
minting a second NFT containing a digital deed to the tangible item.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 33 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
transferring the first NFT and the second NFT from the house wallet to a digital wallet controlled by the user when the API response indicates a successful minting event.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 34 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
transferring the deed to the tangible item; and
transferring ownership of tangible item along with the deed.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 35 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
delivering physical possession of the tangible item to the user.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 36 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
storing the tangible item on behalf of the user.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 37 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the dedicated minter configured to be a secure microservices server.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 38 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the API is a secure blockchain request API.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional element reciting the claim fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
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.
Claims 19-20, 26- 27 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Alwar (US 2018/0191503 A1), in view of Chapman (US 11641280 B1) and further in view of Metaplex (Candy Machine. < https://developers.metaplex.com/candy-machine>).
Regarding claim 19, Alwar discloses:
A method of minting tokens comprising: (Alwar – Abstract, The Asynchronous Crypto Asset Transfer and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems ("SOCOACT") transforms transfer of assets (TOA) initiation request inputs via SOCOACT components into TOA confirmation outputs… An API call to generate a crypto token asset for the requested asset in a socially aggregated blockchain datastructure is made.)
generating a token minting request from an activation programming interface (API) request queue; (Alwar ¶0512, At 2a and 2b, if the asset is not defined on the blockchain, the broker calls asset creation API to request that an administrator (e.g., DTC) create an asset definition for the asset. At 2c and 2d, the administrator confirms that the asset definition may be created, and issues an asset creation request to add the asset definition to the administrative reference database (e.g., security master). At 3a and 3b, the administrator may utilize the API to invoke a smart contract in blockchain node N3 to create the asset definition on the blockchain. The smart contract may be executed in the nodes of the blockchain network to make the asset definition reference available to the nodes of the blockchain network. Alwar ¶0514, At 1 and la, a broker ( e.g., Fidelity) may call asset issuance API to request that an administrator ( e.g., DTC) issue new asset units, while depositing assets to the blockchain. [the request being received at the API constitutes a request queue comprising the at least one request])
sending the token minting request directly to (Alwar ¶0513, A central administrative node that controls asset issuance (e.g., with data stored in an administrative position ledger) on the blockchain may be utilized (e.g., the same entity that controls asset definition). In one implementation, when establishing a position ledger on the blockchain, a broker node may make an asset issuance API call to the administrative node to issue new asset units ( e.g., crypto tokens) based on the broker's specifications (e.g., based on the assets to be transferred) [the administrative node that controls asset issuance constitutes a dedicated minter]. Alwar ¶0514, At 2, 2a, and 2b, the administrator issues an asset issuance request to add the newly created asset units to the administrative position ledger (e.g., security master).)
minting at least one token responsive to the token minting request to a house wallet controlled by the dedicated minter; (Alwar ¶0513, The administrative node may validate the asset issuance request ( e.g., to verify the broker's identity, to verify availability of assets), and may issue the requested asset units to the broker's omnibus wallet address. Alwar ¶0514, At 2c, the administrator may utilize the API to communicate with blockchain node N3 to add the newly created asset units to the broker's wallet (e.g., to the broker's onmibus wallet address).)
generating an API response indicating one of a successful minting event or a failed minting event; and (Alwar ¶0484, The agency SOCOACT server may send an asset create/issue response 6541 to the delivering broker SOCOACT server to confirm that the asset create/issue request was processed successfully. Alwar ¶0485, when utilizing a broker to broker API calls implementation, the delivering broker SOCOACT server may send a TOA response 6545 to the receiving broker SOCOACT server to confirm that the assets were transferred and/or to provide the transaction identifier of the TOA blockchain transaction submitted to the blockchain. In one implementation, the TOA response may include data such as a response identifier, a status, a transaction identifier, and/or the like.)
displaying the response to a user. (Alwar ¶0500, A determination may be made at 6721 whether the assets to be transferred are on the blockchain (e.g., in the delivering broker's wallet). If the assets to be transferred are not on the blockchain, blockchain asset creation and/or asset issuance for the assets to be transferred may be requested from an administrative node ( e.g., a blockchain network node of an agency ( e.g., DTC)) of the blockchain network at 6725. Alwar ¶0501, As shown at 6729, in one embodiment, if the TOA process is implemented using broker to broker API calls, a delivery address for the assets to be transferred may be determined at 6731. In one implementation, the TOA request may be parsed ( e.g., using PHP commands) to determine the delivery address provided by the receiving broker (e.g., based on the value of the delivery address field). A TOA blockchain transaction may be submitted to the blockchain at 6735. In one embodiment, the TOA blockchain transaction may transfer the customer's assets from the delivering broker's wallet to the receiving broker's wallet. See FIG. 77 for an example of a TOA blockchain transaction. A TOA response may be sent ( e.g., via an API call) to the receiving broker at 6739. In one embodiment, the TOA response may be used to confirm that the customer's assets were transferred and/or to provide the transaction identifier of the TOA blockchain transaction submitted to the blockchain. [since the creation of the blockchain assets must be successful in order to complete the TOA request, a TOA response sent to the receiving broker that confirms the transfer of assets constitutes a response indicating a successful minting].)
Alwar does not disclose, however Chapman teaches:
a microservices server (Chapman col 9 lines 22-42, The server 103 runs a microservices architecture for communication among network components, including communication with external systems, messaging among internal systems, and communication with the DLT (e.g., the blockchain-based tokenization platform) on which the digital token will be issued. The microservices architecture may be programmed to have a dedicated microservice performing a dedicated task to enable to the digital token to be created, as disclosed herein, and then modified or added thereunto, as disclosed herein. For example, there may be a dedicated microservice for presenting the menu to the user 101, a dedicated microservice for sending the input from the user 101 to a logic for creation of the digital token, a dedicated microservice for modifying the digital token after issuance, a dedicated microservice for adding attributes to the digital token after issuance, a dedicated microservice for accessing or recalling the digital token after issuance, a dedicated microservice for reissuing the digital token as modified or added thereunto after issuances, or other dedicated microservice for computing tasks or actions disclosed herein. Col 9 lines 46-51, As such, based on requests from the user 101, as communicated to the server 105 through the server 102 and the server 103, the server 105 may issue the digital token, as disclosed herein, with the digital token having the set of asset-specific attributes sourced from the input from the user 101. Col 15 lines 57-67 & col 16 lines 1-11, In one mode of operation, a method may comprise: presenting, by the server 103, the user interface (e.g., a visual menu, a visual wizard) to the client (e.g., a desktop, a laptop). The user interface may be programmed to receive (a) the set of asset-specific attributes for the digital token to tokenize the asset (e.g., a building) of the asset type (e.g., real estate) and (b) the identifier of the blockchain-based tokenization platform (e.g., Ethereum) from the set of identifiers of the set of blockchain-based tokenization platforms (e.g., Ethereum, Corda, Hyperledger) capable of hosting the digital token having the set of asset-specific attributes. For example, the user interface may be presented via a dApp. The method may further comprise receiving, by the server, the set of asset-specific attributes and the identifier of the blockchain-based tokenization platform from the client (e.g., based on interacting with the user interface). The method may further comprise generating, by the server, the digital token based on the set of asset-specific attributes and the identifier of the blockchain-based tokenization platform such that the digital token contains the header component, the attribute component, and the immutable component, as shown in FIG. 3.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Alwar with the teaching of Chapman. One of ordinary skills in the art would have been motivated to combine these in order to ensure a reliable processing of the minting requests and integrity of the blockchain transactions.
The combination of Alwar and Chapman do not disclose however Metaplex teaches:
non-fungible tokens (NFT). (Metaplex P.2 ¶1, The Metaplex Protocol Candy Machine is the leading minting and distribution program for fair NFT collection launches on Solana. Metaplex P.3 ¶1, By September 2022, 78% of all NFTs in Solana were minted through Metaplex's Candy Machine. This includes most of the well known NFT projects in the Solana ecosystem. Metaplex P.9 ¶2, As mentioned in the Candy Guards page, there are two programs responsible for minting NFTs from Candy Machines: The Candy Machine Core program - responsible for minting the NFT…)
the dedicated minter dedicated to a single blockchain, (Metaplex P.1, Launch your next NFT collection on Solana. Metaplex P.2 ¶1, The Metaplex Protocol Candy Machine is the leading minting and distribution program for fair NFT collection launches on Solana… you can think of a Candy Machine as a temporary structure which is first loaded by creators and then unloaded by buyers. It allows creators to bring their digital assets onchain in a secure and customizable way. Metaplex P.3 ¶1, By September 2022, 78% of all NFTs in Solana were minted through Metaplex's Candy Machine. This includes most of the well known NFT projects in the Solana ecosystem. Metaplex P.9 ¶3, From a Candy Guard program which will then delegate the minting to the Candy Machine Core program. Most of the time, you will want to do this as it allows for much more complex minting workflows. You may need to pass extra remaining accounts and instruction data to the mint instruction based on the guards configured in the account. Fortunately, our SDKs make this easy by requiring a few extra parameters and computing the rest for us. Metaplex P.10 ¶4, To mint from a Candy Machine via a configured Candy Guard account, you may use the mintV2 function and provide the mint address and update authority of the collection NFT the minted NFT will belong to. Metaplex P.11 ¶3, Note that the mintV2 instruction takes care of creating the Mint and Token accounts for us by default and will set the NFT owner to the minter)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Alwar and Chapman with Metaplex’s teaching of a Solana exclusive NFT minting program that operates solely on the Solana blockchain and responds to minting requests that come from API or SDK calls such as the mintV2 function as provided in the CandyMachinesV2Client JavaScript SDK. One of ordinary skills in the art would have been motivated to combine these in order to guarantee blockchain specific compliance and increase security and control over the minted NFTs.
Further, the combination of prior art does not teach “… wherein the microservices server is a dedicated minter…” and “wherein the only function of the dedicated minter is to be in persistent communication with the API request queue and requests between the API request queue and the dedicated minter being made at least once every ten seconds”. However, the claim expressions only describes characteristics of the dedicated minter which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Similarly, the limitation “the dedicated minter dedicated to a single blockchain” only describes characteristics of the dedicated minter which is non-functional descriptive material that does not move to distinguish over prior art.
Further, the limitation “to…” in “…wherein, to maximize effectiveness of the dedicated minter, only packages necessary to the operation thereof are installed thereon” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 20, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex further disclose:
transferring the at least one NFT from the house wallet to a digital wallet controlled by the user when the API response indicates a successful minting event. (Alwar ¶0182, Virtual currency users manage their virtual currency addresses by using either a digital or paper "wallet." Wallets let users send or receive virtual currency payments, calculate the total balance of addresses in use, and generate new addresses as needed. Wallets may include precautions to keep the private keys secret, for example by encrypting the wallet data with a password or by requiring two-factor authenticated logins. Alwar ¶0500, A determination may be made at 6721 whether the assets to be transferred are on the blockchain (e.g., in the delivering broker's wallet). If the assets to be transferred are not on the blockchain, blockchain asset creation and/or asset issuance for the assets to be transferred may be requested from an administrative node ( e.g., a blockchain network node of an agency ( e.g., DTC)) of the blockchain network at 6725. Alwar ¶0501, As shown at 6729, in one embodiment, if the TOA process is implemented using broker to broker API calls, a delivery address for the assets to be transferred may be determined at 6731. In one implementation, the TOA request may be parsed ( e.g., using PHP commands) to determine the delivery address provided by the receiving broker (e.g., based on the value of the delivery address field). A TOA blockchain transaction may be submitted to the blockchain at 6735. In one embodiment, the TOA blockchain transaction may transfer the customer's assets from the delivering broker's wallet to the receiving broker's wallet. Alwar ¶0513, In one implementation, upon receipt of the newly issued asset units, the broker may reallocate the newly issued asset units to the customer's account.)
Regarding claim 26, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex further discloses:
minting the at least one NFT further comprises minting the at least one NFT on a commercial blockchain. (Alwar ¶0181, network nodes of the SOCOACT, in which virtual currency wallet transactions are recorded in Bitcoin-style blockchains. Alwar ¶0514, At 2c, the administrator may utilize the API to communicate with blockchain node N3 to add the newly created asset units to the broker's wallet (e.g., to the broker's onmibus wallet address). In one implementation, a copy of the broker's wallet is shared with the nodes of the blockchain network. The wallet may be encrypted such that the asset holdings are visible to the broker, but not to other brokers.)
Regarding claim 27, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex further disclose:
minting the at least one NFT further comprises a smart contract. (Alwar ¶0512, At 3a and 3b, the administrator may utilize the API to invoke a smart contract in blockchain node N3 to create the asset definition on the blockchain. The smart contract may be executed in the nodes of the blockchain network to make the asset definition reference available to the nodes of the blockchain network. Alwar ¶0513, A central administrative node that controls asset issuance (e.g., with data stored in an administrative position ledger) on the blockchain may be utilized (e.g., the same entity that controls asset definition). In one implementation, when establishing a position ledger on the blockchain, a broker node may make an asset issuance API call to the administrative node to issue new asset units ( e.g., crypto tokens) based on the broker's specifications (e.g., based on the assets to be transferred).)
Regarding claim 37, the combination of Alwar, Chapman, and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman, and Metaplex further teaches:
the dedicated minter configured to be a secure microservices server. (Chapman col 9 lines 22-42, The server 103 runs a microservices architecture for communication among network components, including communication with external systems, messaging among internal systems, and communication with the DLT (e.g., the blockchain-based tokenization platform) on which the digital token will be issued. The microservices architecture may be programmed to have a dedicated microservice performing a dedicated task to enable to the digital token to be created, as disclosed herein, and then modified or added thereunto, as disclosed herein. For example, there may be a dedicated microservice for presenting the menu to the user 101, a dedicated microservice for sending the input from the user 101 to a logic for creation of the digital token, a dedicated microservice for modifying the digital token after issuance, a dedicated microservice for adding attributes to the digital token after issuance, a dedicated microservice for accessing or recalling the digital token after issuance, a dedicated microservice for reissuing the digital token as modified or added thereunto after issuances, or other dedicated microservice for computing tasks or actions disclosed herein.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, and Metaplex with Chapman’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure a reliable processing of the minting requests and integrity of the blockchain transactions.
Claims 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman and Metaplex as applied to claim 20 above, in further view of Schouppe (US 2020/0162246 A1).
Regarding claim 21, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 20 above. The combination of Alwar, Chapman and Metaplex further disclose:
minting the digital wallet controlled by the user; (Alwar ¶0395, a user 4602 (e.g., a person who wishes to use an electronic wallet with crypto tokens) may use a client device (e.g., a desktop, a laptop, a tablet, a smartphone) to send a multiple key account data structure datastore (MKADSD) generation request 4621 to a SOCOACT Server 4604. For example, a MKADSD (e.g., a multisignature electronic wallet) may be associated with one or more multisignature addresses, and crypto tokens associated with each of these multi signature addresses may be accessed using multiple private keys ( e.g., crypto tokens associated with a 1-of-2 multisig address may be accessed using either one of the two associated private keys). In one implementation, the MKADSD generation request may include data such as a request identifier, a user identifier, a set of private keys, a set of public keys, validation server settings, recovery settings, and/or the like. Alwar ¶0396, MKADSD generation request data may be used by a MKADSD generating (MKADSDG) component 4625 to facilitate generating a MKADSD and/or one or more addresses associated with the MKADSD. See FIG. 47 for additional details regarding the MKADSDG component.
creating a digital wallet key; (Alwar ¶0404, Public keys for the MKADSD may be determined at 4705. In one implementation, the MKADSD generation request may be parsed (e.g., using PHP commands) to determine the public keys ( e.g., a normal use public key and a recovery public key). For example, the user may utilize a normal use private key corresponding to the normal use public key to engage in transactions using the MKADSD. In another implementation, the public keys may be generated by the SOCOACT Server. For example, the SOCOACT Server may provide the user with the generated normal use public key and with a normal use private key corresponding to the generated normal use public key (e.g., via the confirmation response 4629). Alwar ¶0405, A recovery private key for the MKADSD may be determined at 4709. In one implementation, the MKADSD generation request may be parsed (e.g., using PHP commands) to determine the recovery private key. For example, the recovery private key may correspond to the recovery public key, and the SOCOACT may utilize the recovery private key to conduct recovery actions. In another implementation, the recovery private key may be generated by the SOCOACT Server.
storing the first part of the digital wallet key in a minter database on a network separate from the dedicated minter; (Alwar ¶0400, a recovery private key associated with the user's MKADSD may be encrypted, and a trigger event message may be sent (e.g., by the user, by other entities) to a validation server 4606 to inform the validation server that the SOCOACT Server is permitted to decrypt the recovery private key. The SOCOACT Server may send a recovery key decryption request 4637 to the validation server. For example, the recovery key decryption request may specify that a decryption key associated with the user is requested. The validation server may send a recovery key decryption response 4641 to the SOCOACT Server. For example, the recovery key decryption response may include the requested decryption key. In an alternative embodiment, the validation server may be provided with a the encrypted recovery private key and may return the decrypted recovery private key. Alwar ¶0407, The recovery private key may be stored at 4725. In one implementation, the recovery private key may be stored in the wallet database 7919n.)
The combination of Alwar, Chapman and Metaplex do not disclose, however Schouppe teaches:
encrypting a first part of the digital wallet key with a first cipher; (Schouppe ¶0036, Key management device 204, at 222, may create a new group, assign a group ID and user IDs and create mapping information for the group for mapping users 103 and associated user IDs to a particular group ID and may also determine one or more asset private key splitting parameters, such as a number of subkeys 116, a number of a first portion 122 of the subkeys that will be distributed to users 103 in the group, a number of a second portion 124 of the subkeys that will be controlled by one or more validators, and in some examples, a number of the second portion may be used as backup subkeys 126. At 224, key management device 204 may prompt initiating user computing device 202, e.g., via the web browser on the user device, to upload or otherwise make available the asset private key 110 that the initiating user would like to split and securely store and manage. At 224, key management device 204 may also provide asset private key splitting instructions. At 226 the imitating user device 202, e.g., via a web browser or other program running locally on the initiating user computing device may receive the asset private key 110 uploaded by the initiating user and execute one or more splitting algorithms according to the received key splitting instructions, such as an algorithm that executes Equation (1) according to the asset private key splitting parameters received from the key management device, to generate a plurality of subkeys 116 that are temporarily stored locally on the initiating user computing device. For example, key management device 204 may provide instructions for executing a key splitting algorithm in JavaScript executable by a web browser of the initiating user computing device 202. At 228, after the plurality of subkeys 116 are generated, the web browser may be configured to prompt the initiating user to connect a first cold storage device 206 for storing one or more of the subkeys. Schouppe ¶0037, At 230, initiating user may connect the first cold storage device 206 to the initiating user computing device 202… The cold storage device credentials may include a cold storage device public key of an asymmetric key public-private key pair... The initiating user computing device 202 may also be configured to identify a first number of the subkeys 116 to assign to the first cold storage device 206, encrypt the identified first number of subkeys with the cold storage device public key, and perform a cryptographic hash calculation of each assigned subkey 116 to generate a hash of each subkey assigned to the first cold storage device 206. Schouppe ¶0039, At step 236, the initiating user computing device 202, for example, via JavaScript in a web browser, or other locally executed software, may identify one or more of the subkeys 116 as validator subkeys 125 that will be controlled by a validator, and the initiating user computing device may be configured to randomly generate an asymmetric public-private validator key pair and passphrase 127 (FIG. 1) with any asymmetric key derivation function known in the art, and encrypt the identified validator subkeys 125 with the validator public key to form encrypted validator subkeys 128. The initiating user device may also generate a hash-calculated value of validator subkeys 125. [public key of the cold storage of the validator constitutes a first cipher and the cold storage of the validator constitutes the a minter database].)
encrypting a second part of the digital wallet key with a second cipher; (Schouppe ¶0043, In examples where a key management program selected by the initiating user includes backup subkeys 126, steps similar to steps 236-242 can be performed to generate an asymmetric public/private backup subkey key pair and passphrase 129, encrypt the identified backup subkeys 126 with the generated backup public key to generate encrypted backup subkeys 130, generate a hash-calculated value of the backup subkeys 126, and prompt the initiating user to connect a backup cold storage device for storing the asymmetric public-private backup key pair 129 for future use to decrypt the encrypted backup subkeys 130 stored on blockchain platform 210.)
transferring the second part of the digital wallet key to the digital wallet; (Schouppe ¶0043, prompt the initiating user to connect a backup cold storage device for storing the asymmetric public-private backup key pair 129 for future use to decrypt the encrypted backup subkeys 130 stored on blockchain platform 210.)
generating at least one wallet retrieval phrase; (Schouppe ¶0039, the initiating user computing device may be configured to randomly generate an asymmetric public-private validator key pair and passphrase 127 (FIG. 1) with any asymmetric key derivation function known in the art)
encrypting the at least one wallet retrieval phrase with the first cipher; and (Schouppe ¶0017, For example, cold storage devices 118 may be computing devices that include a memory and in some examples, a processor configured to encrypt data, such as subkeys 116, stored thereon, for example, with one or more cold storage device cryptographic keys 119. In some examples, cold storage devices may also be configured to store identification information and execute an authentication procedure to authenticate the cold storage device. In some examples, cold storage devices 118 may be encrypted USB thumb drives. Schouppe ¶0018, Data on cold storage devices 118 may be encrypted, for example, with AES256, and in some examples, accessible only after a user provides a correct PIN. In some examples to facilitate ease of use, the PIN used to access encrypted data is the same or shared with the authentication protocol, e.g., a FIDO2 PIN application. Cold storage devices 118 may be connected to one of user devices 102 and store data as received from the user device, and in some examples, encode the received data in a Concise Binary Object Representation (CBOR) data structure. Cold storage devices 118 may utilize a FIDO U2F transport layer, which facilitates backward-compatibility and communication over a variety of internet web browsers. Encryption of data stored on the cold storage devices may incorporate any encryption technology known in the art. In one example, cold storage devices include a sector-addressable memory and incorporate block cipher-based disk encryption, such as 256-bitAES-CBCESSIV. Cold storage devices 118 keys 119 may include a master encryption key that is wrapped by AES256-CBC with an encryption key derived from a user PIN, for example, derived using a Password-Based Key Derivation Function 2 (PBKDF2) hash from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. In one example, cold storage devices 118 include an encryption scheme that is a variation of 256-bitAES-CBC-ESSIV, with data slot index-derived IV, wherein each slot of data is encrypted with the same AES key, but with an IV quasi-randomized per slot, for given AES key instance. Cold storage devices 118 may be configured to randomly generate an AES key for encryption of internal storage the first time the cold storage device is used. Schouppe ¶0040, storage and control of the encrypted validator subkeys 128 and validator key pair and passphrase 127 may vary according to the key management protection plan selected by the initiating user. For example, if the initiating user opts to use a trusted third party, such as a law firm, or one of the users 103, such as the oldest or most responsible child, to be the validator, then the validator key pair and passphrase 127 may be stored on the validator cold storage device 208 and/or validator computing device 212. [the passphrase of data is encrypted using the cold storage public key])
storing the at least one wallet retrieval phrase in the minter database. (Schouppe ¶0040, the validator key pair and passphrase 127 may be stored on the validator cold storage device 208 and/or validator computing device 212 [cold storage of the validator constitutes minter database])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman and Metaplex with the cryptographic key management system of Schouppe for the purpose of providing web-based (also referred to as cloud-based) key management services for the secure and decentralized control and storage of private cryptographic keys and/or other information. As described more below, asset private keys, seeds, passphrases, or any other digital data string or data set may be split into a plurality of subkeys and distributed to a group of people that may gain control of the asset private key in the event a specified condition has occurred. (Schouppe ¶0012)
Regarding claim 22, the combination of Alwar, Chapman, Metaplex and Schouppe disclose the limitations as shown in the rejection of claim 21 above. The combination of Alwar, Chapman, Metaplex and Schouppe further teaches:
encrypting a third part of the digital wallet key with the second cipher; and (Schouppe ¶0043, In examples where a key management program selected by the initiating user includes backup subkeys 126, steps similar to steps 236-242 can be performed to generate an asymmetric public/private backup subkey key pair and passphrase 129, encrypt the identified backup subkeys 126 with the generated backup public key to generate encrypted backup subkeys 130, generate a hash-calculated value of the backup subkeys 126, and prompt the initiating user to connect a backup cold storage device for storing the asymmetric public-private backup key pair 129 for future use to decrypt the encrypted backup subkeys 130 stored on blockchain platform 210. [Table 1 shows a number of backup subkeys 126 as two, for column C, therefore a second backup subkey constitutes a third part of the digital wallet key])
storing the third part of the digital wallet key in a native application separate from the digital wallet. (Schouppe ¶0045, At 244, the initiating user computing device 202 can also send encrypted validator subkeys 128 that were encrypted with a corresponding validator private key of a key pair 127 to the key management device 204. If there are any backup keys 126, the initiating user computing device 202 can also send encrypted backup subkeys 130 that were encrypted with a corresponding backup public key of a key pair 129. [key management device constitutes a native application separate from a wallet])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex and Schouppe with the cryptographic key management system of Schouppe for the purpose of providing web-based (also referred to as cloud-based) key management services for the secure and decentralized control and storage of private cryptographic keys and/or other information. As described more below, asset private keys, seeds, passphrases, or any other digital data string or data set may be split into a plurality of subkeys and distributed to a group of people that may gain control of the asset private key in the event a specified condition has occurred. (Schouppe ¶0012)
Claims 25 and 30-31 are rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman and Metaplex as applied to claim 19 above, in further view of Quigley (US 2022/0351186 A1).
Regarding claim 25, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex further disclose:
an API index identifier; (Alwar ¶0483, when asset units for an asset should be issued on the blockchain, as asset issue request may be sent. In one implementation, the asset issue request may include data such as a request identifier… In one embodiment, the delivering broker SOCOACT server may provide the following example asset issue request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:
POST /asset_issue_request.php HTTP/1.1…
<asset_issue_request>
<request_identifier>ID_request_ 4</request_identifier>
Alwar ¶0513, a broker node may make an asset issuance API call to the administrative node to issue new asset units ( e.g., crypto tokens) based on the broker's specifications (e.g., based on the assets to be transferred).)
a receiving wallet index identifier; (Alwar ¶0483, when asset units for an asset should be issued on the blockchain, as asset issue request may be sent… In one implementation, the asset issue request may include data such as a request identifier requesting broker information, delivery address of the requesting broker… In one embodiment, the delivering broker SOCOACT server may provide the following example asset issue request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:
POST /asset_issue_request.php HTTP/1.1…
<delivery address> lHnh WpkMHMjgtl 67kvgcPyurMmsCQ2WPhh</ delivery address>)
a user index identifier; (Alwar ¶0483, when asset units for an asset should be issued on the blockchain, as asset issue request may be sent… In one implementation, the asset issue request may include data such as a request identifier requesting broker information… In one embodiment, the delivering broker SOCOACT server may provide the following example asset issue request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:
POST /asset_issue_request.php HTTP/1.1…
<requesting_broker_identifier>ID_broker_2</requesting_broker_identifier> )
a token creation information file (Alwar ¶0483, when asset units for an asset should be issued on the blockchain, as asset issue request may be sent… In one implementation, the asset issue request may include data such as a request identifier requesting broker information, delivery address of the requesting broker, information regarding assets to be issued,… In one embodiment, the delivering broker SOCOACT server may provide the following example asset issue request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:
POST /asset_issue_request.php HTTP/1.1…
<requested_assets>
<asset>
<CUSIP> 38259P508</CUSIP>
<Symbol>GOOGL</Symbol>
<Description>Google Corporation</Description>
<Quantity> 20 Shares</Quantity>
</asset> )
an NFT (Metaplex P.2 ¶1, The Metaplex Protocol Candy Machine is the leading minting and distribution program for fair NFT collection launches on Solana. Metaplex P.3 ¶1, By September 2022, 78% of all NFTs in Solana were minted through Metaplex's Candy Machine. This includes most of the well-known NFT projects in the Solana ecosystem. Metaplex P.9 ¶2, As mentioned in the Candy Guards page, there are two programs responsible for minting NFTs from Candy Machines: The Candy Machine Core program - responsible for minting the NFT…)
The combination of Alwar, Chapman and Metaplex do not disclose. However, Quigley teaches:
a receiving wallet public key; (Quigley ¶0217, Each account may be assigned a public key and a private key that may be used to transact on the platform 100. In embodiments, the address of an account may be based on the public key of the account (e.g., the address may be a hash value of the public key. Quigley ¶0218, the platform 100 may update the distributed ledger to indicate an assignment of the token to the user (e.g., to a wallet associated with an account of the user). Quigley ¶0255, the token generation system 302 may embed or otherwise encode the public key used to digitally sign the token in the token.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman and Metaplex with the tokenization platform of Quigley for the purpose of improving the state of art for digital collectible tokens by allowing users to maintain their tokens in digital form on distributed ledgers (which provides transparency and prevents damage or destruction), and allows for updating attributes, such as mutable attributes, in order to provide for dynamic collectible tokens, tokens that may be used an in-game items, and the like. Systems and techniques described herein further enable users to see which types of collectibles are rare and hence more valuable, enable users to view unboxing recipes that may reveal the precise odds of obtaining a particular desired collectible when they open a digital pack, allow users to programmatically level up or exchange their collectibles for other collectibles using crafting recipes (thereby increasing the functionality and utility, and hence value, of the collectibles), and allow users to view supply data, such as the maximum number of collectibles that be created, the currently-issued supply, and the like. (Quigley ¶0519).
Regarding claim 30, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex do not disclose, however Quigley teaches:
the at least one NFT further comprises an image of a tangible item. (Quigley ¶0534, The minting smart contract may store templates and schemas as smart contract configuration data… The NFT template 3240 may further include a media assets 3244 data value that may link to or store one or more media assets. For example, the media assets data field may include one or more interplanetary filesystem (IPFS) links to media assets that may be used for any NFT minted using the template (e.g., an image of a baseball player for a baseball card NFT or the like, an animated image of a fighting game character for a trading card NFT, etc.). Example media assets are illustrated in FIG. 39)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman and Metaplex with the tokenization platform of Quigley for the purpose of improving the state of art for digital collectible tokens by allowing users to maintain their tokens in digital form on distributed ledgers (which provides transparency and prevents damage or destruction), and allows for updating attributes, such as mutable attributes, in order to provide for dynamic collectible tokens, tokens that may be used an in-game items, and the like. Systems and techniques described herein further enable users to see which types of collectibles are rare and hence more valuable, enable users to view unboxing recipes that may reveal the precise odds of obtaining a particular desired collectible when they open a digital pack, allow users to programmatically level up or exchange their collectibles for other collectibles using crafting recipes (thereby increasing the functionality and utility, and hence value, of the collectibles), and allow users to view supply data, such as the maximum number of collectibles that be created, the currently-issued supply, and the like. (Quigley ¶0519).
Regarding claim 31, the combination of Alwar, Chapman, Metaplex and Quigley disclose the limitations as shown in the rejection of claim 30 above. The combination of Alwar, Chapman, Metaplex and Quigley further teaches:
the at least one NFT further comprises one of a photograph, video, 3D image, and a drawing. (Quigley ¶0534, The minting smart contract may store templates and schemas as smart contract configuration data… The NFT template 3240 may further include a media assets 3244 data value that may link to or store one or more media assets. For example, the media assets data field may include one or more interplanetary filesystem (IPFS) links to media assets that may be used for any NFT minted using the template (e.g., an image of a baseball player for a baseball card NFT or the like, an animated image of a fighting game character for a trading card NFT, etc.). Example media assets are illustrated in FIG. 39)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex and Quigley with the tokenization platform of Quigley for the purpose of improving the state of art for digital collectible tokens by allowing users to maintain their tokens in digital form on distributed ledgers (which provides transparency and prevents damage or destruction), and allows for updating attributes, such as mutable attributes, in order to provide for dynamic collectible tokens, tokens that may be used an in-game items, and the like. Systems and techniques described herein further enable users to see which types of collectibles are rare and hence more valuable, enable users to view unboxing recipes that may reveal the precise odds of obtaining a particular desired collectible when they open a digital pack, allow users to programmatically level up or exchange their collectibles for other collectibles using crafting recipes (thereby increasing the functionality and utility, and hence value, of the collectibles), and allow users to view supply data, such as the maximum number of collectibles that be created, the currently-issued supply, and the like. (Quigley ¶0519).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman, Metaplex and Schouppe as applied to claim 22 above, in further view of Simu (US 2022/0210061 A1).
Regarding claim 23, the combination of Alwar, Chapman, Metaplex and Schouppe disclose the limitations as shown in the rejection of claim 22 above. The combination of Alwar, Chapman, Metaplex and Schouppe do not disclose, however Simu teaches:
the first cipher further comprises an activation programming interface (API) cipher. (Simu ¶0288, At 3418, the client sends a mint request via an API call to the fabric API layer 3250. The mint request references the NFT template hash 3208 and includes the authorization token 3406.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex and Schouppe with the method of Simu for the purpose of implementing logic for creating an output variant as a new offering, e.g., using a JSON object or a Makefile. (Simu ¶0288)
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman, Metaplex, Schouppe and Simu as applied to claim 23 above, in further view of Sharifi (US 2018/0351921 A1).
Regarding claim 24, the combination of Alwar, Chapman, Metaplex, Schouppe and Simu disclose the limitations as shown in the rejection of claim 23 above. The combination of Alwar, Chapman, Metaplex, Schouppe and Simu do not disclose, however Sharifi teaches:
the second cipher further comprises a server cipher. (Sharifi ¶0086, the server 1504 provides a list of server cipher suites and at least one reference to a cipher suite server.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex, Schouppe and Simu with the cipher of Sharifi for the purpose of providing the identified compatible pluggable cipher suite to the client. (Sharifi ¶0086)
Claims 28 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman and Metaplex as applied to claim 19 above, in further view of Martin (Technichal Deep Dive Into and Implementation of Non-Fungible Tokens in a Practical Setting, 12/2021).
Regarding claim 28, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex do not disclose, however Martin teaches:
minting the at least one NFT further comprises at least one terminal command. (Martin ¶2 Pag 7, In order to make an NFT, the spl-token program must commit a series of transactions. Martin ¶1 Pag 8, The first step or transaction required in creating a token is through the following command:
1 $ ~ spl - token create - token -- decimals 0
2 Creating token EWSpj To Wb VKccty 9 Uhbz 42 Wh QEuo Xn 2 m K 281 PMNjac CM
4 Signature : 42 XSc Ff YHU 62 kfjnkt K 9 r Bah Zjcpy BYaq Wpw CZDLVnh FKYZtq Gz VKx Amqh YHCXhpjv
5 Hq 8 pc4 ebo ZTGiTn NecLa V 6
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman and Metaplex with the Solana blockchain of Martin for the purpose of speed and security. (Martin ¶3 Pag 7)
Regarding claim 29, the combination of Alwar, Chapman and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman and Metaplex do not disclose, however Martin teaches:
minting the at least one NFT further comprises a combination of at least one smart contract and at least one terminal command. (Martin ¶7 Pag. 6, In order to make an NFT in Solana, one first has to create a wallet. There are many types of wallet infrastructures in Solana, i.e. Phanton, SolFlare, etc. In fact you can make wallet through the command line, as it is just the generation of a private key/public key pair or an address that is used to sign to allocate an account to an address. Martin ¶7-8 Pag 8, The next step is to now mint the token into the account. You specify the address of the token, the amount and then the account where you want the token to reside.
1 ~ spl - token mint EWSpjToWbVKccty9Uhbz42WhQEuoXn2mK281PMNjacCM 1 … The following source code specifies that the command mint calls the function mint-to which
returns an instruction to transfer the account of the token, then the command-mint executes the instruction.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman and Metaplex with the Solana blockchain of Martin for the purpose of speed and security. (Martin ¶3 Pag 7)
Claims 32-36 are rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman, Metaplex and Quigley as applied to claim 30 above, in further view of Martino (NFTs and Intellectual Property 05/17/2021).
Regarding claim 32, the combination of Alwar, Chapman, Metaplex and Quigley disclose the limitations as shown in the rejection of claim 30 above. The combination of Alwar, Chapman, Metaplex and Quigley further teaches:
minting a first NFT containing the image of the tangible item; and (Quigley ¶0534, The minting smart contract may store templates and schemas as smart contract configuration data… The NFT template 3240 may further include a media assets 3244 data value that may link to or store one or more media assets. For example, the media assets data field may include one or more interplanetary filesystem (IPFS) links to media assets that may be used for any NFT minted using the template (e.g., an image of a baseball player for a baseball card NFT or the like, an animated image of a fighting game character for a trading card NFT, etc.). Example media assets are illustrated in FIG. 39)
The combination of Alwar, Chapman, Metaplex and Quigley do not disclose, however Martino does:
minting a second NFT containing a digital deed to the tangible item. (Martino ¶5 Pag 2, any digital content can be minted into an NFT, any file of a JPG, meaning digital images or an MP3, meaning digital sounds: think photographs, songs, tweets, memes, video games, items, or traditionally, a digital deed to real estate.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Alwar, Chapman, Metaplex, Quigley and Martino teaching with the digital files of Martino for the purpose of allowing anyone to track the providence, authenticity, ownership, or transfer of NFTs. (Martino ¶5 Pag 2)
Regarding claim 33, the combination of Alwar, Chapman, Metaplex, Quigley and Martino disclose the limitations as shown in the rejection of claim 32 above. The combination of Alwar, Chapman, Metaplex, Quigley and Martino further teaches:
transferring the first NFT and the second NFT from the house wallet to a digital wallet controlled by the user when the API response indicates a successful minting event. (Alwar ¶0182, Virtual currency users manage their virtual currency addresses by using either a digital or paper "wallet." Wallets let users send or receive virtual currency payments, calculate the total balance of addresses in use, and generate new addresses as needed. Wallets may include precautions to keep the private keys secret, for example by encrypting the wallet data with a password or by requiring two-factor authenticated logins. Alwar ¶0500, A determination may be made at 6721 whether the assets to be transferred are on the blockchain (e.g., in the delivering broker's wallet). If the assets to be transferred are not on the blockchain, blockchain asset creation and/or asset issuance for the assets to be transferred may be requested from an administrative node ( e.g., a blockchain network node of an agency ( e.g., DTC)) of the blockchain network at 6725. Alwar ¶0501, As shown at 6729, in one embodiment, if the TOA process is implemented using broker to broker API calls, a delivery address for the assets to be transferred may be determined at 6731. In one implementation, the TOA request may be parsed ( e.g., using PHP commands) to determine the delivery address provided by the receiving broker (e.g.,based on the value of the delivery address field). A TOA blockchain transaction may be submitted to the blockchain at 6735. In one embodiment, the TOA blockchain transaction may transfer the customer's assets from the delivering broker's wallet to the receiving broker's wallet. Alwar ¶0513, In one implementation, upon receipt of the newly issued asset units, the broker may reallocate the newly issued asset units to the customer's account.)
Regarding claim 34, the combination of Alwar, Chapman, Metaplex, Quigley and Martino disclose the limitations as shown in the rejection of claim 33 above. The combination of Alwar, Chapman, Metaplex, Quigley and Martino further teaches:
transferring the deed to the tangible item; and (Martino ¶5-6 Pag 2, any digital content can be minted into an NFT, any file of a JPG, meaning digital images or an MP3, meaning digital sounds: think photographs, songs, tweets, memes, video games, items, or traditionally, a digital deed to real estate; the NFT is a unique cryptographic key contained within a digital token that verifies the corresponding content file as genuine and establishes a record of ownership as it is transferred on a blockchain. For example, a deed that real estate could be embodied and stored on a blockchain as an NFT, which could then be transferred from the seller of the property to a buyer as a means of recording the sale transaction and new ownership.)
transferring ownership of tangible item along with the deed. (Martino ¶5-6 Pag 2, any digital content can be minted into an NFT, any file of a JPG, meaning digital images or an MP3, meaning digital sounds: think photographs, songs, tweets, memes, video games, items, or traditionally, a digital deed to real estate; the NFT is a unique cryptographic key contained within a digital token that verifies the corresponding content file as genuine and establishes a record of ownership as it is transferred on a blockchain. For example, a deed that real estate could be embodied and stored on a blockchain as an NFT, which could then be transferred from the seller of the property to a buyer as a means of recording the sale transaction and new ownership.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex, Quigley and Martino with the digital files of Martino for the purpose of allowing anyone to track the providence, authenticity, ownership, or transfer of NFTs (Martino ¶5 Pag 2)
Regarding claim 35, the combination of Alwar, Chapman, Metaplex, Quigley and Martino disclose the limitations as shown in the rejection of claim 34 above. The combination of Alwar, Chapman, Metaplex, Quigley and Martino further teaches:
delivering physical possession of the tangible item to the user. (Quigley ¶0238, the platform 100 can include a logistics system (not shown) that enables the physical delivery of an item, such as a good or food. The logistics system may be configured to manage the logistics from the source location of the item (e.g., a warehouse or restaurant) to the redeemer of the token ( e.g., the house or current location of the redeemer)… In this example, the logistics system may generate an electronic notification based on the user's geolocation (or a selected delivery location) and the user's order (e.g., the user's selected topping) and may transmit the electronic notification to a location of the pizza delivery chain that is closest to the intended delivery location.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex, Quigley and Martino with the tokenization platform of Quigley for the purpose of improving the state of art for digital collectible tokens by allowing users to maintain their tokens in digital form on distributed ledgers (which provides transparency and prevents damage or destruction), and allows for updating attributes, such as mutable attributes, in order to provide for dynamic collectible tokens, tokens that may be used an in-game items, and the like. Systems and techniques described herein further enable users to see which types of collectibles are rare and hence more valuable, enable users to view unboxing recipes that may reveal the precise odds of obtaining a particular desired collectible when they open a digital pack, allow users to programmatically level up or exchange their collectibles for other collectibles using crafting recipes (thereby increasing the functionality and utility, and hence value, of the collectibles), and allow users to view supply data, such as the maximum number of collectibles that be created, the currently-issued supply, and the like. (Quigley ¶0519).
Regarding claim 36, the combination of Alwar, Chapman, Metaplex, Quigley and Martino disclose the limitations as shown in the rejection of claim 34 above. The combination of Alwar, Chapman, Metaplex, Quigley and Martino further teaches:
storing the tangible item on behalf of the user. (Quigley ¶0510, In embodiments, one or more systems for supporting commerce in token-based trading cards that are linked to physical items ( e.g., VIRLs as described herein and in the documents incorporated herein by reference) may include, link to, incorporate, communicate with, or integrate with the digital token or token-based trading cards and/or the system or systems that design, mint, deploy and manage them; for example, such other systems may include, in embodiments, systems for escrow of physical items, systems for authentication of physical items, logistics and transportation
systems, storage management systems, and the like.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, Metaplex, Quigley and Martino with the tokenization platform of Quigley for the purpose of improving the state of art for digital collectible tokens by allowing users to maintain their tokens in digital form on distributed ledgers (which provides transparency and prevents damage or destruction), and allows for updating attributes, such as mutable attributes, in order to provide for dynamic collectible tokens, tokens that may be used an in-game items, and the like. Systems and techniques described herein further enable users to see which types of collectibles are rare and hence more valuable, enable users to view unboxing recipes that may reveal the precise odds of obtaining a particular desired collectible when they open a digital pack, allow users to programmatically level up or exchange their collectibles for other collectibles using crafting recipes (thereby increasing the functionality and utility, and hence value, of the collectibles), and allow users to view supply data, such as the maximum number of collectibles that be created, the currently-issued supply, and the like. (Quigley ¶0519).
Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Alwar, Chapman and Metaplex as applied to claim 19 above, in further view Coffing (US 20190273746 A1).
Regarding claim 38, the combination of Alwar, Chapman, and Metaplex disclose the limitations as shown in the rejection of claim 19 above. The combination of Alwar, Chapman, and Metaplex do not disclose, however Coffing teaches:
the API is a secure blockchain request API (Coffings ¶0029, API gateway 130 may serve as an entry point to the service mesh. API gateway 130 may expose public endpoints using OAuth token for authentication and inject user context via a token (JWT) to proxied requests signed using a private key issued exclusively for the API gateway 130 by internal CA in security plane 120. API gateway 130 can enforce rich policies that can be created in IDaaS server 110 based on such factors as user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device. Coffing ¶0034, The client application 210 may be a web application that may be accessible and visible via a web browser. Such a client application 210 may trigger a request (e.g., by a button click). Such request may contains a payload and the access token (e.g., in the request header). The API gateway 130 may authenticates the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. Upon successful authentication and authorization, the request may then be proxied to the appropriate microservice 140 in the mesh with added JWT token that has been enriched with user data (e.g., from payload). Since the API gateway 130 is a microservice itself, API gateway 130 may be aware of other microservices 140A-N in the network. API gateway 130 may further sign the JWT token with its individual private key (e.g., generated with Vault), so that other microservices can verify the signed JWT token and identify the microservice. Coffing ¶0041, As noted previously, client application 210 may allow a user device to establish a session and provide certain data (e.g., regarding the user device, application context) to API gateway 130. API gateway 130 may provide for end-user authentication, authorization(s), microservice mesh egress, and user context enrichment (e.g., via tokens injected/enriched with user and other related contextual data). API gateway 130 may further open a microservice session with any of a number of different microservices 140, including financial service 140A, which is illustrated with its respective security plane 120 and data plane (e.g., proxy 150A) within the container of the microservice 140A.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Alwar, Chapman, and Metaplex with Coffing’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to prevent unauthorized or fraudulent blockchain transactions.
Response to arguments
Claim Rejections – 35 U.S.C. § 112
Claim rejections 35 U.S.C. § 112 in the previous non-final action dated 03/25/2026 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions in regards to claim rejection 35 U.S.C. § 101. The basis for these assertions are found on pages 6-16 of applicant’s arguments dated 03/25/2026.
Regarding, the applicant’s assertion that “various elements of claim 19 as amended directly support at least one of the process effectiveness or the security thereof”. The examiner finds this assertion not persuasive and respectfully disagrees. The claim as amended does not recite any specific improvement to process effectiveness or security, and instead merely describes the use of generic computing components arranged to perform the functions of minting tokens. The steps of generating a token minting request, sending the token minting request to a minter, minting at least one token responsive to the minting request, generating a response indicating the results of the minting event and displaying the response to the user do not provide any specific improvement to the functioning of the computer or technology. Also, the claim does not recite any particular security mechanism that would improve security.
Regarding, the applicant’s assertion that “because the dedicated minter of amended claim 19 is "dedicated to a single blockchain", its "only function... is to be in persistent communication with the API request queue," and "to maximize effectiveness of the dedicated minter, only packages necessary to the operation thereof are installed thereon," the complexity of the dedicated minter is clearly reduced, thus, helping to maximize the effectiveness and speed of operation thereof. For one, by having only packages necessary to the operation thereof installed on the dedicated minter, the control programs needed for its operation can be more easily and quickly accessed, as opposed to an operating system in which a large library of operating software is available for use.
Also, being "dedicated to a single blockchain" and having its "only function... to be in persistent communication with the API request queue," improves the security of the computer process associated with amended claim 19 by effectively limiting access to a given NFT. That is, the operation of a given "dedicated minter" per amended claim 19 is effectively "siloed" and thereby "walled off" from other blockchains, thereby limiting any opportunity for widespread security breaches in the overall system. Thus, the claim does "include the components or steps of the invention that provide the improvement described in the specification,". The examiner finds this assertion not persuasive and respectfully disagrees. The assertions of the applicant do not correspond to the actual claim language and rely on unclaimed benefits rather than a specific technological limitation recited in the claim. First, having a dedicated minter to a single blockchain or restricting communication reflects a routing design choice and not a technological improvement. Also, allocating a minter to a particular job does not constitute an improvement in computer functionality. Second, installing only necessary packages is a consider a conventional system administration measure and doesn’t improve upon the technology. Third, the alleged “improvement in security” is unsupported by the claim language. The claim does not recite any concrete security technique. Stating that the minter is dedicated to a single blockchain and communicates only with the API request queue merely describes characteristics of the dedicated minter and not a security improvement. Finally, any alleged reduction in complexity resulting from assigning the minter to a single blockchain merely relates to how software tasks are organized and not to an actual improvement in how the computer itself operates.
Regarding, the applicant’s assertion that "the dedicated minter" is "dedicated to a single blockchain"; that "the only function of the dedicated minter is to be in persistent communication with the API request queue"; and that "to maximize effectiveness of the dedicated minter, only packages necessary to the operation thereof are installed thereon," as now provided in amended claim 19, and such a combination of features does, indeed, improve both the security and efficiency of the "method of minting non- fungible tokens" of amended claim 19. That is, the method of claim 19, as amended, improves the functionality of the underlying computer process associated therewith, and, in contradistinction to the argument set forth in the Office Action, clearly does more than "merely serve as a tool to perform the abstract idea." The examiner finds this assertion not persuasive and respectfully disagrees. The amended claim stills does not recite a specific technological improvement to the underlining computer technology, but instead uses generic computer components as tools to perform the method of minting non fungible tokens. The claim steps describe generic computer operations such as receiving data, transmitting data, processing requests and generating outputs. Further, the alleged improvements in security and efficiency are recited at a high level and are not tight to any particular limitation in the claim. As amended the claim does not recite any particular security protocol or technique, instead any alleged benefits come from using a dedicated minter. Accordingly, the amended claim merely uses generic computer technology to implement the abstract idea of minting non fungible tokens and does not do more than serve as a tool to perform the abstract idea nor does it contradict the conclusion set forth on the previous office action.
Regarding, the applicant’s assertion that “a tool merely performing the argued overall abstract idea would simply provide a generic mechanism for minting non-fungible tokens. However, the method of amended claim 19 exceeds the provision of such a basic tool. Instead, the tool of the method of claim 19, as amended, is able to (1) achieve the persistent communication of the dedicated minter with the API request queue by ensuring that requests between the API request queue and the dedicated minter are made at least once every ten seconds; and (2) maximize the effectiveness of the dedicated minter by providing that only packages necessary to the operation thereof are installed thereon.” The examiner finds this assertion not persuasive and respectfully disagrees. The amended claim still recites the use of generic computer components as tools to perform the abstract idea rather than a specific technological improvement. Requiring that requests between the API queue and the dedicated minter be made every 10 seconds simply rules the timing of normal communication between two known components and does not set an improvement to the technology. Also, as previously mentioned installing only required or necessary packages on the minter is a common system administration practice and does not constitute an improvement to the computer technology.
Regarding, the applicant’s assertion that “claim 19, as amended, both improves the functionality of the computer process and sets forth a technological solution to a technological problem”, “claim 19 when view as a whole clearly shows that the claimed subject matter is not abstract, clearly leads to the practical application of minting NFTs and provides an improve method for minting NFTs”. The examiner finds this assertion not persuasive and respectfully disagrees. The claim as amended does not recite a technological solution to a technical problem, nor does it improve upon the functionality of the computer process itself. Instead, the claim uses generic computer components to perform the method of minting non fungible tokens. Although the applicant claims that the amended claim improves the method of minting non fungible tokens, improving on the underlining operational process of minting non fungible tokens is not the same as improving the computer technology. Further, the claim does not recite any specific technological mechanism that solves a technical problem. Rather, it generally applies existing computing tools to implement the abstract idea.
Regarding, the applicant’s assertion that “the claim recites additional elements that amount to significantly more than the judicial exception”. The additional elements of a non-fungible tokens, an activation programming interface (API), a microservices server, a dedicated minter and a single blockchain, as recited in the claim, are merely additional elements representing conventional computer technologies employed to apply the underlying abstract idea. To meet the requirements for patent eligibility, the claim must do more than simply apply this abstract idea using generic technological tools. Therefore, the recited claim, does not include any additional features that rise to the level of an inventive concept under step 2B of the subject matter eligibility framework.
Regarding, the applicant’s assertion that “an inventive concept is clearly present in the claims” because “there is no evidence in the cited prior art, the prosecution history, the specification, or in decided cases that such physical elements are routine or conventional in the technological field”. The examiner respectfully disagrees. As mentioned on the previous office action, the recited additional elements (i.e. dedicated minter, single blockchain and API request queue) are generic computing components performing their ordinary functions of receiving , routing and processing requests. Limiting a component to a single blockchain or restricting communication reflects a routing design choice and not a technological improvement.
Regarding, the applicant’s assertion that “the additional elements, as recited in amended claim 19, are not well understood, routine, or conventional activity in the field”. The examiner respectfully disagrees with this assertion. The rejection under 35 U.S.C. 101 was not based on the determination that the recited steps or elements are routine or conventional. Rather, the claims are directed to an abstract idea and do not recite additional elements that integrate the abstract idea into a practical application. Therefore, whether the claimed steps or elements are routine or unconventional does not overcome the rejection. Even assuming, arguendo, that the steps or elements are not routine or conventional, the claim still recites the abstract idea implemented using generic computer components and do not amount to significantly more than the underlining abstract idea.
As previously stated, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. Therefore, the rejection under 35 U.S.C. § 101 is maintained.
Claim Rejections – 35 U.S.C. § 103
The applicant argues that Metaplex fails to disclose or render obvious "…wherein the only function of the dedicated minter is to be in persistent communication with the API request queue and requests between the API request queue and the dedicated minter being made at least once every ten seconds, and wherein, to maximize effectiveness of the dedicated minter, only packages necessary to the operation thereof are installed thereon”. The examiner has considered these arguments and agrees with the applicant. However, the limitation in question is not limiting and does not move to distinguish over prior art. As recited the limitation "…wherein the only function of the dedicated minter is to be in persistent communication with the API request queue and requests between the API request queue and the dedicated minter being made at least once every ten seconds, and wherein, to maximize effectiveness of the dedicated minter, only packages necessary to the operation thereof are installed thereon”, only describes characteristics of the dedicated minter which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Conclusion
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.
The following prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
US 2022/0058636 A1 to Yantis et al. discloses: A tokenization platform that utilizes smart contracts for facilitating token-based transactions for items is disclosed. The system includes an item management system that generates a virtual representation of an item based on item attributes thereof and that generates a smart contract that defines conditions for self-executing a transaction relating to the item. The system includes a tokenization system that generates a digital token that corresponds to the item that is cryptographically linked to the virtual representation thereof. The system also includes a ledger update system that updates a cryptographic ledger with the virtual representation, the digital token, and the smart contract corresponding to the virtual representation, wherein in response to determining that the set of verifiable conditions are satisfied, the smart contract instructs the ledger update system to transfer the digital token to an account of a user that transacted for the item.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached on (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 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.
/J.L./Examiner, Art Unit 3698 /STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights