Detailed Action
This office action is in response to applicant’s submission filed on November 11, 2025. Claims 2 and 18 were previously canceled. Claims 1, 3-17, 19-22 are pending and are 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 .
Response to Amendment
This communication is in response to the amendment filed on November 11, 2025. The Examiner has acknowledged the amended Claims 1, 3-6, and 19-21. Claims 2 and 18 were previously canceled. Claims 1, 3-17, 19-22 are pending and are rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed November 11, 2025 have been fully considered, but are moot. Note that this action is made FINAL. See MPEP § 706.07(a).
Applicant’s arguments with respect to claims 1, 3-17, 19-22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner also notes that the remainder of the arguments have been addressed by the newly added art. See also 103 rejection below.
Applicant’s amendments to claims 1 and 5 has issued a 112(f). See also below.
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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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 use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “means for: receiving…verifying” in claim 1 and “means for verifying…” in claim 5.
Since this claim limitation invokes 35 U.S.C. 112, sixth paragraph, claims 1 and 5 interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 USC 112(f) or 35 U.S.C. 112, sixth paragraph limitation: Referring to FIG. 6, a flowchart depicting a process600 for operating a storage device associated with a non-fungible token in accordance with various embodiments of the disclosure is shown. In certain embodiments, the process600 may encrypt data within a memory array of a storage device (block610). In this way, only the owner of the storage device that has the specific unique identifier and/or encryption key can access stored data. At one or more points during operation, the device may receive a request for the unique identifier associated with the device (block620). In some embodiments, this can occur when a user wishes to verify the provenance of the storage device, or transfer ownership of the device to a new owner. Upon receipt of the request, the process600 can provide the unique identifier data (block630). In a variety of embodiments, this data is provided to a host-computing device for further processing. In further embodiments, the process640 can receive a request to transfer the ownership of the device to a new owner (block640). This request can often be validated to determine the authenticity of the request and to verify that it has come from the current owner (block650). In certain embodiments, the storage device can carry out this validation by comparing it against current user data. Upon validation, the process600 can execute a light blockchain client that resides within a memory of the storage device (block660). The light blockchain client may attempt to interact with the blockchain associated with the storage device” [0092-0093].
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not wish to have the claim limitation treated under 35 USC 112(f) or 35 U.S.C. 112, sixth paragraph, applicant may amend the claim so that it will clearly not invoke 35 USC 112(f) or 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites sufficient structure, material, or acts for performing the claimed function to preclude application of 35 USC 112(f) or 35 U.S.C. 112, sixth paragraph.
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.
Claims 1, 3-8, 14-15, 17, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248653 A1 to McKenzie et al. (hereinafter, “McKenzie”) in view of US 2020/0242711 A1 to Cao et al. (hereinafter, “Cao”).
Regarding claim 1, McKenzie discloses: A storage device comprising:
at least one memory device (“Examples of computer-readable storage media include memory such as primary memory, cache memory, and secondary memory (e.g., CD, DVD, Blu-Ray) and include other storage means” [0030]); and
means for: receiving a request to transfer ownership of the storage device from a first owner to a second owner; verifying the request using at least one blockchain (“The exchange component facilitates a transaction between a buyer and a seller. In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller)... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence...an indication that the transaction is a transfer of ownership” [0035]);
McKenzie does not explicitly disclose: in response to verifying the request, generating an encryption key associated with the second owner; and encrypting subsequently-received data for storage in the at least one memory device with the generated encryption key in place of a prior encryption key used to encrypt data for the first owner for storage in the at least one memory device.
However, Cao discloses: in response to verifying the request, generating an encryption key associated with the second owner; and encrypting subsequently-received data for storage in the at least one memory device with the generated encryption key in place of a prior encryption key used to encrypt data for the first owner for storage in the at least one memory device (“In some embodiments, ownership can only be transferred by the owner 42, working together with the registry 41. In this case, the owner 42 may transmit the owner key 411 and a new owner public key of a new owner (not pictured). The registry 41 uses the owner key 411 to decrypt the encrypted digital asset private key 412 to get back the digital asset key 410. The registry 41 then generates a new owner key, encrypts the digital asset key 410 with the new owner key to get a new encrypted digital asset private key, encrypts the new owner key with the new owner public key of the new owner to get a new encrypted owner key, sends the new encrypted owner key to the new owner (optionally the new encrypted owner key can be transmitted to the new owner by the previous owner, or the new encrypted owner key can be saved on the registry, etc.), and then destroys the digital asset key 410, the new owner key, and the previous encrypted digital asset private key, and stores only the new encrypted digital asset private key. At this point, only the new owner can prove the ownership of the digital asset. The previous owner does not have proof of ownership anymore since the previous encrypted digital asset private key is destroyed. Although the previous owner may still has his or her owner key, it is useless without the other half, that is the previous encrypted digital asset private key which is now destroyed” [0081]; “The process for transferring ownership of an asset as shown in FIG. 6B may include the facilitator 620 verifying that the current owner 630 is the real owner of the asset 610 and the current owner 630 transferring the owner private key 660 to a new owner 630B as shown in FIG. 6B. A new owner secret key 640B should be selected, which should be known to the new owner 630B only and unknown to the current owner 630. The derived secret key 641 of secret key 640B is made known to the facilitator 620. Once the above process is complete, the previous owner 630 cannot prove his ownership over the asset anymore since they do not know the new secret key 640B. The facilitator 620 will not verify an owner if an owner cannot provide the current secret (e.g., secret key 640B). At all times, the three parties (the previous owner 630, the facilitator 620, and the current owner 630B) never know at least one of the thee secrets. The previous owner 630 does not know the current secret key 640B. The facilitator 620 does not know the owner private key 660 of the owner 630. The current owner does not know the facilitator private key 661 of the facilitator 620. All three secrets (e.g., private keys or secrets) are needed in order to verify ownership or transfer ownership” [0096-0097] [Examiner notes that these texts show that ownership is verified before the new key is effective (transfer only proceeds after verification happens). A new owner-specific key is created. The texts also show how revoking the old key ensured that the first owner can no longer access the asset. Encrypting the digital asset key under the new owner key controls future access, which shows that the new owner can encrypt the data coming in as the digital access key is what is encrypting that data. By encrypting the digital asset key under the new owner key, the system ensures that the new owner controls the digital access key, which in turn encrypts all future data, effectively making the new owner the only person who can encrypt/decrypt incoming data. The registry replaces the old key with the new encrypted key in storage which lets the system enforce the new key before any future access]).
Thus, it 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, to combine the method of McKenzie and the structure of Cao for the added benefit of being able to determine the rightful owner and authenticity of the digital asset [Cao 0003].
Regarding claim 3, a combination of McKenzie-Cao discloses the storage device of claim 1. McKenzie further discloses: wherein the storage device associated with on a blockchain of the at least one blockchain generating a non-fungible token for the product using, for example, the ERC-721 or ERC-1155 standards, applying a hash function (e.g., SHA-256, RIPEMD-160, etc.) to a) the unique identifier associated with the tag” [0032] [Examiner notes that any device (whether first, second, etc.) is associated with an NFT]; “In block 514, the buyer receives the product. In block 515, the buyer logs in to the scanner application to prove their identity and scans the tag attached to the product to confirm transfer of the product. In some examples, buyer's scanner application also finalizes payment to the seller...In block 532, the component returns a value of true, indicating that the exchange was successful. One of ordinary skill in the art will recognize that the transaction provided for recordation may include additional information related to the transaction and that various steps performed during the process can be completed using one or more smart contracts” [0035] [Examiner notes that the device's NFT was registered on the blockchain, establishing a record of its identity, ownership, and authenticity. When the device is transferred to a new owner, the NFT's blockchain record can be updated to reflect the buyer as the current owner since scanning the device's tag and validating the transaction on the blockchain ensures that each transfer is authenticated, aligning ownership records with the blockchain-stored NFT]).
Regarding claim 4, a combination of McKenzie-Cao discloses the storage device of claim 3. McKenzie further discloses: wherein the association with the NFT comprises at least a unique identifier assigned to the storage device An identity token for a physical or digital asset is generated” [0005]; “the component generates an identifier for the product by, for example, generating an identity token for the product, generating a non-fungible token for the product…” [0032]);
Regarding claim 5, a combination of McKenzie-Cao discloses the storage device of claim 1. McKenzie further discloses: means for verifying the request by providing a unique identifier assigned to the storage device and receiving a blockchain-based response unique identifier associated with the tag attached to the product” [0032]; “When the buyer receives the product, the buyer can scan the tag to confirm and claim ownership. Moreover, the transaction between the buyer and the seller can be recorded in a blockchain transaction to provide further proof of the transaction” [0022]; “The identifier created for the product can be a digital cryptographic identifier (e.g., a hash value generated using a secure hashing algorithm), a hash value generated from a description (or partial description) of the product and/or a serial number associated with the product, and so on. Furthermore, information about the product and tag is issued on a blockchain, such as a tag id, current owner, date and time authenticated, authenticator, and so on using a transaction signed using a private key (of a public/private key pair) of the authenticator” [0024]; “In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence” [0035] [Examiner notes that these texts, especially from [0022], show how the blockchain is providing a response (or record) confirming the transaction has occurred between the buyer and seller, which can be verified by looking up this transaction in the blockchain. When queried, the blockchain provides a response containing these details, which can be used to confirm the current ownership and authentication history of the product (in [0024])]).
Regarding claim 6, McKenzie discloses: A device, comprising:
a processor (“execution by one or more processors” [0030]);
a communication port (“network interfaces... Various communications links can be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on for connecting the computing systems and devices to other computing systems and devices to send and/or receive data, such as via the Internet or another network and its networking hardware...” [0030]);
a memory array comprising a plurality of memory devices (“Examples of computer-readable storage media include memory such as primary memory, cache memory, and secondary memory (e.g., CD, DVD, Blu-Ray) and include other storage means” [0030]); and
a storage device non-fungible token (NFT) logic configured to:
receive a request to transfer ownership of the device from the first owner to a second owner; verify, via the communication port, the The exchange component facilitates a transaction between a buyer and a seller. In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller)... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence...an indication that the transaction is a transfer of ownership” [0035]);
McKenzie does not explicitly disclose: generate a first encryption key associated with a first owner of the device; encrypt received data, prior to storing on the memory array with the first encryption key for the first owner of the device; in response to verifying the request of the device, with the second encryption key in place of the first encryption key previously used to encrypt data stored on the memory array for the first owner.
However, Cao discloses: generate a first encryption key associated with a first owner of the device (“a first owner key from the digital asset identifier” [0104]);
encrypt received data, prior to storing on the memory array with the first encryption key for the first owner of the device (“…may further encrypt the digital asset key 410 to produce the encrypted digital asset private key 412 using the owner key 411. In some embodiments, the owner key 411 is transmitted/given to the owner 42” [0075]);
in response to verifying the request of the device, with the second encryption key in place of the first encryption key previously used to encrypt data stored on the memory array for the first owner (“In some embodiments, ownership can only be transferred by the owner 42, working together with the registry 41. In this case, the owner 42 may transmit the owner key 411 and a new owner public key of a new owner (not pictured). The registry 41 uses the owner key 411 to decrypt the encrypted digital asset private key 412 to get back the digital asset key 410. The registry 41 then generates a new owner key, encrypts the digital asset key 410 with the new owner key to get a new encrypted digital asset private key, encrypts the new owner key with the new owner public key of the new owner to get a new encrypted owner key, sends the new encrypted owner key to the new owner (optionally the new encrypted owner key can be transmitted to the new owner by the previous owner, or the new encrypted owner key can be saved on the registry, etc.), and then destroys the digital asset key 410, the new owner key, and the previous encrypted digital asset private key, and stores only the new encrypted digital asset private key. At this point, only the new owner can prove the ownership of the digital asset. The previous owner does not have proof of ownership anymore since the previous encrypted digital asset private key is destroyed. Although the previous owner may still has his or her owner key, it is useless without the other half, that is the previous encrypted digital asset private key which is now destroyed” [0081]; “The process for transferring ownership of an asset as shown in FIG. 6B may include the facilitator 620 verifying that the current owner 630 is the real owner of the asset 610 and the current owner 630 transferring the owner private key 660 to a new owner 630B as shown in FIG. 6B. A new owner secret key 640B should be selected, which should be known to the new owner 630B only and unknown to the current owner 630. The derived secret key 641 of secret key 640B is made known to the facilitator 620. Once the above process is complete, the previous owner 630 cannot prove his ownership over the asset anymore since they do not know the new secret key 640B. The facilitator 620 will not verify an owner if an owner cannot provide the current secret (e.g., secret key 640B). At all times, the three parties (the previous owner 630, the facilitator 620, and the current owner 630B) never know at least one of the thee secrets. The previous owner 630 does not know the current secret key 640B. The facilitator 620 does not know the owner private key 660 of the owner 630. The current owner does not know the facilitator private key 661 of the facilitator 620. All three secrets (e.g., private keys or secrets) are needed in order to verify ownership or transfer ownership” [0096-0097] [Examiner notes that these texts show that ownership is verified before the new key is effective (transfer only proceeds after verification happens). A new owner-specific key is created. The texts also show how revoking the old key ensured that the first owner can no longer access the asset. Encrypting the digital asset key under the new owner key controls future access, which shows that the new owner can encrypt the data coming in as the digital access key is what is encrypting that data. By encrypting the digital asset key under the new owner key, the system ensures that the new owner controls the digital access key, which in turn encrypts all future data, effectively making the new owner the only person who can encrypt/decrypt incoming data. The registry replaces the old key with the new encrypted key in storage which lets the system enforce the new key before any future access]).
Thus, it 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, to combine the method of McKenzie and the structure of Cao for the added benefit of being able to determine the rightful owner and authenticity of the digital asset [Cao 0003].
Regarding claim 7, a combination of McKenzie-Cao discloses the device of claim 6.
McKenzie further discloses: wherein a unique identifier was assigned to the device during a manufacturing process of the device (“a product can be uniquely identified using the name of its manufacturer and its serial number” [0005] [Examiner notes that the unique identifier assigned to the device during the manufacturing process is the serial number]), and
wherein the storage device NFT logic is further configured to send the unique identifier via the communication port to verify the received request to transfer ownership of the device (“The exchange component facilitates a transaction between a buyer and a seller. In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller)... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence... In block 526, the scanner application generates a transaction indicating that the seller is selling the tagged product to the potential buyer, the transaction including identification information for the product, the seller, and the buyer, such as a unique identifier associated with each, a public key associated with each, etc. and information about the transaction, such as the date and time of the transaction, the cost, an indication that the transaction is a transfer of ownership, etc.” [0035] [Examiner notes that this text aligns to the claim language as it is sending the unique identifier (serial number in this case) by scanning the tag to get the unique identifier in order to verify a transfer request by verifying ownership via a trusted system then creating a transfer record]).
Regarding claim 8, a combination of McKenzie-Cao discloses the device of claim 6.
McKenzie further discloses wherein the storage device NFT logic is further configured to verify the received request to transfer ownership via accessing a blockchain associated with the device (“The exchange component facilitates a transaction between a buyer and a seller. In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller)... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence... In block 526, the scanner application generates a transaction indicating that the seller is selling the tagged product to the potential buyer, the transaction including identification information for the product, the seller, and the buyer, such as a unique identifier associated with each, a public key associated with each, etc. and information about the transaction, such as the date and time of the transaction, the cost, an indication that the transaction is a transfer of ownership, etc.” [0035] [Examiner notes that since the transaction in block 526 indicates that a transaction is created involving a “unique identifier associated with each” party and the product, the unique identifier for the product would be linked to the blockchain and used to facilitate the transfer of ownership which shows how the any device or product is directly associated with the blockchain via the unique identifier (by including the unique identifier in the transaction, the blockchain serves as the record for the device's ownership and transaction history, tying the product to the blockchain through the identifier)]).
Regarding claim 14, a combination of McKenzie-Cao discloses the device of claim 6.
McKenzie further discloses: wherein the device is associated with an NFT on a blockchain In block 514, the buyer receives the product. In block 515, the buyer logs in to the scanner application to prove their identity and scans the tag attached to the product to confirm transfer of the product. In some examples, buyer's scanner application also finalizes payment to the seller...In block 532, the component returns a value of true, indicating that the exchange was successful. One of ordinary skill in the art will recognize that the transaction provided for recordation may include additional information related to the transaction and that various steps performed during the process can be completed using one or more smart contracts” [0035] [Examiner notes that the device's NFT was registered on the blockchain, establishing a record of its identity, ownership, and authenticity. When the device is transferred to a new owner, the NFT's blockchain record can be updated to reflect the buyer as the current owner since scanning the device's tag and validating the transaction on the blockchain ensures that each transfer is authenticated, aligning ownership records with the blockchain-stored NFT]).
Regarding claim 15, a combination of McKenzie-Cao discloses the device of claim 14.
McKenzie further discloses: wherein the association with the NFT comprises at least a Additionally, a product (e.g., refrigerator) can be uniquely identified using the name of its manufacturer and its serial number. The identity tokens for each would be a cryptographic one-way hash of such combinations. The identity token for an entity (e.g., person or company) may be the public key of a public/private key pair, where the private key is held by the entity” [0005]; “In block 250, the component generates an identifier for the product by, for example, generating an identity token for the product, generating a non-fungible token for the product using, for example, the ERC-721 or ERC-1155 standards, applying a hash function (e.g., SHA-256, RIPEMD-160, etc.) to a) the unique identifier associated with the tag, b) a serial number and/or other description information pertaining to the product, including general information and information specific to the product (e.g., information unique to the product, an identifier associated with an owner of the product, condition information, size and/or weight information, manufacture date/time/location, and so on), c) to information about the when the product was authenticated and who authenticated the product, d) to information about who requested the authentication, and so on or any combination thereof. In block 260, the component records product authentication information in the product authentication store, such as unique identifier associated with the tag attached to the product, the identifier generated for the product, information about the who authenticated the product and when the product was authenticated, and so on” [0032] [Examiner notes that since the product's unique identifier (serial number) is used to create the NFT on the blockchain, the public key address is linked to the product's NFT, associating the unique identity of the product with its owner's address. By incorporating both a unique identity (e.g., serial number and manufacturer name) and an owner's address (public key), this setup reflects the requirement that the association with the NFT includes a unique identifier and an address, providing a foundation for blockchain-based ownership and verification]).
Regarding claim 17, a combination of McKenzie-Cao discloses the device of claim 14.
McKenzie further discloses: wherein the device is associated with an NFT on a blockchain prior to deployment (“non-fungible tokens may be generated and exchanged or transferred using one or more smart contracts” [0027] [Examiner notes that this statement reflects how NFTs operate on a blockchain: they are created (or “minted”) and managed via smart contracts, which define the rules for ownership and transfers. This is consistent with the idea that an NFT is formatted as a smart contract, as it clarifies that the smart contract is responsible for issuing the NFT and facilitating its transfer between parties]).
Regarding claim 19, McKenzie discloses: A method for transferring ownership of a storage device, the method comprising:
receiving a request to transfer ownership of the storage device from a first owner to a second owner; verifying the request The exchange component facilitates a transaction between a buyer and a seller. In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller)... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence... In block 526, the scanner application generates a transaction indicating that the seller is selling the tagged product to the potential buyer, the transaction including identification information for the product, the seller, and the buyer, such as a unique identifier associated with each, a public key associated with each, etc. and information about the transaction, such as the date and time of the transaction, the cost, an indication that the transaction is a transfer of ownership, etc.” [0035] [Examiner notes that since the transaction in block 526 indicates that a transaction is created involving a “unique identifier associated with each” party and the product, the unique identifier for the product would be linked to the blockchain and used to facilitate the transfer of ownership which shows how the any device or product is directly associated with the blockchain via the unique identifier (by including the unique identifier in the transaction, the blockchain serves as the record for the device's ownership and transaction history, tying the product to the blockchain through the identifier)]);
McKenzie does not explicitly disclose: in response to verifying the request generated encryption key in place of a prior encryption key used to encrypt data for the first owner for storage in the storage device.
However, Cao discloses: in response to verifying the request generated encryption key in place of a prior encryption key used to encrypt data for the first owner for storage in the storage device (“In some embodiments, ownership can only be transferred by the owner 42, working together with the registry 41. In this case, the owner 42 may transmit the owner key 411 and a new owner public key of a new owner (not pictured). The registry 41 uses the owner key 411 to decrypt the encrypted digital asset private key 412 to get back the digital asset key 410. The registry 41 then generates a new owner key, encrypts the digital asset key 410 with the new owner key to get a new encrypted digital asset private key, encrypts the new owner key with the new owner public key of the new owner to get a new encrypted owner key, sends the new encrypted owner key to the new owner (optionally the new encrypted owner key can be transmitted to the new owner by the previous owner, or the new encrypted owner key can be saved on the registry, etc.), and then destroys the digital asset key 410, the new owner key, and the previous encrypted digital asset private key, and stores only the new encrypted digital asset private key. At this point, only the new owner can prove the ownership of the digital asset. The previous owner does not have proof of ownership anymore since the previous encrypted digital asset private key is destroyed. Although the previous owner may still has his or her owner key, it is useless without the other half, that is the previous encrypted digital asset private key which is now destroyed” [0081]; “The process for transferring ownership of an asset as shown in FIG. 6B may include the facilitator 620 verifying that the current owner 630 is the real owner of the asset 610 and the current owner 630 transferring the owner private key 660 to a new owner 630B as shown in FIG. 6B. A new owner secret key 640B should be selected, which should be known to the new owner 630B only and unknown to the current owner 630. The derived secret key 641 of secret key 640B is made known to the facilitator 620. Once the above process is complete, the previous owner 630 cannot prove his ownership over the asset anymore since they do not know the new secret key 640B. The facilitator 620 will not verify an owner if an owner cannot provide the current secret (e.g., secret key 640B). At all times, the three parties (the previous owner 630, the facilitator 620, and the current owner 630B) never know at least one of the thee secrets. The previous owner 630 does not know the current secret key 640B. The facilitator 620 does not know the owner private key 660 of the owner 630. The current owner does not know the facilitator private key 661 of the facilitator 620. All three secrets (e.g., private keys or secrets) are needed in order to verify ownership or transfer ownership” [0096-0097] [Examiner notes that these texts show that ownership is verified before the new key is effective (transfer only proceeds after verification happens). A new owner-specific key is created. The texts also show how revoking the old key ensured that the first owner can no longer access the asset. Encrypting the digital asset key under the new owner key controls future access, which shows that the new owner can encrypt the data coming in as the digital access key is what is encrypting that data. By encrypting the digital asset key under the new owner key, the system ensures that the new owner controls the digital access key, which in turn encrypts all future data, effectively making the new owner the only person who can encrypt/decrypt incoming data. The registry replaces the old key with the new encrypted key in storage which lets the system enforce the new key before any future access]).
Thus, it 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, to combine the method of McKenzie and the structure of Cao for the added benefit of being able to determine the rightful owner and authenticity of the digital asset [Cao 0003].
Regarding claim 20, a combination of McKenzie-Cao discloses the method of claim 19.
McKenzie further discloses: wherein the verification of the request unique identifier associated with the tag attached to the product” [0032]; “When the buyer receives the product, the buyer can scan the tag to confirm and claim ownership. Moreover, the transaction between the buyer and the seller can be recorded in a blockchain transaction to provide further proof of the transaction” [0022]; “The identifier created for the product can be a digital cryptographic identifier (e.g., a hash value generated using a secure hashing algorithm), a hash value generated from a description (or partial description) of the product and/or a serial number associated with the product, and so on. Furthermore, information about the product and tag is issued on a blockchain, such as a tag id, current owner, date and time authenticated, authenticator, and so on using a transaction signed using a private key (of a public/private key pair) of the authenticator” [0024]; “In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence” [0035] [Examiner notes that these texts, especially from [0022], show how the blockchain is providing a response (or record) confirming the transaction has occurred between the buyer and seller, which can be verified by looking up this transaction in the blockchain. When queried, the blockchain provides a response containing these details, which can be used to confirm the current ownership and authentication history of the product (in [0024])]).
Claims 9-13, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248653 A1 to McKenzie et al. (hereinafter, “McKenzie”) in view of US 2020/0242711 A1 to Cao et al. (hereinafter, “Cao”) as applied to claims 8 and 15 above, and in further view of WO 2019/185710 A1 to Capkun et al. (hereinafter, “Capkun”).
Regarding claim 9, the combination of McKenzie-Capkun does disclose: the device of claim 8, wherein the storage device NFT logic is further configured to operate a lightweight blockchain client, wherein the associated blockchain is accessed via the lightweight blockchain client (“lightweight clients that operate on Simplified Payment Verification (SPV) mode. Unlike full nodes, SPV nodes do not receive and validate all transactions broadcasted to the P2P network, nor do they store the whole blockchain” [Capkun page 2, lines 6-9]).
Thus, it 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, to combine the method of McKenzie and the added lightweight blockchain client structure of Capkun for the added benefit of increased usability [Capkun page 9, line 28].
Regarding claim 10, the combination of McKenzie-Capkun does disclose: the device of claim 9, wherein the lightweight blockchain client receives block headers associated with the first owner and any previous owners of the device (“Embodiments of the invention allow lightweight clients to send requests containing addresses of their interest and directly receive information regarding unspent outputs, without the need to verify block headers and Merkle tree paths. As a result the method according to the present invention provides strong privacy protection and additionally improves performance of current lightweight payment verification” [Capkun page 5, line 33-page 6, line 4] [Examiner notes that lightweight blockchain clients can receive block headers associated with a specific address (e.g., any owners) if needed, but it describes an improved method where the client can bypass the need for verifying block headers by simply sending a request with specific addresses and directly receiving relevant information. This is a direct and faster way to get the needed information, as compared to the claim's language in receiving block headers and performing further verification]).
Thus, it 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, to combine the method of McKenzie and the structure of Capkun for the added benefit of privacy and efficiency since a lightweight client is able to retrieve information about the amount of BTC connected to the addresses of the lightweight client without insecurely releasing any information about these addresses to the full node [Capkun page 10, line 8-10].
Regarding claim 11, the combination of McKenzie-Capkun does disclose: the device of claim 10, wherein the block headers comprise identity and address pairs associated with one or more owners of the device (“To transfer ownership of a bitcoin, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the owner with the owner's private key (of a public/private key pair) to transfer ownership to the new owner, as represented by the new owner public key... Once the block is full, the block is “capped” with a block header, that contains a hash digest of all the transaction identifiers within the block. To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction” [0003] [Examiner notes that this text explains how a new transaction (representing the transfer of ownership) is generated, signed, and recorded within a block, aligning with the idea of “identity and address pairs associated with owners”]).
Regarding claim 12, the combination of McKenzie-Capkun does disclose: the device of claim 11, wherein the storage device NFT logic is further configured to verify the identity and address pairs of the first owner any previous owners (“the product authentication store may include, for each authenticated product, a history of transactions involving that product or a list of previous owner of that product” [0033]; “In block 524, the seller logs in to the scanner application to prove their identity...to provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence. In decision block 525, if the seller's scanner application confirms that the product's authentication is valid (by, for example, checking transactions in a blockchain or a product authentication data store) and that the product is owned by the seller, processing continues at block 526, else the component returns false. In block 526, the scanner application generates a transaction indicating that the seller is selling the tagged product to the potential buyer, the transaction including identification information for the product, the seller, and the buyer, such as a unique identifier associated with each, a public key associated with each, etc. and information about the transaction, such as the date and time of the transaction, the cost, an indication that the transaction is a transfer of ownership, etc. Accordingly, the transaction provides evidence that the buyer is now the current owner. In block 527, the seller signs the transaction with the seller's private key (of a public/private key pair) by, for example, selecting an option to sign in the scanner application. In block 528, the seller's scanner application provides the signed transaction for recordation in the blockchain or other secure, trusted tracking system” [0035] [Examiner notes that this text highlights the identity verification process, where the seller's identity and proof of ownership are confirmed through blockchain. The transaction includes addresses (which, by the application's specification, refer to public keys associated with unique identifiers and these addresses are used to prove ownership and facilitate the transfer of ownership through cryptographic signatures) associated with both the buyer and seller, linking them to the unique identifiers that prove ownership. This text also shows the support of verifying the ownership transfer by using blockchain's record of the transaction, tying the address and identity pairs of the previous and current owners. Overall, the public address is used to authenticate ownership and to trace transaction history, ensuring the ownership transfer of the storage device is properly verified on the blockchain]).
Regarding claim 13, the combination of McKenzie-Capkun does disclose: the device of claim 12, wherein, the storage device NFT logic is further configured to, in response to successful verification of the identity and address pairs of the first owner and any previous owners, generate the second encryption key (“Lightweight clients connect to one of the improved full nodes that support full privacy preservation and allows lightweight clients to outsource computational work, such as block and transactional verification, to a secure enclave residing on the full node. A lightweight client can choose any available full node to connect to. The connection establishment between the lightweight client and the full node uses secure bootstrapping for confidential communication between the client and the enclave residing in the full node. These two entities perform an authenticated Diffie-Helman key exchange to establish a session key. The lightweight client has a unique identifier with which it can authenticate to the full node for future sessions. This is advantageous for frequent, repeated or incrementally larger requests. After the session is established, the lightweight client sends a message containing all of the transaction for which the lightweight client needs additional information” [Capkun page 11, lines 22-33] [Examiner notes that the text shows the Diffie-Hellman key exchange resulting in a “session key” enabling secure communication for further data exchange which emphasized a verification-dependent process for establishing encryption keys (key generation post-verification)]).
Thus, it 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, to combine the method of McKenzie and the structure of Capkun for the added benefit of confidential communication [Capkun page 11, line 27].
Regarding claim 16, the combination of McKenzie-Capkun does disclose: the device of claim 15, wherein the address is comprised of at least the first encryption key (“These addresses actually indicate public keys” [Capkun page 1, line 23] [Examiner interprets this text to display that the address is derived from or represents a public key that can be used for encryption or as part of a public-private key pair in the context of cryptography]).
Thus, it 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, to combine the method of McKenzie and the structure of Capkun for the added benefit of secure ownership verification and simplified identity management.
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248653 A1 to McKenzie et al. (hereinafter, “McKenzie”) in view of US 2020/0242711 A1 to Cao et al. (hereinafter, “Cao”) as applied to claims 6 and 19 above, and in further view of US 2012/0174232 A1 to Dharawat et al. (hereinafter, “Dharawat”).
Regarding claim 21, a combination of McKenzie-Cao discloses the method of claim 19.
McKenzie further discloses: assigning a first unique identifier to the device (“An identity token for a physical or digital asset is generated” [0005]; “the component generates an identifier for the product by, for example, generating an identity token for the product, generating a non-fungible token for the product…” [0032]);
determining first device data for on-chain storage that is associated with the first unique identifier; determining second device data for on-chain storage that is associated with the second unique identifier; and adding the first device data and the second device data to the at least one blockchain (“For example, rather than (or in addition to) linking physical tags to physical products, the product authentication system can use non-fungible tokens associated with items that solely exist as virtual items, such as digital collectables issued by brands, generated from end users activating tags for physical products, and so on. In this manner, the product authentication system can be used to authenticate (and verify the authenticity of) virtual items, rather than relying on physical tags attached to physical items. For example, virtual items, such as virtual shirts, shoes, collectible trading cards, and so on, can be associated with non-fungible tokens and transactions involving those virtual items can be recorded in a secure, trusted tracking system, such as a distributed ledger... If the item is purchased, the product authentication system and blockchain can be used to both verify the authenticity of the virtual item and verify that it is owned by the seller before it is transferred out of the current owner's closet and into the new owner's possession” [0027] [Examiner interprets this text as a linking between physical product and its digital counterpart (the NFT, or the device data in this context). When the NFT is created for a physical product and then stored on the blockchain, the physical and digital realms are being linked through the NFT since the activation of a physical tag on a product triggers the creation of a non-fungible token (NFT) and once it is created, the NFT is added and stored on the blockchain (effectively linking the physical item with its digital counterpart in the secure, decentralized ledger. Examiner also notes that whether the unique identifier is for a single device or multiple, the art is able to determine the device data for on-chain storage]);
wherein the received request to transfer ownership of the storage device from the first owner to the second owner includes the second unique identifier (“In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller). In some examples, the request includes identification information for the potential buyer while in other examples the request can be anonymous. In this case, the potential buyer can provide identification information, for example, after the buyer and the seller have agree on terms. In block 521, the seller receives the request... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence. In decision block 525, if the seller's scanner application confirms that the product's authentication is valid (by, for example, checking transactions in a blockchain or a product authentication data store) and that the product is owned by the seller, processing continues at block 526, else the component returns false. In block 526, the scanner application generates a transaction indicating that the seller is selling the tagged product to the potential buyer, the transaction including identification information for the product, the seller, and the buyer, such as a unique identifier associated with each, a public key associated with each, etc. and information about the transaction, such as the date and time of the transaction, the cost, an indication that the transaction is a transfer of ownership, etc...In block 528, the seller's scanner application provides the signed transaction for recordation in the blockchain or other secure, trusted tracking system. In this manner, the purchase history of the authenticated product can be recorded in the blockchain, thereby providing a safe and trusted mechanism for buyers and sellers to determine whether a particular user owns an authenticated product” [0035]);
wherein the verification of the request unique identifier associated with the tag attached to the product” [0032]; “When the buyer receives the product, the buyer can scan the tag to confirm and claim ownership. Moreover, the transaction between the buyer and the seller can be recorded in a blockchain transaction to provide further proof of the transaction” [0022]; “The identifier created for the product can be a digital cryptographic identifier (e.g., a hash value generated using a secure hashing algorithm), a hash value generated from a description (or partial description) of the product and/or a serial number associated with the product, and so on. Furthermore, information about the product and tag is issued on a blockchain, such as a tag id, current owner, date and time authenticated, authenticator, and so on using a transaction signed using a private key (of a public/private key pair) of the authenticator” [0024]; “In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence” [0035] [Examiner notes that these texts, especially from [0022], show how the blockchain is providing a response (or record) confirming the transaction has occurred between the buyer and seller, which can be verified by looking up this transaction in the blockchain. When queried, the blockchain provides a response containing these details, which can be used to confirm the current ownership and authentication history of the product (in [0024])]).
McKenzie does not explicitly disclose: assigning a second unique identifier to a group of storage devices including the storage device;
However, Dharawat discloses: assigning a second unique identifier to a group of storage devices including the storage device (“A unique identifier is not limited to identifying a single device; rather, it may identify a group of devices” [0022]);
Thus, it 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, to combine the method of McKenzie-Cao and the structure of Dharawat for the added benefits of having the ability to uniquely identify more than 1 device using the same identifier.
Regarding claim 22, McKenzie in view of Cao disclosed the device of claim 6, McKenzie further discloses:
the device was assigned a first unique identifier (“An identity token for a physical or digital asset is generated” [0005]; “the component generates an identifier for the product by, for example, generating an identity token for the product, generating a non-fungible token for the product…” [0032]); and
the NFT logic is further configured to send the second unique identifier via the communication port to verify the received request to transfer ownership of the device (“The exchange component facilitates a transaction between a buyer and a seller. In block 511, the potential buyer sends a request for the product to the potential seller (e.g., an initial or original seller or reseller)... In block 524, the seller logs in to the scanner application to prove their identity (if they have not done so already) and scans the tag attached to the product to, for example, provide proof of ownership (verifiable via a secure, trusted tracking system, such as a blockchain, and/or the product authentication store) and proof of presence... In block 526, the scanner application generates a transaction indicating that the seller is selling the tagged product to the potential buyer, the transaction including identification information for the product, the seller, and the buyer, such as a unique identifier associated with each, a public key associated with each, etc. and information about the transaction, such as the date and time of the transaction, the cost, an indication that the transaction is a transfer of ownership, etc.” [0035] [Examiner notes that this text aligns to the claim language as it is sending the unique identifier (serial number in this case) by scanning the tag to get the unique identifier in order to verify a transfer request by verifying ownership via a trusted system then creating a transfer record]).
McKenzie-Cao does not explicitly disclose: a second unique identifier that was further assigned to a plurality of devices in addition to the device;
However, Dharawat discloses: a second unique identifier that was further assigned to a plurality of devices in addition to the device (“A unique identifier is not limited to identifying a single device; rather, it may identify a group of devices” [0022]);
Thus, it 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, to combine the methods of McKenzie-Cao and the structure of Dharawat for the added benefits of having the ability to uniquely identify more than 1 device using the same identifier.
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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6:30pm.
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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights