DETAILED ACTION
Examiner's Note: The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s remarks filed on 07/22/2026 have been fully considered.
Regarding claim[s] 1 – 20 under the various anticipatory and obviousness rejections, applicant’s remarks are not persuasive, therefore, see the examiner’s response to such marks in the office action below.
The examiner will respond to all other remarks that do not concern the prior art rejections, if any, in the office action below.
Applicant states on page[s] 13 of the remarks as filed: “B. The Amended Independent Claims Recite a Limitation Eby Does Not Disclose Each of independent claims 1, 15, and 20 has been amended to recite that the blockchain token owner identifier "is stored in a digital wallet application on the owner device" and that "the physical representation of the blockchain token owner identifier is presented by the digital wallet application." This limitation now appears in every independent claim, together with the previously recited requirement that the owner identifier "was transferred from an owner device to the verifier device, at a locale, using a physical representation of the owner identifier." Eby does not disclose this subject matter.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Eby. Specifically, Figure # 3, and paragraph: 0023, Beginning with block 303, the authenticator 113 can receive a request to setup an NFT 116 for use in authentication situations. In some instances, the request could be receive from the owner of the NFT 116 (e.g., using a wallet client on a client device of the owner) [i.e. applicant’s…wallet application on the owner device]. In other instances, the request could be received from the NFT smart contract 109 (e.g., in response to or as a portion of the creation of the NFT 116). The request can include the owner wallet address 123 of the owner of the NFT 116 [i.e. applicant’s physical representation of the blockchain token owner identifier] and the NFT identifier 119 that identifies the NFT 116.
Then further of Eby, at paragraph: 0024, then, at block 306, the authenticator 113 can request a unique authentication credential associated with the NFT 116. For example, the authenticator 113 can invoke an API function call provided by the NFT smart contract 109 to request the unique authentication credential. The authenticator 113 could pass the owner wallet address 123 and NFT identifier 119 as arguments to the function of the NFT smart contract 109 in order to specify with particularity the NFT 116 being configured and, therefore, the unique authentication credential to be used.
Further of Eby, at paragraph: 0025, Subsequently, at block 309, the NFT smart contract 109 can return the edge wallet URI 126 of the edge wallet 203 associated with the owner of the NFT 116. In some instances, the edge wallet URI 126 returned could include the owner wallet address 123, which would allow the authenticator 113 to directly request the unique authentication credential from the edge wallet 203.
Further of Eby, at paragraph: 0026, Next, at block 313, the authenticator 113 can request the unique authentication credential associated with the NFT 116 from the edge wallet 203. For example, the authenticator could send a request to the edge wallet URI 126 receive at block 309. The request could include information such as the purpose of the request (to configure an NFT 116 for authentication purposes) and the identity of the requestor [i.e. applicant’s the blockchain token owner identifier]. In some instances, this information could be embedded in the URI.
Further of Eby, at paragraph: 0030, Finally, at block 326, the authenticator 113 can record that the NFT 116 can be used to authenticate the owner [i.e. applicant’s the blockchain token owner identifier] as identified by the owner wallet address 123. This could be done in response to two conditions. First, it could be done in response to validating the signature of the signed challenge received at block 319 using the public key 129 retrieve at block 323. Second, it could be done in response to determining that the signed public key 129 received at block 319 matches the public key 129 retrieved at block 323. If both conditions are true, then the authenticator 113 can record that the NFT 116 can be used by its owner, as defined by the owner wallet address 123, for authentication purposes.
***The examiner’s response above equally applies to the same or similar remarks made on page[s] 13 - 16 of the remarks as filed regarding claim[s] 2 – 7, 11, 12, 14 - 17, 19, 20.
Applicant states on page[s] 16 of the remarks as filed: “
VI. Rejection of Claim 12 under 35 U.S.C. § 103 (Eby in view of Spivak)
In the Office Action, claim 12 was rejected under 35 U.S.C. § 103 as unpatentable over Eby in view of Spivak. Claim 12 depends from claim 1 and additionally recites "issuing an electronic identification card for the blockchain token owner identifier," wherein "the electronic identification card is stored in the digital wallet application on the owner device" and "the physical representation is part of the electronic identification card."
A. The Combination Does Not Disclose the Claimed Wallet Application and Electronic Identification Card
As set forth above with respect to claim 1, Eby does not disclose a digital wallet application on the owner device that stores the owner identifier and from which a physical representation is presented. The Office Action relies on Spivak to supply the electronic identification card stored in a wallet application, but Spivak does not cure Eby's deficiency. The cited passage of Spivak (I [0108]) describes a "security device on a physical object" used to trigger operations such as unlocking a door, and refers to "the user's printed ID card or badge or pass or ticket" - that is, a physical, printed credential scanned in an access-control context. Spivak does not disclose an electronic identification card stored in a consumer wallet application on the owner device, the physical representation of which is presented from that wallet application and transferred to a verifier device at a locale. A printed badge scanned at a door is not the claimed electronic identification card stored in, and presented from, a wallet application on the owner device.”
In response the examiner isn’t persuaded, the examiner points to paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on. The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.
What is further of Spivak, at Figures # 2A – 2H – 2H-1 – 2I – 2P, and paragraphs: 0122, 0179, show composite patterns [i.e. QR codes] that can be rendered digitally on the user’s scan device for authentication with the door.
Further the examiner notes that applicant’s claim language of claim 12 is indefinite at best. How can applicant’s recited “electronic identification card,” be stored in digital wallet, and be physical representation at the same time? Therefore, the examiner’s application of the teachings of Spivak [Figures # # 2A – 2H – 2H-1 – 2I – 2P and paragraphs: 0108, 0122, 0179] is fair and reasonable.
Applicant states on page[s] 16, 17 of the remarks as filed: “
B. The Rejection Lacks an Articulated Rationale Directed to the Claimed Combination
An obviousness rejection must provide "some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness." KSR Int'l Co. V. Teleflex Inc., 550 U.S. 398, 418 (2007); In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006). The stated rationale - to "implement a simplistic way of authenticating the owner - physical NFT by use of physically authenticating operations" (Office Action at 46-47, citing Spivak I [0110]) - does not address, much less supply a reason to arrive at, storing the owner identifier as an electronic identification card in a consumer wallet application on the owner device. Because neither Eby nor Spivak teaches the claimed wallet application and electronic identification card, and because the Office Action”
In response the examiner isn’t persuaded, the examiner points the examiner’s previous logic and reason to combine the prior art’s of Eby and Spivak.
Specifically, It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Spivak in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include authenticating the owner - NFT by a physical means to the requesting party of Spivak. This would allow for the custodian computing environment to implement a simplistic way of authenticating the owner - physical NFT by use of physically authenticating operations. See paragraph: 0110 of Spivak.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 23 are pending in the instant application.
Regarding claim[s] 1 – 20 under the various anticipatory and obviousness rejections, applicant’s claim amendments are not persuasive, therefore, the examiner has addressed such claim amendments in the office action below.
Regarding claim[s] 21 – 23, they are newly added claims and are addressed in the office action below.
Specification
Applicant’s amendment to the title filed on 07/22/2026 has been inspected, and is accepted.
Double Patenting
Regarding claim[s] 1 – 20 that were rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1 - 20 of U.S. Patent No. 12341916 [reference patent], applicant’s e-terminal disclaimer filed on 07/22/2026 and was approved on 08/03/2026, therefore, all double patenting rejections are withdrawn
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 8 – 10, 15, 20 is/are rejected under 35 U.S.C. 102[a][2] as being taught by Eby et al. [US PGPUB # 2023/0104103].
As per claim 1. Eby does teach a method for verifying a nonfungible token (NFT) [Eby, paragraph: 0006, lines 1 – 6, Disclosed are various approaches for managing ownership of digital assets, such as non-fungible tokens (NFTs) stored on a distributed ledger, using third-parties as custodians. When ownership of a digital asset, such as an NFT, is transferred between user, the NFT is often updated to reflect the wallet address of the new owner.] comprising:
receiving a blockchain token owner identifier from a verifier device, wherein the blockchain token owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the blockchain token owner identifier [Eby, Figure # 2, and paragraph: 0035, lines 13 – 17, In general, the request to take ownership of the NFT 123 will include at least the NFT identifier 129 of the NFT 123 and the owner identifier 139 [i.e. applicant’s….blockchain token owner identifier] of the individual requesting [i.e. applicant’s owner device] that the custody service 143 [i.e. applicant’s verifier device] take possession of the NFT 123.] and wherein the blockchain token owner identifier is stored in a digital wallet application on the owner device and the physical representation of the blockchain token owner identifier is presented by the digital wallet application [Eby, Figure # 3, and paragraph: 0023, Beginning with block 303, the authenticator 113 can receive a request to setup an NFT 116 for use in authentication situations. In some instances, the request could be receive from the owner of the NFT 116 (e.g., using a wallet client on a client device of the owner) [i.e. applicant’s…wallet application on the owner device]. In other instances, the request could be received from the NFT smart contract 109 (e.g., in response to or as a portion of the creation of the NFT 116). The request can include the owner wallet address 123 of the owner of the NFT 116 [i.e. applicant’s physical representation of the blockchain token owner identifier] and the NFT identifier 119 that identifies the NFT 116.
Then further of Eby, at paragraph: 0024, then, at block 306, the authenticator 113 can request a unique authentication credential associated with the NFT 116. For example, the authenticator 113 can invoke an API function call provided by the NFT smart contract 109 to request the unique authentication credential. The authenticator 113 could pass the owner wallet address 123 and NFT identifier 119 as arguments to the function of the NFT smart contract 109 in order to specify with particularity the NFT 116 being configured and, therefore, the unique authentication credential to be used.
Further of Eby, at paragraph: 0025, Subsequently, at block 309, the NFT smart contract 109 can return the edge wallet URI 126 of the edge wallet 203 associated with the owner of the NFT 116. In some instances, the edge wallet URI 126 returned could include the owner wallet address 123, which would allow the authenticator 113 to directly request the unique authentication credential from the edge wallet 203.
Further of Eby, at paragraph: 0026, Next, at block 313, the authenticator 113 can request the unique authentication credential associated with the NFT 116 from the edge wallet 203. For example, the authenticator could send a request to the edge wallet URI 126 receive at block 309. The request could include information such as the purpose of the request (to configure an NFT 116 for authentication purposes) and the identity of the requestor [i.e. applicant’s the blockchain token owner identifier]. In some instances, this information could be embedded in the URI.
Further of Eby, at paragraph: 0030, Finally, at block 326, the authenticator 113 can record that the NFT 116 can be used to authenticate the owner [i.e. applicant’s the blockchain token owner identifier] as identified by the owner wallet address 123. This could be done in response to two conditions. First, it could be done in response to validating the signature of the signed challenge received at block 319 using the public key 129 retrieve at block 323. Second, it could be done in response to determining that the signed public key 129 received at block 319 matches the public key 129 retrieved at block 323. If both conditions are true, then the authenticator 113 can record that the NFT 116 can be used by its owner, as defined by the owner wallet address 123, for authentication purposes.];
verifying ownership of a blockchain token using the blockchain token owner identifier [Eby, Figure # 2, and paragraph: 0038, lines 1 – 9, Proceeding to block 216, the custody service 143 can create a verifiable credential 159 that can be used by the customer who sent the request at block 206 to take ownership of the NFT 123 to prove that the customer is the owner of the NFT 123 held by the custody service 143. For example, the custody service 143 could generate the verifiable credential 159 and sign the verifiable credential 159 with the NFT owner private key 136.]; and
returning ownership verification data of the blockchain token to the verifier device [Eby, Figure # 2, and paragraph: 0038, lines 13 – 23, In some examples, where custody service 143 [i.e. applicant’s verifier device] could instead provide a copy of the verifiable credential 159 to the verifier service 153. In these examples, the verifier service 153 could verify the authenticity of the verifiable credential 159 provided by the custody service 143 and then either sign the verifiable credential 159 with the verifier private key 163 or generate a signed token with the verifier private key 163, which could then be included in the verifiable credential 159. In these examples, the verifiable credential 159 could then be returned by the verifier service 153 to the custody service 143.].
As per claim 8. Eby does teach the method of claim 1, wherein:
the blockchain token owner identifier is a public wallet identifier associated with the blockchain token on a blockchain [Eby, Figure # 1, and paragraph: 0016, lines 6 – 8, In some implementations, the NFT owner public key 133 can be referred to as the wallet address or owner address for the NFT 123.]; and
verifying ownership of the blockchain token includes accessing the blockchain and requesting a message encrypted with a private key associated with the public wallet identifier [Eby, Figure # 1, and paragraph: 0016, lines 8 – 15, For each NFT owner public key 133, there can also be a respective NFT owner private key 136. The NFT owner private key 136 allows for the owner of an NFT 123 to verify his or her ownership by generating cryptographically secure signatures that can be verified using the NFT owner public key 133. Accordingly, the NFT owner private key 136 may be stored in a non-public location separate from the asset ledger 113.].
As per claim 9. Eby does teach the method of claim 1, wherein verifying ownership of the blockchain token using the blockchain token owner identifier comprises:
searching a database of a blockchain shell system for the blockchain token owner identifier using the blockchain token owner identifier [Eby, paragraph: 0022, lines 8 – 14, The custody service 143 can also create, revoke, or update ownership claims 126 stored in the identity ledger 116 for individual NFTs 123. As part of these processes, the custody service 143 can also create or issue verifiable credentials 159 to client devices 109 so that owners of NFTs 123 can verify their ownership to third-parties.].
As per claim 10. Eby does teach the method of claim 1, wherein verifying ownership of the blockchain token using the blockchain token owner identifier comprises:
searching a database of a blockchain shell system for a public wallet identifier using the blockchain token owner identifier [Eby, Figure # 3, paragraph: 0045, Proceeding to block 306, the verifier service 153 can send a proof request to the identity wallet 169 in response to receiving the verification request at block 303. The proof request can specify the verifiable credential 159 to be authenticated or verified, so that the identity wallet 169 can return the proof for the desired verifiable credential 159. For example, the proof request could specify the NFT 123 associated with the verifiable credential 159 (e.g., by including the NFT identifier 129 of the NFT 123).]; and
accessing a blockchain to verify that the public wallet identifier is associated with the blockchain token on the blockchain [Eby, Figure # 3, paragraph: 0046, Then, at block 309, the identity wallet 169 can search for the verifiable credential 159 and return a proof of authenticity or integrity to the verifiable credential 159 to the verifier service 153. For example, if the verifiable credential 159 had been signed by the custody service 143 or the verifier service 153, then the identity wallet 169 could return the signature of the verifiable credential 159. As another example, if the verifiable credential 159 includes a token that had been signed by the custody service 143 or the verifier service 153, the token and the cryptographic signature for the token could be returned to the verifier service 153 as proof of authenticity or integrity.].
As per non – transitory computer-readable media claim 15 that includes the same or similar claim limitations as method claim 1, and is similarly rejected.
***The examiner notes that applicant’s recited: “non – transitory computer-readable media,” “instructions,” and “one or more processors” is taught by the prior art of Eby at paragraphs: 0067 – 0070, 0072.
As per system claim 20 that includes the same or similar claim limitations as method claim 1, and is similarly rejected.
***The examiner notes that applicant’s recited: “one or more servers” is taught by the prior art of Eby at paragraph: 0012, lines 1 – 4.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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 non-obviousness.
Claim(s) 2 - 4, 16, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eby et al. [US PGPUB # 2023/0104103] in view of Cardo Sanchez et al. [US PGPUB # 2022/0269754]
As per claim 2. Eby does teach what is taught in the rejection of claim # 1 above.
While Eby does teach the claim limitation of: “...and wherein registering the blockchain token with the blockchain shell system includes generating the blockchain token owner identifier.” [paragraph: 0029, To begin, a user registers his owner identifier 139 as a decentralized identifier (DID) 127 in the identity ledger 116. The DID 127 can include information identifying the user (e.g., name, contact information, etc.) and a public key that can be used to identify the user].
Eby does not clearly teach the method of claim 1, further comprising: registering the blockchain token with a blockchain shell system.
However, Cardo Sanchez does teach the method of claim 1, further comprising:
registering the blockchain token with a blockchain shell system [paragraph: 0005, lines 2 – 6, relating to particular Assets on a blockchain, each represented by a Non-Fungible Token (NFT) which upon creation is recorded in a block of a public blockchain architecture alongside all of the information relating to the represented Asset.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Cardo Sanchez in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include digital right asset ledger of Cardo Sanchez. This would allow for the requesting party and owner to assert and prove any action or access to the NFT before access or action is allowed to the NFT. See paragraph: 0017 of Cardo Sanchez.
As per claim 3. Eby as modified does teach the method of claim 2, wherein registering the blockchain token comprises:
transferring the blockchain token via an entry on a blockchain [Eby, paragraph: 0029, To begin, a user registers his owner identifier 139 as a decentralized identifier (DID) 127 in the identity ledger 116. The DID 127 can include information identifying the user (e.g., name, contact information, etc.) and a public key that can be used to identify the user.].
As per claim 4. Eby does teach the method of claim 2, wherein registering the blockchain token comprises:
accessing a blockchain to find a public key associated with the blockchain token [Eby, Figure # 1, and paragraph: 0016, lines 8 – 15, For each NFT owner public key 133, there can also be a respective NFT owner private key 136. The NFT owner private key 136 allows for the owner of an NFT 123 to verify his or her ownership by generating cryptographically secure signatures that can be verified using the NFT owner public key 133. Accordingly, the NFT owner private key 136 may be stored in a non-public location separate from the asset ledger 113.]; and
requesting a message encrypted with a private key associated with the blockchain token [Eby, Figure # 2, and paragraph: 0038, lines 1 – 9, Proceeding to block 216, the custody service 143 can create a verifiable credential 159 that can be used by the customer who sent the request at block 206 to take ownership of the NFT 123 to prove that the customer is the owner of the NFT 123 held by the custody service 143. For example, the custody service 143 could generate the verifiable credential 159 and sign the verifiable credential 159 with the NFT owner private key 136.].
As per non – transitory computer-readable media claim 16 that includes the same or similar claim limitations as method claim 2, and is similarly rejected.
As per non – transitory computer-readable media claim 17 that includes the same or similar claim limitations as method claim 3, and is similarly rejected.
Claim(s) 5 – 7, 11, 14, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eby et al. [US PGPUB # 2023/0104103] in view of Barhudarian et al. [US PGPUB # 2023/0135947]
As per claim 5. Eby does teach what is taught in the rejection of claim # 1 above.
Eby does not clearly teach the method of claim 1, further comprising:
registering the blockchain token with a blockchain shell system; and
wherein registering the blockchain token with the blockchain shell system includes
generating the blockchain token owner identifier for storage on an owner device, wherein the blockchain token owner identifier internally identifies an owner of the owner device in a blockchain shell system.
However, Barhudarian does teach the method of claim 1, further comprising:
registering the blockchain token with a blockchain shell system [Figure # 9, and paragraph: 0076, lines 1 – 8, FIG. 9A illustrates an example communication pattern 900A for registering a new physical item and associating the new physical item with a new NFT. As illustrated in FIG. 9A, the data system 906 is configured to generate a new record associated with a new physical item (represented by arrow 912A). In response to generating a new record, the data system 906 is configured to send a request to the decentralized system 908 (represented by arrow 914A), causing the new NFT to be registered in the decentralized system 908 (represented by arrow 916A).]; and
wherein registering the blockchain token with the blockchain shell system includes generating the blockchain token owner identifier for storage on an owner device, wherein the blockchain token owner identifier internally identifies an owner of the owner device in a blockchain shell system [Barhudarian, Figure # 9, and paragraph: 0077, lines 1 – 2, Once the first dataset and the second dataset are stored in the smart fabric 902, a computing device 910 (e.g., a computing device associated with the current owner or a potential buyer) can be used to verify authenticity and/or ownership of the physical item].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Barhudarian in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include smart fabric of Barhudarian. This would allow for the requesting party and owner to consult a smart contract and prove that any action or access to the NFT is sanctioned by the smart contract before access or action is allowed with the NFT. See paragraph: 0004 of Barhudarian.
As per claim 6. Eby as modified does teach the method of claim 1, further comprising:
registering the blockchain token with a blockchain shell system, wherein registering the blockchain token with the blockchain shell system includes storing a full legal name for an owner in the blockchain shell system [Barhudarian, paragraph: 0049, In some embodiments, the NFPFT system further includes a data system configured to store a data record associated with the physical item 110 and/or NFT 122…..The computer system of manufacture 130 is further configured to record a data record associated with the physical item 110 in the data system 170. For example, the data record associated with the physical item 110 may contain (but are not limited to) (1) attribute(s) of the physical item (e.g., a design, a color, a photo, and/or a sales price of the physical item), (2) personal information associated with owner(s) of the physical item 110 (e.g., a name, an email address, a phone number, a physical address of each owner), and/or (3) service performed on the physical item 110 (e.g., repair, maintenance, appraisal, etc.).];
wherein the ownership verification data of the blockchain token includes the full legal name for the owner [Barhudarian, paragraph: 0072, lines 1 – 12, In some embodiments, the computing device 500 is also configured to extract the service end point from the smart fabric 112 and/or the NFT 122 and access the data system 170 via the service end point 854 to retrieve the data record associated with the physical item 110, such as (but not limited to) (1) attribute(s) of the physical item 110 (e.g., a design, a color, a photo, and/or a sales price of the physical item 110), (2) personal information associated with owner(s) of the physical item 110 (e.g., a name, an email address, a phone number, a physical address of each owner), and/or (3) service performed on the physical item 110 (e.g., repair, maintenance, appraisal).].
As per claim 7. Eby as modified does teach the method of claim 1, further comprising:
the physical representation of the blockchain token owner identifier is a visual encoding presented on a display of an owner device [Barhudarian, Figure # 8, and paragraph: 0072, lines 12 – 17, In some embodiments, in response to retrieving the data record associated with the physical item 110, the computing device 500 is configured to generate a visualization, visualizing the data record associated with the physical item, e.g., displaying a photo of the physical item.]; and
the blockchain token owner identifier is transferred from the owner device to the verifier device using an optical sensor on the verifier device [Eby, Figure # 2, and paragraph: 0035, lines 13 – 17, In general, the request to take ownership of the NFT 123 will include at least the NFT identifier 129 of the NFT 123 and the owner identifier 139 [NFT owner identifier] of the individual requesting [i.e. applicant’s owner device] that the custody service 143 [i.e. applicant’s verifier device] take possession of the NFT 123. Then further of Barhudarian, Figure # 8, and paragraph: 0072, lines 12 – 17, In some embodiments, in response to retrieving the data record associated with the physical item 110, the computing device 500 is configured to generate a visualization, visualizing the data record associated with the physical item, e.g., displaying a photo of the physical item.].
As per claim 11. Eby as modified does teach the method of claim 1, wherein verifying ownership of the blockchain token using the blockchain token owner identifier comprises:
delivering a link to the blockchain token on a blockchain with the ownership verification data [Barhudarian, paragraph: 0071, lines 8 – 20, As such, when a set of multiple physical items are physically linked together, their corresponding NFTs are digitally linked together. As another example, an artist may create a first physical item and associate the first physical item with a first NFT. Later, the artist may create a second physical item, and associate the second physical item with a second NFT. If the first item and the second item form a set, the second NFT may include an NFT identifier of the first NFT in its metadata, and the first NFT may be added an NFT identifier of the second NFT in its metadata.].
As per claim 14. Eby as modified does teach the method of claim 13, further comprising:
registering the blockchain token with a blockchain shell system, wherein registering the blockchain token with the blockchain shell system [Barhudarian, Figure # 9, and paragraph: 0076, lines 1 – 8, FIG. 9A illustrates an example communication pattern 900A for registering a new physical item and associating the new physical item with a new NFT. As illustrated in FIG. 9A, the data system 906 is configured to generate a new record associated with a new physical item (represented by arrow 912A). In response to generating a new record, the data system 906 is configured to send a request to the decentralized system 908 (represented by arrow 914A), causing the new NFT to be registered in the decentralized system 908 (represented by arrow 916A).] includes storing the personal information for an owner in the blockchain shell system [Barhudarian, paragraph: 0072, lines 1 – 12, In some embodiments, the computing device 500 is also configured to extract the service end point from the smart fabric 112 and/or the NFT 122 and access the data system 170 via the service end point 854 to retrieve the data record associated with the physical item 110, such as (but not limited to) (1) attribute(s) of the physical item 110 (e.g., a design, a color, a photo, and/or a sales price of the physical item 110), (2) personal information associated with owner(s) of the physical item 110 (e.g., a name,]; and
wherein registering the blockchain token with the blockchain shell system includes generating the blockchain token owner identifier [Barhudarian, paragraph: 0006, lines 1 – 4, In some embodiments, the NFT also includes an owner identifier associated with an owner of the NFT. The owner of the NFT corresponds to an owner of the physical item].
As per non – transitory computer-readable media claim 19 that includes the same or similar claim limitations as method claim 14, and is similarly rejected.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over in Eby et al. [US PGPUB # 2023/0104103] view of Spivak et al. [US PGPUB # 2022/0366061]
As per claim 12. Eby does teach what is taught in the rejection of claim 1 above.
Eby does not clearly teach the method of claim 1, further comprising:
issuing an electronic identification card for the blockchain token owner identifier;
wherein the electronic identification card is stored in the digital wallet application on the owner device; and
wherein the physical representation is part of the electronic identification card.
However, Spivak does teach the method of claim 1, further comprising:
issuing an electronic identification card for the blockchain token owner identifier [paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on. The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.];
wherein the electronic identification card is stored in the digital wallet application on the owner device [paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on.]; and
wherein the physical representation is part of the electronic identification card [paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on. The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Spivak in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include authenticating the owner - NFT by a physical means to the requesting party of Spivak. This would allow for the custodian computing environment to implement a simplistic way of authenticating the owner - physical NFT by use of physically authenticating operations. See paragraph: 0110 of Spivak.
Claim(s) 21 – 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eby et al. [US PGPUB # 2023/0104103] in view of Meyers et al. [US PGPUB # 2023/0122552]
As per claim 21. Eby does teach what is taught in the rejection of claim # 1 above.
Eby does not clearly teach the method of claim 1, wherein the digital wallet application is Apple Wallet or Google Wallet.
However, Meyers does teach the method of claim 1, wherein the digital wallet application is Apple Wallet or Google Wallet [Figure # 8 and paragraph: 0118, Furthermore, the network interface 220 includes one more geolocations elements 222 such as a GPS receiver, a ultra-wideband (UWB) transceiver, a Bluetooth transceiver and/or other component(s) that that facilitate the generation of geolocation data and/or facilitate other location-based services. Consider the case where the client device 825 is a smartphone or tablet and the wallet app 250 is an Apple or Android wallet or mobile wallet card that is in a Apple or Android wallet. Once the wallet app 250 is activated, NFTs can be easily added to the wallet. In addition, the wallet app 250 can access the location services of the device, and for example, generate push notifications regarding NFTs that are available near the current location.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Meyers in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include authenticating the owner - NFT by a physical means of the requesting party of Meyers. This would allow for the custodian computing environment to implement a simplistic way of authenticating the owner - physical NFT by use of geo-location authenticating operations. See paragraph: 0113 of Meyers.
As per non – transitory computer-readable media claim 22 that includes the same or similar claim limitations as method claim 21, and is similarly rejected.
As per system claim 23that includes the same or similar claim limitations as method claim 21, and is similarly rejected.
Allowable Subject Matter
Claim[s] 13 and 18 contain allowable subject matter, but as allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Claim[s] 13, 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
***The examiner notes that a reasons for allowance can be written the next subsequent office action once all formal requirements have been overcome.
Conclusion
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 DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm.
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, Ali Shayanfar can be reached at 571-270-1050. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434
Prosecution Insights