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 .
DETAILED ACTION
In view of the Appeal Brief filed on 3/9/2026, PROSECUTION IS HEREBY REOPENED. A new grounds of rejection is set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/GLENTON B BURGESS/Supervisory Patent Examiner, Art Unit 2454
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 3/9/2026 have been fully considered, and further review has indicated new grounds of rejection are required, thus new grounds of rejection have been added and prosecution reopened (as noted above). This includes both a clarified claim mapping to previously cited prior art (Padmanabhan (US-20230394481-A1) and OpenSea (OpenSea. How To buy an NFT. https://opensea.io/learn/nft/how-to-buy-nft. (Year: 2022))) and new grounds of rejection made further in view of Minaev (Minaev, A. "How to Buy an NFT: A Guide for Beginners". https://cryptodose.net/learn/how-to-buy-nft/. May 13. (Year: 2022)), OpenZeppelin (OpenZeppelin. etherscan-verify. "Could someone reuse the signature from a previous NFT mint transaction to mint another token?". October 11. (Year: 2021)) and Asa (US-20200320519-A1).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 6, 20, 21, and 24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph.
Regarding claim 1, said claim is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for signing a message with a private key to create a “digital signature on a message” does not reasonably provide enablement for a signature that “includes a unique identifier” - creating a “digital signature on a message” is not the same thing as a “signature” alone, which is claimed. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to use the invention commensurate in scope with these claims. In other words, the claimed scope of the invention and the disclosed scope of the invention differ to such an extent that issues are raised with regards to compliance under 35 USC 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph.
For example, claim 1, lines 1 – 3 on page 3 note “issuing . . . a first signature”, with line 6 continuing to note that the “first signature provides authorization” and “includes a unique identifier” and “is for a self-executing program”. Applicant’s specification, e.g., in [42] recites: “In some embodiments, system 200 may combine a message with a private key to create a digital signature on the message. For example, the digital signature may be used to verify the authenticity of blockchain operations. As an illustration, when conducting blockchain operations, system 200 may use the digital signature to prove to every node in the system that it is authorized to conduct the blockchain operations.”
Thus, the specification supports how a message may be signed with a private key “to create a digital signature on the message”. This supports how to create a signed message. However, how a “signature” itself “includes a unique identifier” in the manner claimed is not disclosed. How such a signature is created is absent from the specification, as is what precisely such a signature may contain or be composed of. Such a signature is also totally lacking from the figures and specification as a whole. Merely signing a message with a private key to create a signed message does not sufficiently describe how a signature alone can also include “a unique identifier corresponding to the first previously minted digital asset”, as is claimed.
Further regarding claim 1, said claim recites on line 6 of page 3 that “the first signature provides authorization to obtain”. The Examiner notes that [94] of Applicant’s specification provides language similar to line 6 on page 3, but no disclosure in the specification is provided as to how such a signature can either “provide” such authorization (or as [94] recites, “include authorization”).
Regarding claim 6, said claim is dependent upon claim 1, where claim 1 concludes with a “transferring” step being performed after a “validating” operation. Dependent claims 2 and 3 clarify that this “validating” step “comprises verifying”. This is supported by the specification repeatedly noting that the validating includes the verifying operation, e.g., [79] reciting “validating the first user account includes verifying”, [80] reciting “validating the first user account includes verifying”, [85] reciting “validating the first signature may include verifying”, etc.
Thus, the specification is enabling for performing a validating step that includes a verifying operation. However, enablement for performing a validating step that includes a verifying operation does not reasonably provide enablement for distinct “validating” and “verifying” operations, as is further specified in claim 6. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to practice the invention commensurate in scope with these claims. Claim 6’s further recitation is that the “verifying” is performed prior to the transferring step; this additional recitation requires that the “verifying” steps thus are not part of the prior specified and above discussed “validating” step. This conflicts with the above noted details of claims 2 and 3, and the written description support provided in the specification, which both support the verifying and validating operations being tied together (whereas claim 6 recites the “transferring” is performed in response to one three distinct “verifying” criteria). Thus the specification reasonably provides enablement for a validating step that comprises verifying, but not a validating step that is distinct and separate from a verifying step as recited in claim 6. Regarding claim 20, said claim is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for signing a message with a private key to create a “digital signature on a message” does not reasonably provide enablement for “wherein the first signature comprises a first blockchain operation characteristic” and “wherein the first signature comprises authorization to obtain the first previously-minted unique digital asset for the value.” The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to use the invention commensurate in scope with these claims. In other words, the claimed scope of the invention and the disclosed scope of the invention differ to such an extent that issues are raised with regards to compliance under 35 USC 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph.
As noted above in the discussion of claim 1, utilizing how a private key can be utilized to sign a message is disclosed in the specification, but how a mere signature itself may either “comprises a first blockchain operation characteristic” or comprise “authorization to obtain the first previously-minted unique digital asset for the value” is never discussed or otherwise disclosed.
Regarding claim 21, said claim is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, for the same reasons as claims 1 and 20. In the case of claim 21, said claim recites the above discussed signature “specifies a time window during which the first signature can be used”.
Regarding claim 24, said claim is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, for the same reasons as claims 1 and 20. In the case of claim 21, said claim recites the above discussed signature “comprises a first blockchain operation characteristic”.
In order to perform a complete examination, the claimed “signature” has been interpreted broadly (such as being in line with a signed message or a message created with or containing a signature; specific interpretation remarks are provided in the rejections presented below).
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 3, 6 – 15, and 20 - 26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, said claim begins on lines 1 though 5 of page 2 by reciting that it is directed to “A system for facilitating initial deployment . . . comprising one or more processors . . . ”. Claim 1 then continues to recite on lines 10 – 12 of page 2 to recite that these one or more processors generate a first request “on a platform service that resides on a server that includes at least one processor of the one or more processors”. It is unclear if this “server” of line 11 (which is claimed as hosting/housing the “platform service” and utilizing “at least one processor” of the “one or more processors”) is part of the initially claimed “system for facilating”.
If the server of line 11 is not part of the initially claimed system, then it is unclear how said “server” can comprise at least one processor that is also a processor comprised in the “system for facilitating”. Note that claim 1 continues to recite actions performed by the above noted “platform service” (e.g., “determining” as claimed on lines 13 – 15 of page 2, “validating” as claimed on line 16 of page 2, and “issuing” on line 1 of page 3), but as noted above it is unclear if this platform service is intended as part of the claimed “system for facilitating”, and thus whether those operations performed by said platform service are part of the system of claim 1. Further regarding claim 1, lines 6 – 9 of page 3 recites:
“wherein the first signature provides authorization to obtain the first previously- minted unique digital asset, includes a unique identifier corresponding to the first previously-minted unique digital asset, and is for a first self-executing program, of a crypto service . . .” (emphasis added).
The overall scope of lines 6 – 11 suggest that the “crypto service” is further describing the “first self-executing program”. However, if this is the intention then the comma between “program” and “of” is non-standard English and unnecessary. This raises issues about the intended scope of the recitation and renders the intended relationship between the “crypto service” and the “first self-executing program” unclear and indefinite. Lines 8 – 11 of page 3 additionally recites: “for a first self-executing program, of a crypto service that is separate from the platform service and the cryptography-based storage application . . .” (emphasis added). It is unclear whether the emphasized language is intended to further limit the “self-executing program” or the “crypto service”.
Claim 1 continues on page 3 on lines 10 – 12 to recite: “program, of a crypto service that is separate from the platform service and the cryptography-based storage application, that authorizes a transfer of the first previously-minted unique digital asset” (emphasis added).
It is unclear if the above emphasized language is referencing the “crypto service”, the “first self-executing program” recited in lines 8 – 9, or some other item from the clause recited in lines 6 – 11 of claim 1 on page 3. Thus the recitations in this clause are rendered unclear and indefinite by the lack of clear association between the recited steps/functions and the recited application, services, and programs. The overall relationship between what steps and functionality are performed by the system to which claim 1 is directed, and what steps and functions are performed by the “first self-executing program” are also rendered unclear and indefinite.
Regarding claim 6, said claim recites further limitations to the “transferring” step at the conclusion of claim 1, and recites that it occurs “in response to a set of one or more criteria being met”. The meeting these criteria are then specified, describing three distinct “verifying” steps. In claim 1 the “transferring” step is recited as being performed subsequent to a “validating” step, each of these operations being claimed as being performed by “the first self-executing program”. However, claim 6 attaches no such limitation to the three “verifying” steps claimed. It thus is unclear whether the “system for facilitating” of claim 1, the “the first self-executing program”, or some other entity given antecedent basis in claim 1 is responsible for performing the particular “verifying” steps recited in claim 6.
Regarding claims 2, 3, and 6 – 9, said claims further specify the subject matter of claim 1 and fail to clarify the issues noted above. These dependent claims inherit the above noted issues in parent claim 1.
Regarding claim 10, line 10 on page 5 recites “issuing, after a first previously-minted unique digital asset is listed and selected” (emphasis added). There is no antecedent basis for a listing and selecting operation in claim 10. Thus, the scope of the clause on line 10 along the claim as a whole is rendered unclear and indefinite, as further specifying what is performed after an undefined and undescribed listing and selecting step is unclear and indefinite. For example, there is no discussion in the claim regarding the context and scope for interpreting a listing a selecting operation, and thus the meaning of performing an action after this undefined listing and selecting is indefinite. Regarding claims 11 – 14 and 21 – 26, said claims further specify the subject matter of claim 10 and fail to clarify the issues noted above. These dependent claims inherit the above noted issues in parent claim 10.
Regarding claim 15, line 9 on page 7 recites language directly analogous to the language in claim 10 (discussed above) and thus suffers from issues corresponding to those noted in claim 10.
Regarding claim 20, said claim further specifies the subject matter of claim 15 and fail to clarify the issues noted above. This dependent claim inherits the above noted issues in parent claim 15.
In order to further the goals of compact prosecution and ensure complete examination, the above language and claims have been interpreted broadly. Specific comments are provided in the rejections presented below regarding the broadest reasonable interpretation applied to the claim limitations.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 3, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan (US-20230394481-A1) in view of OpenSea (OpenSea. How To buy an NFT. https://opensea.io/learn/nft/how-to-buy-nft. (Year: 2022)), further in view of Minaev (Minaev, A. "How to Buy an NFT: A Guide for Beginners". https://cryptodose.net/learn/how-to-buy-nft/. May 13. (Year: 2022)), OpenZeppelin (OpenZeppelin. etherscan-verify. "Could someone reuse the signature from a previous NFT mint transaction to mint another token?". October 11. (Year: 2021)) and Asa (US-20200320519-A1). Regarding claim 1, Padmanabhan shows a system for facilitating initial deployments of cryptographic assets across a computer network in a cryptographically secure manner while mitigating interactions with computer programs that simulate human activity (note this recitation regarding what the claimed system is “for” is treated as non-functional descriptive material corresponding to a statement of the system’s intended use, and thus is not accorded patentable weight), the system comprising: one or more processors configured to perform operations (Fig. 18, [241,306]) comprising: generating a first request (Fig. 1 step 104, showing “Receive a request . . .”, said received request implicitly being previously generated, further discussion e.g., in [54], see “a request is received . . .”) from a first user account ([63,78] discussing a “database system account”; as illustrated in the overview of the database system 300 shown in Fig. 3, and discussed in [64] the database system contains entries identifying both a “wallet ID” and an “account ID”) on a platform service (Fig. 3 item 320, [61-63] discussing an account for the database system, which is representing the claimed platform service) that resides on a server that includes at least one processor of the one or more processors (Figs. 16, 18, [211]); based on the first request from the first user account on the platform service (Fig. 1 step showing where the validation step 106 is performed based on the request reception at step 104), determining a required account characteristic specified ([43] discussing request validation tied to a particular requesting wallet ID); validating, by the platform service ([83] discussing where the database system validates requests), the first user account on the platform service based on comparing the required account characteristic specified to a first account characteristic of the first user account on the platform service ([41,43,63], Fig. 3 items 306, 318, 320, where user accounts on the database system are tied to both wallet IDs and account IDs, and this data is used to validate requests, such as validating that a requesting user matches the requirements for an NFT transfer, discussed in [32,38,42], and cited above); and issuing, by the platform service ([32,38] discussing where the database system is configured to generate vouchers), a first signature ([32,38] discussing a voucher signed with a private key, thus creating the claimed “first signature”, which is in accordance with Applicant’s specification [42] disclosing combining a private key with data) to a first address ([198] discussing where wallets are communicated with via their addresses, suggesting communication such as the this issuing step be performed via said address) of a cryptography-based storage application ([32,38] discussing a “voucher holder”, where said voucher will “authorize particular wallets”, the wallet representing the storage application, an interpretation in line with Applicant’s specification [20]), that is separate and distinct from the first user account on the platform service (Fig. 3 item 306 and [63] showing use of a wallet table containing wallet identifiers (but not the actual wallets themselves), [63] suggests the wallets are “in a public trust ledger”, i.e., a blockchain, rather than the database/platform service), wherein the first signature provides authorization ([32] discussing where “a voucher holder may then execute . . .”, [41] see “allowing particular wallet IDs to perform actions. . .”, [52], see “a voucher may authorize . . . “) to obtain the first previously-minted ([273] noting “the action may involve purchasing a token that has already been minted”) unique digital asset, use of a unique identifier corresponding to the first previously-minted unique digital asset ([92,95] discussing an item token with a digital asset ID, which corresponds to an NFT), and is for a first self-executing program, of a crypto service that is separate from the platform service and the cryptography-based storage application ([32,52] discussing a “smart contract” which [34,53,86] note may be executed on a “public trust ledger”, i.e., blockchain), that authorizes a transfer ([32] noting that before an action such as an asset transfer is performed, “the smart contract may perform one or more validation operations”) of the first previously-minted unique digital asset ([273] noting where the tokens/NFTs discussed above may have already been minted); receiving, by the first self-executing program, the first signature (Fig. 1 showing the smart contract process which validates requests based on voucher (i.e., first signature) authorizations, and [32] discussing where the voucher is provided to the smart contract by the voucher holder); validating, by the first self-executing program, the first signature (Fig. 1 step 106 showing “Perform the action after validating” and [32] discussing the smart contract performing validation operations after being provided the signature/signed voucher); and transferring, by the first self-executing program ([85-86] discussing the smart contract executing to perform actions such as transfer of ownership), the first previously-minted unique digital asset ([273]) to the first address of the cryptography-based storage application ([38-40] nothing where tokens/NFTs can be transferred directly to a recipients wallet, and [198] noting that wallets are communicated with via their addresses).
Padmanabhan does not show: generating for display, on a user interface, a listing for a first unique digital asset collection; receiving a user selection selecting a visual element corresponding to a first previously-minted unique digital asset of the first unique digital asset collection; acting based on the user selection,
use of a required characteristic specified by a creator of a unique digital asset collection;
where the cryptography-based storage application/wallet is on a user device. OpenSea shows generating for display, on a user interface, a listing for a first unique digital asset collection (pg. 2 lines 42-47 discussing setting up websites to sell NFTs as well as reselling of NFTs on other NFT marketplaces, such as the OpenSea marketplace discussed at the bottom of pg. 3; also note the figure at the bottom of pg. 2 and the top of pg. 3 showing an NFT collection called “Archetype by Kjetil Golid” an exemplary unique digital asset collection, and also the “Generativemasks collection” discussed on pg. 10);
receiving a user selection selecting a visual element (e.g., via the “Buy Now” visual element corresponding to the NFT #9626 basketball card shown on pg. 4 and discussed on lines 13 – 54 of pg. 4) corresponding to a first previously-minted unique digital asset of the first unique digital asset (an NFT minted by its creator and offered for sale or for resale, with the prospective buyer choosing one to purchase on the website interface; pg. 2 lines 20-47, pg. 3 lines 1-8; note that a resold NFT is implicitly previously minted) collection (pgs. 7 and 10, showing a “Buy now” button for an NFT in the “Generativemasks collection”); and
acting based on the user selection (pg. 4 lines 1 – 25 and pg. 6 lines 43-46, discussing a user executing a buy operation),
use of a required characteristic specified by a creator of a unique digital asset collection (pg. 2 lines 24 – 26 discussing a “creator” of NFT work, including, in Step 1 on pgs. 2-3 where a project for NFT sale may be formed by creation of the project’s own website, each sale point having its own specifications such as supported blockchains, fee structures, “and more”; note the discussion of NFT creators and projects on pg. 3 lines 44-50); where the cryptography-based storage application/wallet is on a user device (pg. 2 lines 8 – 11 discussing a “hardware wallet” implemented as a “physical device that you plug into your computer”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of Padmanabhan with the purchasing interface of OpenSea in order to simplify NFT exchange for owners or buyers; the well-understood web-based interface suggested by OpenSea (and the use of prior art hardware wallets as also suggested by OpenSea) allow for re-use of existing technology with which system users are likely to be familiar and thus comfortable utilizing, which would achieve the predictable result of providing a more accessible, user-friendly system and interface, facilating platform growth via new users. The above combination does not show: where the digital asset is issued after it is listed and selected, and based on the platform service validating the first user account.
Minaev shows where the digital asset is issued after it is listed and selected (pg. 5 lines 1 - 31 discussing a “Buy Now” option for NFTs listed on the “OpenSea website”, resulting in “the NFT in your MetaMask wallet”, the NFT being within a purchasing user’s wallet being within the broadest reasonable interpretation of being “issued”) and based on the platform service validating the first user account (pg. 4 discussing the Metamask/OpenSea platforms service, and the steps of adding payment currency such that you “have funds in your wallet”, ensuring you are “logged into your OpenSea account” and that your wallet is “linked” to said account; requiring a linked account that you are logged into is interpreted as within the broadest reasonable interpretation the account validation). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of the above combination, including the voucher-based purchasing of the above combination with the issuing based on account verification steps discussed in Minaev in order to better ensure the purchase completes reliably (via ensuring that the buying user has the funds to complete the purchase and a linked wallet with which to receive the purchased NFT). The above combination, while showing the digital asset collection (e.g., OpenSea, pg. 3) and creator-controlled distribution and requirements specifications (OpenSea, pgs. 2-3 discussing creator projects and their own websites, with particular blockchain and fee requirements) does not show:
where the first signature includes a unique digital asset identifier. OpenZeppelin shows where the first signature includes a unique digital asset identifier (pg. 1 lines 16-20 where the required “signed message” includes the “tokenID”, and also further on pg. 5 showing the “PreSaleVoucher” containing a “tokenID”), and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of the above combination with the voucher redemption techniques of OpenZeppelin, specified in disclosed code, in order to utilize previously written implementation (i.e., the code) thus saving on development time, as well as to ensure that the token/digital asset distribution function logic has both the identifiers of the asset to be distributed and the rules for its distribution, thus ensuring that said distribution function logic acts within the intended rules and parameters of its creator.
While showing where cryptography-based storage application (i.e., wallets) communicate data from their addresses (e.g., Padmanabhan, [198]), the above combination does not show where the self-executing program receives communication from said cryptography-based storage application.
Asa shows where the self-executing program receives from the cryptography-based storage application ([34,38] discussing where a user’s crypto wallet (i.e., the claimed “storage application”) can request actions such as asset transfers, via sending a message to a smart contract (i.e., the claimed “self-executing program”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of the above combination with the crypto asset rule management and action control enabled by Asa in order to provide asset rule enforcement functionality using existing digital resources such as smart contracts and digital wallets, thus enabling more specific controls and rules for digital asset exchanges and thus better ensuring user interactions with digital assets are predictable and reliable.
Regarding claim 2, the above combination further shows wherein validating the first signature comprises verifying that the first signature was issued by a second address associated with the platform service (Padmanabhan, [32,38] discussing where “The voucher may be signed with a private key associated with the database system”, the voucher being subject to validation, [52-53] further discussing verification that the signed voucher’s validity, where the database system’s signature, e.g., is verified by the smart contract; see also [82-83,88-89,122,130,173]).
Regarding claim 3, the above combination further shows wherein validating the first signature comprises verifying that the first signature was received from the first address of the cryptography-based storage application (Padmanabhan, [82-83,88-92], also Asa [32-38] discussing smart contract verification prior to execution).
Regarding claim 6, the above combination further shows wherein transferring the first previously-minted (Padmanabhan, [273] noting “the action may involve purchasing a token that has already been minted.”) unique digital asset occurs in response to a set of one or more criteria being met, the set of one or more criteria including: verifying that the first signature was issued by a second address associated with the platform service (Padmanabhan, [52-53] discussing verification that the signed voucher’s validity, where the database system’s signature, e.g., is verified by the smart contract; see also [82-83,88-89,122,130,173]); verifying that the first signature was received from the first address of the cryptography-based storage application (Padmanabhan, [82-83,88-89]); and verifying that the first signature was received by a predefined time (OpenZeppelin, pg. 5 lines 40-44 discussing validation to be within the particular time period when the presale value is true/active, and Padmanabhan, [294] discussing where a “transaction ID may only be valid for a designated period of time”, [52] noting that this information is part of the signed voucher).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea, Minaev, OpenZeppelin, and Asa as applied to claim 1 above, further in view of Lee (US-20230351369-A1) and Doyle (Doyle, B. "Instagram Allowing Creators & Brands to Sell NFTs". https://wallaroomedia.com/blog/social-media/why-instagram-embracing-nfts-is-huge-how-your-brand-can-capitalize/. (Year: 2022)).
Regarding claim 7, the above combination shows claim 1. The above combination does not show wherein the required account characteristic comprises a social media characteristic of the first user account, wherein retrieving the first account characteristic for the first user account comprises retrieving the social characteristic for the first user account, and wherein validating the first user account includes verifying the social characteristic. Lee shows wherein the required account characteristic comprises a social characteristic of the first user account, wherein retrieving the first account characteristic for the first user account comprises retrieving the social characteristic for the first user account, and wherein validating the first user account includes verifying the social characteristic (Lee, [26,38] discussing verification including “participation or membership” by a user in an “event”, and [147], discussing tracking attendance at a “social event” or activity that may “signal membership in a club”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the verification of Lee in order to better control access to resources while also utilizing the NFTs to influence social behavior, enabling improvements in marketing and otherwise spreading awareness of the resultant system.
The above combination does not show where the social characteristic is a social media characteristic, validating includes verifying that a social media account linked to the first user account follows a particular social media account. Doyle shows where the social characteristic is a social media characteristic (as discussed below, who one follows on social media such as Twitter is a characteristic of a Twitter account holder), and validating includes verifying that a social media account linked to the first user account follows a particular social media account (pg. 3 lines 13-22, pg. 4 lines 16-27, which suggests brands facilitate “integrating NFTs into the rest of the social media + community building strategy” and suggests to “ask people to follow you on Twitter . . . in order to enter a contest to win an exclusive NFT”; note entry into a contest that is contingent on the “follow” action Twitter (a well-known social media platform) fully suggests that the “follow” action is validated, else the “follow” action would not actually need to be performed, and the resultant disclosure would be non-operational).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the verification of Doyle in order to increase the number of mechanisms available for incentivizing user behavior and further improve public awareness of the resultant system by utilizing the marketing awareness created through the resultant social media activity.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea, Minaev, OpenZeppelin, and Asa as applied to claim 1 above, further in view of Maier (US-20240112177-A1).
Regarding claim 8, the above combination shows claim 1. The above combination does not show wherein the required account characteristic comprises a know-your-customer characteristic of the first user account, wherein retrieving the first account characteristic for the first user account comprises retrieving the know-your-customer characteristic for the first user account, and wherein validating the first user account includes verifying that the first user account has completed a know-your-customer process Maier shows wherein the required account characteristic comprises a know- your-customer characteristic of the first user account ([21], discussing identity management system” that utilizes a KYC (know-your-customer) system to verify users, all performed in a cryptographic blockchain environment, noted in [22] to “advantageously facilitates identity verification and transaction authorization” and can “connect a verified identity to a wallet”. An identity being verified is an example of a “know-your-customer characteristic”), wherein retrieving the first account characteristic for the first user account comprises retrieving the know-your-customer characteristic for the first user account ([21-22]), and wherein validating the first user account includes verifying that the first user account has completed a know-your-customer process ([22] suggests that account “has completed a know-your-customer process” via the discussion of an identity being verified via the KYC process discussed in [21-22] that ties a “blockchain network wallet to a specific user”; as [29] notes, the KYC process allows the client to “initiate a transaction requiring identity verification”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the customer verification of Maier in order to enable compliance with various financial regulations, such as those requiring a KYC process.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea, Minaev, OpenZeppelin, and Asa as applied to claim 1 above, further in view of Lee. Regarding claim 9, the above combination shows validation of a required account characteristic (Padmanabhan, [32,38] discussing particular users/accounts tied to executing an NFT ownership transfer) and retrieving the first account characteristic for the first user account (Padmanabhan, [53,285]). The above combination does not show wherein the required account characteristic comprises ownership of an additional unique digital asset by the first address, and wherein retrieving the first account characteristic for the first user account comprises determining whether the first address currently owns the additional unique digital asset based on a current state of a blockchain. Lee suggest where the required account characteristic comprises ownership of an additional unique digital asset by the first address ([23] discussing verification operations that can include a rule which is “conditional on ownership of one of the non-fungible tokens of the non-fungible token collection . . .” and [40] discussing that ownership of “two or more” NFTs may be required, or as [34-35] note, a condition may be ownership of at least one NFT (different from an exemplary NFT being purchased) that is part of a collection), and wherein retrieving the first account characteristic for the first user account comprises determining whether the first address ([134,145]) currently owns the additional unique digital asset based on a current state of a blockchain ([23,46,75] where NFT ownership “maybe be a gating condition for granting access to particular online resources”, with [69] noting NFT ownership is recorded “on-chain and verifiable”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT purchasing discussed in the above combination with existing NFT ownership verification of Lee in order to better control access to resources, such a requiring existing ownership of one asset to acquire another asset, and thus further encourage more purchasing activity on the resultant platform while increasing the perceived value of a user’s existing NFTs.
Claims 10, 15, and 20 – 26 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea and Minaev.
Regarding claim 10, Padmanabhan shows a method for facilitating initial deployments of cryptographic assets across a computer network in a cryptographically secure manner while mitigating interactions with computer programs that simulate human activity (note that what the method is “for” is interpreted as non-functional descriptive material corresponding to a statement of the intended use, and thus is not accorded patentable weight), the method comprising: receiving a first request (Fig. 1 step 104, showing “Receive a request . . .”, further discussion e.g., in [54], see “a request is received . . .”) from a first user account ([63,78] discussing a “database system account”; as illustrated in the overview of the database system 300 shown in Fig. 3, and discussed in [64] the database system contains entries identifying both a “wallet ID” and an “account ID”); determining a required account characteristic based on the first request (Fig. 1 step showing where the validation step 106 is performed based on the request reception at step 104, and [43] discussing request validation tied to a particular requesting wallet ID); retrieving a first account characteristic for the first user account ([32] discussing the smart contract performing validation steps, [38,41] noting that this includes whether the requestor is authorized to perform a particular transaction); validating ([83] discussing where the database system validates requests) the first user account based on comparing the required account characteristic to the first account characteristic ([41,43,63], Fig. 3 items 306, 318, 320, where user accounts on the database system are tied to both wallet IDs and account IDs, and this data is used to validate requests, such as validating that a requesting user matches the requirements for an NFT transfer, discussed in [32,38,42], and cited above); and issuing ([32,38] discussing where the database system is configured to generate vouchers) to a first address ([198] discussing where wallets are communicated with via their addresses, suggesting communication such as the this issuing step be performed via said address) of a cryptography-based storage application ([32,38] discussing a “voucher holder”, where said voucher will “authorize particular wallets”, the wallet representing the storage application, an interpretation in line with Applicant’s specification [20]), a first signature that is specific to the first previously-minted unique digital asset ([32,38] discussing a voucher signed with a private key, thus creating the claimed “first signature”, which is in accordance with Applicant’s specification [42] disclosing combining a private key with data to create a signature) and that is for a first self-executing program that authorizes a transfer of the first previously-minted unique digital asset (note that the “at that is for. . . ” language is interpreted as non-functional descriptive material corresponding to a statement of the intended use, and thus is not accorded patentable weight). Padmanabhan, while showing operations directed to a previously-minted unique digital asset ([273]), does not show where the previously-minted unique digital asset is listed and selected, and where the cryptography-based storage application/wallet is on a user device. OpenSea shows where the previously-minted unique digital asset (an NFT minted by its creator and offered for sale or for resale, with the prospective buyer choosing one to purchase on the website interface; pg. 2 lines 20-47, pg. 3 lines 1-8; note that a resold NFT is implicitly previously minted) is listed (pg. 3 lines 1 - 33 showing a “collection on OpenSea”) and selected (e.g., via the “Buy Now” visual element corresponding to the NFT #9626 basketball card shown on pg. 4 and discussed on lines 13 – 54 of pg. 4),
where the cryptography-based storage application/wallet is on a user device (pg. 2 lines 8 – 11 discussing a “hardware wallet” implemented as a “physical device that you plug into your computer”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of Padmanabhan with the purchasing interface of OpenSea in order to simplify NFT exchange for owners or buyers; the well-understood web-based interface suggested by OpenSea (and the use of prior art hardware wallets as also suggested by OpenSea) allow for re-use of existing technology with which system users are likely to be familiar and thus comfortable utilizing, which would achieve the predictable result of providing a more accessible, user-friendly system and interface, facilating platform growth via new users. The above combination does not show: where the digital asset is issued after it is listed and selected, and based on the platform service validating the first user account.
Minaev shows where the digital asset is issued after it is listed and selected (pg. 5 lines 1 - 31 discussing a “Buy Now” option for NFTs listed on the “OpenSea website”, resulting in “the NFT in your MetaMask wallet”, the NFT being within a purchasing user’s wallet being within the broadest reasonable interpretation of being “issued”) and based on the platform service validating the first user account (pg. 4 discussing the Metamask/OpenSea platforms service, and the steps of adding payment currency such that you “have funds in your wallet”, ensuring you are “logged into your OpenSea account” and that your wallet is “linked” to said account; requiring a linked account that you are logged into is interpreted as within the broadest reasonable interpretation the account validation). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of the above combination, including the voucher-based purchasing of the above combination with the issuing based on account verification steps discussed in Minaev in order to better ensure the purchase completes reliably (via ensuring that the buying user has the funds to complete the purchase and a linked wallet with which to receive the purchased NFT).
Regarding claim 15, Padmanabhan shows one or more non-transitory computer readable media having instructions recorded thereon that when executed by one or more processors cause operations comprising: determining a required account characteristic based on a first request from a first user account (Fig. 1 showing a request received in step 104 and a validating step for the request in step 106, as [32,38,41] each note, requests may be limited to particular authorized wallets, wallets being tied to the accounts in the database system of Fig. 3 (illustrated in item 306 linking items 318 and 320) and as discussed in [41,43,63], user accounts on the database system are tied to both wallet IDs and account IDs, and this data is used to validate requests); retrieving a first account characteristic for the first user account ([32] discussing the smart contract performing validation steps, [38,41] noting that this includes whether the requestor is authorized to perform a particular transaction); validating ([83] discussing where the database system validates requests) the first user account based on comparing the required account characteristic to the first account characteristic ([41,43,63], Fig. 3 items 306, 318, 320, where user accounts on the database system are tied to both wallet IDs and account IDs, and this data is used to validate requests, such as validating that a requesting user matches the requirements for an NFT transfer, discussed in [32,38,42], and cited above); issuing ([32,38] discussing where the database system is configured to generate vouchers), to a first address ([198] discussing where wallets are communicated with via their addresses, suggesting communication such as the this issuing step be performed via said address) of a cryptography-based storage application ([32,38] discussing a “voucher holder”, where said voucher will “authorize particular wallets”, the wallet representing the storage application, an interpretation in line with Applicant’s specification [20]), a first signature that is specific to the first previously-minted unique digital asset ([32,38] discussing a voucher signed with a private key, thus creating the claimed “first signature”, which is in accordance with Applicant’s specification [42] disclosing combining a private key with data to create a signature) and that is for a first self-executing program ([32,52] discussing a “smart contract” which [34,53,86] note may be executed on a public trust ledger”, i.e., blockchain) that authorizes a transfer ([32] noting that before an action such as an asset transfer is performed, “the smart contract may perform one or more validation operations”) of the first previously-minted unique digital asset ([273] noting where the tokens/NFTs discussed above may have already been minted); and executing the first self-executing program using the first signature ([32] where the smart contract performs validation operations utilizing the voucher, which as [260,289] notes include determining the voucher was created with/contains the required signature). Padmanabhan does not show where the cryptography-based storage application/wallet is on a user device. OpenSea shows where the cryptography-based storage application/wallet is on a user device (pg. 2 lines 8 – 11 discussing a “hardware wallet” implemented as a “physical device that you plug into your computer”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of Padmanabhan with the wallet options disclosed in OpenSea in order to ensure that popular wallet types are supported, and thus encourage existing wallet holders to utilize the resultant system.
The above combination does not show: where the digital asset is issued after it is listed and selected and based on the platform service validating the first user account.
Minaev shows where the digital asset is issued after it is listed and selected (pg. 5 lines 1 - 31 discussing a “Buy Now” option for NFTs listed on the “OpenSea website”, resulting in “the NFT in your MetaMask wallet”, the NFT being within a purchasing user’s wallet being within the broadest reasonable interpretation of being “issued”) and based on the platform service validating the first user account (pg. 4 discussing the Metamask/OpenSea platforms service, and the steps of adding payment currency such that you “have funds in your wallet”, ensuring you are “logged into your OpenSea account” and that your wallet is “linked” to said account; requiring a linked account that you are logged into is interpreted as within the broadest reasonable interpretation the account validation). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of the above combination, including the voucher-based purchasing of the above combination with the issuing based on account verification steps discussed in Minaev in order to better ensure the purchase completes reliably (via ensuring that the buying user has the funds to complete the purchase and a linked wallet with which to receive the purchased NFT). Regarding claim 20, the above combination further shows wherein the first signature comprises a first blockchain operation characteristic, wherein the first blockchain operation (Padmanabhan, [51], discussing to “perform one or more blockchain-related operations”) characteristic comprises a value for obtaining the first previously-minted unique digital asset (Padmanabhan, [32] noting “The voucher may include information such as . . . a transaction price” associated with “minting a token . . . on a blockchain” and [38] disclosing the voucher includes “a transaction price paid by the minter to mint the token”), and wherein the first signature (Padmanabhan, [32] describing “ The voucher may be signed with a private key associated with the database system”) comprises authorization to obtain the first previously-minted (Padmanabhan, [273] reciting “As another example, the action may involve purchasing a token that has already been minted.”) unique digital asset for the value (Padmanabhan, [32] discussing “a voucher authorizing an action such as minting a token to be performed at a smart contract on a blockchain”).
Regarding claim 21, the above combination further shows wherein the first signature (Padmanabhan, [32] describing “ The voucher may be signed with a private key associated with the database system”) specifies a time window during which the first signature can be used to obtain the first previously-minted unique digital asset (Padmanabhan, [294] discussing where a “transaction ID may only be valid for a designated period of time”, [52] noting that this information is part of the signed voucher).
Regarding claim 22, the above combination further shows wherein the first account characteristic comprises a requirement (Padmanabhan, [294] discussion voucher redemption time requirements, [32,38,41] discussing requirements related to who may redeem the voucher and transaction price requirements) added by a creator of the first previously-minted unique digital asset for obtaining the first previously-minted unique digital asset (OpenSea, pg. 2 lines 24 – 26 discussing a “creator” of NFT work, including, in Step 1 on pgs. 2-3 where a project for NFT sale may be formed by creation of the project’s own website, each sale point having its own specifications such as supported blockchains, fee structures, “and more”; note the discussion of NFT creators and projects on pg. 3 lines 44-50; the redeeming user would implicitly have to have an account tied to support the indicated blockchain, the resources to comply with the fee structure, etc.).
Regarding claim 23, the above combination further shows determining, based on the first request (Padmanabhan, Fig. 1 step showing where the validation step 106 is performed based on the request reception at step 104) , requirements (Padmanabhan, [294] discussion voucher redemption time requirements, [32,38,41] discussing requirements related to who may redeem the voucher and transaction price requirements) added by a creator of the first previously-minted unique digital asset for obtaining the first previously-minted unique digital asset (OpenSea, pg. 2 lines 24 – 26 discussing a “creator” of NFT work, including, in Step 1 on pgs. 2-3 where a project for NFT sale may be formed by creation of the project’s own website, each sale point having its own specifications such as supported blockchains, fee structures, “and more”; note the discussion of NFT creators and projects on pg. 3 lines 44-50; the redeeming user would implicitly have to have an account tied to support the indicated blockchain, the resources to comply with the fee structure, etc.), wherein the requirements include the required account characteristic (Padmanabhan, [32,38,41] discussing where vouchers are formulated using particular requirement characteristics).
Regarding claim 24, the above combination further shows wherein the first signature comprises a first blockchain operation (Padmanabhan, [51], discussing to “perform one or more blockchain-related operations”) characteristic for a first blockchain operation (Padmanabhan, [32] noting “The voucher may include information such as . . . a transaction price” associated with “minting a token . . . on a blockchain” and [38] disclosing the voucher includes “a transaction price paid by the minter to mint the token”).
Regarding claim 25, the above combination further shows wherein the first self-executing program includes conditions related to a blockchain operation (Padmanabhan, [51], discussing to “perform one or more blockchain-related operations”) to obtain (Padmanabhan, [294] discussion voucher redemption time requirements, [32,38,41] discussing requirements related to who may redeem the voucher and transaction price requirements) the first previously-minted unique digital asset (Padmanabhan, [273] noting “the action may involve purchasing a token that has already been minted”).
Regarding claim 26, the above combination further shows wherein the conditions include a value for the blockchain operation (Padmanabhan, [32] noting “The voucher may include information such as . . . a transaction price” associated with “minting a token . . . on a blockchain” and [38] disclosing the voucher includes “a transaction price paid by the minter to mint the token”).
Claim 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea and Minaev as applied to claim 10 above, further in view of Lee. Regarding claim 11, the above combination further shows wherein retrieving the first account characteristic for the first user account (Padmanabhan, [53,285]) and consideration of required value for the first previously-minted unique digital asset (Minaev, discussing on pg. 4 lines 44 – 54 that a user must “have funds in their wallet, and your wallet has to be linked to the OpenSea account before completing the transaction”, pg. 5 lines 18 – 23 noting that transaction confirmation includes review of “the amount of ETH you will spend on an NFT”, coming from the user’s wallet, and pg. 6 lines 1 – 5 nothing the indicated “amount will be taken out of your wallet automatically”, suggesting this amount being the required value for the NFT) The above combination does not show all of: retrieving a current amount in the first address of the cryptography-based storage application for the first user account, and wherein validating the first user account based on the first account characteristic comprises determining whether the current amount equals or exceeds a required value. Lee shows retrieving a current amount in the first address of the cryptography-based storage application for the first user account, and wherein validating the first user account based on the first account characteristic comprises determining whether the current amount equals or exceeds a required value (Lee, [28] discussing applying an “access rule” which may “be based on the current balance being above a minimum amount of currency or coins”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT exchange functionality of the above combination with the value consideration of Lee in order to ensure that prospective users have the required account balances before attempting to execute an asset transfer, thus avoiding transactions that will fail and thus waste the systems computation resources.
Regarding claim 14, the above combination shows claim 10. The above combination does not show wherein the required account characteristic comprises ownership of an additional unique digital asset by the first address, and wherein retrieving the first account characteristic for the first user account comprises determining whether the first address currently owns the additional unique digital asset based on a current state of a blockchain.
Lee suggests where the required account characteristic comprises ownership of an additional unique digital asset by the first address ([23] discussing verification operations that can include a rule which is “conditional on ownership of one of the non-fungible tokens of the non-fungible token collection . . .” and [40] discussing that ownership of “two or more” NFTs may be required, or as [34-35] note, a condition may be ownership of at least one NFT (different from an exemplary NFT being purchased) that is part of a collection), and wherein retrieving the first account characteristic for the first user account comprises determining whether the first address ([134,145]) currently owns the additional unique digital asset based on a current state of a blockchain ([23,46,75] where NFT ownership “maybe be a gating condition for granting access to particular online resources”, with [69] noting NFT ownership is recorded “on-chain and verifiable”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the NFT purchasing discussed in the above combination with existing NFT ownership verification of Lee in order to better control access to resources, such a requiring existing ownership of one asset to acquire another asset, and thus further encourage more purchasing activity on the resultant platform while increasing the perceived value of a user’s existing NFTs.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea and Minaev, as applied to claim 10 above, further in view of Lee and Doyle.
Regarding claim 12, the above combination shows claim 10. The above combination does not show wherein the required account characteristic comprises a social characteristic of the first user account, wherein retrieving the first account characteristic for the first user account comprises retrieving the social characteristic for the first user account, and wherein validating the first user account includes verifying the social characteristic. Lee shows wherein the required account characteristic comprises a social characteristic of the first user account, wherein retrieving the first account characteristic for the first user account comprises retrieving the social characteristic for the first user account, and wherein validating the first user account includes verifying the social characteristic (Lee, [26,38] discussing verification including “participation or membership” by a user in an “event”, and [147], discussing tracking attendance at a “social event” or activity that may “signal membership in a club”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the verification of Lee in order to better control access to resources while also utilizing the NFTs to influence social behavior, enabling improvements in marketing and otherwise spreading awareness of the resultant system.
The above combination does not show where the social characteristic is a social media characteristic, validating includes verifying that a social media account linked to the first user account follows a particular social media account. Doyle shows where the social characteristic is a social media characteristic (as discussed below, who one follows on social media such as Twitter is a characteristic of a Twitter account holder), and validating includes verifying that a social media account linked to the first user account follows a particular social media account (pg. 3 lines 13-22, pg. 4 lines 16-27, which suggests brands facilitate “integrating NFTs into the rest of the social media + community building strategy” and suggests to “ask people to follow you on Twitter . . . in order to enter a contest to win an exclusive NFT”; note entry into a contest that is contingent on the “follow” action Twitter (a well-known social media platform) fully suggests that the “follow” action is validated, else the “follow” action would not actually need to be performed, and the resultant disclosure would be non-operational).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the verification of Doyle in order to increase the number of mechanisms available for incentivizing user behavior and further improve public awareness of the resultant system by utilizing the marketing awareness created through the resultant social media activity.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea and Minaev as applied to claim 1 above, further in view of Maier.
Regarding claim 13, the above combination shows claim 10. The above combination does not show wherein the required account characteristic comprises a know-your-customer characteristic of the first user account, wherein retrieving the first account characteristic for the first user account comprises retrieving the know-your-customer characteristic for the first user account, and wherein validating the first user account includes verifying that the first user account has completed a know-your-customer process Maier shows wherein the required account characteristic comprises a know- your-customer characteristic of the first user account ([21], discussing identity management system” that utilizes a KYC (know-your-customer) system to verify users, all performed in a cryptographic blockchain environment, noted in [22] to “advantageously facilitates identity verification and transaction authorization” and can “connect a verified identity to a wallet”. An identity being verified is an example of a “know-your-customer characteristic”), wherein retrieving the first account characteristic for the first user account comprises retrieving the know-your-customer characteristic for the first user account ([21-22]), and wherein validating the first user account includes verifying that the first user account has completed a know-your-customer process ([22] suggests that account “has completed a know-your-customer process” via the discussion of an identity being verified via the KYC process discussed in [21-22] that ties a “blockchain network wallet to a specific user”; as [29] notes, the KYC process allows the client to “initiate a transaction requiring identity verification”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the customer verification of Maier in order to enable compliance with various financial regulations, such as those requiring a KYC process.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
/GLENTON B BURGESS/Supervisory Patent Examiner, Art Unit 2454
Prosecution Insights