DETAILED ACTION
Status of the Application
This office action is in response to Applicant's communication received on May 20, 2024 and October 11, 2024. Claims 1-3 are pending, have been examined and currently stand rejected.
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 .
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.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Drawings
The original drawings submitted on May 20, 2024 and the replacement drawings submitted on October 11, 2024, which replaced figures 2-5 and 7, have been received.
Drawing Objections:
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because:
reference character “820” (i.e., step 820) has been used to designate both creating “an entity private key/wallet address pair associated with the specific blockchain” and creating “an entity private key/wallet address pair associated with one or more of the specific locations.” See Fig. 8 step 820 and Specification [0119].
Reference character “830” (i.e., step 830) has been used to designate both creating “a smart contract for chat data associated with a relationship between the specific renter and the specific entity” and creating “smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database.” See Fig. 8 step 830 and Specification [0120].
Reference character “840” (i.e., step 840) has been used to designate both generating “a new NFT in a series on the specific blockchain according to the new chat data” and generating “a new NFT in a series on the specific blockchain according to new location data.” See Fig. 8 step 840 and Specification [0121].
Phrased differently steps 820, 830 and 840 shown in Figure 8 are not commensurate in scope with the description provided in paragraphs [0119-0121] of the Specification. Examiner notes that the Specification fails to provide any written description pertaining to the renter (e.g., a specific renter) or the chat data (e.g., new chat data) shown in Figure 8. Corrected drawing sheets in compliance with 37 CFR 1.121(d) 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.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a “first module” create a user private key/wallet address pair associated with a specific user to interact with the system, in claim 3;
a “second module” to create an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract, in claim 3;
a “third module” to create a smart contract for renter data associated with a relationship between a specific user and at least one specific location in a location history database, in claim 3; and
a “fourth module” to generate a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history, in claim 3.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. For computer-implemented means-plus-function limitations, the corresponding structure includes both the computer and the algorithm that performs the recited functions.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claims 2 and 3 are objected to for the following informalities:
Claims 2 and 3 recite, in part, create/creating “a smart contract for renter data associated with a relationship between a specific user and at least one specific location in a location history database.” (Emphasis added). Claim 1 differs from claims 2 and 3 because, in claim 1, the smart contract is for location data, not renter data. It is unclear if it was intentional to have the contracts in claims 2 and 3 be different (e.g., different in name and/or function) from the contract in claim 1. As currently recited, the smart contract in claim 1 appears to be created and utilized in the same manner as the contracts in claims 2 and 3. Accordingly, in view of the surrounding claim language it appears that this was a typographical error, and claims 2 and 3 should also recite “a smart contract for location data.” Clarification and/or appropriate correction is requested.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-3 are rejected under 35 U.S.C. 112(a) 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 at the time the application was filed, had possession of the claimed invention.
Regarding Claims 1 and 2: Claim 1 recites, in part, “creating a user private key/wallet address pair associated with a specific user to interact with the system, wherein the user private key/wallet address pair is associated with a specific blockchain.” Examiner has reviewed Applicant’s disclosure and is unable to find support for this limitation. Specifically, Applicant’s disclosure fails to provide any details (e.g., steps, diagrams, flow charts, etc.) describing how the claimed invention creates a user private key/wallet address pair that is associated with a particular user and a specific blockchain. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0118]. Since the disclosure fails to disclose these details, it is unknow what specific steps/actions one must take in order to create a key pair that is associated with the user and the specific blockchain.
Claim 1 recites, in part, “creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract and store at least a portion of the location data associated with the specific user on the blockchain.” Examiner has reviewed Applicant’s disclosure and is unable to find support for this limitation. Specifically, Applicant’s disclosure fails to provide any details describing how the claimed invention creates an entity private key/wallet address pair that is associated with one or more of the specific locations. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0119]. Since the disclosure fails to disclose these details, it is unknow what specific steps/actions one must take in order to create a key pair that is associated with one or more of the specific locations. Additionally, the disclosure fails to disclose how the claimed invention, or module, would store at least a portion of the location data associated with the specific user on the blockchain. For example, it is unclear/unknow what portion(s) of the location data are stored. It is also unclear/unknown if this location data, or the portions thereof, must be stored in a particular manner (e.g., placed in a certain transaction, signed by a particular key, stored by a certain entity and/or device, etc.) for the claimed invention to function properly. Claim 1 recites, in part, “creating a smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database.” Examiner has reviewed Applicant’s disclosure and is unable to find support for this limitation. Specifically, Applicant’s disclosure indicates that “Smart contracts can be automatically configured and deployed via API calls, on demand in real-time, and on a choice of blockchains or test network environments.” Specification [0038]. The disclosure also indicates “At step 830, a smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database is created”. Specification [0120]. Accordingly, the disclosure broadly indicates that API calls can be used to configure and deploy smart contracts, however the disclosure fails to provide any indication what steps the claimed invention is performing in order to create a smart contract that has the particular functionality (e.g., a contract for location data, a contract associated with particular information, etc.) described in the claim. Based on the inadequate description it is unclear/unknown if the smart contract must contain particular information (e.g., rules, location information, etc.) to be considered a “smart contract for location data.”
Claim 1 recites, in part, “generating a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history.” Examiner has reviewed Applicant’s disclosure and is unable to find support for this limitation. Specifically, Applicant’s disclosure merely reiterates the language found in the claim. Specification [0121]. The disclosure fails to provide any details (e.g., steps, diagrams, flow charts, etc.) describing how the claimed invention would generate the new NFT in this manner (e.g., according to new location data, the smart contract, the entity private key/wallet key pair of the specific user, or the one or more specific locations, etc.). For example, it is unknown if the smart contract is “used” to evaluate one or more particular conditions (e.g., a location requirement), or if the smart contract is merely “used” to generate an NFT representing a particular location (e.g., a new location), or something else altogether.
The MPEP is clear when it states that “the specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art in a way that shows that the inventor actually invented the claimed invention at the time of filing.” MPEP 2161.01. In this instance, Applicant’s disclosure fails to provide any indication on how the steps indicated above should be performed. Phrased differently, Applicant is expressing a desired result to achieve various steps without providing any indication as to how they achieve the result. Examiner notes that for computer-implemented inventions, such as the one claimed here, applicant must describe the steps/procedures taken to perform the function in sufficient details so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. In this instance those details are lacking. Independent claim 2 recites substantially similar steps to those identified above with respect to claim 1 and has the same written description issues, accordingly, claim 2 is also rejected under 35 U.S.C. 112(a) for the same reasons and rational explained above.
Regarding Claim 3: The claim limitations identified in the 35 U.S.C. 112(f) Claim Interpretation section, seen above, invoke 35 U.S.C. 112(f), however applicant’s disclosure fails to disclose the corresponding structure, material, or acts for performing the entire claimed function(s).
The structure corresponding to the 35 U.S.C. 112(f) claim limitations that are computer-implemented specialized functions must include a general purpose computer or computer component along with the algorithms that the computer uses to perform each claimed specialized function.
With respect to the various modules (i.e., the first, second, third and fourth modules) recited in claim 3, Applicant’s disclosure fails to provide any indication what structure, if any, is associated with the various modules. Claim 3 recites that is stores the various modules in memory, which suggests that the modules are some sort of data (e.g., software, code, a program, instructions, etc.), however neither the claim nor the disclosure provides any explicit indication of what these stored modules comprise. It is also worth noting that while the claimed system comprises a processor, the processor is not actual used to execute any instructions (e.g., instruction in a module, instructions stored in the memory), accordingly the claim implies that the module, by itself, is capable of performing the associated function(s).
As per the step of creating a user private key/wallet address pair associated with a specific user to interact with the system, wherein the user private key/wallet address pair is associated with a specific blockchain. Applicant’s disclosure fails to provide any details (e.g., steps, diagrams, flow charts, etc.) describing how the claimed invention, or the module, creates a user private key/wallet address pair that is associated with a particular user and a specific blockchain. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0118]. Since the disclosure fails to disclose these details, it is unknow what specific steps/actions one must take in order to create a key pair that is associated with the user and the specific blockchain.
As per the step of creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract and store at least a portion of the location data associated with the specific user on the blockchain. Here again the disclosure fails to provide any details describing how the claimed invention, or the module, creates an entity private key/wallet address pair that is associated with one or more of the specific locations. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0119]. Since the disclosure fails to disclose these details, it is unknow what specific steps/actions one must take in order to create a key pair that is associated with one or more of the specific locations. Additionally, the disclosure fails to disclose how the claimed invention, or module, would store at least a portion of the location data associated with the specific user on the blockchain. For example, it is unclear/unknow what portion(s) of the location data are stored. It is also unclear/unknown if this location data, or the portions thereof, must be stored in a particular manner (e.g., placed in a certain transaction, signed by a particular key, stored by a certain entity and/or device, etc.) for the claimed invention to function properly. As per the creating of a smart contract for renter/location data associated with a relationship between a specific user and at least one specific location in a location history database. The disclosure indicates that “Smart contracts can be automatically configured and deployed via API calls, on demand in real-time, and on a choice of blockchains or test network environments.” Specification [0038]. The disclosure also indicates “At step 830, a smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database is created”. Specification [0120]. Accordingly, the disclosure broadly indicates that API calls can be used to configure and deploy smart contracts, however the disclosure fails to provide any indication what steps the claimed invention is performing in order to create a smart contract that has the particular functionality (e.g., a contract for location data, a contract associated with particular information, etc.) described in the claim. Based on the inadequate description it is unclear/unknown if the smart contract must contain particular information (e.g., rules, location information, etc.) to be considered a “smart contract for location data.”
As per the generating of a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0121]. The disclosure fails to provide any details (e.g., steps, diagrams, flow charts, etc.) describing how the claimed invention would generate the new NFT in this manner (e.g., according to new location data, the smart contract, the entity private key/wallet key pair of the specific user, or the one or more specific locations, etc.). For example, it is unknown if the smart contract is “used” to evaluate one or more particular conditions (e.g., a location requirement), or if the smart contract is merely “used” to generate an NFT representing a particular location (e.g., a new location), or something else altogether.
In view of the details provided above, Examiner contends that Applicant’s disclosure fails to disclose the corresponding structure or material for performing the entire claimed function(s) and to clearly link the structure or material to the function(s). Accordingly, claim 3 is rejected under 35 U.S.C. 112(a) because it fails to comply with the written description requirement.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-3 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding Claim 1-3: Claim 1 recites the limitation “the specific locations” as in “creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract […].” There is insufficient antecedent basis for this limitation in the claim. The lack of antecedent basis also makes the claim unclear because claim 1 also recites “at least one specific location” in the “creating a smart contract” limitation“, and a “new location” in the “generating a new NFT” limitation. Accordingly, it is unknown what relationship, if any, the “one of more of the specific locations” has with the other locations recited in the claim. In order to further prosecution, Examiner has interpreted “creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract […]” to mean “creating an entity private key/wallet address pair associated with one or more of to interact with the smart contract […].”
Claims 2 and 3 also contain the same antecedent basis issue, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claim 1-3: Claim 1 recites the limitation “the smart contract” as in “creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract […].” There is insufficient antecedent basis for this limitation in the claim. The lack of antecedent basis also makes the claim unclear because it is unknown how the smart contract recited in this limitation is related, if at all, to the smart contract recited in the subsequent “creating a smart contract for location data” limitation. As best understood, these are the same smart contracts. In order to further prosecution the claim has been interpreted in this manner. Claims 2 and 3 also contain the same antecedent basis issue, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claim 1-3: Claim 1 recites the limitations “the location data” and “the blockchain” as in “creating an entity private key/wallet address pair […] and store at least a portion of the location data associated with the specific user on the blockchain.” There is insufficient antecedent basis for these limitations in the claim. The lack of antecedent basis also makes the claim unclear because it is unknown what location data, or portion thereof, is being stored. The preamble recites an immutable location history transaction and a NFT based location history certificate, however the claim fails to introduce the term/phrase “location data.” Additionally, the first limitation of the claim introduces “a specific blockchain”, however this particular limitation recites “the blockchain”. It is unclear, if the “specific blockchain” and “the blockchain” are the same or different blockchains. In order to further prosecution, Examiner has interpreted this portion of the limitation as reciting “store at least a portion of location data associated with the specific user on the specific blockchain.”
Claims 2 and 3 also contain the same antecedent basis issues, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claims 1-3: Claim 1 recites, in part, “creating a smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database.” This limitation is unclear. In particular, it is unclear what is data is “in a location history database.” For example, it is unclear if the smart contract is created in the location history database (i.e., the smart contract is created/stored in a particular location, e.g., the location history database), or if the data associated with a relationship between a specific user and at least one specific location is in the location history database (i.e., data about the association is stored in the database), or if only “at least one specific location” is stored in the location history database, or something else altogether. Applicant’s disclosure only mentions a “location history database” one time (Specification [0120]), and there it only reiterates the claim language, thus it fails to clarify what is in the location history database. In order to further prosecution, Examiner has interpreted this limitation as meaning that only the at least one specific location is in the location history database.
Claims 2 and 3 recite a substantially similar limitation, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claim 1-3: Claim 1 recites the limitation “the entity private key/wallet key pair of the specific user” as in “generating a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history.” There is insufficient antecedent basis for this limitation in the claim. The lack of antecedent basis also makes the claim unclear because the claim recites both a “user private key/wallet address pair associated with a specific user” and an “entity private key/wallet address pair associated with one or more of the specific locations”, accordingly it is unknown/unclear whether “the entity private key/wallet key pair of the specific user” is one of these key pairs or if it is another key pair altogether. Applicant’s disclosure fails to provide any clarification to this issue as the disclosure recites the same language found in the claim. See Specification [0121]. The lack of written description pertaining to this limitation, in addition to the lack of clarity in the claim and the disclosure makes it impossible to accurately determine the scope of this limitation.
Claims 2 and 3 recite a substantially similar limitation, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claim 1-3: Claim 1 recites the limitation “the location history” as in “generating a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history.” There is insufficient antecedent basis for this limitation in the claim. The lack of antecedent basis also makes the claim unclear because it is unknown/unclear what location history is being activated. Claim 1 never recites “a location history”, however claim 1 recites “immutable location history transactions”, a “NFT based location history certificate”, and a “location history database.” It is unclear, if the recited “location history” is the same as any of these of history related claim elements of if this is a different history claim element. In order to further prosecution, Examiner has interpreted this limitation as reciting “a location history.”
Claims 2 and 3 also contain the same antecedent basis issues, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claims 1-3: Claim 1 recites, in part, “generating a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history.” This limitation is unclear for at least two reasons. First, it is unclear what it means to be “authorized by the entity private key/wallet key pair of the specific user.” As indicated above, “the entity private key/wallet key pair of the specific user” lacks antecedent basis, however even if one were able to determine which key/wallet pair this is supposed to be, it is unclear what it means to be authorized by the key/wallet pair. For example, it is unclear if means the private key and the wallet/public key do something (e.g., sign something) to authorize the generation of the NFT, or if the private key/wallet key pair are used in some other manner. Applicant’s disclosure fails to elaborate on this process (see Specification [0121]), accordingly it is unknown how to appropriately interpret this portion of the limitation. Secondly, it is unclear what it means to “activate” the location history. For example, it is unknown if the NFT is generated in a particular manner so that it give a user access to particular information or a particular database, or if merely generating the NFT in the manner describe in the claim is considered to be “activating” some location history. Again, the disclosure only reiterates the claim language (see Specification [0121]), accordingly it is impossible to determine the scope of the claim.
Claims 2 and 3 recite a substantially similar limitation, accordingly claims 2 and 3 are also rejected for the same reasons and rational explained above.
Regarding Claim 3: The claim limitations identified above in the Claim Interpretation section are claim limitations that invoke 35 U.S.C. 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. For computer-implemented means-plus-function limitations, the corresponding structure includes both the computer and the algorithm that performs the recited functions.
With respect to the various modules (i.e., the first, second, third and fourth modules) recited in claim 3, Applicant’s disclosure fails to provide any indication what structure, if any, is associated with the various modules. Claim 3 recites that is stores the various modules in memory, which suggests that the modules are some sort of data (e.g., software, code, a program, instructions, etc.), however neither the claim nor the disclosure provides any explicit indication of what these stored modules comprise. It is also worth noting that while the claimed system comprises a processor, the processor is not actual used to execute any instructions (e.g., instruction in a module, instructions stored in the memory), accordingly the claim implies that the module, by itself, is capable of performing the associated function(s). In view of Applicant’s disclosure, it is unclear/unknow what structure, if any, the various modules comprise.
As per the step of creating a user private key/wallet address pair associated with a specific user to interact with the system, wherein the user private key/wallet address pair is associated with a specific blockchain. Applicant’s disclosure fails to provide any details (e.g., steps, diagrams, flow charts, etc.) describing how the claimed invention, or the module, creates a user private key/wallet address pair that is associated with a particular user and a specific blockchain. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0118]. Since the disclosure fails to disclose these details, it is unknow what specific steps/actions one must take in order to create a key pair that is associated with the user and the specific blockchain.
As per the step of creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract and store at least a portion of the location data associated with the specific user on the blockchain. Here again the disclosure fails to provide any details describing how the claimed invention, or the module, creates an entity private key/wallet address pair that is associated with one or more of the specific locations. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0119]. Since the disclosure fails to disclose these details, it is unknow what specific steps/actions one must take in order to create a key pair that is associated with one or more of the specific locations. Additionally, the disclosure fails to disclose how the claimed invention, or module, would store at least a portion of the location data associated with the specific user on the blockchain. For example, it is unclear/unknow what portion(s) of the location data are stored. It is also unclear/unknown if this location data, or the portions thereof, must be stored in a particular manner (e.g., placed in a certain transaction, signed by a particular key, stored by a certain entity and/or device, etc.) for the claimed invention to function properly. As per the creating of a smart contract for renter/location data associated with a relationship between a specific user and at least one specific location in a location history database. The disclosure indicates that “Smart contracts can be automatically configured and deployed via API calls, on demand in real-time, and on a choice of blockchains or test network environments.” Specification [0038]. The disclosure also indicates “At step 830, a smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database is created”. Specification [0120]. Accordingly, the disclosure broadly indicates that API calls can be used to configure and deploy smart contracts, however the disclosure fails to provide any indication what steps the claimed invention is performing in order to create a smart contract that has the particular functionality (e.g., a contract for location data, a contract associated with particular information, etc.) described in the claim. Based on the inadequate description it is unclear/unknown if the smart contract must contain particular information (e.g., rules, location information, etc.) to be considered a “smart contract for renter data” or a “smart contract for location data.”
As per the generating of a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history. Applicant’s disclosure merely reiterates the language found in the claim. Specification [0121]. The disclosure fails to provide any details (e.g., steps, diagrams, flow charts, etc.) describing how the claimed invention would generate the new NFT in this manner (e.g., according to new location data, the smart contract, the entity private key/wallet key pair of the specific user, or the one or more specific locations, etc.). For example, it is unknown if the smart contract is “used” to evaluate one or more particular conditions (e.g., a location requirement), or if the smart contract is merely “used” to generate an NFT representing a particular location (e.g., a new location), or something else altogether. Since the disclosure does not clearly identify the specific structure/computer to perform each of the recited functions, claim 3 is indefinite and is rejected under 35 U.S.C. 112(b).
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Sutton-Shearer et al. (US 2023/0027380 A1) (hereinafter “Sutton”) in view of Gillen (US 2019/0019144 A1).
Regarding Claims 1, 2 and 3: Sutton discloses:
Claim 1: A computer-implemented method in a system, on a data communication network, for providing immutable location history transactions within a non-fungible cryptographic token (NFT) based location history certificate, the method comprising:
Claim 2: A non-transitory computer-readable medium in a rental verification system, on a data communication network, storing code that when executed, performs a method for providing immutable location history transactions within a non-fungible cryptographic token (NFT) based location history certificate, the method comprising: Claim 3: A location system (i.e., computing platform), on a data communication network (i.e., network), for providing immutable location history transactions within a non-fungible cryptographic token (NFT) based location history certificate, the location system comprising (See at least Sutton Fig. 2 and corresponding text):
a processor (See at least Sutton [0086] “Computing platform(s) 202 may include one or more electronic storage and/or memory components 234, one or more processors 236, user interface components and/or other components.”; [0091] “one or more processing devices”; [0093] “one or more hardware processors”.);
a network interface communicatively coupled to the processor and to a data communication network (See at least Sutton [0061]; [0083]; [0086] “Computing platform(s) 202 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms”); and
a memory, communicatively coupled to the processor and storing (See at least Sutton [0087] “Electronic storage or memory component 234 may comprise non-transitory storage media that electronically stores information and may include traditional memory component(s) and storage component(s).”): a first module, second module, a third module and a fourth module (See at least Sutton [0088] “Processor(s) 236 may be configured to execute modules 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, and/or 230, and/or other modules”) to:
store at least a portion of the location data associated with the specific user on the blockchain (See at least Sutton [0039-0040]; [0045]; [0049]; [0064]. Sutton discloses storing (i.e., inserting) at least a portion of the location data associated with the specific user (i.e., location data (e.g., GPS data from a user's mobile device)) on the blockchain (i.e., into the blockchain).);
creating a smart contract for location data associated with a relationship between a specific user and at least one specific location in a location history database (See at least Sutton [0037]; [0045]. Sutton discloses creating (i.e., coding/programming) a smart contract for location data associated with a relationship between a specific user (i.e., a user’s location) and at least one specific location in a location history database (i.e., the location specified in the location criteria).);
generating a new NFT in a series on the specific blockchain according to new location data using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations to activate the location history (See at least Sutton [0016]; [0027-0034]; [0051]; [0054]; [0058]; [0071]; [0073]. Sutton discloses generating (i.e., minting) a new NFT (i.e., NFT) in a series (e.g., a series of NFTs that provide the same experience to each user, a series of NFTs that provide different experiences to each user) on the specific blockchain (i.e., the Ethereum blockchain) according to new location data (i.e., based on sensor or other event data, e.g., GPS or other location data) using the smart contract and authorized by the entity private key/wallet key pair of the specific user or the one or more specific locations (i.e., authorized by determining that the sensor-based or other event data meets a predetermined condition/rule/criteria, e.g., a specific location, a geofence or other location designator) to activate the location history (i.e., to activate an entitlement, e.g., an experience related to the location, providing access to a page, etc.).); and
sending the NFT to the user private key/wallet address pair (See at least Sutton [0027-0030]; [0078]. Sutton discloses sending (i.e., allocating/transferring) the NFT to the user private key/wallet address pair (i.e., to the digital wallet associated with the user).).
Sutton does not explicitly disclose: creating a user private key/wallet address pair associated with a specific user to interact with the system, wherein the user private key/wallet address pair is associated with a specific blockchain; or creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract.
Gillen, on the other hand, teaches:
creating a user private key/wallet address pair associated with a specific user to interact with the system, wherein the user private key/wallet address pair is associated with a specific blockchain (See at least Gillen [0078] “a digital asset can be transferred between one or more digital addresses and one or more temporary, digital address corresponding to a physical location. As mentioned, each digital address may be associated with unique private and public keys. In various embodiments, a random number generator can generate the private key. The random number generator may be a cryptographically secure, pseudo-random number generator that outputs a private key. The private key may then be input for a one-way cryptographic function. In various embodiments, the one-way cryptographic function is an elliptic curve multiplication. Utilizing the private key as input, the one-way cryptographic function can output a public key. The private and public key may then be used to encrypt/decrypt and/or sign/authorize a transfer request. In one embodiment, the public key can be hashed with a hashing algorithm, such as a RIPEMD hashing algorithm, a Secure Hash Algorithm (SHA), and/or the like. Additionally and/or alternatively, the hashing algorithm can hash the public key utilizing the location parameter of one or more computing devices to generate a digital address (e.g., a blockchain digital-physical address).”; also see [0084] and [0087] which indicate that the private-public key pair can be associated with a computing device (e.g., a computing device of a receiver).); and
creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with the smart contract (See at least Gillen [0076] “ The temporary digital address can be generated based on data/information associated with information/data from one or more computing devices. In one non-limiting example, the temporary digital address may be generated based in part on a location parameter of the one or more computing devices. For instance, the temporary digital address may be generated based at least in part on a location parameter (e.g., a set of GPS coordinates, a set of wireless signal identifiers, or a set of radio tower identifiers) of the one or more computing device's current location. The location parameter may then be used to generate a temporary private and/or public key pair that is used to create a temporary, location-based digital address. In further embodiments, the digital asset can be transferred from a first address to a second address based on the execution of a smart contract. For instance, the digital asset may not be transferred unless the location parameter of one or more computing device is submitted and/or validated