Detailed Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgments
The submission filed on 03/19/26 is acknowledged.
Status of Claims
Claims 1-16, 22 and 23 are pending.
In the Amendment filed on 03/19/26, claims 1, 3, 5, 8-13, 15, 22 and 23 were amended, claims 17-21 were cancelled, and no claims were added.
Claims 1-16, 22 and 23 are rejected.
Response to Arguments
Regarding the objections to the specification
In view of the substitute specification filed, the objections to the specification are withdrawn.
For clarification of the record, it is noted that the substitute specification as filed does not comply with 37 CFR 1.121(b)(3) and 1.125(c), as not all changes relative to the immediate prior version of the specification of record have been shown with markings. For example, "500" (original specification as filed, 034, p. 23) was changed to "300" (substitute specification, 048, p. 24) but the change is not shown in the marked up copy.
As a courtesy to Applicant, the substitute specification is entered.
Regarding the objections to the drawings
In view of the replacement drawings and the change to the specification indicated in the preceding paragraph (6.), the objections to the drawings are withdrawn in part.
Applicant has corrected the objections to the drawings set forth in paragraphs 8-10 of the previous Office Action (issued 11/19/25). Applicant has not addressed the objections to the drawings set forth in paragraphs 11-13 of the previous Office Action, and accordingly these objections remain in force.
As for paragraph 7 of the previous Office Action, the instant replacement drawings, unlike the previous replacement drawings, are not seen to contain any substantive changes relative to the originally filed drawings. Therefore, paragraph 7 is not applicable to the instant replacement drawings.
Regarding page 3 ("Amendments to the Drawings") of Applicant's instant Response: for clarification of the record, instant replacement Figs. 3 and 5 (not Figs. 3 and 4) have been converted from color to black and white.
Regarding the claim objections
In view of the amendments to the claims and the cancellation of claims, the previous objections are withdrawn or rendered moot.
Regarding the rejections under 35 U.S.C. 112
In view of the amendments to the claims, the previous rejections are withdrawn in part. Note some of the rejections are not addressed, and some of the amendments give rise to new or revised rejections.
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but they are not persuasive.
The Office responds to Applicant's arguments below. Page numbers in the discussion below refer to Applicant's Response unless otherwise indicated.
Applicant argues:
Applicant respectfully disagrees. he [sic] claims are directed to a specific technological implementation for generating an NFT-based rental certificate on a specific blockchain using defined cryptographic key/address pairs, a smart contract, renter data stored on-chain, and a series of NFTs tied to respective rental-history intervals of a specific renter.
This is not a generic "organizing human activity" claim. The amended claims recite a particular technical architecture and a particular manner of generating immutable rental-history entries:
renter and landlord cryptographic key/address pairs are created and associated with a specific blockchain;
renter data is stored at least in part on that blockchain;
a smart contract is created for renter data associated with a renter-landlord relationship in a rental history database; and
a new NFT is generated in a series in which each NFT corresponds to a respective rental-history interval. (Response, p. 14; emphasis added)
In response:
The bolded content shown above in Applicant's argument represents abstract idea. The non-bolded content represents additional elements. As seen from the bolded and non-bolded portions, the additional elements are generic elements, recited at a high level of generality and not described, used off-the shelf in their ordinary capacities, in other words, the additional elements merely 'apply' the abstract idea.
Applicant further argues:
Those limitations impose a concrete technological structure on the claimed process and improve the manner in which rental history is generated, stored, and verified in a blockchain environment. The claims are therefore integrated into a practical application. (Response, p. 15; emphasis added)
In response:
The bolded content shown above in Applicant's argument represents abstract idea. The underlined content represents additional elements. As seen from the bolded portion, the alleged improvement is an improvement in the abstract idea, which does not render the claims eligible under 35 U.S.C. 101. As seen from the bolded and non-bolded portions, the additional elements are generic elements, recited at a high level of generality and not described, used off-the shelf in their ordinary capacities, in other words, the additional elements merely 'apply' the abstract idea.
Applicant further argues:
Even if the Office were to characterize some aspect of the claims as involving a commercial context, the claims amount to significantly more than such an alleged abstraction. The claims do not merely say "record rental history." They require a particular cryptographic and blockchain-based implementation that creates interval-based NFT entries authorized by specific wallet/key pairs and generated via a smart contract on a specific blockchain. That is a technical solution to a technical data-integrity and verification problem. (Response, p. 15; emphasis added)
In response:
The bolded content shown above in Applicant's argument represents abstract idea. The underlined content represents additional elements. As seen from the bolded and non-bolded portions, the additional elements are generic elements, recited at a high level of generality and not described, used off-the shelf in their ordinary capacities, in other words, the additional elements merely 'apply' the abstract idea.
Regarding the rejections under 35 U.S.C. 102 and 103
Applicant's arguments have been fully considered but they are not persuasive (as explained below) and/or are moot in view of the new combinations of references being used in the current rejections.
The Office responds to Applicant's arguments below. Page numbers in the discussion below refer to Applicant's Response unless otherwise indicated.
Applicant argues:
The Office Action relies on Richter's disclosure of rentable NFTs and an immutable ledger of NFT transactions. That is materially different from the presently claimed invention. As amended, the claims require generating a new NFT in a series where each NFT in the series corresponds to a respective rental-history interval of the specific renter. Richter does not disclose that.
Richter appears to describe renting an NFT or recording NFT-related transactions. That is not the same as generating interval-specific rental-history certificate NFTs for a renter. An immutable ledger of transactions involving an NFT is not, without more, a series of NFTs in which each NFT corresponds to a respective rental-history interval of a renter. (Response, p. 16; emphasis added)
In response:
First, the underlined portion shown above does not accurately reflect the claim language. For example, the claim does not recite "certificate NFTs."
Second, an immutable ledger of transactions involving an NFT is, without more, a series of NFTs. For example, Richter teaches:
[0072] Referring now to FIG. 2 , an exemplary embodiment of an immutable sequential listing 200 is illustrated. An “immutable sequential listing,” as used in this disclosure, is a data structure that places data entries in a fixed sequential arrangement, such as a temporal sequence of entries and/or blocks thereof, where the sequential arrangement, once established, cannot be altered or reordered. An immutable sequential listing 200 may be, include and/or implement an immutable ledger, where data entries that have been posted to immutable sequential listing 200 cannot be altered. (emphasis added)
The above teachings of Richter, e.g., "a fixed sequential arrangement" and "a temporal sequence of entries," constitute a "series." Further, Richter pertains to NFTs. See Richter, 0001. Therefore, the teachings of 0072 teach a "series of NFTs."
Finally, Richter teaches that "each NFT corresponds to a respective rental-history interval of a renter," for example:
[0035] … A “reNFT,” as disclosed in this disclosure, is an NFT that may be rented and/or leased from an owner to a renter and/or lessee for a predetermined period of time [rental-history interval]. … The owner of the reNFT may assign temporary usage rights [rental-history interval] to a user using a self-executable data structure …. permitting the owner of the reNFT to delegate a user role and an expiration date [rental-history interval] associated with the delegated user role. (emphasis added)
[0098] … "A “temporary usage right,” as used in this disclosure, is the right to use an NFT with a predetermined timeframe [rental-history interval]." (emphasis added)
Therefore, Richter teaches "a series of NFTs in which each NFT corresponds to a respective rental-history interval of a renter."
Applicant further argues:
Nor does Richter disclose the amended authorization limitation as claimed. The amended claims require that generation of the new NFT is authorized by either the renter private key/wallet key pair or the entity private
key/wallet key pair. The cited portions of Richter, at most, describe parties agreeing to rental terms or a user role being delegated. That is not a disclosure of the specific claimed authorization of generation of a new rental-history NFT entry by one of the two recited cryptographic key/wallet pairs. (Response, pp. 16-17)
In response:
Nguyen is newly cited as teaching the instant amended authorization limitation.
Applicant further argues:
The Office Action also equates Richter's immutable ledger with an "NFT-based rental certificate." That reading is overly broad. The present claims require generation of a new NFT in a defined series to represent rental-history information. Richter's transaction ledger is not itself a newly generated NFT certificate entry corresponding to a rental-history interval. (Response, p. 17; emphasis added)
In response:
First, the underlined portion shown above does not accurately reflect the claim language.
Second, Choi is newly cited as teaching the NFT certificate.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) and (5) because:
The following reference numerals appear in the figures but not in the specification:
Fig. 3: 285
Fig. 6: 601, 601a
The following reference numerals appear in the specification but not in the figures:
067, p 37: 500 (Fig. 6)
In the following cases, the same reference numeral is used to refer to two different elements:
Fig. 1, 100 and Fig. 5, 100
Corrected drawing sheets in compliance with 37 CFR 1.121(d) and/or amendment to the specification, as applicable, are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
In addition to Replacement Sheets containing the corrected drawing figure(s), all changes to the drawings shall be explained, in detail, in either the drawing amendment or remarks section of the amendment paper, pursuant to 37 CFR 1.121(d). Applicant may submit a marked-up copy of each Replacement Sheet including annotations indicating the changes made to the previous version, as warranted for clarity of the record. Any marked-up copy must be clearly labeled as “Annotated Sheets” and must be presented in the amendment or remarks section that explains the change(s) to the drawings. See 37 CFR 1.121(d)(1). Failure to timely submit the proposed drawing and explanation of the drawing changes, or amendments to the specification, will result in the abandonment of the application.
Claim Rejections - 35 USC § 112
35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-16, 22 and 23 are 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Lack of Written Description/Not in Specification
Claims 1, 22 and 23 recite:
wherein generation of the new NFT is authorized by either (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair, to activate the rental history.
Similarly, claims 9-11 recite:
where the private key/wallet pair that authorizes generation of the new NFT is … key/wallet key pair.
Support in the disclosure is not found for the above-indicated recitations.
As best understood, the subject matter in the originally filed disclosure most relevant to the above limitations is in original claims 1, 22 and 23, and in the specification, paragraphs 008 (p. 4) and 0121 (p. 58). Original claim 1 recites:
generating a new NFT in a series on the specific blockchain according to new rental data using the smart contract and authorized by the entity private key/wallet key pair of the specific renter or the specific landlord to activate the rental history.
Original claims 22 and 23 and specification, paragraphs 008 (p. 4) and 0121 (p. 58), teach the same content.
As seen, this content describes merely that the NFT is authorized, not that the generating of the NFT is authorized.
Accordingly, support in the disclosure is not found for the above-indicated recitation of claims 1, 9-11, 22 and 23.
Claims 2-16 are (also) rejected by virtue of their dependency from a rejected claim.
35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-16, 22 and 23 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 pre-AIA the applicant regards as the invention.
Lack of Antecedent Basis/Unclear Antecedent Basis/Unclear Scope
Claim 1 recites:
(Letters added below for ease of reference.)
(A) creating a renter private key/wallet address pair associated with a specific renter to interact with the system, wherein the renter private key/wallet address pair is associated with a specific blockchain;
(B) creating an entity private key/wallet address pair associated with a specific landlord to interact with the smart contract and store at least a portion of the renter data associated with the specific renter on the specific blockchain;
(C) creating a smart contract for renter data associated with a relationship between the specific renter and the specific landlord in a rental history database; and
(D) generating a new NFT in a series on the specific blockchain according to new rental data using the smart contract, wherein each NFT in the series corresponds to a respective rental-history interval of the specific renter, and wherein generation of the new NFT is authorized by either (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair, to activate the rental history.
In step (B), "the smart contract" and "the renter data" lack antecedent basis. This could be resolved by amending to recite step (C) before step (B).
In step (C), it is not clear if "a smart contract" and "renter data" refer to "the smart contract" and "the renter data," respectively, in step (B). If so, this could be resolved by amending to recite step (C) before step (B). If not, Applicant should amend "a smart contract" and "renter data" of step (C) to clarify that they are different from "the smart contract" and "the renter data" of step (B).
In step (D), the recitations "the renter private key/wallet key pair" and "the entity private key/wallet key pair" (underlined above) are inconsistent with the similar language recited in steps (A) and (B). Consequently, these underlined recitations of step (D) lack antecedent basis. In addition, these underlined recitations of step (D), while apparently purporting to track the similar language in steps (A) and (B), are inaccurate in that regard: steps (A) and (B) recite a "renter private key/wallet address pair" and an "entity private key/wallet address pair" while step (D) recites the "renter private key/wallet key pair" and "the entity private key/wallet key pair."
In step (D), the recitation "the rental history" lacks antecedent basis.
Claim 7 recites:
storing the NFT in a wallet.
The recitation "the NFT" lacks antecedent basis. The relationship between "the NFT" of claim 7 and the "new NFT" of claim 1 is not clear. The relationship between "the NFT" of claim 7 and "each NFT in the series" of claim 1 is not clear.
Claim 8 recites:
where the extraction is done via an AI agent.
The recitation "the extraction" lacks antecedent basis. Also, it is not clear how claim is related to base claim 1. For example, it is not clear if the "rental data" of claims 8 is the same as the "renter data" of claim 1 or not. Again, it is not clear from where the rental data is "extracted," for example, whether it is extracted from the specific blockchain, the database, the smart contract, the rental history, or something else.
Claim 12 recites:
The method of claim 1, where the private key/wallet pair is authorized to interact with the smart contract.
The underlined language lacks antecedent basis. (Claim 1 recites (i) "renter private key/wallet key pair" and (ii) "entity private key/wallet key pair" but not "private key/wallet key pair," and it would not be clear to which of (i) and (ii) the underlined language in claim 11 refers.)
Claim 13 recites:
wherein during the step of creating the NFT further comprises paying a transaction fee by the user of the private key/wallet pair.
First, the recitation is on its face ungrammatical and accordingly unclear in meaning. As best understood, Applicant may have intended this claim to conform in grammatical form to claims 14 and 15. Second, "the step of creating the NFT" lacks antecedent basis, and it is not clear what it refers to. As best understood, Applicant may have intended "the step of creating the NFT" to refer to the step of "generating a new NFT …" in claim 1. Third, "the user" lacks antecedent basis, and it is not clear what it refers to. Fourth, "the private key/wallet pair" lacks antecedent basis and it is not clear what it refers to. As best understood, Applicant may have intended "the user of the private key/wallet pair" to be "the renter private key/wallet address pair" inasmuch as in context a renter is sometimes referred to as a "user," in contrast to the landlord who is sometimes referred to as an "owner" or also in the instant claims as an "entity."
Claim 14 recites:
wherein during the step of creating the NFT, a transaction fee is paid by the entity private key/wallet pair.
First, "the step of creating the NFT" lacks antecedent basis, and it is not clear what it refers to. As best understood, Applicant may have intended "the step of creating the NFT" to refer to the step of "generating a new NFT …" in claim 1.
Claims 22 and 23 recite:
(Letters added below for ease of reference.)
(A) creating1 a renter private key/wallet address pair associated with a specific renter to interact with the system, wherein the renter private key/wallet address pair is associated with a specific blockchain;
(B) creating an entity private key/wallet address pair associated with a specific landlord to interact with the smart contract and store at least a portion of the renter data associated with the specific renter on the blockchain;
(C) creating a smart contract for renter data associated with a relationship between the specific renter and the specific landlord in a rental history database; and
(D) generating a new NFT in a series on the specific blockchain according to new rental data using the smart contract wherein each NFT in the series corresponds to a respective rental-history interval of the specific renter, and wherein generation of the new NFT is authorized by either (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair, to activate the rental history.
Step (A) recites "a specific blockchain," step (B) recites "the blockchain," and step (D) recites "the specific blockchain." This inconsistency here between step (B) and (D) raises the question of whether "the blockchain" of step (B) refers to the "specific blockchain" of step (A). As best understood, "the blockchain" of step (B) does refer to the "specific blockchain" of step (A). If so, "the blockchain" of step (B) should be changed to "the specific blockchain," consistent with steps (A) and (D). If not, Applicant should amend "the blockchain" of step (B) to clarify that it is different from the "specific blockchain" of step (A).
In step (B), "the smart contract" and "the renter data" lack antecedent basis. This could be resolved by amending to recite step (C) before step (B).
In step (C), it is not clear if "a smart contract" and "renter data" refer to "the smart contract" and "the renter data," respectively, in step (B). If so, this could be resolved by amending to recite step (C) before step (B). If not, Applicant should amend "a smart contract" and "renter data" of step (C) to clarify that they are different from "the smart contract" and "the renter data" of step (B).
In step (D), the recitations "the renter private key/wallet key pair" and "the entity private key/wallet key pair" (underlined above) are inconsistent with the similar language recited in steps (A) and (B). Consequently, these underlined recitations of step (D) lack antecedent basis. In addition, these underlined recitations of step (D), while apparently purporting to track the similar language in steps (A) and (B), are inaccurate in that regard: steps (A) and (B) recite a "renter private key/wallet address pair" and an "entity private key/wallet address pair" while step (D) recites the "renter private key/wallet key pair" and "the entity private key/wallet key pair."
In step (D), the recitation "the rental history" lacks antecedent basis.
Claims 2-16 are (also) rejected by virtue of their dependency from a rejected claim.
35 USC § 112(d)
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), fourth paragraph:
Subject to the following paragraph, a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 11 is rejected under 35 U.S.C. 112(d) or 35 U.S.C. 112 (pre-AIA ), fourth paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends. Claim 11 recites:
The method of claim 1 where the private key/wallet pair that authorizes generation of the new NFT is any private key/wallet key pair.
The portion of the originally filed disclosure most closely related to the subject matter of claim 11 is Fig. 8 and its description at 0118-0121 (pp. 57-58) of the specification. In light of this disclosure, the term "any" is interpreted as referring to either the renter or the owner/landlord/"entity," as no other party (e.g., third party) is discussed in this context.
On this interpretation, dependent claim 11 does not further limit independent claim 1. That is, independent claim 1 recites:
wherein generation of the new NFT is authorized by either (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair, to activate the rental history.
and dependent claim 11 recites:
The method of claim 1 where the private key/wallet pair that authorizes generation of the new NFT is any private key/wallet key pair, i.e., where the private key/wallet pair that authorizes generation of the new NFT is either (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair.
As seen above, claim 11 recites the same substance as claim 1, and as such does not further limit claim 1.
Applicant may cancel claim 11, amend claim 11 or claim 1, or present a sufficient showing that claim 11 complies with the statutory requirements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-16, 22 and 23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-16, 22 and 23 are directed to a method, non-transitory computer-readable medium, or system, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 22 and 23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method, non-transitory computer-readable medium, and rental verification system for providing a history of rental transactions. For claims 1, 22 and 23 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
creating a renter private key/wallet address pair associated with a specific renter to interact with the system, wherein the renter private key/wallet address pair is associated with a specific blockchain;
creating an entity private key/wallet address pair associated with a specific landlord to interact with the smart contract and store at least a portion of the renter data associated with the specific renter on the specific blockchain;
creating a smart contract for renter data associated with a relationship between the specific renter and the specific landlord in a rental history database; and
generating a new NFT in a series on the specific blockchain according to new rental data using the smart contract, wherein each NFT in the series corresponds to a respective rental-history interval of the specific renter, and wherein generation of the new NFT is authorized by either (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair, to activate the rental history.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 22 and 23 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1, 22 and 23 recite the additional elements of a data communication network (the foregoing recited in claim 1), a non-transitory computer-readable medium in a rental verification system, on a data communication network, storing code (the foregoing recited in claim 22), a processor; a network interface communicatively coupled to the processor and to a data communication network; a memory, communicatively coupled to the processor and storing: a first module, a second module, a third module, and a fourth module (the foregoing recited in claim 23), and the system, a specific blockchain, and a smart contract (the foregoing recited in claims 1, 22 and 23), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions), such that they amount to no more than mere instructions to apply the exception using generic computer elements. Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a data communication network (the foregoing recited in claim 1), a non-transitory computer-readable medium in a rental verification system, on a data communication network, storing code (the foregoing recited in claim 22), a processor; a network interface communicatively coupled to the processor and to a data communication network; a memory, communicatively coupled to the processor and storing: a first module, a second module, a third module, and a fourth module (the foregoing recited in claim 23), and the system, a specific blockchain, and a smart contract (the foregoing recited in claims 1, 22 and 23), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements. Mere instructions to apply an exception using generic computer elements cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 22 and 23 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 2-16 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 22 and 23 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Dependent claim 2 merely further describes further comprising taking an action, responsive to combined rental data of the series of NFTs.
Dependent claim 3 merely further describes further comprising minting an NFT certificate based on immutable rental history transactions.
Dependent claim 4 merely further describes further comprising periodically updating at least one of a tenant assessments log and a tenant complaints log.
Dependent claim 5 merely further describes wherein a plurality of NFTs representing different sets of metadata are created.
Dependent claim 6 merely further describes further comprising periodically updating a rental payment history.
Dependent claim 7 merely further describes further comprising storing the NFT in a wallet.
Dependent claim 8 merely further describes where the extraction of rental data is done.
Dependent claims 9-11 merely further describe which private key/wallet key pair is the private key/wallet pair [sic] that authorizes generation of the new NFT.
Dependent claim 12 merely further describes where any private key/wallet pair is authorized to interact.
Dependent claims 13-16 merely further describe paying/sponsoring a transaction fee.
As for additional elements:
Dependent claims 4 and 6 recite "on the blockchain." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claim 8 recites "an AI agent." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claim 12 recites "the smart contract." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 2, 3, 5, 7, 9-11 and 13-16 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 2-16 are not patent eligible.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 7, 9-14, 22 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Richter (U.S. Patent Application Publication No. 2024/0281779 A1), in view of Choi (KR-20230030916-A), and further in view of Nguyen et al. (WO2023082008A1), hereafter Nguyen.
Regarding Claim 1, 22 and 23
Richter teaches:
(claim 1) A computer-implemented method in a system (Fig. 1, 100), on a data communication network (Fig. 7, 744), for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental …, the method comprising: (regarding computer-implemented method: the prior art teaching the method steps set forth below teaches the recited method; regarding immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental …: 0072, Fig. 2, the immutable sequential listing/immutable ledger of NFT (0031, 0035, e.g., rental) transactions (as shown in Fig. 2) teaches for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental history)
(claim 22) A non-transitory computer-readable medium in a rental verification system (Fig. 1, 100), on a data communication network (Fig. 7, 744), storing code that when executed, performs a method for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental …, the method comprising: (regarding non-transitory computer-readable medium … storing code: Fig. 7, 720, 724,728; regarding performs a method: the prior art teaching the method steps set forth below teaches performs a method; regarding immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental …: 0072, Fig. 2, the immutable sequential listing/immutable ledger of NFT (0031, 0035, e.g., rental) transactions (as shown in Fig. 2) teaches for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental history)
(claim 23) A rental verification system (Fig. 1, 100), on a data communication network (Fig. 7, 744), for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental …, the rental verification system comprising: (regarding immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental …: 0072, Fig. 2, the immutable sequential listing/immutable ledger of NFT (0031, 0035, e.g., rental) transactions (as shown in Fig. 2) teaches for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental history)
(claim 23) a processor; (Fig. 1, 104, Fig. 7, 704)
(claim 23) a network interface communicatively coupled to the processor and to a data communication network; and (Fig. 7, 740)
(claim 23) a memory, communicatively coupled to the processor and storing: (Fig. 1, 108, Fig. 7, 708, 724, 728)
(claim 23) a first module to …; a second module to …; a third module to …; a fourth module to …; (Fig. 7, 720)
creating a renter private key/wallet address pair associated with a specific renter (0031 tenant/renter) to interact with the system, wherein the renter private key/wallet address pair is associated with a specific blockchain; (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet; regarding to interact with the system: 0069 ERC-4709 allows an NFT owner to delegate a role (user/tenant) and time-limited usage rights to another. In this scenario, the owner and user/tenant agree on the terms of the rental (0035, 0098). For the user/tenant to rent the NFT involves an act of accepting, signing, or the like with respect to the self-executable structure (smart contract) on the NFT platform, that is, to interact with the system.; regarding wherein the renter private key/wallet address pair is associated with a specific blockchain: 0035 ERC-4709 refers to Ethereum, which is a specific blockchain ; 0070 decentralized platform 152 includes NFT marketplace such as the various entities named in 0070 ("OpenSea," etc.), each of which indicates a specific blockchain; that is to say, the context in which the wallet address is taught indicates that the wallet address is associated with a specified blockchain address.)
creating an entity private key/wallet address pair associated with a specific landlord (0031 owner) to interact with the smart contract and store at least a portion of the renter data associated with the specific renter on the specific2 blockchain; (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet; regarding to interact with the smart contract: 0069 ERC-4709 allows an NFT owner to delegate a role (user/tenant) and time-limited usage rights to another. For the owner to carry this out involves setting the terms of the self-executable structure (smart contract), that is, to interact with the smart contract.; regarding store at least a portion of the renter data associated with the specific renter on the blockchain: Fig. 2, 0072 immutable sequential listing/immutable ledger (stored on blockchain) of NFT (0031, 0035, e.g., rental) transactions, which includes renter data; also taught by Fig. 1 immutable sequential listing 148 is stored on decentralized platform 152 which per 0067-0068 is stored on blockchain; 0047 tokenized assets (i.e., NFTs), which include/would constitute renter data for a renter of the NFT, may be stored on digital ledger/immutable ledger (on blockchain) )
creating a smart contract (generate self-executable data structure, as described in 0035, 0064, 0098) for renter data associated with a relationship between the specific renter and the specific landlord in a rental history database; and (0035, 0064; regarding in a rental history database: 0098 self-executable data structure (smart contract) is stored in immutable sequential listing which per 0076 is stored in a database; 0052 "data entries in a database may store, retrieve, organize, and/or reflect data and/or records as used herein, as well as categories and/or populations of data consistently with this disclosure" -- that is, any data/records mentioned in the disclosure may be stored in the database; see also 0072, Fig. 2 shows an immutable sequential listing/immutable ledger of NFT (0031, 0035, e.g., rental) transactions (as shown in Fig. 2) and as per 0076 this immutable sequential listing is stored in a database)
generating a new NFT (0035 rental NFT (“reNFT”) or “wrapped” version of the NFT) in a series (0075 "series"; as per 0072-0073 the contents of the series includes NFT) on the specific blockchain according to new rental data (0031, 0035) using the smart contract (0035, 0064, 0098), wherein each NFT in the series corresponds to a respective rental-history interval of the specific renter, and … (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair, to activate the rental history. (regarding on the specific blockchain: 0047 tokenized assets (i.e., NFTs) may be stored on digital ledger, i.e., blockchain, or immutable ledger, which is stored on blockchain (per Fig. 1 immutable sequential listing 148 is stored on decentralized platform 152 which per 0067-0068 is stored on blockchain); regarding specific blockchain: 0035 ERC-4709 refers to Ethereum, which is a specific blockchain ; 0070 decentralized platform 152 includes NFT marketplace such as the various entities named in 0070 ("OpenSea," etc.), each of which indicates a specific blockchain; regarding wherein each NFT in the series corresponds to a respective rental-history interval of the specific renter: 0035 "A “reNFT,” as disclosed in this disclosure, is an NFT that may be rented and/or leased from an owner to a renter and/or lessee for a predetermined period of time [rental-history interval]. … The owner of the reNFT may assign temporary usage rights [rental-history interval] to a user using a self-executable data structure …. permitting the owner of the reNFT to delegate a user role and an expiration date [rental-history interval] associated with the delegated user role."; 0098 "A “temporary usage right,” as used in this disclosure, is the right to use an NFT with a predetermined timeframe [rental-history interval]."; regarding … (i) the renter private key/wallet key pair or (ii) the entity private key/wallet key pair: this recitation is taught as explained above for the steps of "creating a renter private key/wallet address pair …" and "creating an entity private key/wallet address pair …"; regarding activate the rental history: 0071-0072, 0075, Fig 2 each rental transaction is added to the immutable sequential listing/immutable ledger, which therefore contains a rental history, so the first transaction, and under broadest reasonable interpretation each transaction, activates the rental history)
Richter does not explicitly disclose a certificate but Choi teaches:
… for providing immutable rental history transactions within a non-fungible cryptographic token (NFT) based rental certificate … (e.g., p. 10 "The private blockchain platform system issues an NFT-based ownership certificate that manages the ownership change history of real assets and stores and manages owner information and real asset information to the owner who requested proof of ownership to verify ownership of real assets in the building. and real asset details management, smart contract management when ownership changes by smart contract of real assets, owner information of real assets, ownership change history, investor information of real assets, and transaction history and transaction records for each real asset."; claim 4 at p. 14 "A digital asset management system that uses block chain and NFT technology to store and manage each transaction history and transaction record."; see also discussion of NFT certificates and ownership change history throughout pp. 8-12 and claims at pp. 14 -16)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, by incorporating therein Choi's teachings regarding an NFT certificate including rental history, because a certificate serves as an authoritative concrete token that is useful to prove rental history, and because the combination is just a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143 I.(A).
Richter in view of Choi does not explicitly disclose but Nguyen teaches:
… wherein generation of the new NFT is authorized by either (i) the renter … or (ii) the entity …; (The method of Fig. 6, described at 0157-0183, includes creating (generating) a new NFT, see 0160-0161, 0167-0169; and per 0158 the method may be initiated by the renter or by the owner (landlord; entity); under broadest reasonable interpretation, initiation of the method that includes creation of the new NFT teaches authorization of generation of the new NFT)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, by incorporating therein Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, because it provides flexibility as to who can authorize generation of the NFT, and because it is just a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143 I.(A).
Regarding Claim 2
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
further comprising taking an action, responsive to combined rental data of the series of NFTs. (0071-0072, 0075, Fig 2 each rental transaction is added to the immutable sequential listing/immutable ledger; this adding of a transaction to the listing/ledger constitutes taking an action; after the first transaction is added, the listing/ledger includes combined rental data of the series of NFTs; therefore, after the first transaction is added, the next adding of a transaction to the listing/ledger constitutes taking an action responsive to combined rental data of the series of NFTs.)
Regarding Claim 3
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Choi further teaches:
further comprising minting an NFT certificate based on immutable rental history transactions. (e.g., p. 10 "The private blockchain platform system issues an NFT-based ownership certificate that manages the ownership change history of real assets and stores and manages owner information and real asset information to the owner who requested proof of ownership to verify ownership of real assets in the building. and real asset details management, smart contract management when ownership changes by smart contract of real assets, owner information of real assets, ownership change history, investor information of real assets, and transaction history and transaction records for each real asset."; claim 4 at p. 14 "A digital asset management system that uses block chain and NFT technology to store and manage each transaction history and transaction record."; see discussion of NFT certificates and change history throughout pp. 8-12 and claims at pp. 14 -16)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein these further teachings of Choi's regarding issuing (minting) an NFT certificate including ownership change information (rental history transactions), because a certificate serves as an authoritative concrete token that is useful to prove rental history, and because the combination is just a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143 I.(A).
Regarding Claim 5
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
wherein a plurality of NFTs representing different sets of metadata are created. (0035 "data collection 112 includes a plurality of data objects 116 associated with at least one NFT 120. … the at least one NFT 120 may be a utility NFT, a rental NFT (“reNFT”), a fractional NFT, a governance NFT, or the like." -- i.e., the at least one NFT may be different kinds of NFTs, i.e., multiple NFTs of different kinds are created; 0047 "metadata such as user profile, user classification, user categories, NFT types, use cases of NFT 120, and/or value dictation" -- since per 0035 the multiple NFTs are of different kinds, it follows per 0047 that they have different metadata.)
Regarding Claim 7
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
further comprising storing the NFT in a wallet. (0016 "the NFT will never leave the owner's digital wallet")
Regarding Claim 9
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
… the private key/wallet pair … the renter private key/wallet key pair …. (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet)
Nguyen further teaches:
where the private … wallet … that authorizes generation of the new NFT is the renter private … wallet …. (The method of Fig. 6, described at 0157-0183, includes creating (generating) a new NFT, see 0160-0161, 0167-0169; and per 0158 the method may be initiated by the renter (renter private) or by the owner (landlord; entity); under broadest reasonable interpretation, initiation of the method that includes creation of the new NFT teaches authorization of generation of the new NFT; regarding wallet: 0011 "the renter account comprising a renter wallet address;" 0174-0175 create NFT, issue to renter's wallet, and deduct fee from renter; 0230, 0255 "The wallet module 1140 is configured to create a wallet when users are created."; 0273-0274 users connected to wallets; 0284; 0293)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein these more specific teachings of Nguyen regarding authorizing generation of an NFT by the renter, because it provides flexibility for the renter, and because it is just a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143 I.(A).
Regarding Claim 10
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
… the private key/wallet pair … the entity private key/wallet key pair …. (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet)
Nguyen further teaches:
where the private …wallet … that authorizes generation of the new NFT is the entity private …wallet …. (The method of Fig. 6, described at 0157-0183, includes creating (generating) a new NFT, see 0160-0161, 0167-0169; and per 0158 the method may be initiated by the renter (renter private) or by the owner (landlord; entity); under broadest reasonable interpretation, initiation of the method that includes creation of the new NFT teaches authorization of generation of the new NFT; regarding wallet: 0230, 0255 "The wallet module 1140 is configured to create a wallet when users are created."; 0273-0274 users connected to wallets; 0284; 0293)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein these more specific teachings of Nguyen regarding authorizing generation of an NFT by the owner, because it provides flexibility for the owner/landlord, and because it is just a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143 I.(A).
Regarding Claim 11
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
… the private key/wallet pair … private key/wallet key pair …. (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet)
Nguyen further teaches:
where the private …wallet … that authorizes generation of the new NFT is any private …wallet …. (The method of Fig. 6, described at 0157-0183, includes creating (generating) a new NFT, see 0160-0161, 0167-0169; and per 0158 the method may be initiated by the renter (renter private) or by the owner (landlord; entity); under broadest reasonable interpretation, initiation of the method that includes creation of the new NFT teaches authorization of generation of the new NFT; regarding wallet: 0011 "the renter account comprising a renter wallet address;" 0174-0175 create NFT, issue to renter's wallet, and deduct fee from renter; 0230, 0255 "The wallet module 1140 is configured to create a wallet when users are created."; 0273-0274 users connected to wallets; 0284; 0293; note re claim interpretation: as explained in the rejection under 35 U.S.C. 112(d) above, the portion of the originally filed disclosure most closely related to the subject matter of claim 11 is Fig. 8 and its description at 0118-0121 (pp. 57-58) of the specification; in light of this disclosure, the term any is interpreted as referring to either the renter or the owner/landlord/ "entity", as no other party (e.g., third party) is discussed in this context)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein these more specific teachings of Nguyen regarding authorizing generation of an NFT by any party (i.e., owner or renter)3, because it provides flexibility as to who can authorize generation of the NFT, and because it is just a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143 I.(A).
Regarding Claim 12
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
where the any private key/wallet pair is authorized to interact with the smart contract. (0069 ERC-4709 allows (authorizes) an NFT owner to delegate a role (user/tenant) and time-limited usage rights to another. For the owner to carry this out involves setting the terms of the self-executable structure (smart contract), that is, to interact with the smart contract; 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet)
Regarding Claim 13
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
… the private key/wallet pair. (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet)
Nguyen further teaches:
wherein during the step of creating the new NFT further comprises paying a transaction fee by the user of the … wallet …. (0104 "Reference is made to FIG. 2, showing a block diagram of an example embodiment of a method 200 of creating an NFT." (during the step of creating the new NFT); 0109 "At 242, the back end deducts an online currency (e.g., Cointiks) as fees [further comprises paying a transaction fee] from the seller or the buyer [by the user] as agreed to create the NFT [during the step of creating the new NFT]." same/similar teachings also taught at 0129-0134, 0160-0165, 0186; regarding wallet: 0011 "the renter account comprising a renter wallet address;" 0174-0175 create NFT, issue to renter's wallet, and deduct fee from renter; 0230, 0255 "The wallet module 1140 is configured to create a wallet when users are created."; 0273-0274 users connected to wallets; 0284; 0293)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein these further teachings of Nguyen regarding payment of transaction fees by users/tenants, because transaction fees need to be paid by some party, it would assist landlords by having the fees paid by the tenants, and it is arguably fair to make the tenant pay this fee because the tenant seeks/needs usage of the property.
Regarding Claim 14
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
… the entity private key/wallet pair. (0031, 0035, 0069 under ERC-4907, the roles of owner (landlord) and user (tenant/renter) are created/assigned (see Deosthale ("Create Rentable NFTs with the ERC4907 standard"), p.2 "ERC4907 is a standard for non-fungible tokens (NFTs) that can be rented out to other wallets. This means this NFT will have an owner as well as a user.", pp 5-6 under the section heading "How To Rent NFTs" (p. 5), see the figure entitled "Renting out NFT" (p. 6), which contains fields under the heading "WRITE" including inter alia "setOwner" (i.e., instructions to create owner/landlord) and "setUser" (i.e., instructions to create user/renter/tenant)); 0074 "in one embodiment, an address is a textual datum identifying the recipient of virtual currency or another item of value in a digitally signed assertion 204. In some embodiments, address is linked to a public key, the corresponding private key of which is owned by the recipient of a digitally signed assertion 204. For instance, address may be the public key. Address may be a representation, such as a hash, of the public key. Address may be linked to the public key in memory of a computing device, for instance via a “wallet shortener” protocol. … a transferee … may [subsequently transfer] some or all of the value [s/he previously received] to a new address" -- thus as per 0074 when one wishes to transfer value (e.g., NFT, cryptocurrency) to another, one uses an address of the other to accomplish this -- one transfers the value to the address of the other; as indicated by the reference to "wallet shortener protocol," the term "address" here (i.e., in Richter's context of exchanging NFTs, by smart contracts, with associated storage on blockchain) refers to a "wallet address"; this point is confirmed, e.g., by 0016 teaching that NFTs are stored in (hence transferred to) a wallet)
Nguyen further teaches:
wherein during the step of creating the NFT, a transaction fee is paid by the entity … wallet …. (0104 "Reference is made to FIG. 2, showing a block diagram of an example embodiment of a method 200 of creating an NFT." (during the step of creating the new NFT); 0109 "At 242, the back end deducts an online currency (e.g., Cointiks) as fees [further comprises paying a transaction fee] from the seller [by the entity] or the buyer as agreed to create the NFT [during the step of creating the new NFT]." same/similar teachings also taught at 0129-0134, 0160-0165, 0186; regarding wallet: 0230, 0255 "The wallet module 1140 is configured to create a wallet when users are created."; 0273-0274 users connected to wallets; 0284; 0293)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein these further teachings of Nguyen regarding payment of transaction fees by owners/landlords, because transaction fees need to be paid by some party, it would assist tenants by having the fees paid by the landlords, and it is arguably fair to make the landlord pay this fee because the landlord is typically in a better financial position (wealthier) than the tenant and stands to earn income from renting the property.
Claims 4 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Richter (U.S. Patent Application Publication No. 2024/0281779 A1), in view of Choi (KR-20230030916-A), further in view of Nguyen et al. (WO2023082008A1), hereafter Nguyen, and further in view of Sher (U.S. Patent Application Publication No. 2018/0322597 A1).
Regarding Claim 4
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter in view of Choi and Nguyen does not explicitly disclose but Sher teaches:
further comprising periodically updating at least one of a tenant assessments log and a tenant complaints log on the blockchain. (0282-0283, 0289-0290, e.g., 0282 "In an example of a decentralized cryptographic platform for real estate transaction assistance …, the blockchain may include data relating to renters, tenants, landlords, owners, …. The blockchain may additionally include information related to …. Additional information may be associated with the above-mentioned data, such as performance history of a renter and/or tenant [tenant assessments log], repair requests associated with the unit, complaints made about a renter and/or tenant, complaints filed by the renter and/or tenant [tenant complaints log], payment history, financial information, likelihood of timely payment, responsibility, and other information that may assist in the determination of offering possession of a residence, commercial establishment, or other location. In this example, entry into record into the blockchain may advantageously be distributed an [sic, and] updated [periodically updating] substantially simultaneously with other parties having access to the blockchain.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein Sher's teachings regarding establishing/updating logs for tenant assessment and tenant complaints, because it would provide information and transparency for both (prospective) tenants and (prospective) landlords whereby both parties can find out information about the other, so as to reduce the effort and expense of finding out such information and to better protect both parties, and consequently to promote streamlined/efficient commerce between both parties and satisfaction of both parties, see Sher, Abstract and 0003-0005, 0009, 0018-0019, 0021-0023.
Regarding Claim 6
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter in view of Choi and Nguyen does not explicitly disclose but Sher teaches:
further comprising periodically updating a rental payment history on the blockchain. (0282-0283, 0289-0290, esp. 0282-0283, e.g., 0282 "In an example of a decentralized cryptographic platform for real estate transaction assistance …, the blockchain may include data relating to renters, tenants, landlords, owners, …. The blockchain may additionally include information related to …. Additional information may be associated with the above-mentioned data, such as performance history of a renter and/or tenant, …, payment history [rental payment history], financial information, likelihood of timely payment, responsibility, and other information that may assist in the determination of offering possession of a residence, commercial establishment, or other location. In this example, entry into record into the blockchain may advantageously be distributed an [sic, and] updated [periodically updating] substantially simultaneously with other parties having access to the blockchain.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein Sher's teachings regarding establishing/updating rental payment history, because it is useful for (prospective) landlords to have this information so as to be better informed about prospective tenants and therefore be able to make better selection of tenants, and it is useful for (prospective) tenants to have this information compiled for landlords so that the tenants can build up a good reputation that would help them compete against other tenants to be selected by landlords for properties they desire to rent, so in conclusion the proposed combination would assist both parties so as to promote streamlined/efficient commerce between them and promote the satisfaction of both parties, see Sher, Abstract and 0003-0005, 0018-0019, 0021-0023.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Richter (U.S. Patent Application Publication No. 2024/0281779 A1) in view of Choi (KR-20230030916-A), further in view of Nguyen et al. (WO2023082008A1), hereafter Nguyen, and further in view of Fernando et al. (U.S. Patent Application Publication No. 2021/0377310 A1), hereafter Fernando.
Regarding Claim 8
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter further teaches:
where the extraction of rental data is done …. (0059-0063 teaches extracting text/words, e.g., 0059 "role designation machine-learning model 132 may include a language processing module and/or an image processing module configured to identify the type of NFT by extracting one or more data objects, textual information, image information, and the like associated with NFT 120."; 0063 teaches that the extracted content can be rental data, e.g., 0063 "language module and/or processor 104 may perform this analysis using a selected set of documents concerning NFT 120, and/or data objects 116 such as owner profile, owner intent, owner category, types of assets associated with NFT 120, and/or ownership, which may also including documents identified by one or more experts as representing good information")
Richter in view of Choi and Nguyen does not explicitly teach AI but Fernando teaches:
where the extraction of … data is done via an AI agent. (0144 In blockchain context, AI agent extracts data)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein Fernando's teachings regarding using an AI agent to extract data, because it would improve efficiency and reduce cost.
Claims 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Richter (U.S. Patent Application Publication No. 2024/0281779 A1), in view of Choi (KR-20230030916-A), further in view of Nguyen et al. (WO2023082008A1), hereafter Nguyen, and further in view of Shin ("What is a Smart Contract Wallet? ERC-4337 Explained").
Regarding Claim 15
Richter in view of Choi and Nguyen teaches the limitations of base claim 1 as set forth above. Richter in view of Choi and Nguyen does not explicitly disclose but Shin teaches:
wherein during the step of generating the non-fungible token, a transaction fee is paid by a third party private key/wallet pair. (p. 5 "Gas Sponsorship: ERC-4337 introduced the ability for dApp developers [third party] to pay the gas [transaction fee] on behalf of their users. This can be especially useful for free NFT mints or other kinds of airdrops."; regarding private key/wallet pair: pp. 2-3 "The History of Smart Wallets: To understand the history of smart wallets, lets [sic] first dive into what web3 wallets were at their inception. What is an externally-owned account (EOA)? An externally-owned account (or EOA) is a web3 wallet created by generating a public-private key pair. The account owner (individual or organization) can then use the key pair to access and manage the funds associated with the account. Most of the popular web3 wallets on Ethereum, such as MetaMask or Ledger, are EOAs. You can use them to initiate transactions with other EOAs or smart contracts and send transactions.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, and as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, by incorporating therein Shin's teachings regarding payment of transaction fees by a third party, because transaction fees need to be paid by some party, it would assist tenants and landlords by having the fees paid by a third party, and it is arguably fair to make the third party pay this fee because the third party may be a well-funded organization (e.g., dApp developer) that is in a better financial position (wealthier) than the tenant and landlord and that stands to gain financially from having the tenant rent from the landlord (e.g., in a virtual reality/game setting), see Shin, p. 5.
Regarding Claim 16
Richter in view of Choi and Nguyen and Shin teaches the limitations of base claim 1 and intervening claims 15 as set forth above. Shin further teaches:
wherein the transaction fee is sponsored by a second entity with a second entity private key/wallet pair. (p. 5 "Gas Sponsorship [sponsored]: ERC-4337 introduced the ability for dApp developers [second entity] to pay the gas [transaction fee] on behalf of their users. This can be especially useful for free NFT mints or other kinds of airdrops."; regarding private key/wallet pair: pp. 2-3 "The History of Smart Wallets: To understand the history of smart wallets, lets [sic] first dive into what web3 wallets were at their inception. What is an externally-owned account (EOA)? An externally-owned account (or EOA) is a web3 wallet created by generating a public-private key pair. The account owner (individual or organization) can then use the key pair to access and manage the funds associated with the account. Most of the popular web3 wallets on Ethereum, such as MetaMask or Ledger, are EOAs. You can use them to initiate transactions with other EOAs or smart contracts and send transactions.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Richter's system for renting NFTs (e.g., representing real estate) using smart contracts and blockchain, as modified by Choi's teachings regarding an NFT certificate including rental history, as further modified by Nguyen's teachings regarding authorizing generation of an NFT by either owner or renter, and as further modified by Shin's teachings regarding payment of transaction fees by a third party, by incorporating therein Shin's further teachings regarding sponsorship of transaction (gas) fees by a second entity, because transaction fees need to be paid by some party, it would assist tenants and landlords by having the fees paid by a sponsor, and it is arguably fair to make the sponsor pay this fee because the sponsor may be a well-funded organization (e.g., dApp developer) that is in a better financial position (wealthier) than the tenant and landlord and that stands to gain financially from having the tenant rent from the landlord (e.g., in a virtual reality/game setting), see Shin, p. 5.
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure.
Richter (US-11836692-B1) and Richter (US-11880434-B1) teach subject matter similar to primary reference Richter (US-20240281779-A1).
MAKINO (US-20250062900-A1) teaches a decentralized ledger for renting NFTs, including generating and storing public/private key pairs and wallet address/private key pairs, and illustrations of distributed ledger data tables.
Lowenberg (US-20200349659-A1) teaches a verifiable/reliable/transparent renter-landlord information sharing platform stored on blockchain.
Tran (US-20210256070-A1) teaches a decentralized ledger for recording and managing property/ownership rights, contract details, etc., including smart contracts for administering real estate contracts including rentals, and tracking/recording renter behavior, among a wide variety of other applications.
NGUYEN (WO-2023082008-A1) teaches a detailed account of providing a digital media/NFT rental platform.
The following are NPLs:
Bilyeu provides a beginner's guide to cryptocurrency and NFTs.
Blockchain App Factory provides a guide to creating an NFT marketplace/ ecosystem.
DeCommas teaches about smart contract wallets.
Deosthale, Zavgorodniy, Shahzad, Yıldırım, Manoylov, and Maliukina teach about renting NFTs under the ERC-4907 standard.
"EIP4907: ERC-721 User And Expires Extension" and "ERC-4907: Rental NFT, an Extension of EIP-721" provide documentation including code re the ERC-4907 standard.
"ERC-6551: Non-fungible Token Bound Accounts" provides documentation including code re the ERC-6551 standard.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am - 5:30 pm ET.
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, Jessica Lemieux can be reached on 571-270-3445. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DOUGLAS W PINSKY/
Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
1 The claim language shown here is of claim 22; claim 23 recites the identical language except that it recites "a first/second/third/fourth module to create" instead of creating" for steps (A)-(D), respectively.
2 Note claims 22 and 23 omit the word "specific" here.
3 See rejection under 35 U.S.C. 112(d) above.
Prosecution Insights