DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s RCE filed August 21, 2026.
Claims 1-3 are currently amended.
Claims 1-3 are currently pending.
Claims 1-3 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8/21/2026 has been entered.
Claim Objections
Claims 1-3 are objected to because “the smart contract” lacks antecedent basis. Below is a suggested amendment to claim 1. Claims 2-3 should be corrected similarly.
creating an entity private key/wallet address pair associated with a specific chat service provider to interact with a smart contract and store at least a portion of the chat data associated with the specific chat on the blockchain;
Claim Rejections - 35 USC § 112
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.
Claims 1-3 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claims 1-3
Claim 1 recites, in relevant part:
creating an entity private key/wallet address pair associated with a specific chat service provider to interact with the smart contract and store at least a portion of the chat data associated with the specific chat on the blockchain;
creating the smart contract for chat data associated with a relationship between the specific chat and the specific chat provider in a chat history database;
responsive to receiving the transaction data, generating a new NFT in a series on the specific blockchain according to the chat data using the smart contract, including using the entity private key/wallet address pair associated with the specific chat service provider to cryptographically authorize a blockchain transaction that mints the new NFT; and
Claim 1 introduces “the chat data associated with the specific chat on the blockchain” and then later introduces “chat data associated with a relationship between the specific chat and the specific chat provider in a chat history database”. Claim 1 then later refers to “the chat data”. It is not clear if all three of these refer to the same data.
Claims 2-3 recite similar language and are indefinite for the same reasons as claim 1.
Below are suggested changes for claim 1 if all three phrases are meant to refer to the same data:
creating an entity private key/wallet address pair associated with a specific chat service provider to interact with the smart contract and store at least a portion of ;
creating the smart contract for the chat data, the chat data being associated with a relationship between the specific chat and the specific chat provider in a chat history database;
[…]
responsive to receiving the transaction data, generating a new NFT in a series on the specific blockchain according to the chat data using the smart contract, including using the entity private key/wallet address pair associated with the specific chat service provider to cryptographically authorize a blockchain transaction that mints the new NFT; and
For purposes of examination, the claims are interpreted as if they had these suggested changes.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Carter (US 20220270421 A1) in view of Robell et al. (US 20230281604 A1).
Regarding claims 1-3
Carter teaches:
A computer-implemented method in a system, on a data communication network, for providing immutable chat session history transactions within a non-fungible cryptographic token (NFT) based chat session certificate, the method comprising:
creating a user private key/wallet address pair associated with a specific user to interact with the system, wherein the user private key/wallet address pair is associated with a specific blockchain; {[0141] “a user account is connected to a digital wallet… the digital wallet [user private key/wallet address pair] is created and hosted by the software platform of the present invention… the platform is operable to support all ETHEREUM Request for Comment (ERC) standards as described by the ETHEREUM Improvement Proposals (EIP). For example, the platform is operable to support EIP-721: ERC-721 Non-Fungible Token Standard”}
creating the smart contract for the chat data, the chat data being associated with a relationship between the specific chat and the specific chat provider in a chat history database; {[0141] “the platform of the present invention deploys at least one smart contract to handle minting of the NFT”}
“For chat data associated with a relationship between a specific entity in a chat history database” is interpreted as an intended use of the smart contract. It is interpreted as merely referring to the data which is intended to be contained in generated NFTs.
receiving, by an NFT engine from a chat transaction module, transaction data generated responsive to a consumer accepting an offer within a chat application, the transaction data identifying the specific chat; {[0141] “When the user account is connected to the digital wallet, the user account is operable to upload [receiving] the image [data], e.g., as a file.”}
Paragraph [007] of the specification notes that accepting an offer can be “actuating a digital button or otherwise”. The terms “chat application” and “chat transaction module” are interpreted merely as labels for software. Uploading the file at least implies actuating a digital button and therefore reads on “accepting an offer within a chat application”. Additionally, the only step is “receiving”. Generating the data is not a claimed method step. What the data identifies is merely a description of the data’s meaning and is not given patentable weight.
responsive to receiving the transaction data, generating a new NFT in a series on the specific blockchain according to the chat data using the smart contract […]; {[0141] “the platform provides for creating an NFT from an image [data] in a minting process.”; [0141] “the platform of the present invention deploys at least one smart contract to handle minting of the NFT”}
The claim’s description of the data as “chat” data is considered non-functional descriptive material. The type of data has no effect on any step of the claim.
Carter does not teach, however Robell teaches the following bolded language:
creating an entity private key/wallet address pair associated with a specific chat service provider to interact with a smart contract and store at least a portion of {[0039] “Additionally, an administrator (admin) that operates the admin wallet [entity private key/wallet address pair]… is involved in the creation of the NFT IDs by coding, compiling, deploying, and running a smart contract”}
Robell does not explicitly teach creating an admin wallet. However, creating an admin wallet is implied because Robell teaches using it.
responsive to receiving the transaction data, generating a new NFT in a series on the specific blockchain according to the chat data using the smart contract, including using the entity private key/wallet address pair associated with the specific chat service provider to cryptographically authorize a blockchain transaction that mints the new NFT; {[0039] “Additionally, an administrator (admin) that operates the admin wallet [entity private key/wallet address pair]… is involved in the creation of the NFT IDs by coding, compiling, deploying, and running a smart contract”}
sending the new NFT to the user private key/wallet address pair associated with the specific user. {[0086] “At step 5.5, the minted NFT ID 402 is added to the admin wallet [entity private key/wallet address pair] 360. The newly minted NFT ID 402 initially belongs to whoever did (or requested) the actual minting, which in this example is the admin… The NFT ID 402 is then transferred [sending] to the individual's wallet [user private key/wallet address pair]… The transfer of the minted NFT ID 402 from the admin wallet 360 to the wallet 310 of the new ID holder 501 may be recorded as a transaction 417 and/or is added as a block to the relevant blockchain(s) 415.”}
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Carter to include the admin wallet of Robell. One would have been motivated to do so, in order to allow the platform to exercise administrative control over creation of NFTs and define the functions of each NFT (Robell [0039] “Additionally, an administrator (admin) that operates the admin wallet… associated with an org/entity defines the requirements and functions of each NFT ID type. The admin 360 may be the same or similar as the client 310, but is operated by a user having administrator privileges.”). Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Carter evidently discloses a system which creates a user wallet, creates a smart contract, and mints NFTs for users using the smart contract. Robell is merely relied upon to illustrate the functionality of an admin wallet for controlling the smart contract to mint the NFT, receive the NFT, and transfer to the user wallet, in the same or similar context. As best understood by Examiner, since both Carter, as well as Robell are implemented through well-known blockchain technologies in the same or similar context, combining their features as outlined above using such well-known blockchain technologies (i.e., smart contracts, wallets, NFTs), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Carter, as well as Robell would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Carter/Robell.
Claims 2 and 3 are similar in scope to claim 1 and are treated the same with respect to prior art rejections.
Response to Arguments
Objections
The objections to the specification and drawings are withdrawn due to the specification amendment and replacement drawing.
35 USC § 112(b)
Claims 1-3 were rejected as indefinite. Applicant asserts the claim amendments cure the indefiniteness. However, many antecedent basis and indefiniteness issues have not been corrected. Applicant states:
In response, the claims have been amended to resolve those issues.
In particular, claim 1 now introduces "a smart contract" before subsequently referring to that smart contract. Claim 1 also expressly introduces "a specific chat" and identifies the relationship as being between the specific chat and the specific chat service provider.
However, contrary to Applicant’s assertion, the claims have not been amended as described and the indefiniteness remains. Suggested amendments have been provided in the above claim objections and 112(b) rejections. Applicant is again advised to review 2173.05(e) Lack of Antecedent Basis.
35 USC § 103
The claims previously required that an NFT be generated according to chat data using a wallet of a chat service provider. The rejection stated that the description of data as “chat data” was considered a non-functional description of the content of data and could not distinguish the claim from the prior art. The rejection further stated that “chat service provider” was being treated merely as a label for an entity.
Applicant has amended the claims to now require that transaction data be received and that generating the NFT be done “responsive to receiving the transaction data”. The transaction data is described as being “generated responsive to a consumer accepting an offer within a chat application” and “identifying the specific chat”.
Applicant argues Carter in view of Robell does not teach the functional sequence:
a consumer accepts an offer within a chat application;
a chat transaction module generates transaction data responsive to that acceptance;
the transaction data identifies the specific chat;
an NFT engine receives the transaction data from the chat transaction module;
responsive to receipt of the transaction data, the NFT engine generates a new NFT using the smart contract; and
an entity private key/wallet address pair associated with the specific chat service provider is used to cryptographically authorize the blockchain transaction that mints the new NFT.
However, nos. 1, 2, and 3 are not required functions. In the claims, they are written merely as descriptions of the received transaction data. The transaction data itself has no functional role in the method because it is merely claimed as being received and is not involved in any other claimed step.
Additionally, paragraph [007] of the specification notes that accepting an offer can be “actuating a digital button or otherwise”. The claim terms “chat application” and “chat transaction module” are interpreted merely as labels for software. Therefore, this is very broad and, even if it were given patentable weight, is taught by Carter’s teaching in [0141] “the user account is operable to upload the image, e.g., as a file.” Uploading the file at least implies actuating a digital button.
No. 4, receiving data, is taught by Carter’s teaching at [0141] of uploading a file before minting the NFT. Nos. 5-6 are taught as previously alleged and Applicant has not specifically pointed out why they are not.
Cited Art Not Relied Upon
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed in the enclosed PTO-892.
Jeremias (US 20140351093 A1) teaches (relevant to accepting an offer within a chat application):
PNG
media_image1.png
527
792
media_image1.png
Greyscale
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached on (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights