Acknowledgments
Claims 21 and 31 have been amended.
Claims 21-40 are pending and have been examined.
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
Regarding applicant’s arguments:
Applicant’s argument, see pg. 9, filed 04/02/2026, with respect to the rejections of instant claims 21-40 under Double Patenting that the Terminal Disclaimer obviates the rejection has been considered and is persuasive. Therefore, the rejection has been withdrawn.
Applicant’s arguments, see pg. 10, filed 04/02/2026, with respect to the rejections of claim 21 under Claim Rejection - 35 USC § 103 that the combination of Nahapetyan and Nam does not anticipate amended claim 21, specifically the concept of issuer-authorized agreement frameworks in which execution is conditionally governed by rule-based evaluation and user-specific agreement context prior to updating ownership on a distributed ledger are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made under Claim Rejection - 35 USC § 103 in view of Binder (US 20240265223) and in further view of Comito (US 20230037296) in further view of Boneta (US 20240403957).
Priority
Applicant's claim for the benefit of a US Provisional Application No. 63/510,478 filed on 06/27/2023 is acknowledged. Applicant's claim for the benefit of a US Provisional Application No. 63/607,745 filed on 12/08/2023 is acknowledged. Applicant's claim for the benefit of a US Patent Application No. 18/626,841 filed on 04/04/2024 is acknowledged.
Claim Objections
Claims 21 and 31 are objected to because of the following informalities:
In claim 21, line 33 and claim 21, line 37 “associated with” should be removed.
Appropriate correction is required.
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 21-40 are rejected under 35 U.S.C. 103 as being anticipated by Nahapetyan (US 20240370942) in view of Binder (US 20240265223) and in further view of Comito (US 20230037296) in further view of Boneta (US 20240403957).
Regarding Claims 21 and 31, Nahapetyan teaches generating a cryptographic digital asset associated with the membership, wherein the cryptographic digital asset includes metadata defining at least a membership identifier, issuer identifier, and ownership data (Paragraphs 0175 and 0119 teach a server generates or mints a new non-fungible token, for example, by using a secret key to execute a command to the blockchain; the system may also create an active membership card for the user for the respective community; the server then generates or mints a new non-fungible token, for example, by using a secret key to execute a command to the blockchain; the token is owned or possessed by the authenticated invitee and grants her/him/them access into the decentralized community; the minted token comprises or is embedded, incorporated, or associated with the membership card; received parameters are used to generate or mint non-fungible tokens that may be used for membership in the new community; club metadata is added to the appearance of the card, such as the club name and NFT edition number; each member receives a unique card which can be distinguished by the edition number); creating an agreement application including an agreement and one or more predetermined conditions, wherein: the agreement application is configured to contain information comprising at least one value associated with the cryptographic digital asset, an image associated with the cryptographic digital asset, and a unique identifier (Paragraphs 0068-0069 and 0119 teach the application uses non-fungible tokens specifically to maintain membership within decentralized communities; a non-fungible token can function to represent a user or member's identity, property rights, privileges, etc. for the community; the non-fungible tokens are represented, e.g., on a user interface associated with the application, through algorithmically generated images that resemble a uniquely editioned “membership card;” when creating a club, the application provides an option to add in photos and generate the NFT membership card design algorithmically and/or through neural networks; a user or individual must have a non-fungible token to establish that she/he/they is a member of a community, thereby being granted access to the respective on-line or virtual space of the community; holders of these tokens—i.e., users who are members of a community—may engage in governance of such community, such as electing new moderators or removing content that violates their community's guidelines; this governance and control of the community by members can be implemented or provided through smart contracts living on the blockchain that execute decisions automatically, for example, based on voting by token holders; membership tokens can be generated using one of the images provided by the user; the image is processed or transformed into a “membership card;” when the club creator uploads an image to use as the basis for the membership card NFT, the image is sent through an image processing pipeline; the image is scaled to the appropriate starting size; a metallic sheen is added; club metadata is added to the appearance of the card, such as the club name and NFT edition number; each member receives a unique card which can be distinguished by the edition number); associating the cryptographic digital asset with the user (Paragraph 0161 teaches when that person clicks on that link, the token or tokens are seamlessly created (minted) and deposited into that person's wallet (or a custodial wallet is created for her/him/them if she/he/they do not already have one on the application); the digital wallet allows a user to quickly view of all of her/his/their digital memberships); and sending for display to a user device, confirmation of the agreement and current ownership status of the cryptographic digital asset (Paragraph 0172 teaches FIG. 10 shows an example of a screenshot of a user interface for a digital wallet with one or more membership cards; the digital wallet may include active membership cards for each community to which a user is already a member and open membership cards for each community to which a user has been invited; each membership card(whether active or open) can be associated with an active element or icon that can be “pushed” or activated by the user; upon activation of the respective active element by the user, the systems and methods (e.g., application) will present an interface showing the membership card virtually being removed from the digital wallet and presented in full or complete form on the screen (e.g., of user device)).
However, Nahapetyan does not explicitly teach authenticating a membership issuer, via a graphical user interface, using a multi-factor authentication process, wherein the membership issuer is pre-approved to define membership regulations; and issuing a membership to a user, over a distributed computing network on a server, to a user device associated with the user based on the authentication and linked to a cryptographic wallet associated with the user.
Binder from same or similar field of endeavor teaches authenticating a membership issuer, via a graphical user interface, using a multi-factor authentication process, wherein the membership issuer is pre-approved to define membership regulations (Paragraphs 0052-0053 and 0177 teach a frontend may be usable by one or more issuer instances to request creation of and/or performance of one or more transactions and/or other actions related to one or more NFTs; the issuer instance may include one or more minters that may include an issuer; the issuer may be verified and authenticated by the host platform, such as by communication over a verified connection, using multi-factor authentication (such as a login and/or password, a one-time password sent to a known email address and/or other communication address, one or more authenticator apps, and so on), and so on; the minting authority and/or the issuer instance may be communicably connected to the frontend; the NFT may be associate with a membership program and the second portion of the smart contract include one or more components associated with one or more expiration dates associated with the membership program, terms and conditions associated with the membership program, and so on; in this way, the expiration date, terms and conditions, and so on returned by the one or more components may be changeable without having to revoke the NFT and generate a new one); and issuing a membership to a user, over a distributed computing network on a server, to a user device associated with the user based on the authentication and linked to a cryptographic wallet associated with the user (Paragraphs 0053-0054, 0085, and 0088 teach an issuer instance may include one or more minters that may include an issuer; the user platform may include a user wallet and a user; the user wallet may be a token wallet; the user wallet may store one or more private and/or public keys related to one or more NFTs; the user wallet and/or the user platform may be communicably connected to the one or more unsecure and/or secure storages, one or more blockchains, and/or backend services; the user may be verified and authenticated by the host platform, such as by communication over a verified connection, using multi-factor authentication (such as a login and/or password, a one-time password sent to a known email address and/or other communication address, one or more authenticator apps, and so on), and so on; an electronic device may generate an NFT associated with an asset; the electronic device may determine whether or not to change the first address; the electronic device may determine to change the first address when an authorized request to change the first address is received; authorization may be determined using one or more passwords, NFTs, and/or other credentials; if so, the flow may proceed to operation where the electronic device may change the first address before the flow returns to operation and the electronic device again determines whether or not a request for the asset is received at the first address).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Nahapetyan to incorporate the teachings of Binder to authenticate a membership issuer, via a graphical user interface, using a multi-factor authentication process, wherein the membership issuer is pre-approved to define membership regulations; and issue a membership to a user, over a distributed computing network on a server, to a user device associated with the user based on the authentication and linked to a cryptographic wallet associated with the user.
There is motivation to combine Binder into Nahapetyan because multi-factor authentication (MFA) significantly strengthens security by requiring multiple forms of verification, reducing the risk of unauthorized access and enhancing compliance with industry standards.
However, the combination of Nahapetyan and Binder does not explicitly teach creating an agreement application including an agreement and one or more predetermined conditions, wherein: the one or more predetermined conditions include membership regulations defined by the authenticated membership issuer; the agreement application is programmed to enforce the membership regulations and update ownership of the cryptographic digital asset only upon cryptographic verification of compliance with the one or more predetermined conditions; the agreement application contains one or more agreement attributes based on an agreement type, and the user; enforcing the agreement and the one or more predetermined conditions using the agreement application; and conditionally enforcing the agreement and the one or more predetermined conditions, including preventing transfer of the cryptographic digital asset when the predetermined conditions are not satisfied and selectively transferring the associated value only upon successful completion of the predetermined conditions.
Comito from same or similar field of endeavor teaches creating an agreement application including an agreement and one or more predetermined conditions, wherein: the one or more predetermined conditions include membership regulations defined by the authenticated membership issuer (Paragraphs 0028-0029 teach the specialized digital asset may require previous consent to or otherwise represent an agreement between i) a given user to hold the set of rights that is associated with the correlated entity and ii) an original holder of the set of rights, and/or require completion of other prerequisites; the correlated entities of the specialized digital assets may include a digital membership card; the given user may be required to consent to the agreement and/or complete the other prerequisites prior to receiving the specialized digital asset in their digital wallet; the specialized digital asset may be permitted to be acquired from the digital asset distribution platform upon receipt of the consent to the agreement by the user; by way of non-limiting example, the agreement may specify that the correlated entity is made available to the holder of the collectible digital asset, particular transfer and use restrictions, that the holder does not own the correlated entity itself, and/or other information; the agreement may include the set of rights which specify such availability, transfer restrictions, and user restrictions); the agreement application is programmed to enforce the membership regulations and update ownership of the cryptographic digital asset only upon cryptographic verification of compliance with the one or more predetermined conditions (Paragraph 0029 teaches the specialized smart contract that mints the specialized digital assets may be encoded to restrict the specialized digital asset from being transferred between digital wallets of different users and/or restrict transfers to between digital wallets of the same user; acquisition of the specialized digital asset may include a set of restrictions to the specialized digital asset; the set of restrictions may restrict the user from transferring, trading, loaning, selling, or otherwise surrendering to another user); the agreement application contains one or more agreement attributes based on an agreement type, and the user (Paragraphs 0028 and 0039 teach the specialized digital asset may be minted or established directly by a particular service by employing a specialized smart contract; the specialized smart contract may be stored on decentralized ledger(s); the specialized digital asset may require previous consent to or otherwise represent an agreement between i) a given user to hold the set of rights that is associated with the correlated entity and ii) an original holder of the set of rights, and/or require completion of other prerequisites; the specialized digital assets may be correlated with an entity, i.e., correlated entities; the correlated entities of the specialized digital assets may be different that the correlated entities of the collectible digital assets; smart contract(s) may be configured to determine whether one or more conditions related to the digital wallet are fulfilled; conditions may include a first condition, a second condition, and/or other conditions; by way of non-limiting example, a condition may require that the digital wallet is coupled with an account with an external member system; external member systems may include streaming services, subscription services, club memberships, identification systems, and/or other external membership systems); enforcing the agreement and the one or more predetermined conditions using the agreement application (Paragraph 0059 teaches determining whether one or more conditions related to the digital wallet are fulfilled; performed by smart contract(s), in accordance with one or more implementations); and conditionally enforcing the agreement and the one or more predetermined conditions, including preventing transfer of the cryptographic digital asset when the predetermined conditions are not satisfied and selectively transferring the associated value only upon successful completion of the predetermined conditions (Paragraphs 0060-0061 teach upon determination that the one or more conditions are fulfilled, transmitting to the digital asset distribution platform an authorization indication that the acquisition of the collectible digital asset by the digital wallet is permitted; upon determination that the one or more conditions are not fulfilled, transmitting to the digital asset distribution platform a prevention indication to prevent the acquisition of the collectible digital asset by the digital wallet).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Nahapetyan and Binder to incorporate the teachings of Comito to create an agreement application including an agreement and one or more predetermined conditions, wherein: the one or more predetermined conditions include membership regulations defined by the authenticated membership issuer; the agreement application is programmed to enforce the membership regulations and update ownership of the cryptographic digital asset only upon cryptographic verification of compliance with the one or more predetermined conditions; the agreement application contains one or more agreement attributes based on an agreement type, and the user; enforce the agreement and the one or more predetermined conditions using the agreement application; and conditionally enforce the agreement and the one or more predetermined conditions, including preventing transfer of the cryptographic digital asset when the predetermined conditions are not satisfied and selectively transferring the associated value only upon successful completion of the predetermined conditions.
There is motivation to combine Comito into the combination of Nahapetyan and Binder because the system facilitates dynamic, meaningful, and legally enforceable relationships between original content creators of the correlated entities and users who collect the collectible digital assets (Comito Paragraph 0003).
However, the combination of Nahapetyan, Binder, and Comito does not explicitly teach enforcing the agreement, such that enforcement of the agreement application requires cryptographic signing by the user.
Boneta from same or similar field of endeavor teaches enforcing the agreement, such that enforcement of the agreement application requires cryptographic signing by the user (Paragraph 0175 teaches when a token owner wants to transfer their NFTs or tokens (representing ownership of the NFT), the token owner can create a transaction and sign it with their private key).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Nahapetyan, Binder, and Comito to incorporate the teachings of Boneta to enforce the agreement, such that enforcement of the agreement application requires cryptographic signing by the user.
There is motivation to combine Boneta into the combination of Nahapetyan, Binder, and Comito because the digital signature proves that the transaction was created by the actual owner and was not tampered with. Anyone can verify the signature with the corresponding public key, but they cannot forge the signature without the private key (Boneta Paragraph 0175).
Regarding Claim 21, Nahapetyan teaches a computer-implemented method executed by at least one processor, for management of user memberships (Paragraph 0162 teaches FIG. 8 is a simplified diagram of a method for receiving a non-fungible token through an invitation link, according to some embodiments).
Regarding Claim 31, Nahapetyan teaches a system for management of user memberships using a software module, comprising: a memory storing instructions; and at least one processor in electronic communication with the memory, the at least one processor configured to execute the instructions (Paragraph 0162 teaches one or more of the processes of method may be implemented, at least in part, in the form of executable code stored on non-transitory, tangible, machine-readable media that when run by one or more processors—such as may be present, for example, in user device shown in FIG. 1 or one or more servers, user computers, and mobile devices of the networked computing environment shown in FIG. 2 —may cause the one or more processors to perform one or more of the processes).
Regarding Claims 22 and 32, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the agreement application is embedded with the one or more predetermined conditions to ensure compliance with a membership regulation (Paragraphs 0087 and 0095 teach ecosystem for one or more non-fungible token (NFT)-gated communities is supported or implemented with computer hardware and software which together execute the necessary processes, algorithms, instructions, modules, and/or operations for ecosystem; these operations and processes include, for example, creating the on-line or virtual space for each community, creating a decentralized autonomous organization (DAO) for a community, generating non-fungible tokens for use by members, administering the communities (e.g., by checking tokens, hosting the on-line or virtual space, adding, storing, deleting, or removing content, executing smart contracts, administering voting and elections, admitting new members and removing existing members, maintaining or ensuring compliance with policies and processes), etc.; such smart contracts implement actions, transactions, administration, governance, and the like in connection with the activity of members in their communities; for example, a smart contract can implement gate-keeping for the community, checking whether users have the appropriate token for a club and allowing or granting only those users with the appropriate tokens access to the on-line or virtual space or the community; as another example, a smart contract can implement or execute a purchase of a product or service by one member from another-such as a fan member buying the latest song track from an artist member; as yet another example, a smart contract can implement voting or elections for the community, such as the members voting on new officers or the location of the next in-person meeting).
Regarding Claims 23 and 33, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 22 and 32 above; and Nahapetyan further teaches wherein the membership regulation refers to at least one of a set of rules, a set of requirements, a set of regulations, or a set of qualifications associated with the membership issuer (Paragraph 0122 teaches the smart contracts can implement the policies, processes, procedures, rules, bylaws, etc. for the DAO or community as the members interact; for example, one or more smart contracts may provide or support the processes or procedures for electing officers for a community, including opening up the election, issuing ballots to voting members, receiving and counting votes, and announcing the winners; as another example, a smart contract may provide or support the processes or rules for admitting new members to a community (e.g., upon a majority vote of existing members); one or more smart contracts may relate to the policies or bylaws for how to disband or dissolve the community, and what happens to the community's assets and content in such situation; as yet another example, a smart contract may provide or support the sale or purchase of various goods or services between members of a community).
Regarding Claims 24 and 34, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the agreement application is associated with each individual transaction between users (Paragraph 0122 teaches the smart contract causes the funds to be disbursed to the seller, and transfers rights from the seller to the purchaser).
Regarding Claims 25 and 35, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the cryptographic digital asset is a non-fungible token (NFT) (Paragraphs 0063-0064 teach access to the on-line or virtual space of a community can be restricted or controlled by the use of non-fungible tokens (NFTs); each member of a community can be assigned, granted, or associated with her/his/their own unique non-fungible token for that community; each non-fungible token is a digital asset, similar to cryptocurrency, and can be owned by only one person at a time; unlike cryptocurrency tokens, which are fungible with many of the same token existing, non-fungible tokens are limited to a supply of one unique digital token).
Regarding Claims 26 and 36, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the agreement application is linked to a template associated with the user (Paragraph 0121 teaches one or more parameters input by the creating user are converted into smart contracts for the DAO; for example, based on input or parameters provided by the user, systems and methods of the present disclosure identify appropriate or relevant forms of smart contracts; fill-in, modify, or complete the form smart contracts, e.g., for implementing or executing transactions, voting on action items, elections of new officers, admission of new members, deletion or removal of existing members, the deletion or removal of text, comments, discussion, images, audio or video content; and store, maintain, deploy, or execute the completed smart contracts in order to implement or support the DAO).
Regarding Claims 27 and 37, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the agreement application is self-executing (Paragraph 0122 teaches the smart contracts are self-executing).
Regarding Claims 28 and 38, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the agreement application is used to transfer ownership of the cryptographic digital asset from the user to another user (Paragraphs 0067 and 0122 teach after that, smart contracts can transfer the non-fungible tokens to new owners, such as various users, when such users agree to join as members of a community; the smart contract causes the funds to be disbursed to the seller, and transfers rights to the digital artwork from the seller to the purchaser).
Regarding Claims 29 and 39, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the agreement application authenticates ownership of the membership (Paragraph 0095 teaches user computers, and mobile devices store and maintain one or more forms, code, or modules for smart contracts; such smart contracts implement actions, transactions, administration, governance, and the like in connection with the activity of members in their communities; for example, a smart contract can implement gate-keeping for the community, checking whether users have the appropriate token for a club and allowing or granting only those users with the appropriate tokens access to the on-line or virtual space or the community).
Regarding Claims 30 and 40, the combination of Nahapetyan, Binder, Comito, and Boneta teaches all the limitations of claims 21 and 31 above; and Nahapetyan further teaches wherein the membership issuer can track membership ownerships on a distributed cryptographic digital asset private key generator (Paragraphs 0067, 0069-0070, and 0072 teach when a new non-fungible token is minted, the smart contract automatically sets the creator, which can be the administrator or operator for ecosystem, as the owner; after that, smart contracts can transfer the non-fungible tokens to new owners, such as various users, when such users agree to join as members of a community; this governance and control of the community by members can be implemented or provided through smart contracts living on the blockchain that execute decisions automatically, for example, based on voting by token holders; communities of ecosystem are decentralized, leveraging peer-to-peer technologies such as layer one blockchains to maintain membership information; as such, membership for each community can be verified in a trust-less, distributed, and permanent way that cannot be tampered with by a third-party, such as the administrator or operator of ecosystem; a decentralized community, like any one or more of the communities of ecosystem, is managed through membership that is maintained using blockchain or distributed ledger technology, where members hold non-fungible tokens representing participation and ownership in this community; the distributed ledger prevents a single centralized service from removing members or shutting down the community; Furthermore, the distributed ledger gives the token owners the power to move from one platform to another at their will).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Albero et al. (US 20240020690) teaches a system is provided for implementing transfer and access restrictions on electronic digital resources. In particular, the system may generate a digital resource on a distributed electronic data register using a custom set of executable code. Using the custom set of code, the generated digital resource may in some embodiments be an access restricted resource that may be controlled by one or more access and/or transfer restrictions. Accordingly, the system may require a user to provide valid authentication credentials in order to access and/or transfer the digital resource. In this way, the system may prevent the misuse of digital resource stored within the network environment.
Esquibel et al. (US 20240086905) teaches a computing system and method for protecting access to a particular resource. The computing device can identify a first cryptographic token in a first digital wallet. The first cryptographic token is configured to provide access to a particular resource. The computing device can generate a second cryptographic token bound to the first cryptographic token. The computing device can transfer the second cryptographic token to a second digital wallet based on the first cryptographic token. The computing device can access the particular resource based on the second cryptographic token being in the second digital wallet.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights