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 .
Response to Arguments
Applicant's arguments filed 7/22/2026 have been fully considered and are partially persuasive. While the amendments to claim 1 have clarified several issues and overcome previously presented rejections made under 35 USC 112, the remainder of the arguments are unpersuasive; these arguments are addressed below and are found unpersuasive for the reasons given below. Beginning on page 10 and continuing through page 11, Applicant addresses the rejection of claim 6 under 35 USC 112. Applicant asserts that the claim “does not recite that the transferring is performed ‘after’ the validating.” Applicant’s assertion is not persuasive. Though the claim does not utilize the word “after”, there is no other way the claim can otherwise be interpreted. The various clauses of claim 1 (upon which claim 6 relies) require a specific order due to language chosen by Applicant. For example, line 8 on page 2 of claim 1 recites “receiving a user selection”, and line 10 subsequently recites “based on the user selection”. Thus, the recitation in line 10 is required to be performed after the recitation in line 8 (or alternatively, the recitation in line 8 must be performed “prior” to the recitation in line 10). The claim need not recite the exact word “after” or “prior” in order to require such an interpretation. Claim 6 then initially recites a transferring “in response to” some criteria being met. Similar to the above examples, this requires the transferring coming after the criteria being met (despite the lack of the work “after”). The claim thus can clearly require a particular order of operations without explicitly reciting words such as “after”. Applicant’s arguments on pages 10 – 11 directed to claim 6 thus cannot be held as persuasive. Next on page 11, Applicant addresses claim 21. And argues the Examiner noting claim 21 is rejected for “the same reasons as claims 1 and 20” is not a reasonable assertion and does not support a rejection of claim 21 under 35 USC 112. Applicant argues “Neither claim 1
nor claim 20 recites a signature that ‘specifies a time window during which the first signature can be used’; that recitation appears only in previously pending claim 21.” Applicant’s argument cannot be held as persuasive as the rejection on page 7 of the prior Office Action clearly states that “specifies a time window during which the first signature can be used” is relevant to the language of claim 21. The issues appearing in claims 1 and 20 are related to “the above discussed signature”; the problematic signature recitations appearing in claim 1 and 20 and discussed in their corresponding rejections are present in dependent claim 21 via the recitation in claim 21 that further specifies the “signature”. In other words, the issues with the “signature” noted in claims 1 and 20 are applicable to claim 21 because claim 21 further limits this “signature” and utilizes the language in the same manner that resulted in the issues noted in claims 1 and 20. Continuing on pages 11 – 12, Applicant argues that the rejection of claims 10 and 15 “is misplaced” as claims 10 and 15 do “not refer back, by a definite article, to any previously unrecited ‘listing’ or ‘selecting’ step”.
In response, the Examiner notes that a failure to provide sufficient antecedent basis for a limitation in a claim can occur in situations that do not rely on the lack of a particular definite article. In this case, the claim explicitly recites an action to be performed “after” a step that has no prior description or support. This is an indefinite recitation for the reasons given on page 11 of the prior Office Action; Applicant’s argument cannot be held as persuasive as the claim language remains indefinite for the reasons previously stated.
Concluding on page 12 and continuing to page 13, Applicant addresses the rejections presented under 35 USC 103. After summarizing the prior art relied upon by the Examiner along with summarizing how to make a proper rejection under 35 USC 103, on page 14 Applicant quotes a section of claim 1 and asserts the prior art fails to show this language. To support this assertion, Applicant argues that neither Padmanabhan nor OpenSea show “issuing a first signature to a first address of a cryptography-based storage application”. The Examiner notes that the language was rejected as follows on page 14 of the prior Office Action, via citations to
Padmanabhan:
“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]) . . .”
Applicant’s support for this assertion fails to address the actual rejection and analysis provided above. Applicant attempts to support their assertion by stating, e.g., that the “issuing” operation is not shown in [198] of Padmanabhan (see “[198] states only . . .” on page 14 of the presently addressed arguments). However, as is clearly shown in the actual rejection, [32,38] were cited and an explanation provided by the Examiner as to how these paragraphs address the ”issuing” language. Applicant’s piecemeal evaluation of the Examiner’s position fails to address the actual rationale relied upon by the Examiner and thus cannot be held as persuasive.
Next on page 15, Applicant argues that Padmanabhan in view of OpenSea fail to show the “based on the first request from the first user account on the platform service, determining a required account characteristic specified by a creator of the first unique digital asset collection" of claim 1 as in Padmanabhan, the “a voucher field [is] set by the database system
- not a required account characteristic specified by a creator of a collection”. In response, the Examiner notes that the features tied to the “creator of a collection” are shown by OpenSea, and not by Padmanabhan as Applicant asserts above. Applicant then addresses OpenSea’s teachings but asserts “supported blockchains and fee structures is not a ‘required account characteristic’”. In response, the Examiner notes that, e.g., the “fee structure” noted in OpenSea corresponds to an example of a required account characteristic when viewed based on the teachings of Padmanabhan in view of OpenSea; OpenSea’s multiple illustration of prices that are to be paid to purchase the “claimed unique digital asset” (i.e., NFT) represent the “characteristic”. One of ordinary skill in art would have readily understood that, when presented with the marketplace of OpenSea, that a purchaser must have the funds available to complete a purchase. As the citations to Padmanabhan show, requests to complete transactions are performed after validation, which is tied to an evaluation of the requesting user’s wallet. As the citations to Padmanabhan in the prior Office Action state, Padmanabhan in [41,43,63] and Fig. 3 items 306, 318, 320 shows
“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”.
Evaluation of the wallet corresponding to the wallet ID is how the “characteristics” are checked in the relied upon combination of Padmanabhan in view of OpenSea. In other words, Padmanabhan shows evaluations utilizing a particular purchasing user’s wallet identifier in order to verify the purchasing user has the required characteristics, and OpenSea illustrates where purchasing an NFT requires a particular price to be paid based on whatever sales conditions the NFT owner/creator decides upon. One of ordinary skill in the art in possession of the teaching of Padmanabhan in view of OpenSea would have readily recognized resultant disclosures suggestion of requiring a purchaser have the funds needed to pay a displayed purchase price.
Next, concluding on page 15 and moving to page 16, Applicant quotes another portion of claim 1 along with citations to Padmanabhan and then argues that these citation to Padmanabhan “do not disclose comparing a creator-specified required account characteristic to a first account characteristic of the first user account on a platform service”. In response, the Examiner notes that Padmanabhan alone was not relied upon to teach all of “comparing a creator-specified required account characteristic to a first account characteristic of the first user account on a platform service”; this language was mapped to the teachings of Padmanabhan in view of OpenSea, with OpenSea relied upon for showing the “creator-specified” features.
Continuing on page 16, Applicant addresses their arguments to Minaev and OpenZeppelin. However, neither Minaev nor OpenZeppelin were relied upon for showing the claim language argued above. In other words, the arguments directed to Minaev and OpenZeppelin rely on the rationale addressed above, and thus they continue to be unpersuasive.
Concluding on page 16, Applicant argues “the Office Action fails to articulate a proper rationale to combine” and that the stated motivation provided by the Examiner corresponds to “ensuring reliable purchase completion (MINAEV), reusing existing code (OPENZEPPELIN), and asset-rule enforcement (ASA)”. However, this language does not correspond to the actual motivation relied on by the Examiner. For example, the motivation to utilize the teachings of Minaev is not merely “ensuring reliable purchase completion”. The actual motivation statement and rationale relied upon by the Examiner is that: “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).”
Applicant has omitted nearly all of the actual explanation provided by the Examiner and then argued that no explanation was provided. Applicant’s argument thus cannot be held as persuasive.
Continuing on page 17, Applicant addresses the dependent claims, starting with claim 2 and the claim language related to a “second address” and verification of its issuance of a signature. Applicant argues the cited prior art fails to show this “second address”.
As an initial matter, the Examiner notes the most applicable dictionary definition for ”address” is one of “a place where a person or organization is located or may be communicated with” or “a location (as in the memory of a computer)”. One of ordinary skill in the art would readily understand that a “location” or “a place” itself cannot perform the claimed “issued” step given a literal reading (e.g., a letter cannot be sent by 600 Dulany Street, rather a person facilitating preparation of a written correspondence sends a letter from 600 Dulany Street. In the same manner, an IP address itself cannot send a packet, rather the computer running software identifiable by the IP address sends the packet). Thus, “address” as claimed must be interpreted broadly.
In the present case, the claimed “address” corresponds to an identifier enabling communication with the platform service (i.e., the “database system” of Padmanabhan) or alternatively the identifier enabling communication with the account holder that authorized or otherwise created the signed voucher (which represents the claimed “first signature”, as noted in the prior and present rejection of claim 1).
In Padmanabhan, the authorized account holder that creates the voucher provides instructions to facilitate its generation to the database system (creation of the voucher being within the broadest reasonable interpretation of the claimed “issued by”). Whether one views this creation as being performed by the database system or by the account holder is of little relevance as the claim does not specify or otherwise require such a distinction to be made. The database system has an address (as it can communicate and send communications and thus is addressable, as discussed in cited [82]) and the account holder has an address via their wallet (Padmanabhan in [198] discussing where wallets are communicated with via their addresses, suggesting communication such as the issuing step be performed via said address).
The account holder (voucher creator) “issues” the voucher (first signature) via operations performed with the database system, and thus the generated first signature is “by a second address” associated with the platform service. As noted above, whether this is the address of the platform service/database system itself or the address of the account holder is not required by the claim.
The cited prior art thus meets the limitations positively recited by the claim under multiple interpretations. If Applicant desires a more precise interpretation, then Applicant is encouraged to incorporate additional language specifying the desired additional features into claim 2.
Continuing on page 17 addressing claim 3, Applicant argues that the rejection of claim 3 shows “comparing identifiers, not verifying that the signature was received from the first address”. In response, the Examiner notes that the signature verification relied upon in the prior art is performed via the comparison of what Applicant characterizes as “identifiers”. Applicant’s assertion that this interpretation is insufficient thus cannot be held as persuasive, particularly given the claim lacks additional details positively reciting how the claimed signature “verifying” is performed.
Concluding on page 17, Applicant again argues the “address” limitations of claim 6. Applicant’s arguments related to the “address” language relies on arguments addressed above, and they continue to be unpersuasive for the reasons given above. Continuing to address claim 6, Applicant next argues that Padmanabhan’s teachings that a “’transaction ID may only be valid for a designated period of time’ do not disclose verifying that ‘the first signature was received by a predefined time’”. As noted in the rejection presently presented and presented in the prior Office Action, OpenZepplin discusses a requirement that validation “be within a particular time period when the presale value is true/active”; as shown on cited pg. 5 of OpenZepplin, this is performed via a check that that a “presaleActive” Boolean (i.e., true/false variable) evaluate to true. The arguments on page 17 and concluding on page 18 fail to address the rejection as a whole, and cannot be held as persuasive for the reasons noted above. Applicant next argues the relied upon citations fail to show “. . . performing the transfer only in response to all three recited criteria.” In response, the Examiner notes that the above quotation was noted relied upon to show a “transfer only in response to all three recited criteria” as the claim fails to recite such a limitation. No recitation of “all three” appears in the claim. Applicant’s argument fails to correspond to the limitations actually required by the applicable claim and thus cannot be held as persuasive. If Applicant desires a different interpretation of the claim (e.g., “performing the transfer only in response to all three recited criteria”) then Applicant is requested to amend their claim to positively recited the argued language. Finally, regardless of the differences between the language actually presented in claim 6 and the language argued above, both the previous rejection of claim 6 and the present rejection of claim 6 address each of the three listed “verifying” steps.
Next at the top of page 18, Applicant addresses claim 9 and argues that the citations fail to show claim 9. Applicant argues that instead of showing the features of claim 9, Padmanabhan shows “matching wallet identifiers or transaction prices to voucher fields” and that Padmanabhan “does not define the required account characteristic as ownership of an additional unique digital asset.” In response, the Examiner notes vouchers can require particular account identifiers (i.e., wallet identifiers) in order to execute as a mechanism for enforcing account requirement for voucher redemption. This is an example of the claimed “required account characteristic”; that an account correspond to a particular identifier is a “required characteristic” of the account. Applicant notes Padmanabhan also shows consideration of “transaction prices”; being able to accommodate a specified transaction price (via having sufficient funds in one’s account) is another example of the “required account characteristic” required by the claim.
Applicant continues to argue that, regarding claim 9, Lee fails to show “determining whether the first address ‘currently owns’ an additional unique digital asset ‘based on a current state of a blockchain,’ as recited. Applicant argues that instead Lee shows “NFT ownership as a gating condition”.
In response, the Examiner notes that Lee’s evaluation of “NFT ownership”, acknowledged above by Applicant, directly corresponds to the argued determination of “currently owns a unique digital asset”. The “ownership” acknowledged by Applicant corresponds to the “currently owns” argued above, and the NFT is an example of a “unique digital asset”. Applicant’s arguments thus continue to be unpersuasive as the details Applicant acknowledges the cited art teaches directly corresponds to what is required by their claim language. Additionally, Applicant fails to address the citations actually made to Lee and instead omits relevant sections of the rejection that clearly address the claimed “current state of the blockchain” (e.g., those on page 25 of the prior Office Action noting the teachings in [69] of Lee regarding ownership being “on-chain and verifiable”).
Continuing on page 18, Applicant argues that in claim 7 Lee does show “media characteristics or ‘follows’ relationships” and instead shows “NFTs used as tickets,
proofs of attendance, or membership indicators”.
In response, the Examiner notes that the features argued above by Applicant fail to correspond to the claim limitations Lee was relied upon to show. Lee was noted cited to show the argued “media characteristics or ‘follows’ relationships”; Doyle instead was cited to modify the combination made using Lee to show the relevant claim language.
Applicant continues to argue that in claim 7 Doyle merely provides a “suggestion . . . to enter a contest” rather than “verifying that a linked social media account follows a particular account”.
In response, the Examiner notes the citations explicitly address the argued claim language. One of ordinary skill in the art would not have interpreted Doyle’s teachings as corresponding merely to a “suggestion . . . to enter a contest” as Applicant asserts above. Applicant’s arguments, which fail to address the rationale relied upon by the Examiner on page 22 of the prior Office Action thus cannot be held as pervasive.
Concluding on page 18, Applicant discusses claim 8 and argues that Maier does not show the required "know-your-customer characteristic" as claimed which requires treating a KYC characteristic of a first account as a required characteristic that is validated.
In response, the Examiner notes that the above argument merely repeats portions of the claim language without actually addressing the position articulated by the Examiner on page 23 of the prior Office Action. As noted previously, the account being verified as having completed a KYC (know-your-customer) process is required in Maier in order to perform a desired “transaction requiring identify verification”. Applicant’s arguments continue to fail to address the actual rationale relied upon by the Examiner and thus continue to fail to be persuasive.
Moving to page 19, Applicant begins by arguing claims 20 and 24. Applicant asserts that
Padmanabhan showing a "’transaction price’ does not disclose a first signature associated with a blockchain operation characteristic that is associated with a value for obtaining the first previously-minted unique digital asset, nor a signature associated with authorization to obtain that asset for the value, as recited in amended claims 20 and 24.” In response, the Examiner notes that all of the above argued language was never mapped or otherwise relied upon by the Examiner as being anticipated by merely a “transaction price”. A ”transaction price” as cited does anticipate the recited “characteristic for a first blockchain operation” as the transactions of Padmanabhan are performed on a blockchain and require a transaction price, as discussed in the citations to [32,38,51] of Padmanabhan. The mapping of the disclosure in Padmanabhan’s [32,38,51,273] to claim 20 is provided in detail on page 32 of the prior Office Action, and Applicant’s arguments fail to address the reasoning and mapping provided in these sections.
Continuing on page 19, Applicant addresses claim 21 and characterizes Padmanabhan’s teachings showing a “time window” via a “transaction-ID validity period”. Applicant then argues that this showing of a “transaction-ID validity period” does not anticipate a “first signature associated with a time window during which the signature can be used to obtain the asset”.
In response, the Examiner notes that a “transaction-ID validity period” was not asserted to anticipate the above language argued by Applicant. Applicant’s arguments fail to address the citations made to specifically to show each limitation actually recited in claim 21, e.g., the specific citations to who the argued “first signature”, etc.
Applicant’s arguments fail to address the actual rejection made by the Examiner and thus cannot be held as persuasively arguing the rejection is deficient.
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.
Claim 6 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Regarding claim 6, said claim is dependent upon claim 1, where claim 1 concludes with a “transferring” step being performed after a “validating” operation. Note that the limitations claim 1 specify a particular order via the mechanism Applicant has chosen for drafting the claims. For example, line 8 of page 2 in claim 1 recites “receiving a user selection” and then line 10 recites “based on the user selection”. This requires the language in line 10 to occur after the language in line 8. Similar rationale applies throughout claim 1. 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.
Claim 6 is further rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
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. While the last of these three steps is supported (“verifying . . . that the first signature was received by a predefined time”) in [86] of the specification, the first two “verifying” steps are not supported in the specification (i.e., “verifying, by the first self-executing program, that the first signature was issued by a second address associated with the platform service” and “verifying, by the first self-executing program, that the first signature was received from the first address of the cryptography-based storage application”. The specification is silent regarding the “self-executing program” performing verifying “that the first signature was issued by a second address associated with the platform service” and silent regarding the “self-executing program” performing verifying “that the first signature was received from the first address of the cryptography-based storage application”.
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 10 – 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 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 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 claims 11 – 14 and 21 – 26, said claims further specify the subject matter of claims 10 and 15 and fail to clarify the issues noted above. These dependent claims inherit the above noted issues in parent claim 10.
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 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, and 3 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)), 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); 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 is for a first self-executing program ([32] discussing where “a voucher holder may then execute . . .”, [41] see “allowing particular wallet IDs to perform actions. . .”, [52], see “a voucher may authorize . . . “) 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).
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).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea, Minaev, and Asa, as applied to claim 1 above, further in view of Chang (US-20230162225-A1).
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, by the first self-executing program (Padmanabhan, [32] “the smart contract may perform one or more validation operations”, thus suggesting performing verifying operations; further verification and validation operations are discussed in [38,51-53,137,250,254,258,263-269], etc.), that the first signature was issued by a second address associated with the platform service (Padmanabhan, [52-53] discussing verification of 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, by the first self-executing program (Padmanabhan, [32] “the smart contract may perform one or more validation operations”, thus suggesting performing verifying operations), that the first signature was received from the first address of the cryptography-based storage application (Padmanabhan, [82-83,88-89]); and verifying, by the first self-executing program (Padmanabhan, [32] “the smart contract may perform one or more validation operations”, thus suggesting performing verifying operations), and consideration regarding a first signature validity (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).
While being aware of validity periods (as cited above, e.g., Padmanabhan, [294]), the above combination does not specifically address reception by a predefined time.
Chang suggests verification by a predefined time ([113-114,131] discussing a message code verification technique that ensures a received code is valid based on consideration “valid time information and the current time”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the message exchange techniques of the above combination with the verification techniques of Chang in order to require messages be processed in a timely manner in order to be valid, thus ensuring that users with redeemable codes (such as the vouchers of Padmanabhan) utilize their redemption option in a predictable time window, better ensuring user satisfaction (via a successful redemption) while also avoiding maintaining system infrastructure indefinitely, which one of ordinary skill in the art would have readily understood would require committing excessive resource consumption (contrasted with the common practice of requiring redemption of checks, coupons, and all other manner of vouchers or items within a predetermined time window).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan in view of OpenSea, Minaev, 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, 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, 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 is associated with first blockchain operation characteristic (Padmanabhan, [32,38,51] and OpenSea, pgs. 2 -3 and 8-11 suggesting that to complete an NFT purchase, you will have to have the required funds, or as pg. 8 lines 1 – 5 notes “you’ll need to load your wallet with cryptocurrency”), wherein the first blockchain operation (Padmanabhan, [51], discussing to “perform one or more blockchain-related operations”) characteristic is associated with 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”) is associated with 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”) is associated with 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 is associated with 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
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.
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
Prosecution Insights