DETAILED ACTION
Response to Amendment
The amendment filed on April 1, 2026 has been entered. Applicant has amended claims 1-3. Claims 1-3 remain 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.
Specification
The amendment to the Specification submitted on April 1, 2026 is acceptable. The Specification amendment will be entered.
Drawings
The replacement drawing submitted on April 1, 2026, which replaced figure 8, has been received.
Drawing Objections:
The drawings, specifically Figure 8, is/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]. Phrased differently step 820 shown in Figure 8 is not commensurate in scope with the description provided in paragraph [0119] of the Specification. 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 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 difference in claim language was drafted in 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 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 location data” 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 this limitation 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.” 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 “address 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/address pair this is supposed to be, it is unclear what it means to be authorized by the key/wallet/address 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 gives a user access to particular information or a particular database, or if merely generating the NFT in the manner described 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.
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 location 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 instructions that, when executed by the processor, cause the processor to (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).”; [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”):
store at least a portion of the location data associated with the specific user on the specific 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 specific 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 a 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). Where the generated private and public key associated with a receiver = the created user private key/wallet address pair associated with a specific user.); and
creating an entity private key/wallet address pair associated with one or more of the specific locations to interact with a 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.”; also see [0087]. Where the generated temporary private and public key pair, which are generated based on a location parameter = the created entity private key/wallet address pair associated with one or more of the specific locations.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gillen into Sutton’s method of sending (i.e., allocating/transferring) an NFT to a user private key/wallet address pair (i.e., to a digital wallet associated with the user) based on determining that sensor-based or other event data meets a predetermined condition/rule/criteria. One of ordinary skill in the art would have been motivated to include such features in order to tie any transfer of a digital asset (e.g., an NFT) to a temporary address to a physical address/location at which the transfer of an asset occurs (Gillen [0088]).
Response to Arguments
Drawing Objections
Figure 8 was previously objected to for various inconsistencies between the Specification and the drawings. The Specification amendment and the replacement drawing submitted on April 1, 2026 have corrected most of the previously cited issues, however Figure 8 has a remaining issue pertaining to step 820 that was not addressed in the Specification amendment or the replacement drawing. Examiner has updated the drawing object to address the remaining issue.
Claim Objections
Claims 2 and 3 were objected to for inconsistencies in the claim language (e.g., renter data versus location data). Applicant’s amendments removed one reference to the rental data, however claims 2 and 3 are still reciting rental data in the “creating a smart contract” step. Examiner has maintained the claim objections since the originally cited issues in the objections has not been fully addressed.
Claim Rejections – 35 U.S.C. § 112(a)
Claims 1-3 were rejected under 35 U.S.C. § 112(a) for various written description issues. Examiner has reconsidered these rejections and has chosen to withdraw these rejections. Accordingly, Applicant’s remarks regarding the 112(a) rejections (See Amendment, pp. 10-13) are rendered moot.
Claim Rejections – 35 U.S.C. § 112(b)
Claims 1-3 were rejected under 35 U.S.C. § 112(b) as being indefinite. Applicant’s remarks identify five different amendments that were allegedly incorporated into the claims to address antecedent basis issues and clarity issues. Amendment, pp. 13-14. Examiner notes that, of these five amendments, three of these amendments are not found in the amended claims (i.e., the amendments associated with bullet points 1, 4 and 5). In particular, the amendment regarding “the specific locations,” the amendments regarding “the location history,” and the amendment regarding the authorization phrase is not found/recited in the amended claim set.
Examiner notes that the October 1, 2025 Non-Final Office Action identified several more 112(b) clarity issues that were not addressed in the claim amendments nor in applicant’s remarks. Examiner has withdrawn some of the 112(b) rejections that were addressed by the claim amendments, however the majority of the issues identified in the prior office action remain valid. Accordingly, the remaining 35 U.S.C. 112(b) rejections are being maintained.
Claim Interpretation – 35 U.S.C. § 112(f)
Claim 3 was previously interpreted as invoking 35 U.S.C. 112(f). Applicant indicates that they have amended claim 3 into a conventional processor-memory-instructions format, and concludes that 112(f) is no longer invoked. Amendment, pp. 14-15. Examiner agrees.
Claim Rejections – 35 U.S.C. § 103
Applicant argues that even if Sutton discloses location-based digital assets
or location-triggered minting, that is materially different from the presently claimed role-based wallet/key structure operating within a location-history certificate framework. In particular, Applicant alleges that Sutton does not teach the claimed separation between a user-associated wallet/key pair and an entity/location-associated wallet/key pair that interacts with a smart contract in the claimed manner. Amendment, pp. 16-17. This argument is unclear. The claimed invention does not recite/describe anything pertaining to a separation between a user-associated wallet/key pair and an entity/location-associated wallet/key pair. As per the user private key/wallet address pair, the claimed invention merely creates this pair and then sends the NFT to this pair. As per the entity private key/wallet address pair associated with one or more of the specific locations, the claimed invention merely creates this pair. The claimed invention takes no further action with this pair beyond its initial creation. As per “the entity private key/wallet key pair of the specific user,” this particular pair was first introduced in the step which generates the NFT. Due to remaining antecedent basis issues (see the 112(b) rejections above), it is unclear what relationship if any “the entity private key/wallet key pair of the specific user” has with any of the other pairs recited in the claim.
It is also noted that the claim does not explicitly require any pairs (e.g., a
user-associated wallet/key pair and an entity/location-associated wallet/key pair) to interact with the smart contract. That is, while the claim indicates that the generation of the new NFT could be authorized by the entity private key/wallet key pair of the specific user, the claim fails to provide any indication of how this authorization is provided (e.g., via some interaction with the smart contract, by signing some transaction, etc.). Furthermore, it is important to note that the “generating a new NFT” step, particularly the authorization aspect of this step, has an “or” option. That is, the generating of the NFT can be authorized by “the entity private key/wallet key pair of the specific user” or
the generating of the NFT can be authorized by “the one or more specific locations.” Accordingly, as currently recited, the generating of a new NFT and/or the authorization of the generation of the NFT does not require a key pair.
Applicant argues that Gillen's temporary location-derived address does not teach the claimed entity private key/wallet address pair associated with one or more specific locations. Amendment, pp. 17-18. This argument is unpersuasive. Gillen explicitly discloses that a 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). Gillen [0076]. Gillen further states that the location parameter may then be used to generate a temporary private and/or public key pair. Gillen [0076]. Examiner contends that this temporary private and public key pair that is generated based on a location parameter is the functional equivalent of the recited creating an entity private key/wallet address pair associated with one or more of the specific locations.
Applicant argues that the Examiner's rationale for combination does not
reach the actual claimed structure. Amendment, pp. 18-19. Examiner respectfully disagrees. Contrary to applicant’s remarks the rational need not explain why one would modify Sutton to arrive at “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, and NFT generation in a series according to new location data using that smart contract and then sending the NFT to the user wallet” because Sutton already discloses these features. Accordingly, Sutton would not need to be modified to include them. In fact, Sutton teaches the majority of the claimed invention. The only aspects not explicitly taught by Sutton pertain to the generation of two different “address pairs.” Furthermore, since Sutton discloses using blockchain related elements such as smart contracts and digital wallets, both of which commonly use one or more keys from a key pair, one of skill in the art would easily recognize that key pairs, or address pairs, would need to be generated. Additionally, the claimed invention merely creates an “entity private key/wallet address pair associated with one or more of the specific locations.” Beyond the creation of this address pair, the claimed invention does nothing with the address pair.
Applicant argues that the cited art does not teach the claimed location-history
relationship. Amendment, p. 19. Applicant’s arguments are based on features recited in the Specification and/or found in the Drawings, however the features described by applicant (e.g., location segmented by time, storing data or metadata via NFT mechanisms, etc.) are not recited in the claimed invention. While the claims are read in light of the specification, limitations from the specification are not read into the claims. Applicant is encouraged to further amend the claimed invention so that it is distinguishable from the prior art.
For the above reasons, and for those set forth in the 35 U.S.C. § 103 rejection above, all claims remain rejected under 35 U.S.C. § 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure is cited in the Notice of References Cited (PTO-892). The additional cited art further establishes the state of the art prior to the effective filling date of Applicant’s claimed invention.
Lynn et al. (US 2019/0340607 A1) discloses that the generation of blockchain tokens may be based on a smart contract, such that a standard set of rules and requirements for a transaction of one or more of the blockchain tokens must be met for the transaction to be executed by the smart contract. As such, blockchain networks like Ethereum that are designed for the generation and implementation of smart contracts (beyond being purely cryptocurrency-based) are especially useful in the process steps described herein. The generation of these blockchain tokens, the smart contract information, and other information (e.g., ownership of each blockchain token) can be recorded in the blockchain network's distributed ledger for accurate and validated ownership and transaction history records. Lynn [0073.
Coventry et al. (US 12,062,037 B1) discloses where processor(s) may be configured to generate a public key/private key pair for each of multiple participants respectively. Each public key/private key pair may be associated with a pseudonymous wallet address in a distributed ledger environment defined by multiple nodes. Coventry Col. 4 lines 50-54.
Eutsler et al. (US 12,361,778 B1) discloses obtaining, from a device of a user, location data, obtaining, from the device in response to a determination that the location parameter identifies a physical location of a physical environment, a public key of the user, generating, based on the public key and a private key of the user, an NFT linked with the user and the physical environment, determining, in response to a determination that the device satisfies a distance threshold to an entry controller at the physical location, that the NFT and the public key are compatible with a control structure of a smart contract, and transmitting, in response to the determination that that the NFT and the public key are compatible with the control structure of the smart contract, an instruction based on the NFT to modify operation of the entry controller to permit entry to the physical location. Eutsler Abstract.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON FENSTERMACHER whose telephone number is (571)270-3511. The examiner can normally be reached Monday - Friday 9:00 AM to 5:30 PM ET, Alternate Fridays Off.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.F./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights