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 .
Claim Objections
Claims 2-3 are objected to because of the following informalities: Claim 2 recites “by a second client devices”. Please amend “devices” to “device”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
Claim 7 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 contains the trademark/trade name Ethereum. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe the blockchain and sidechains and, accordingly, the identification/description is indefinite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-14 and 17-18 recite a method (process) and Claims 15-16 recite a client device (a machine) and therefore fall into a statutory category.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
The claims as a whole recite a method and client device for organizing a transaction based on the authentication of a product, which under its broadest reasonable interpretation, covers concepts under the Certain Methods of Organizing Human Activity.
(Claim 1) A method for carrying out a transaction [in a blockchain- type database], relating to at least one non-fungible token, the method being wherein it comprises carrying out steps of:
(c) receiving, [by a first client device of] a first user that is the recipient of the transaction, a request to authenticate a physical product uniquely associated with said non-fungible token;
(d) if the physical product is authenticated [on said first client device], executing said transaction [in the blockchain-type database].
(Claim 15)
[A first client device of] a first user that is the recipient of a transaction [in a blockchain-type database], relating to at least one non-fungible token, wherein it is configured to:
-receive a request to authenticate a physical product uniquely associated with said non-fungible token;
-if the physical product is authenticated [on said first client device], execute the transaction [in the blockchain-type database].
Where the portions not bracketed recite the abstract idea.
Here the claims recite concepts covering managing personal behavior or relationships or interactions between people (following rules or instructions) but for the recitation of generic computer components. In the present application the claims recite concepts organizing a transaction based on the authentication of a product (See page 1 lines 12-21 and lines 32-36 and page 4 lines 23-30).
If a claim limitation, under its broadest reasonable interpretation, covers concepts performed in managing personal behavior or relationships or interactions between people (following rules or instructions), it falls under the Certain Methods of Organizing Human Activity grouping of abstract ideas. See MPEP 2106.04.
Accordingly, the claims recite an abstract idea.
Step 2A-Prong 2 (Is the Exception Integrated into a Practical Application?):
The Examiner views the following as the additional elements:
Blockchain-type database. (See page 6 lines 7-12)
A first client device. (See page 5 lines 16-22)
These additional elements are recited at a high-level of generality such that they act to merely “apply” the abstract idea using generic computing components and do not integrate the abstract idea into a practical application. (See MPEP 2106.05 (f)).
The combination of these additional elements and/or results oriented steps are no more than mere instructions to apply the exception using generic computing components. (See MPEP 2106.05 (f)). Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B (Does the claim recite additional elements that amount to Significantly More than the Judicial Exception?):
As noted above, the claims as a whole merely describes a method and system that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications v. LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible.
Dependent claims 2 and 16 further define the abstract idea as identified. Additionally, the claim recites the additional element of second client devices (See page 5 lines 16-22) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claims 2 and 16 are considered to be patent ineligible.
Dependent claim 3 further defines the abstract idea as identified. Additionally, the claim recites the additional element of first/second client device (See page 5 lines 16-22) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claim 3 is considered to be patent ineligible.
Dependent claims 4-5, 10, and 14 further define the abstract idea as identified and do not integrate the abstract idea into a practical application or add significantly more. Therefore claims 4-5, 10, and 14 are considered to be patent ineligible.
Dependent claim 6 recites the additional elements of QR code (See page 7 lines 3-7), electronic tag (See page 9 lines 28-29), and an AI algorithm (See page 9 line 35 to page 10 line 2) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claim 6 is considered to be patent ineligible.
Dependent claim 7 recites the additional elements of Ethereum blockchain (See page 6 lines 13-21) and one of its sidechains (See page 6 lines 13-21) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claim 7 is considered to be patent ineligible.
Dependent claims 8-9 recite the additional element of smart contract (See page 2 lines 25-29) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claims 8-9 are considered to be patent ineligible.
Dependent claim 11 recites the additional elements of the second client device (See page 5 lines 16-22) and blockchain-type database (See page 6 lines 7-12) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claim 11 is considered to be patent ineligible.
Dependent claims 12-13 recite the additional elements of the blockchain-type database (See page 6 lines 7-12) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claims 12-13 are considered to be patent ineligible.
Dependent claim 17 recites the additional elements of the computer program product (See page 16 line 34 to page 17 line 2), code instructions (See page 16 line 34 to page 17 line 2), a blockchain-type database (See page 6 lines 7-12), and a computer (See page 16 line 34 to page 17 line 2) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claim 17 is considered to be patent ineligible.
Dependent claim 18 recites the additional elements of the storage medium, (See page 5 lines 16-22), computer equipment (See page 16 line 34 to page 17 line 2), computer program product (See page 16 line 34 to page 17 line 2), code instructions (See page 16 line 34 to page 17 line 2), and a blockchain-type database (See page 6 lines 7-12), and a computer (See page 16 line 34 to page 17 line 2) at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computing components and does not integrate the abstract idea into a practical application or add significantly more. Therefore claim 18 is considered to be patent ineligible.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
Claims 1-12 and 15-16 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by McKenzie et al. (US 20210248653).
McKenzie, which is directed to authenticating products, discloses
(Claim 1) A method for carrying out a transaction in a blockchain- type database, relating to at least one non-fungible token, the method being wherein it comprises carrying out steps of: (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on.)
(c) receiving, by a first client device of a first user that is the recipient of the transaction, a request to authenticate a physical product uniquely associated with said non-fungible token; (Mckenzie paragraph 35 disclosing FIG. 5 is a flow diagram illustrating steps of an exchange component in accordance with some embodiments of the disclosed technology. 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 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 blocks 512 and 522 the potential buyer and seller negotiate over terms of the purchase, such as price, shipping, insurance, payment processing, timelines, etc. In some cases, the potential buyer and/or seller may have fixed terms and be unwilling to negotiate, in other cases the negotiate term may be prolonged. In decision blocks 513 and 523, if terms of the exchange are accepted, then the seller continues at block 524, else the component returns a value of false at block 531, indicating that the exchange was not successful. For example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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)
(d) if the physical product is authenticated on said first client device, executing said transaction in the blockchain-type database. (Mckenzie paragraph 35 disclosing for example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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. 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. 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. In block 529, the seller sends the authenticated product to the buyer or engages with a third-party to have the authenticated product to the buyer. 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.)
Referring to claim 2,
McKenzie further discloses comprising the step (b) of receiving, by a second client devices of a second user that is the originator of the transaction, another request to authenticate the physical product uniquely associated with said non-fungible token. (Mckenzie paragraph 22 disclosing in some embodiments, the product authentication system uses tamper-proof tags or chips, such as NFC Integrated Circuits (ICs) or dual-frequency ICs tags with a Secure Unique NFC (SUN) mechanism that generates a secure unique NFC message authentication each time the tag is scanned or read, for example, for proof of presence, authentication, and ownership. When a product is sold, the seller can scan the tag to provide proof of ownership and proof of presence and then ship the product to the buyer. 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. McKenzie paragraph 35 disclosing 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. 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. In block 529, the seller sends the authenticated product to the buyer or engages with a third-party to have the authenticated product to the buyer. 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.)
Referring to claim 3,
McKenzie further discloses wherein either step (c) is carried out if said physical product is authenticated on said second client device, or in step (d) said transaction is executed if said physical product is authenticated on each of the first and second client devices. (Mckenzie paragraph 35 disclosing FIG. 5 is a flow diagram illustrating steps of an exchange component in accordance with some embodiments of the disclosed technology. 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 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 blocks 512 and 522 the potential buyer and seller negotiate over terms of the purchase, such as price, shipping, insurance, payment processing, timelines, etc. In some cases, the potential buyer and/or seller may have fixed terms and be unwilling to negotiate, in other cases the negotiate term may be prolonged. In decision blocks 513 and 523, if terms of the exchange are accepted, then the seller continues at block 524, else the component returns a value of false at block 531, indicating that the exchange was not successful. For example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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. 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. 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. In block 529, the seller sends the authenticated product to the buyer or engages with a third-party to have the authenticated product to the buyer. 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 some cases, the seller may require payment (or partial payment) prior to sending the authenticated product to the buyer. 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.)
Referring to claim 4,
McKenzie further discloses wherein step (c) comprises the verification of said authentication by an authority entity. (McKenzie paragraph 21 disclosing in some embodiments, during an initial authentication phase a trusted product authenticator, such as one or more employees of a manufacturer, a certified expert in particular products, etc. is provided a product for examination to determine whether the product is authentic. For example, employees of a manufacturer may be called upon to determine whether a particular item, such as a particular shoe, handbag, article of clothing, collectible item, etc. is one that was originally manufactured by the manufacturer. As another example, a certified expert in verifying the authenticity of one or more products can be called on to authenticate a product. In another example, a trusted reseller of a product may authenticate that the product was sold by that reseller. If the product is deemed to be authentic, a physical tag is attached to the product and the product is given a unique product identifier, each of which is used to track the product as it is sold and re-sold over the course of its life. For example, after a product is authenticated the owner of the product, a retailer, a reseller, the authenticator, or a third party may attach a tag to the product using previously-received tags or a tag provided in response to the authentication. McKenzie paragraph 24 disclosing in some embodiments, the product authentication system relies on NFC tags attached to physical products and associated transactions issued on a blockchain. Similarly, non-physical tags or tokens can be associated with non-physical goods, such as virtual goods and associated transactions issued on the blockchain. Initially, a product's authenticity is confirmed by one or more individuals trained to recognize authenticity, such as employees of a manufacturer, employees of a reseller, a third-party expert, etc. Once the product is authenticated, a uniquely-identifiable NFC tag is attached to, or associated with, the product, an identifier can be created for the product (such as an identity token), and the NFC Tag and identification information are associated in the product authentication system in, for example, a product authentication data store. 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. In this manner, the product authentication system issues a secure digital authenticity certification using the blockchain to store and manage identities and NFC tags and to link the NFC tags to corresponding products. Furthermore, an authentication flag in the product authentication data store can be updated by the seller for the tag to identify an authentic original product for a corresponding brand.)
Referring to claim 5,
McKenzie further discloses wherein step (d) comprises the payment of a gas fee. (McKenzie paragraph 7 disclosing to enable more complex transactions than bitcoin can support, some systems use “smart contracts.” A smart contract is computer code that implements codified terms of a contract. The algorithm in the smart contract is executed in a decentralized way by every node that is running the blockchain. To execute the contract code, the platform uses a deterministic virtual machine platform (e.g., an Ethereum platform, which provides a virtual machine) that supports recording transactions in blockchains. In addition, the smart contract itself is recorded as a transaction in the blockchain so that the integrity of the computer code is ensured. When deployed, a constructor of the smart contract executes, initializing the smart contract and its state. The state of a smart contract is stored persistently in the blockchain. When a transaction is recorded against a smart contract, a message is sent to the smart contract, and the computer code of the smart contract executes to implement the transaction (e.g., debit a certain amount from the balance of an account). The Examiner interprets the Ethereum blockchain encompasses the requirement of gas fees for performing transactions using smart contracts on the Ethereum blockchain.)
Referring to claim 6,
McKenzie further discloses wherein the authentication of said the physical product comprises at least one of: reading a QR code on the physical product, reading an electronic tag on the physical product, extracting a digital fingerprint from a photo of said physical product, and recognizing said the physical product by an artificial intelligence algorithm. (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. Thus, the product authentication system provides a product authentication service that reduces the amount of repeated or duplicated effort in authenticating products, thereby saving valuable resources required for performing such activities. The product authentication system provides a more transparent, efficient, and accessible solution that connects businesses and consumers. McKenzie paragraph 21 disclosing each time the authenticity of the product is subsequently confirmed or otherwise verified as part of a transaction (e.g., a sale), the authenticator can be remunerated for the past authentication. Furthermore, because the product does not need to be re-authenticated, the product authentication system avoids any duplicate effort required in re-authenticating the product. In some cases, the authenticator may receive free or discounted physical tags and split the remuneration fee with the physical tag provider. Moreover, the authenticator can provide a transaction for recordation in a secure, trusted tracking system, such as a blockchain or hashgraph, indicating that the product has been authenticated by the authenticator on behalf of, for example, the owner of the product. For example, the transaction may include information about the authenticated product signed using a private key of the authenticator. After the transaction is recorded in the secure, trusted tracking system, the authenticity of the product can be verified by subsequent buyers or sellers of the product via a system that is secure and immutable by, for example, analyzing transactions in the secure, trusted tracking system. In this manner, the product authentication system provides a secure and trusted mechanism for parties in the supply chain to record and verify a product's authenticity, thereby reducing the amount of time and effort needed to authenticate a product over the course of its life.)
Referring to claim 7,
McKenzie further discloses wherein said blockchain-type database is the Ethereum® blockchain or one of its sidechains, and said non-fungible token is based on the ERC-721 standard. (McKenzie paragraph 20 disclosing systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. Thus, the product authentication system provides a product authentication service that reduces the amount of repeated or duplicated effort in authenticating products, thereby saving valuable resources required for performing such activities. The product authentication system provides a more transparent, efficient, and accessible solution that connects businesses and consumers. McKenzie paragraph 50 disclosing from the foregoing, it will be appreciated that specific embodiments of the present technology have been described herein for purposes of illustration, but that various modifications may be made without deviating from the technology. For example, although described as using a blockchain above, one of ordinary skill in the art will recognize that the product authentication system can be implemented using any secure and trusted tracking system, such as known distributed ledger systems and blockchain systems, including Ethereum, described at https://github.com/ethereum/wiki/wiki/White-Paper and in Ethereum white paper by Vitalik Buterin published in 2013, each of which is herein incorporated by reference, Quorum, described at https://raw.githubusercontent.com/jpmorganchase/quorum-docs/master/Quorum%20Whitepaper%20v0.1.pdf, committed on Nov. 22, 2016, which is herein incorporated by reference in its entirety, Hedera, described in Hedera: A Public Hashgraph Network & Governing Council (last updated Aug. 15, 2020), which is herein incorporated by reference in its entirety, and so on. Moreover, in some embodiments, the product authentication system can rely on multiple blockchains such that each node in the blockchain system is a “dual-connection” node connected to a public blockchain, such as Ethereum, and a permissioned blockchain, such as Quorum.)
Referring to claim 8,
McKenzie further discloses implemented in the form of a smart contract. (McKenzie paragraph 35 disclosing FIG. 5 is a flow diagram illustrating steps of an exchange component in accordance with some embodiments of the disclosed technology. 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 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 blocks 512 and 522 the potential buyer and seller negotiate over terms of the purchase, such as price, shipping, insurance, payment processing, timelines, etc. In some cases, the potential buyer and/or seller may have fixed terms and be unwilling to negotiate, in other cases the negotiate term may be prolonged. In decision blocks 513 and 523, if terms of the exchange are accepted, then the seller continues at block 524, else the component returns a value of false at block 531, indicating that the exchange was not successful. For example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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. 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. 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. In block 529, the seller sends the authenticated product to the buyer or engages with a third-party to have the authenticated product to the buyer. 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 some cases, the seller may require payment (or partial payment) prior to sending the authenticated product to the buyer. 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.)
Referring to claim 9,
McKenzie further discloses wherein the smart contract is controlled by a trusted third party, step (d) comprising the calculation and payment of a royalty for the benefit of said trusted third party, in particular in accordance with the ERC- 2981 standard. (McKenzie paragraph 7 disclosing to enable more complex transactions than bitcoin can support, some systems use “smart contracts.” A smart contract is computer code that implements codified terms of a contract. The algorithm in the smart contract is executed in a decentralized way by every node that is running the blockchain. To execute the contract code, the platform uses a deterministic virtual machine platform (e.g., an Ethereum platform, which provides a virtual machine) that supports recording transactions in blockchains. In addition, the smart contract itself is recorded as a transaction in the blockchain so that the integrity of the computer code is ensured. When deployed, a constructor of the smart contract executes, initializing the smart contract and its state. The state of a smart contract is stored persistently in the blockchain. When a transaction is recorded against a smart contract, a message is sent to the smart contract, and the computer code of the smart contract executes to implement the transaction (e.g., debit a certain amount from the balance of an account). The computer code ensures that all the terms of the contract are complied with before the transaction is recorded in the blockchain. McKenzie paragraph 20 disclosing systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. Thus, the product authentication system provides a product authentication service that reduces the amount of repeated or duplicated effort in authenticating products, thereby saving valuable resources required for performing such activities. The product authentication system provides a more transparent, efficient, and accessible solution that connects businesses and consumers. For example, after a product is authenticated the owner of the product, a retailer, a reseller, the authenticator, or a third party may attach a tag to the product using previously-received tags or a tag provided in response to the authentication. Each time the authenticity of the product is subsequently confirmed or otherwise verified as part of a transaction (e.g., a sale), the authenticator can be remunerated for the past authentication. Furthermore, because the product does not need to be re-authenticated, the product authentication system avoids any duplicate effort required in re-authenticating the product. In some cases, the authenticator may receive free or discounted physical tags and split the remuneration fee with the physical tag provider. Moreover, the authenticator can provide a transaction for recordation in a secure, trusted tracking system, such as a blockchain or hashgraph, indicating that the product has been authenticated by the authenticator on behalf of, for example, the owner of the product. McKenzie paragraph 26 disclosing furthermore, in some example, one or more tokens or points distributed in the closed ecosystem can be used to purchase physical tags to attach to products for authentication purposes. For example, a vetted and trusted reseller may be able to purchase physical tags to attach to products they sell. When the tags are used to verify the authenticity of a product, the reseller can be remunerated for having previously authenticated the product. McKenzie paragraph 50 disclosing from the foregoing, it will be appreciated that specific embodiments of the present technology have been described herein for purposes of illustration, but that various modifications may be made without deviating from the technology. For example, although described as using a blockchain above, one of ordinary skill in the art will recognize that the product authentication system can be implemented using any secure and trusted tracking system, such as known distributed ledger systems and blockchain systems, including Ethereum, described at https://github.com/ethereum/wiki/wiki/White-Paper and in Ethereum white paper by Vitalik Buterin published in 2013, each of which is herein incorporated by reference, Quorum, described at https://raw.githubusercontent.com/jpmorganchase/quorum-docs/master/Quorum%20Whitepaper%20v0.1.pdf, committed on Nov. 22, 2016, which is herein incorporated by reference in its entirety, Hedera, described in Hedera: A Public Hashgraph Network & Governing Council (last updated Aug. 15, 2020), which is herein incorporated by reference in its entirety, and so on. Moreover, in some embodiments, the product authentication system can rely on multiple blockchains such that each node in the blockchain system is a “dual-connection” node connected to a public blockchain, such as Ethereum, and a permissioned blockchain, such as Quorum. The Examiner is interpreting that the utilization of NFTs and smart contracts in an Ethereum blockchain encompasses including payment to the third-party in control of the smart contract associated with the NFT through including in the rules/conditions of the smart contract, the royalty calculation and payment determination in view of the ERC-2981 standard for successful transactions.)
Referring to claim 10,
McKenzie further discloses wherein the non-fungible token contains metadata describing a history of the physical product, step (d) comprising updating said metadata. (McKenzie paragraph 5 disclosing identity tokens can also be used to identify collections of assets. An identity token for a collection may be a cryptographic one-way hash of the digital tokens of the assets in the collection. The creation of an identity token for an asset in a blockchain establishes provenance of the asset, and the identity token can be used in transactions (e.g., buying, selling, insuring) involving the asset stored in a blockchain, creating a full audit trail of the transactions. McKenzie paragraph 24 disclosing 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. In this manner, the product authentication system issues a secure digital authenticity certification using the blockchain to store and manage identities and NFC tags and to link the NFC tags to corresponding products. Furthermore, an authentication flag in the product authentication data store can be updated by the seller for the tag to identify an authentic original product for a corresponding brand. Attaching a tamper-proof tag that certifies authenticity of a product and uniquely and digitally identifies a sold product reduces counterfeits both for tags and products.
McKenzie paragraph 32 disclosing in block 240, a physical tag is attached to the product, such as a uniquely identifiable Near Field Communication (NFC) tag. In some cases, the physical tag may be attached by the authenticator. In some cases, the product may be shipped back to the owner or a third-party responsible for attaching the physical tags. 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 (e.g., a stock keeping unit (SKU) code, product type (including, for example, clothing, jacket, shoe, tool, bicycle, recreation, non-perishable, book, collectible, etc.), images of the product, a release date, and so on) 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. In block 270, the component provides a transaction for recordation in a blockchain or other secure, trusted tracking system, such as a transaction that associates the owner of the product with the unique identifier associated with the tag attached to the product and the generated identifier and signed using a private key (of a public/private key pair) associated with the authenticator. Recording the transaction in the secure, trusted tracking system establishes provenance of the product, and the identifier can be used in transactions (e.g., buying, selling, insuring) to establish a full audit trail of the transactions. 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.)
Referring to claim 11,
McKenzie further discloses A method for carrying out a transaction relating to the transfer of a physical product from a second user to a first user wherein it comprises carrying out a step (a) of requesting, from a second client device of the second user, to transfer from the second user to the first user at least one non- fungible token uniquely associated with said physical product, and then carrying out the method according to ,claim 1, wherein said transaction in a blockchain- type database is a transfer of said non-fungible token from the second user to the first user. (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. McKenzie paragraph 24 disclosing in some embodiments, the product authentication system relies on NFC tags attached to physical products and associated transactions issued on a blockchain. Similarly, non-physical tags or tokens can be associated with non-physical goods, such as virtual goods and associated transactions issued on the blockchain. Initially, a product's authenticity is confirmed by one or more individuals trained to recognize authenticity, such as employees of a manufacturer, employees of a reseller, a third-party expert, etc. Once the product is authenticated, a uniquely-identifiable NFC tag is attached to, or associated with, the product, an identifier can be created for the product (such as an identity token), and the NFC Tag and identification information are associated in the product authentication system in, for example, a product authentication data store. 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. In this manner, the product authentication system issues a secure digital authenticity certification using the blockchain to store and manage identities and NFC tags and to link the NFC tags to corresponding products. Furthermore, an authentication flag in the product authentication data store can be updated by the seller for the tag to identify an authentic original product for a corresponding brand. McKenzie paragraph 27 disclosing in some cases, non-fungible tokens may be generated and exchanged or transferred using one or more smart contracts. For example, once a user opens a drop box and receives their virtual items, ownership of the virtual items can be transferred to the user and recorded in the blockchain or other secure, trusted tracking system and the user can then hold on to the virtual item, put the virtual item on sale in a virtual marketplace, transfer the virtual item to another user, and so on. 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. Mckenzie paragraph 35 disclosing FIG. 5 is a flow diagram illustrating steps of an exchange component in accordance with some embodiments of the disclosed technology. 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 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 blocks 512 and 522 the potential buyer and seller negotiate over terms of the purchase, such as price, shipping, insurance, payment processing, timelines, etc. In some cases, the potential buyer and/or seller may have fixed terms and be unwilling to negotiate, in other cases the negotiate term may be prolonged. In decision blocks 513 and 523, if terms of the exchange are accepted, then the seller continues at block 524, else the component returns a value of false at block 531, indicating that the exchange was not successful. For example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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)
Referring to claim 12,
McKenzie further discloses A method for carrying out a transaction relating to the initial acquisition by a first user of a physical product, wherein it comprises carrying out a step (a') of requesting to create at least one non-fungible token uniquely associated with said physical product for the benefit of the first user, and then carrying out the method according to claim 1, in which the transaction in a blockchain-type database is the creation of said non-fungible token for the benefit of the first user. (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. McKenzie paragraph 24 disclosing in some embodiments, the product authentication system relies on NFC tags attached to physical products and associated transactions issued on a blockchain. Similarly, non-physical tags or tokens can be associated with non-physical goods, such as virtual goods and associated transactions issued on the blockchain. Initially, a product's authenticity is confirmed by one or more individuals trained to recognize authenticity, such as employees of a manufacturer, employees of a reseller, a third-party expert, etc. Once the product is authenticated, a uniquely-identifiable NFC tag is attached to, or associated with, the product, an identifier can be created for the product (such as an identity token), and the NFC Tag and identification information are associated in the product authentication system in, for example, a product authentication data store. 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. In this manner, the product authentication system issues a secure digital authenticity certification using the blockchain to store and manage identities and NFC tags and to link the NFC tags to corresponding products. Furthermore, an authentication flag in the product authentication data store can be updated by the seller for the tag to identify an authentic original product for a corresponding brand. McKenzie paragraph 27 disclosing in some embodiments, the product authentication system can be employed in a digital realm. 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. These virtual items may be used in various contexts, such as items acquired as part of a game, items worn by an avatar in a game or other virtual environment, and so on. Moreover, the system can act as a wallet or closet for users to store their digital items or collectibles, but they can also buy, sell, and trade the collectibles on a secondary marketplace. In some cases, users can obtain virtual items through the purchase of drop boxes that include any number of virtual items or by purchasing or acquiring a corresponding physical item, such as a shirt for the user to wear and a corresponding virtual shirt for the user's avatar to wear in a game or other virtual environment. Furthermore, the physical item may have an associated tag used for verifying ownership and authenticity of the physical item itself. In some examples, brands or companies generate digital non-fungible tokens that correspond to a specific virtual item and issue these non-fungible tokens as part of a drop box so that the exact virtual item (or items) is not visible at the time of purchase. As such, the user does not know which non-fungible token (and corresponding virtual item) they are purchasing. Furthermore, the product authentication system can provide a marketplace for users to search, buy, and sell their virtual items and to provide profile pages to see (or share) the items in their collection. In some cases, non-fungible tokens may be generated and exchanged or transferred using one or more smart contracts. For example, once a user opens a drop box and receives their virtual items, ownership of the virtual items can be transferred to the user and recorded in the blockchain or other secure, trusted tracking system and the user can then hold on to the virtual item, put the virtual item on sale in a virtual marketplace, transfer the virtual item to another user, and so on. 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. McKenzie paragraph 32 disclosing in some cases, the physical tag may be attached by the authenticator. In some cases, the product may be shipped back to the owner or a third-party responsible for attaching the physical tags. 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 (e.g., a stock keeping unit (SKU) code, product type (including, for example, clothing, jacket, shoe, tool, bicycle, recreation, non-perishable, book, collectible, etc.), images of the product, a release date, and so on) 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. In block 270, the component provides a transaction for recordation in a blockchain or other secure, trusted tracking system, such as a transaction that associates the owner of the product with the unique identifier associated with the tag attached to the product and the generated identifier and signed using a private key (of a public/private key pair) associated with the authenticator.)
Referring to claim 15,
McKenzie further discloses A first client device of a first user that is the recipient of a transaction in a blockchain-type database, relating to at least one non-fungible token, wherein it is configured to: -receive a request to authenticate a physical product uniquely associated with said non-fungible token; (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. Mckenzie paragraph 35 disclosing FIG. 5 is a flow diagram illustrating steps of an exchange component in accordance with some embodiments of the disclosed technology. 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 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 blocks 512 and 522 the potential buyer and seller negotiate over terms of the purchase, such as price, shipping, insurance, payment processing, timelines, etc. In some cases, the potential buyer and/or seller may have fixed terms and be unwilling to negotiate, in other cases the negotiate term may be prolonged. In decision blocks 513 and 523, if terms of the exchange are accepted, then the seller continues at block 524, else the component returns a value of false at block 531, indicating that the exchange was not successful. For example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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)
-if the physical product is authenticated on said first client device, execute the transaction in the blockchain-type database. (Mckenzie paragraph 35 disclosing for example, the component may receive a message indication acceptance of an offer from the potential buyer or the seller. 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. 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. 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. In block 529, the seller sends the authenticated product to the buyer or engages with a third-party to have the authenticated product to the buyer. 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.)
Referring to claim 16,
McKenzie further discloses An assembly of a first client device according to claim 15 and a second client device of a second user that is the originator of the transaction and configured to receive another request to authenticate the physical product uniquely associated with the non-fungible token. (Mckenzie paragraph 22 disclosing in some embodiments, the product authentication system uses tamper-proof tags or chips, such as NFC Integrated Circuits (ICs) or dual-frequency ICs tags with a Secure Unique NFC (SUN) mechanism that generates a secure unique NFC message authentication each time the tag is scanned or read, for example, for proof of presence, authentication, and ownership. When a product is sold, the seller can scan the tag to provide proof of ownership and proof of presence and then ship the product to the buyer. 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. McKenzie paragraph 35 disclosing 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. 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. In block 529, the seller sends the authenticated product to the buyer or engages with a third-party to have the authenticated product to the buyer. 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.)
Referring to claim 17,
McKenzie further discloses A computer program product comprising code instructions for executing a method according to claim 1 for carrying out a transaction in a blockchain-type database, relating to at least one non-fungible token, when the program is executed on a computer. (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. McKenzie paragraph 31 disclosing the product authentication system can be described in the general context of computer-executable instructions, such as program modules and components, executed by one or more computers, processors, or other devices, including single-board computers and on-demand cloud computing platforms. Generally, program modules or components include routines, programs, objects, data structures, and so on that perform particular tasks or implement particular data types. Typically, the functionality of the program modules can be combined or distributed as desired in various embodiments. Aspects of the product authentication system can be implemented in hardware using, for example, an application-specific integrated circuit (“ASIC”).)
Referring to claim 18,
McKenzie further discloses A storage medium readable by computer equipment on which is recorded a computer program product comprising code instructions for executing a method according to claim 1 for carrying out a transaction in a blockchain- type database, relating to at least one non-fungible token. (Mckenzie paragraph 20 disclosing Systems and methods for authenticating products, such as products from original manufacturers and/or resellers, that provide a trusted and reliable mechanism for buyers and sellers to prove the authenticity of a product and for authenticators to establish an authentication that can be relied on during downstream transactions is provided. In some embodiments, a blockchain-based product authentication system is provided that allows entities within a chain of commerce (e.g., suppliers, manufacturers, distributors, retails, consumers, consignors, resellers) to verify the authenticity of items by way of trusted authenticators and trusted audit processes. The product authentication system enables users to rely on product authentications via off-channel sales with the use of cryptography, blockchain, digital assets, and tagging hardware and software such as Near Field Communication (NFC) or other technologies that supports the need to define a digital twin of a physical product, non-fungible tokens (e.g., ERC721 non-fungible tokens), and so on. McKenzie paragraph 31 disclosing the product authentication system can be described in the general context of computer-executable instructions, such as program modules and components, executed by one or more computers, processors, or other devices, including single-board computers and on-demand cloud computing platforms. Generally, program modules or components include routines, programs, objects, data structures, and so on that perform particular tasks or implement particular data types. Typically, the functionality of the program modules can be combined or distributed as desired in various embodiments. Aspects of the product authentication system can be implemented in hardware using, for example, an application-specific integrated circuit (“ASIC”).)
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 nonobviousness.
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over McKenzie et al. (US 20210248653) in view of Parnerkar (US 20250088372).
Referring to claim 13,
Mckenzie does not teach or suggest A method for carrying out a transaction relating to the repair of a physical product of a first user, comprising the replacement of at least one part of the product, wherein it comprises carrying out a step (a') of requesting to create a new non-fungible token uniquely associated with said the part of the physical product for the benefit of the first user, and then carrying out the method according to claim 1, in which the transaction in a blockchain-type database is the creation of the non-fungible token for the benefit of the first user.
However, Parnerkar, which is directed to verification via utilization of NFTs teaches,
A method for carrying out a transaction relating to the repair of a physical product of a first user, comprising the replacement of at least one part of the product, wherein it comprises carrying out a step (a') of requesting to create a new non-fungible token uniquely associated with said the part of the physical product for the benefit of the first user, and then carrying out the method according to claim 1, in which the transaction in a blockchain-type database is the creation of the non-fungible token for the benefit of the first user. (Parnerkar paragraph 7 teaching A non-fungible token (NFT), sometimes also called non-exchangeable token, is in particular to mean a digitized form of a dataset/asset which is preferably placed on a DLT, such as a blockchain or a tangle or the like, and which is in particular realized so as not to be one-to-one exchangeable, to be non-divisible and unique. NFTs are at least distributable and/or dispatchable within the DLT. In addition, it is conceivable that the DLTs are also capable of bridging the boundaries between different DLTs and are thus distributable and/or dispatchable between different DLTs. In public DLTs, the NFTs placed thereon, and preferably transactions associated with the NFT, can be viewed by anybody. An NFT can in particular be linked to at least one physical or digital object. Herein it is conceivable that an NFT is connected to several physical or digital objects (e. g. several public keys) and/or that an identical physical or digital object (e. g. a public key) is assigned to more than one NFT. In particular, the NFT created in the method step is at least linked to the digital object “public key”. For this purpose, the NFT comprises the public key or its deterministic derivative directly or in the form of a hash value of the public key or the like. As soon as the creation of the NFT comprising the public key or its deterministic derivative has been confirmed by the consensus protocol of the respective DLT, the assignment to the NFT is fixed in the DLT invariably and permanently (until possible redeeming or burning by an owner of the NFT). The creation of an NFT, in particular of an NFT connected to an object, is often also referred to as “minting” of the NFT. In particular, the NFT is generated by the entity itself, for example by means of a computer system of the entity which is connected to the DLT. Making ownership of the NFT impossible for anybody is often also referred to as “burning” of the NFT. Cancelation of the relationship between the NFT and the object assigned thereto is often also referred to as a “redeeming” of the NFT. In particular, the NFT can be created using a smallest possible unit of a DLT token. The DLT token realizes an underlying asset. For some applications, the underlying asset can also be increased, it may for example contain the actual value of the physical or digital object at the time of the creation, etc. NFTs are preferably assigned to at least one, preferably exactly one, owner address within the DLT. This owner address assigned to the NFT may change by shipping, by an activity or by an exchange of the NFT. The DLT is preferably realized as a decentralized DLT. Alternatively, the DLT may also be realized in an only partially decentralized manner (distributed over few nodes) or in a centralized manner. Parnerkar paragraphs 12-13 teaching upon the redeeming of the NFT, all metadata, links and relationships of the NFT with the physical or digital object (here: the public key) are detached/removed from the NFT. The NFT is thus converted back into the “empty” DLT token which it was before creation (minting). To carry out the redeeming process, the NFT is in particular sent back to a DLT address of the creator of the NFT (e. g. a contract address of a smart contract). In particular, the “empty” DLT token is reusable following the redeeming, that is to say, for example, a new NFT containing a further public key can be created therefrom. Upon the burning, the NFT is in particular sent to a “burn address” of the DLT (e. g. 0x000000000000000000000000000000000000dEaD or 0x0000000000000000000000000000000000000000 for ERC20 token, ERC721 token, ERC1155 token or BEP-20 token). Nobody has access/can ever have access to this “burn address”, such that NFTs sent there are quasi destroyed. In particular, the NFT sent to the “burn address” and its underlying DLT token are removed from the circuit and no longer reusable, that is to say, for example, no new NFT containing a further public key can be created therefrom. Often the total number of DLT tokens is limited, such that the rarity of the DLT tokens is augmented by the burning. In particular, the ownership of an NFT can be determined by sending a transaction to a smart contract related to the NFT, for example to the smart contract via which the NFT was created, or by querying DLT nodes. The transaction or the query preferably results in an output of a DLT owner address which currently owns the NFT, in particular the DLT token underlying the NFT, respectively which currently has power of disposal over the NFT, in particular the DLT token underlying the NFT. In this way, the ownership of the NFT can advantageously be determined reliably and easily by each participant of the DLT. In particular, the legitimation entity is assigned to the owner address. In particular, exclusively the legitimation entity has power of disposal over the owner address and preferably over all NFTs owned by the owner address. If the legitimation entity is trustworthy, e. g. is embodied by an official entity such as an authority or by a private trustworthy entity such as an IT security company, a KYC (Know Your Customer) provider etc., the fact that this entity owns the NFT with the public key or the deterministic derivative of the public key permits concluding that the public key is genuine. A communication based on the use of the public key can thus be trusted, respectively can be assigned as much trust as the entity that owns the associated NFT. By a burning or redeeming of the NFT by the legitimation entity, the verifiability of respective public keys by the legitimation entity can be ended. This may for example be the case if a paid time interval or a validity of the public key has expired, if a validity of the linked object has expired (e. g. an expiry date of a passport verified by an authority has been reached), etc. Parnerkar paragraph 16 teaching it is proposed that at least the creation (minting) of the NFT, at least a transaction of the NFT, at least a verification of the NFT, at least a redeeming of the NTF and/or at least a burning of the NFT is implemented by an execution of one or several smart contracts of the DLT or by a direct creation as a native asset of the DLT. A “smart contract” is in particular to mean a contract placed on a DLT, which comprises at least one, preferably a plurality of if/then conditions as preprogrammed functions that can be called up. For this purpose, in particular “if” conditions are provided to the smart contract as input, and the smart contract responds by an output/non-output of “then” results. In particular, the smart contract is realized as a software code placed on the DLT. In particular, the smart contract is realized so as to be unchangeable by the placing on the DLT. In particular, the smart contract is assigned a DLT address in the DLT. In particular, the smart contract can be called up by sending transactions to the DLT address of the smart contract. In particular, an execution of the smart contract requires payment of a fee, which is added in the form of DLT tokens to the transactions calling up the smart contract. In particular, the smart contract is executed after calling up more than one DLT node (“quorum”), wherein an output of the result only takes place if all members of the quorum arrive at the same result. Preferably, the smart contract, which is used at least for the creation of the NFT, comprises at least one of the following functions, preferably at least the following functions: mintToken (for creating an NFT from the underlying DLT token and for sending this NFT to a DLT address), tokenOwner (for outputting the DLT owner address of an NFT), tokenBalance (for outputting all NFTs of a specific DLT owner address), burnToken (for burning an NFT, i.e. for sending the NFT to the burn address), redeemToken (for redeeming the NFT, i. e. for detaching the link to the physical or digital object and for sending the DLT token underlying the NFT back to the DLT address of the smart contract), tokenTransfer (for sending the NFT to another DLT address) and approveTransfer (for accepting a requested shipping of the NFT to a DLT address). Parnerkar paragraphs 21-22 teaching if, alternatively or additionally, the entity is realized as a product and the legitimation entity is a manufacturer of the product, verification of original components is advantageously enabled. In particular, the manufacturer of the product may additionally include further properties of the product in the NFT using the proposed method, for example construction year, serial number, etc., which can then also be read out and verified in the verification method. If, alternatively or additionally, the entity is realized as a product and the legitimation entity is a product checking point or a repair and/or maintenance point for the product, it is advantageously possible to verify whether the product, e. g. the replacement part or the like, has been tested successfully or whether/when the product was correctly repaired and/or maintained. Parnerkar paragraph 24 teaching furthermore, it is proposed that the NFT created in the method step contains in addition to the public key, or in particular also instead of the public key, at least a confirmation, for example a warranty certificate, an insurance confirmation, a use permit certificate, or its deterministic derivative, and/or at least an expiry date, for example a warranty expiry, an insurance period, a duration of a use permit, which is assigned to the entity or to an agreement connected to the entity. As a result, a characteristic of the entity can advantageously be read out by anyone in an unfalsifiable manner. It is conceivable that, e. g. by a manufacturer of the product, an NFT is created which comprises the public key assigned to the product and the confirmation or its deterministic derivative and/or the expiry date. This NFT can then be taken into ownership by an end user of the product, i. e. sent to a DLT address of the end user. In this case, the end user realizes an alternative legitimation entity. The manufacturer can in this case advantageously determine, by querying the DLT address of the end user, whether the respective end user actually owns the product. With ownership of the product verified in this way, advantageously then grant of a service, such as for example a (cost-free) repair, maintenance, warranty or another service, can be linked. By the additionally included expiry date, a time limitation of the promised service can advantageously be publicly and unfalsifiably viewable and verifiable. Parnerkar paragraphs 36-37 teaching FIG. 1 schematically shows an exemplary verification computer system 32, which is configured for carrying out a verification method. The verification computer system 32 comprises an NFT creation device 34. The NFT creation device 34 is configured for creating a non-fungible token (NFT 18) for an entity 20. A public key 10 of an asymmetric cryptography system is assigned to the entity 20. The entity 20 may in this case be realized as a physical or digital object (product) or as a person. The public key 10 is publicly retrievable/viewable. A private key 12 of the asymmetric cryptography system is assigned to the entity 20. The private key 12 and the public key 10 of the entity 20 form a public key-private key pair of the asymmetric cryptography system. The NFT creation device 34 can view/determine the public key 10 of the entity 20. The NFT creation device 34 is configured for checking the allocation of the public key 10 to the entity 20 before the creation of the NFT 18, e. g. by challenge-response authentication. The NFT 18 created by the NFT creation device 34 contains a copy of the public key 16, assigned to the entity 20, of the asymmetric cryptography system. Alternatively, the NFT 18 may also contain a deterministic derivative of the public key 10 instead of the copy of the public key 16. The NFT creation device 34 may be a (mobile or stationary) computer of the entity 20 or a computer of a further entity that is different from the entity 20, such as for example of an authority. The NFT creation device 34 is configured for storing the created NFT 18 in a distributed ledger, such as a blockchain, a tangle or a hashgraph, of a distributed ledger technology (DLT) 44. The DLT 44 is realized as a decentralized DLT. Alternatively, however, centralized or partially centralized DLTs are also conceivable. The NFT 18 is offered via the DLT 44 for transmission to legitimation entities 22 that differ from the entity 20. The legitimation entity 22 may be realized inter alia as a central certification authority, as an authority, as a KYC provider, as a product manufacturer, as a product checking point, as a repair point, as a maintenance point, as an insurer. The NFT 18 is publicly provided via the DLT 44 for verification of the ownership. In addition to the public key 10, the NFT 18 may also include further information or the like, e. g. a confirmation 28, an expiry date 30, a legitimation 42 of a person, an ownership title 46 of a person or their respective deterministic derivatives. The legitimation device 38 publicly provides the NFT 18 via the DLT 44 for the verification of the ownership. The legitimation device 38 is configured to enable the legitimation entity 22 to request transmission of the NFT 18. The legitimation device 38 is configured to enable the legitimation entity 22 to receive/take possession of the requested NFT 18. A DLT owner address of the legitimation entity 22 is assigned to the legitimation entity 22/the legitimation device 38. The legitimation device 38 is configured for checking each NFT 18 received by the legitimation entity 22 as to whether the NFT 18 was previously requested by the legitimation entity 22/by the legitimation device 38, wherein in the event of a negative checking result the NFT 18 is directly redeemed or burned. Alternatively, in the event of a negative checking result the NFT 18 can also be sent back to a DLT sender address. The legitimation device 22 is configured, for a cancelation of the legitimation of the entity 20 by the legitimation entity 22, to burn the NFT 18, i. e. to send it to a burn address of the DLT 44, or to redeem it, i. e. to send it to a DLT address of a developer/administrator of the DLT 44, in particular to a DLT address of the smart contract originally used for creating the NFT 18.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the authentication of products utilizing NFTs as taught in McKenzie to incorporate A method for carrying out a transaction relating to the repair of a physical product of a first user, comprising the replacement of at least one part of the product, wherein it comprises carrying out a step (a') of requesting to create a new non-fungible token uniquely associated with said the part of the physical product for the benefit of the first user, and then carrying out the method according to claim 1, in which the transaction in a blockchain-type database is the creation of the non-fungible token for the benefit of the first user as taught in Parnerkar with the motivation of associating a new NFT with the replacement part information for facilitating subsequent transactions predicated on the replacement part information and conditions associated with the new NFT provided. (Parnerkar paragraphs 7-8, 16, 21-22, 24, and 37)
Referring to claim 14,
Parnerkar further teaches wherein a former non- fungible token is uniquely associated with the at least one part of the physical product prior to the repair, the method comprising carrying out a preliminary step (a") of requesting to destroy the former non-fungible token uniquely associated with said part of the physical product. (Parnerkar paragraphs 36-37 teaching FIG. 1 schematically shows an exemplary verification computer system 32, which is configured for carrying out a verification method. The verification computer system 32 comprises an NFT creation device 34. The NFT creation device 34 is configured for creating a non-fungible token (NFT 18) for an entity 20. A public key 10 of an asymmetric cryptography system is assigned to the entity 20. The entity 20 may in this case be realized as a physical or digital object (product) or as a person. The public key 10 is publicly retrievable/viewable. A private key 12 of the asymmetric cryptography system is assigned to the entity 20. The private key 12 and the public key 10 of the entity 20 form a public key-private key pair of the asymmetric cryptography system. The NFT creation device 34 can view/determine the public key 10 of the entity 20. The NFT creation device 34 is configured for checking the allocation of the public key 10 to the entity 20 before the creation of the NFT 18, e. g. by challenge-response authentication. The NFT 18 created by the NFT creation device 34 contains a copy of the public key 16, assigned to the entity 20, of the asymmetric cryptography system. Alternatively, the NFT 18 may also contain a deterministic derivative of the public key 10 instead of the copy of the public key 16. The NFT creation device 34 may be a (mobile or stationary) computer of the entity 20 or a computer of a further entity that is different from the entity 20, such as for example of an authority. The NFT creation device 34 is configured for storing the created NFT 18 in a distributed ledger, such as a blockchain, a tangle or a hashgraph, of a distributed ledger technology (DLT) 44. The DLT 44 is realized as a decentralized DLT. Alternatively, however, centralized or partially centralized DLTs are also conceivable. The NFT 18 is offered via the DLT 44 for transmission to legitimation entities 22 that differ from the entity 20. The legitimation entity 22 may be realized inter alia as a central certification authority, as an authority, as a KYC provider, as a product manufacturer, as a product checking point, as a repair point, as a maintenance point, as an insurer. The NFT 18 is publicly provided via the DLT 44 for verification of the ownership. In addition to the public key 10, the NFT 18 may also include further information or the like, e. g. a confirmation 28, an expiry date 30, a legitimation 42 of a person, an ownership title 46 of a person or their respective deterministic derivatives. The legitimation device 38 publicly provides the NFT 18 via the DLT 44 for the verification of the ownership. The legitimation device 38 is configured to enable the legitimation entity 22 to request transmission of the NFT 18. The legitimation device 38 is configured to enable the legitimation entity 22 to receive/take possession of the requested NFT 18. A DLT owner address of the legitimation entity 22 is assigned to the legitimation entity 22/the legitimation device 38. The legitimation device 38 is configured for checking each NFT 18 received by the legitimation entity 22 as to whether the NFT 18 was previously requested by the legitimation entity 22/by the legitimation device 38, wherein in the event of a negative checking result the NFT 18 is directly redeemed or burned. Alternatively, in the event of a negative checking result the NFT 18 can also be sent back to a DLT sender address. The legitimation device 22 is configured, for a cancelation of the legitimation of the entity 20 by the legitimation entity 22, to burn the NFT 18, i. e. to send it to a burn address of the DLT 44, or to redeem it, i. e. to send it to a DLT address of a developer/administrator of the DLT 44, in particular to a DLT address of the smart contract originally used for creating the NFT 18.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the authentication of products utilizing NFTs as taught in McKenzie to incorporate wherein a former non- fungible token is uniquely associated with the at least one part of the physical product prior to the repair, the method comprising carrying out a preliminary step (a") of requesting to destroy the former non-fungible token uniquely associated with said part of the physical product as taught in Parnerkar with the motivation of associating a new NFT with the replacement part information for facilitating subsequent transactions predicated on the replacement part information and conditions associated with the new NFT provided rather than utilizing the previous NFT associated and limiting the number of NFTs in circulation. (Parnerkar paragraphs 7-8, 12, 16, 21-22, 24, and 36-37)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen et al. (US 20220215382) - directed to a blockchain-based product authentication system.
Bulawski et al. (US 20210103938) - directed to authenticating physical products via NFC tags and recording authentication transactions on a blockchain.
Suk (US 20230145439) – directed to providing real asset authentication service using decentralized identifiers and NFTs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J MONAGHAN whose telephone number is (571)270-5523. The examiner can normally be reached on Monday- Friday 8:30 am - 5:30 pm.
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, Sarah Monfeldt can be reached on (571) 270-1833. 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.
/Michael J. Monaghan/Examiner, Art Unit 3629
