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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. The application’s effective filing date is February 20, 2024.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-17 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of Hudec et al. (U.S. Patent No. 12,314,963) in view of Bulawski et al. (US 20220284447). Although the claims at issue are not identical, they are not patentably distinct from each other.
Referring to claims 1, 9, and 12,
Hudec, which is directed to product authentication and verification, teaches
(Claim 1) A method for encoding and using a near field communication tag to authenticate a product, comprising:
(Claim 9) A method for encoding and using a near field communication tag to create an immutable tap transaction record for a product, comprising:
(Claim 12) encoding and using a near field communication tag to authenticate a product, comprising:
(Hudec claim 1 A method for authenticating a product, comprising: … claim 1 encoding a near field communication tag with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier, )
generating a unique product identifier for the product, (Hudec claim 1 generating a unique product identifier for the product,)
sending a request to a blockchain to record the unique product identifier, (Hudec claim 1 generating a data structure for the product, wherein the data structure comprises the unique product identifier, sending a request to a blockchain to record the data structure for the product,)
whereupon receiving the request, the blockchain records the unique product identifier on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request, (Hudec claim 1 whereupon receiving the request, the blockchain records the data structure for the product on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request,)
receiving the initial blockchain transaction identifier for the initial transaction, and (Hudec claim 1 receiving the initial blockchain transaction identifier for the initial transaction,)
encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL). (Hudec claim 1 encoding a near field communication tag with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier,… whereupon, when the tag affixed to the product engages in a tap interaction with a proximity coupling device, the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL,)
Hudec does not teach or suggest A system for; a computer processor, and an API module executing on the computer processor and configured to enable the computer processor to:
However, Bulawski, which is directed to product authentication, teaches:
A system for; (Bulawski paragraph 13 teaching referring now to FIG. 1A, a block diagram depicts one embodiment of a system 100 for authenticating physical products via NFC tags and recording authentication transactions on the blockchain. In brief overview, the system 100 includes a client computing device 102, a computing device 106 a, a smart contract 106 b (e.g., a node that provides access to a smart contract), a backend module 103, an NFC reader 105, an NFC tag 107 attached to a physical object, an application 109, and databases 120 a-c.)
a computer processor, and (Bulawski paragraph 78 teaching each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the methods and systems described herein by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory.)
an API module executing on the computer processor and configured to enable the computer processor to: (Bulawski paragraph 12 teaching the methods and systems described herein may provide functionality for authenticating physical products via NFC tags and recording authentication transactions on the blockchain. In some embodiments, the methods and systems described herein combine the following elements to create a secure product authentication ecosystem: a first computing device executing the functionality of a backend module and functionality for writing to blocks in a blockchain and querying a blockchain, providing application programming interfaces (APIs) and backend services as will be described in further detail below; a second computing device associated with a user and executing an application; and at least one near field communication device (e.g., an NFC tag). Bulawski paragraph 78 teaching each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the methods and systems described herein by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory.)
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 manner of authenticating a product as taught in Hudec to incorporate A system for; a computer processor, and an API module executing on the computer processor and configured to enable the computer processor to: as taught in Bulawski with the motivation of leveraging conventional computing components for facilitating the functions of authenticating a product with a NFC. (Bulawski paragraphs 12-13 and 78)
Referring to claims 2 and 13,
Hudec further teaches whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, (Hudec claim 1 encoding a near field communication tag with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier,… whereupon, when the tag affixed to the product engages in a tap interaction with a proximity coupling device,)
the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and (Hudec claim 1 the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and)
a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL. (Hudec claim 1 a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL,)
Referring to claims 3, 10, and 17,
Hudec further teaches
receiving from the web client the unique product identifier and a one or more tap interaction data generated from the tap interaction, (Hudec claim 1 receiving from the web client the unique product identifier and a one or more tap interaction data generated from the tap interaction,)
identifying the initial blockchain transaction identifier for the unique product identifier received from the web client, (Hudec claim 1 identifying the initial blockchain transaction identifier for the unique product identifier received from the web client
whereupon, based on the initial blockchain transaction identifier, sending a subsequent request to the blockchain to record the one or more tap interaction data generated from the tap interaction, and (Hudec claim 1 whereupon, based on the initial blockchain transaction identifier, sending a subsequent request to the blockchain to record the one or more tap interaction data generated from the tap interaction, and)
whereupon receiving the subsequent request, the blockchain records the one or more tap interaction data on the blockchain in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction, and transmits the subsequent blockchain transaction identifier for the subsequent transaction in response to the request, and (Hudec claim 1 whereupon receiving the subsequent request, the blockchain records the one or more tap interaction data on the blockchain in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction, and transmits the subsequent blockchain transaction identifier for the subsequent transaction in response to the request)
receiving the subsequent blockchain transaction identifier for the subsequent transaction. (Hudec claim 1 receiving the subsequent blockchain transaction identifier for the subsequent transaction)
Hudec does not teach or suggest (Claim 17) (wherein the API module executing on the computer processor is further configured to enable the computer processor to)
However, Bulawski teaches (Claim 17) (wherein the API module executing on the computer processor is further configured to enable the computer processor to)
(Bulawski paragraph 12 teaching the methods and systems described herein may provide functionality for authenticating physical products via NFC tags and recording authentication transactions on the blockchain. In some embodiments, the methods and systems described herein combine the following elements to create a secure product authentication ecosystem: a first computing device executing the functionality of a backend module and functionality for writing to blocks in a blockchain and querying a blockchain, providing application programming interfaces (APIs) and backend services as will be described in further detail below; a second computing device associated with a user and executing an application; and at least one near field communication device (e.g., an NFC tag). Bulawski paragraph 78 teaching each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the methods and systems described herein by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory.)
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 manner of authenticating a product as taught in Hudec to incorporate (Claim 17) (wherein the API module executing on the computer processor is further configured to enable the computer processor to as taught in Bulawski with the motivation of leveraging conventional computing components for facilitating the functions of authenticating a product with a NFC. (Bulawski paragraphs 12-13 and 78)
Referring to claims 4 and 14,
Hudec teaches wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data. (Hudec claim 3 wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data.)
Referring to claim 5,
Hudec further teaches wherein the tag data is encrypted. (Hudec claim 4 wherein the tag data is encrypted.)
Referring to claim 6,
Hudec further teaches wherein the initial cryptographic output data comprises a one-time password, a digital signature, or a message authentication code. (Hudec claim 5 wherein the initial cryptographic output data comprises a one-time password, a digital signature, or a message authentication code.)
Referring to claim 7,
Hudec further teaches the step of verifying an authenticity of the product. (Hudec claim 6 further comprising the step of verifying an authenticity of the product.)
Referring to claim 8,
Hudec further teaches wherein the step of verifying the authenticity of the product comprises: reading the initial cryptographic output data from the subsequent tap-unique URL, (Hudec claim 7 wherein the step of verifying the authenticity of the product comprises:
reading the initial cryptographic output data from the subsequent tap-unique URL)
decrypting the encrypted tag data of the subsequent tap-unique URL using an encryption key associated with the product to generate a decrypted tag data, (Hudec claim 7 decrypting the encrypted tag data of the subsequent tap-unique URL using an encryption key associated with the product to generate a decrypted tag data,)
generating a subsequent cryptographic output data using the decrypted tag data, a cryptographic algorithm, and the encryption key, (Hudec claim 7 generating a subsequent cryptographic output data using the decrypted tag data, a cryptographic algorithm, and the encryption key,)
validating the subsequent cryptographic output data by comparing it against the initial cryptographic output data, (Hudec claim 7 validating the subsequent cryptographic output data by comparing it against the initial cryptographic output data,)
determining a verification result, wherein, if the subsequent cryptographic output data is validated, the verification result is that the product is authentic, and (Hudec claim 7 determining a verification result, wherein, if the subsequent cryptographic output data is validated, the verification result is that the product is authentic, and)
transmitting the verification result to the proximity coupling device to be viewed by a user. (Hudec claim 7 transmitting the verification result to the proximity coupling device to be viewed by a user.)
Referring to claims 11 and 16,
Hudec further teaches wherein the tag is a dual NFC/RFID tag. (Hudec claim 17 wherein the tag is a dual NFC/RFID tag)
Referring to claim 15,
Hudec further teaches wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data. (Hudec claim 10 wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data)
Claims 1-17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of Hudec et al (US 20250252453). Although the claims at issue are not identical, they are not patentably distinct from each other.
Hudec, which is directed to product authentication and verification teaches,
(Claim 1) A method for encoding and using a near field communication tag to authenticate a product, comprising:
(Claim 9) A method for encoding and using a near field communication tag to create an immutable tap transaction record for a product, comprising:
(Claim 12) A system for encoding and using a near field communication tag to authenticate a product, comprising:
(Hudec claim 1 A system for authenticating a product, comprising… encode a near field communication tag to be affixed to the product with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier. The Examiner interprets the systems performs steps of a method.)
a computer processor, and (claim 1 a computer processor, and)
an API module executing on the computer processor and configured to enable the computer processor to: (Hudec claim 1 an API module executing on the computer processor and configured to enable the computer processor to: )
generating a unique product identifier for the product, (Hudec claim 1 generate a unique product identifier for the product,)
sending a request to a blockchain to record the unique product identifier, (Hudec claim 1 generate a data structure for the product, wherein the data structure comprises the unique product identifier, send a request to a blockchain module to record the data structure for the product,)
whereupon receiving the request, the blockchain records the unique product identifier on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request, (Hudec claim 1 whereupon receiving the request, the blockchain module records the data structure for the product on the blockchain module in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits to the API module the initial blockchain transaction identifier for the initial transaction in response to the request,
receiving the initial blockchain transaction identifier for the initial transaction, and (Hudec claim 1 receive from the blockchain module the initial blockchain transaction identifier for the initial transaction,)
encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL). (Hudec claim 1 encode a near field communication tag to be affixed to the product with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier,… a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL,)
Referring to claims 2 and 13,
Hudec further teaches whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, (Hudec claim 1 whereupon, when the tag affixed to the product engages in a tap interaction with a proximity coupling device,)
the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and (Hudec claim 1 the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and)
a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL. (Hudec claim 1 a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL)
Referring to claims 3, 10, and 17
Hudec further teaches ((Claim 17) (wherein the API module executing on the computer processor is further configured to enable the computer processor to) (Hudec claim 1 an API module executing on the computer processor and configured to enable the computer processor to:)
receiving from the web client the unique product identifier and a one or more tap interaction data generated from the tap interaction, (Hudec claim 1 receive from the web client the unique product identifier and a one or more tap interaction data generated from the tap interaction,
identifying the initial blockchain transaction identifier for the unique product identifier received from the web client, (Hudec claim 1 identify the initial blockchain transaction identifier associated with the unique product identifier received from the web client,)
whereupon, based on the initial blockchain transaction identifier, sending a subsequent request to the blockchain to record the one or more tap interaction data generated from the tap interaction, and (Hudec claim 1 whereupon, based on the initial blockchain transaction identifier, send a subsequent request to the blockchain module to record the one or more tap interaction data generated from the tap interaction, and)
whereupon receiving the subsequent request, the blockchain records the one or more tap interaction data on the blockchain in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction, and transmits the subsequent blockchain transaction identifier for the subsequent transaction in response to the request, and (Hudec claim 1 whereupon receiving the subsequent request, the blockchain module records the one or more tap interaction data on the blockchain module in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction, and transmits to the API module the subsequent blockchain transaction identifier for the subsequent transaction in response to the request,)
receiving the subsequent blockchain transaction identifier for the subsequent transaction. (Hudec claim 1 receive from the blockchain module the subsequent blockchain transaction identifier for the subsequent transaction)
Referring to claims 4 and 14,
Hudec further teaches wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data. (Hudec claim 3 wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data.)
Referring to claim 5,
Hudec further teaches wherein the tag data is encrypted. (Hudec claim 4 wherein the tag data is encrypted.)
Referring to claim 6,
Hudec further teaches wherein the initial cryptographic output data comprises a one-time password, a digital signature, or a message authentication code. (Hudec claim 5 wherein the initial cryptographic output data comprises one of the following: a one-time password, a digital signature, or a message authentication code.)
Referring to claim 7,
Hudec further teaches the step of verifying an authenticity of the product. (Hudec claim 6 wherein the API module is further configured to enable the computer processor to verify an authenticity of the product.)
Referring to claim 8,
Hudec further teaches wherein the step of verifying the authenticity of the product comprises: reading the initial cryptographic output data from the subsequent tap-unique URL, (Hudec claim 7 wherein to verify the authenticity of the product, the API module is further configured to enable the computer processor to: read the initial cryptographic output data from the subsequent tap-unique URL,)
decrypting the encrypted tag data of the subsequent tap-unique URL using an encryption key associated with the product to generate a decrypted tag data, (Hudec claim 7 decrypt the encrypted tag data of the subsequent tap-unique URL using an encryption key associated with the product to generate a decrypted tag data,)
generating a subsequent cryptographic output data using the decrypted tag data, a cryptographic algorithm, and the encryption key, (Hudec claim 5 generating a subsequent cryptographic output data using the decrypted tag data, a cryptographic algorithm, and the encryption key,)
validating the subsequent cryptographic output data by comparing it against the initial cryptographic output data, (Hudec claim 5 validating the subsequent cryptographic output data by comparing it against the initial cryptographic output data,)
determining a verification result, wherein, if the subsequent cryptographic output data is validated, the verification result is that the product is authentic, and (Hudec claim 5 determining a verification result, wherein if the subsequent cryptographic output data is validated, the verification result is that the product is authentic, and)
transmitting the verification result to the proximity coupling device to be viewed by a user. (Hudec claim 5 transmitting the verification result to the proximity coupling device to be viewed by a user.)
Referring to claims 11 and 16,
Hudec further teaches wherein the tag is a dual NFC/RFID tag. (Hudec claim 9 wherein the tag is a dual NFC/RFID tag.)
Referring to claim 15,
Hudec further teaches wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data. (Hudec claim 16 wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data.
Claims 1-17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-21 of Hudec et al. (U.S. Patent No. 12,437,308). Although the claims at issue are not identical, they are not patentably distinct from each other.
Referring to claims 1, 9, and 12,
(Claim 1) A method for encoding and using a near field communication tag to authenticate a product, comprising:
(Claim 9) A method for encoding and using a near field communication tag to create an immutable tap transaction record for a product, comprising:
(Claim 12) A system for encoding and using a near field communication tag to authenticate a product, comprising: (Hudec claim 1 A method for authenticating a product, comprising… encoding a near field communication tag with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier, Claim 10 A system for authenticating a product, comprising… encode a near field communication tag to be affixed to the product with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier,)
a computer processor, and (Hudec claim 10 a computer processor, and)
an API module executing on the computer processor and configured to enable the computer processor to: (Hudec claim 10 an API module executing on the computer processor and configured to enable the computer processor to)
generating a unique product identifier for the product, (Hudec claim 10 generate a unique product identifier for the product,)
sending a request to a blockchain to record the unique product identifier, (Hudec claim 10 generate a data structure for the product, wherein the data structure comprises the unique product identifier, send a request to a blockchain module to record the data structure for the product,)
whereupon receiving the request, the blockchain records the unique product identifier on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request, (Hudec claim 10 whereupon receiving the request from the API module, the blockchain module records the data structure for the product in a transaction, generates a blockchain transaction identifier for the transaction, and transmits to the API module the blockchain transaction identifier for the transaction in response to the request,)
receiving the initial blockchain transaction identifier for the initial transaction, and (Hudec claim 10 receive from the blockchain module the blockchain transaction identifier for the transaction,)
encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL). (Hudec claim 10 encode a near field communication tag to be affixed to the product with an initial tap-unique URL wherein the initial tap-unique URL comprises the unique product identifier, whereupon, when the tag affixed to the product engages in a tap interaction with a proximity coupling device, the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL,)
Referring to claims 2 and 13,
Hudec further teaches whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, (Hudec claim 1 whereupon, when the encoded tag affixed to the product engages in a tap interaction with a proximity coupling device,)
the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and (Hudec claim 1 the encoded tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and)
a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL. (Hudec claim 1 a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL,)
Referring to claims 3, 10, and 17
Hudec further teaches
((Claim 17) (wherein the API module executing on the computer processor is further configured to enable the computer processor to): (Hudec claim 10 an API module executing on the computer processor and configured to enable the computer processor to)
receiving from the web client the unique product identifier and a one or more tap interaction data generated from the tap interaction, (Hudec claim 1 receiving from the web client the unique product identifier and a one or more tap interaction data generated from the tap interaction,)
identifying the initial blockchain transaction identifier for the unique product identifier received from the web client, (Hudec claim 20 identifying the initial blockchain transaction identifier for the unique product identifier received from the web client,)
whereupon, based on the initial blockchain transaction identifier, sending a subsequent request to the blockchain to record the one or more tap interaction data generated from the tap interaction, and (Hudec claim 20 whereupon, based on the initial blockchain transaction identifier, sending a subsequent request to the blockchain to record the one or more tap interaction data generated from the tap interaction, and)
whereupon receiving the subsequent request, the blockchain records the one or more tap interaction data on the blockchain in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction, and transmits the subsequent blockchain transaction identifier for the subsequent transaction in response to the request, and (Hudec claim 20 whereupon receiving the subsequent request, the blockchain records the one or more tap interaction data on the blockchain in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction, and transmits the subsequent blockchain transaction identifier for the subsequent transaction in response to the request, and)
receiving the subsequent blockchain transaction identifier for the subsequent transaction. (Hudec claim 20 receiving the subsequent blockchain transaction identifier for the subsequent transaction.)
Referring to claims 4 and 14,
Hudec further teaches wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data. (Hudec claim 2 wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data.)
Referring to claim 5,
Hudec further teaches wherein the tag data is encrypted. (Hudec claim 3 wherein the tag data is encrypted.)
Referring to claim 6,
Hudec further teaches wherein the initial cryptographic output data comprises a one-time password, a digital signature, or a message authentication code. (Hudec claim 4 wherein the initial cryptographic output data comprises one of the following: a one-time password, a digital signature, or a message authentication code.)
Referring to claim 7,
Hudec further teaches verifying an authenticity of the product. (claim 1 verifying an authenticity of the product.)
Referring to claim 8,
Hudec further teaches wherein the step of verifying the authenticity of the product comprises: reading the initial cryptographic output data from the subsequent tap-unique URL, (Hudec claim 5 wherein the step of verifying the authenticity of the product comprises:
reading the initial cryptographic output data from the subsequent tap-unique URL,)
decrypting the encrypted tag data of the subsequent tap-unique URL using an encryption key associated with the product to generate a decrypted tag data, (Hudec claim 5 decrypting the encrypted tag data of the subsequent tap-unique URL using an encryption key associated with the product to generate a decrypted tag data,)
generating a subsequent cryptographic output data using the decrypted tag data, a cryptographic algorithm, and the encryption key, (Hudec claim 5 generating a subsequent cryptographic output data using the decrypted tag data, a cryptographic algorithm, and the encryption key,)
validating the subsequent cryptographic output data by comparing it against the initial cryptographic output data, (Hudec claim 5 validating the subsequent cryptographic output data by comparing it against the initial cryptographic output data,)
determining a verification result, wherein, if the subsequent cryptographic output data is validated, the verification result is that the product is authentic, and (Hudec claim 5 determining a verification result, wherein if the subsequent cryptographic output data is validated, the verification result is that the product is authentic, and)
transmitting the verification result to the proximity coupling device to be viewed by a user. (Hudec claim 5 transmitting the verification result to the proximity coupling device to be viewed by a user.)
Referring to claims 11 and 16,
Hudec further teaches wherein the tag is a dual NFC/RFID tag. (Hudec claim 9 wherein the tag is a dual NFC/RFID tag.)
Referring to claim 15
Hudec further teaches wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data. (Hudec claim 16 wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data.)
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-2, 9, and 11-16 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-2 recite a method (process), Claims 9 and 11 recite a method (process), and Claims 12-16 recite a system (machine) and therefore fall into a statutory category.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
The claims as a whole recites methods and a system for organizing the authentication of a product, which under its broadest reasonable interpretation, covers concepts for Certain Methods of Organizing Human Activity.
The abstract idea portion of the claims is as follows:
(Claim 1) A method [for encoding and using a near field communication tag] to authenticate a product, comprising:
(Claim 9) A method [for encoding and using a near field communication tag] to create an immutable tap transaction record for a product, comprising:
(Claim 12) [A system for encoding and using a near field communication tag] to authenticate a product, comprising:
[a computer processor, and
an API module executing on the computer processor and configured to enable the computer processor to:]
generating a unique product identifier for the product,
sending a request [to a blockchain] to record the unique product identifier,
whereupon receiving the request, [the blockchain] records the unique product identifier [on the blockchain] in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request,
receiving the initial blockchain transaction identifier for the initial transaction, and
[encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL)].
Where the portions not bracketed recite the abstract idea.
Here the claims recite concepts covering managing personal behavior or interactions between people (following rules or instructions) but for the recitation of generic computer components. Additionally, the claims recite concepts covering commercial or legal interactions (business relations) but for the recitation of generic computing components. In the present application the claims recite concepts for organizing the authentication of a product. (See paragraphs 4-5).
If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in managing personal behavior or interactions between people or commercial or legal interactions, it falls under the Certain Method 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:
A system. (See paragraph 104 of the Specification and Figure 1.)
A computer processor. (See paragraph 305 of the Specification.)
An API module. (See paragraphs 70-71 of the Specification.)
A blockchain. (See paragraphs 84 of the Specification.)
A near field communication tag. (See paragraphs 47 and 105 of the Specification.)
A proximity coupling device. (See paragraph 6 of the Specification.)
A web client. (See paragraphs 6 and 119 of the Specification.)
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))
Referring to “for encoding and using a near field communication tag” and “encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL the Examiner views as a results-oriented solution lacking details and therefore equivalent to merely apply it. (See Id.) and paragraphs 177 and 196-197 of the Specification).
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 Id.) 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 13 recites the results-oriented solution steps of “whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device,
the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL.” (See paragraph 189 and 196-197) and are therefore viewed as equivalent as mere instructions for implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more.. Therefore claims 2, 7, 13-16, and 19-21 are considered to be patent ineligible.
Dependent claims 11 and 16 further the claim recites the additional elements of dual NFC/RFID tag (See paragraphs 261 and 273) 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 3-4 are considered to be patent ineligible.
Dependent claims 14-15 further define the abstract idea as identified and do not integrate the abstract idea into a practical application or add significantly more. Therefore claims 14-15 are 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 § 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-2 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Bulawski et al. (US 20220284447) in view of Anastas et al. (US 20220398601).
Referring to claims 1, 9, and 12,
(Claim 1) A method for encoding and using a near field communication tag to authenticate a product, comprising:
(Claim 9) A method for encoding and using a near field communication tag to create an immutable tap transaction record for a product, comprising:
(Claim 12) A system for encoding and using a near field communication tag to authenticate a product, comprising: (Bulawski paragraph 13 teaching referring now to FIG. 1A, a block diagram depicts one embodiment of a system 100 for authenticating physical products via NFC tags and recording authentication transactions on the blockchain. In brief overview, the system 100 includes a client computing device 102, a computing device 106 a, a smart contract 106 b (e.g., a node that provides access to a smart contract), a backend module 103, an NFC reader 105, an NFC tag 107 attached to a physical object, an application 109, and databases 120 a-c. Bulawski paragraph 28 teaching the NFC tag 107 may be encoded with a URL, version number, tag ID, and read counter, which may be used together with a securely stored, managed private key to generate a unique CMAC signature every time the chip is read. The tag ID of the NFC tag 107 and current read counter may be run through an AES-128 CMAC cipher (with a private key for a particular tag version (which is the same private key for every tag of that version) as the input key) to generate a session key. Then the entire URL (base URL, version, id, counter) is run through another round of AES-128 CMAC with the session key. The result of that calculation may be truncated and appended to the URL. The result is a unique response every time the tag is read. This ensures that the tag cannot be copied. When a tag is scanned, the backend module 103 performs the same operation and compares results. Only when they are equal and the read counter is within certain bounds, tag authenticity is confirmed. The version number may be a number of versions connected with a specific private key. The Tag ID may be the unique identifier of a particular tag. The tag private key may be AES-128 key, stored in inaccessible memory.
(Claim 12) a computer processor, and
(Bulawski paragraph 78 teaching each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the methods and systems described herein by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory.)
(Claim 12) an API module executing on the computer processor and configured to enable the computer processor to: (Bulawski paragraph 12 teaching the methods and systems described herein may provide functionality for authenticating physical products via NFC tags and recording authentication transactions on the blockchain. In some embodiments, the methods and systems described herein combine the following elements to create a secure product authentication ecosystem: a first computing device executing the functionality of a backend module and functionality for writing to blocks in a blockchain and querying a blockchain, providing application programming interfaces (APIs) and backend services as will be described in further detail below; a second computing device associated with a user and executing an application; and at least one near field communication device (e.g., an NFC tag). Bulawski paragraph 78 teaching each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the methods and systems described herein by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory.)
generating a unique product identifier for the product, (Bulawski paragraph 28 teaching the NFC tag 107 may be encoded with a URL, version number, tag ID, and read counter, which may be used together with a securely stored, managed private key to generate a unique CMAC signature every time the chip is read. The tag ID of the NFC tag 107 and current read counter may be run through an AES-128 CMAC cipher (with a private key for a particular tag version (which is the same private key for every tag of that version) as the input key) to generate a session key. Then the entire URL (base URL, version, id, counter) is run through another round of AES-128 CMAC with the session key. The result of that calculation may be truncated and appended to the URL. The result is a unique response every time the tag is read. This ensures that the tag cannot be copied. When a tag is scanned, the backend module 103 performs the same operation and compares results. Only when they are equal and the read counter is within certain bounds, tag authenticity is confirmed. The version number may be a number of versions connected with a specific private key. The Tag ID may be the unique identifier of a particular tag.
sending a request to a blockchain to record the unique product identifier, (Bulawski paragraph 39 teaching the method 200 includes storing, by a second computing device, in accordance with a smart contracts protocol, an identification of the product and the unique identifier of the NFC tag on a block in a blockchain (204).
Bulawski does not teach or suggest whereupon receiving the request, the blockchain records the unique product identifier on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request, receiving the initial blockchain transaction identifier for the initial transaction, and encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL).
Anastas, which is directed to verifying the authenticity of physical goods using NFC tags, teaches
whereupon receiving the request, the blockchain records the unique product identifier on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request, (Anastas paragraph 30 teaching A blockchain manager executing on the ledger node 60 may create a new, original block of data also referred to as an initial record. The blockchain manager may also create status blocks, chained to the initial record with changes to the data or to the status of the data. The blockchain manager on one node periodically updates each of the peers on other ledger nodes 60 with changes so that every ledger 68 maintains a record of the data. The chained blocks include a field which is generated as a function of prior blocks in the chain. Thus, blockchain managers may execute validation equations to ensure the validity of changes to the records. After validating changes and voting on accepting the changes, blockchain managers store changes made at other nodes 60 in the ledger 68 at their corresponding node 60. In this manner, data is securely stored within the distributed database. Anastas paragraphs 41-43 teaching with reference to FIG. 6 , the steps performed by the manufacturer to register each tag 22 in a blockchain are illustrated. The NFC reader 120 at the workstation 100 is used to scan a tag 22 mounted to a product 20. The NFC reader 120 requests the unique identifier 24 from the tag 22, and the tag 22 transmits the unique identifier 24 back to the NFC reader 120. Along with the unique identifier 24, the NFC tag 22 transmits the URL of the authentication server 70. The computing device 102 at the workstation 100 uses the URL to establish communication with the authentication server 70 and transmits the unique identifier 24 to the authentication server 70. After generating the authentication code 202, the authentication server 70 returns the authentication code (illustrated as Return RO) to the computing device 102. The computing device 102 then establishes communication with a blockchain manager and requests that the blockchain manager create an initial record 200 in the blockchain associating the tag 22 with the authentication code. Upon adding the initial record 200 to the blockchain, the blockchain manager returns an acknowledgement to the computing device. An exemplary initial record 200 is illustrated in FIG. 8 . It is contemplated that the records present in the initial record 200 may vary according to the requirements of the manufacturer. An initial record, RO, will include the authentication code 202. The remaining records may vary. According to the illustrated embodiment, the additional records may include a manufacturer record 204, identifying the manufacturer of the product 20; a Product ID record, identifying a manufacturer's name, model, or the like defining the product 20 in which the tag 22 is mounted; and a serial number record, including a serial number for the product 20. Other records may include, but are not limited, to a version number, date of manufacture, color, style, product options, or any other identifying information corresponding to the product 20. The blockchain manager uses the authentication code as an initial record, providing the unique fingerprint for the initial record 200, and for future identification of the record. The blockchain manager may be executing any one of the ledger nodes 60. The initial record 200 becomes an initial block corresponding to the tag 22 which was read by the NFC reader 120. This block is an immutable block written to the ledger 68 in the corresponding node 60. At periodic intervals a ledger node 60 will update each of the other ledger nodes of any changes in its ledger 68. The initial record 200, therefore, becomes written to each of the ledgers 68 in the distributed database.)
receiving the initial blockchain transaction identifier for the initial transaction, and (Anastas paragraphs 41-43 teaching after generating the authentication code 202, the authentication server 70 returns the authentication code (illustrated as Return RO) to the computing device 102. The computing device 102 then establishes communication with a blockchain manager and requests that the blockchain manager create an initial record 200 in the blockchain associating the tag 22 with the authentication code. Upon adding the initial record 200 to the blockchain, the blockchain manager returns an acknowledgement to the computing device. An exemplary initial record 200 is illustrated in FIG. 8 . It is contemplated that the records present in the initial record 200 may vary according to the requirements of the manufacturer. An initial record, RO, will include the authentication code 202. The remaining records may vary. According to the illustrated embodiment, the additional records may include a manufacturer record 204, identifying the manufacturer of the product 20; a Product ID record, identifying a manufacturer's name, model, or the like defining the product 20 in which the tag 22 is mounted; and a serial number record, including a serial number for the product 20. Other records may include, but are not limited, to a version number, date of manufacture, color, style, product options, or any other identifying information corresponding to the product 20. The blockchain manager uses the authentication code as an initial record, providing the unique fingerprint for the initial record 200, and for future identification of the record. The blockchain manager may be executing any one of the ledger nodes 60. The initial record 200 becomes an initial block corresponding to the tag 22 which was read by the NFC reader 120. This block is an immutable block written to the ledger 68 in the corresponding node 60. At periodic intervals a ledger node 60 will update each of the other ledger nodes of any changes in its ledger 68. The initial record 200, therefore, becomes written to each of the ledgers 68 in the distributed database.)
encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL). (Anastas paragraph 45 teaching having obtained the authentication code 202, the consumer is able to examiner the blockchain to determine whether an initial record 200 corresponding to the tag 22 the consumer just scanned was created by the manufacturer. According to one embodiment of the invention, it is contemplated that the authentication server 70 may be further configured to access the blockchain ledgers 68. As previously discussed, the URL stored on the tag 22 may be configured by the manufacturer. The manufacturer may provide an application to a consumer for execution on the mobile device 30 which guides the consumer through the steps in verifying authenticity of the product 20. …. Because this authentication code 202 is used as the unique signature to identify a block on the blockchain, the blockchain manager may read the record associated with the authentication code 202. The blockchain manager may read the other records or provide links to the other records for the mobile device 30 to retrieve the information. The mobile device 30 then receives the data from the other records R1-R3, associated with the authentication code 202, R0. The additional data may be presented on the display 40 of the mobile device. Based on the display of the data, the consumer has confidence that the manufacturer created the record and, in turn, the consumer has confidence that the product is authentic.)
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 manner of authenticating a product using a NFC tag and blockchain technology as taught in Bulawski to incorporate whereupon receiving the request, the blockchain records the unique product identifier on the blockchain in an initial transaction, generates an initial blockchain transaction identifier for the initial transaction, and transmits the initial blockchain transaction identifier for the initial transaction in response to the request, receiving the initial blockchain transaction identifier for the initial transaction, and encoding the near field communication tag with an initial tap-unique URL, wherein the initial tap-unique URL comprises the unique product identifier ((Claim 9) and whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, a web client operating on the proximity coupling device reads and opens the unique URL) as taught in Anastas with the motivation of enabling a manufacturer to create a URL that is incorporated in a initial block in addition of a blockchain for purposes of managing provenance and illustrating authenticity. (See Oliveira paragraphs 41-43 and 45)
Referring to claims 2 and 13,
Bulawski further teaches, whereupon, when the near field communication tag engages in a tap interaction with a proximity coupling device, (Bulawski paragraph 43 teaching the second user uses an NFC reader 105 external to the client computing device 102; in such an embodiment, the second user places the NFC tag 107 on the NFC reader 105. In another embodiment, the second user uses an NFC reader 105 embedded within or provided by the client computing device 102 (e.g., in an embodiment in which the client computing device 102 is a smartphone that includes an NFC reader 105); in such an embodiment, the user taps the NFC tag 107 with the smartphone 102.)
the tag generates a subsequent tap-unique URL on the tag, wherein the subsequent tap-unique URL comprises the unique product identifier, and (Bulawski paragraph 28 teaching the NFC tag 107 may include a software component. The NFC tag 107 may include a hardware component. The NFC tags may include both hardware and software. The NFC tag 107 may be provided as an NXP tag (e.g., chip type: NTAG 424 DNA). The NFC tag 107 may be encoded with a URL, version number, tag ID, and read counter, which may be used together with a securely stored, managed private key to generate a unique CMAC signature every time the chip is read. The tag ID of the NFC tag 107 and current read counter may be run through an AES-128 CMAC cipher (with a private key for a particular tag version (which is the same private key for every tag of that version) as the input key) to generate a session key. Then the entire URL (base URL, version, id, counter) is run through another round of AES-128 CMAC with the session key. The result of that calculation may be truncated and appended to the URL. The result is a unique response every time the tag is read. This ensures that the tag cannot be copied. When a tag is scanned, the backend module 103 performs the same operation and compares results. Only when they are equal and the read counter is within certain bounds, tag authenticity is confirmed. The version number may be a number of versions connected with a specific private key. The Tag ID may be the unique identifier of a particular tag. The tag private key may be AES-128 key, stored in inaccessible memory.
a web client operating on the proximity coupling device reads and opens the subsequent tap-unique URL. (Bulawski paragraph 28 teaching the NFC tag 107 may include a software component. The NFC tag 107 may include a hardware component. The NFC tags may include both hardware and software. The NFC tag 107 may be provided as an NXP tag (e.g., chip type: NTAG 424 DNA). The NFC tag 107 may be encoded with a URL, version number, tag ID, and read counter, which may be used together with a securely stored, managed private key to generate a unique CMAC signature every time the chip is read. The tag ID of the NFC tag 107 and current read counter may be run through an AES-128 CMAC cipher (with a private key for a particular tag version (which is the same private key for every tag of that version) as the input key) to generate a session key. Then the entire URL (base URL, version, id, counter) is run through another round of AES-128 CMAC with the session key. The result of that calculation may be truncated and appended to the URL. The result is a unique response every time the tag is read. This ensures that the tag cannot be copied. When a tag is scanned, the backend module 103 performs the same operation and compares results. Only when they are equal and the read counter is within certain bounds, tag authenticity is confirmed. The version number may be a number of versions connected with a specific private key. The Tag ID may be the unique identifier of a particular tag. The tag private key may be AES-128 key, stored in inaccessible memory. Bulawski paragraph 61 teaching In one embodiment, a first entity (such as, without limitation, a brand owner or an agent or representative of the brand owner, a producer, a manufacturer, or a retailer) may interact with the backend module 103 to generate a link (e.g., a URL) with which a user that is confirmed to own a specific product may access restricted content, such as access to a discount coupon or to a site that has product-related content only accessible to that specific user. For example, the link may include a code with which the system may determine that the user is associated with an indication of ownership and allow the user to access restricted content.)
Referring to claim 14,
Bulawski further teaches wherein the subsequent tap-unique URL further comprises a web host portion, a tag data, and an initial cryptographic output data. (Bulawski paragraph 28 teaching the NFC tag 107 may include a software component. The NFC tag 107 may include a hardware component. The NFC tags may include both hardware and software. The NFC tag 107 may be provided as an NXP tag (e.g., chip type: NTAG 424 DNA). The NFC tag 107 may be encoded with a URL, version number, tag ID, and read counter, which may be used together with a securely stored, managed private key to generate a unique CMAC signature every time the chip is read. The tag ID of the NFC tag 107 and current read counter may be run through an AES-128 CMAC cipher (with a private key for a particular tag version (which is the same private key for every tag of that version) as the input key) to generate a session key. Then the entire URL (base URL, version, id, counter) is run through another round of AES-128 CMAC with the session key. The result of that calculation may be truncated and appended to the URL. The result is a unique response every time the tag is read. This ensures that the tag cannot be copied. When a tag is scanned, the backend module 103 performs the same operation and compares results. Only when they are equal and the read counter is within certain bounds, tag authenticity is confirmed. The version number may be a number of versions connected with a specific private key. The Tag ID may be the unique identifier of a particular tag. The tag private key may be AES-128 key, stored in inaccessible memory.)
Referring to claim 15,
Bulawski further teaches wherein the tag data comprises a one or more of the following: a unique tag identifier, an interaction counter data and a tag tamper detection data. (Bulawski paragraph 28 teaching the NFC tag 107 may include a software component. The NFC tag 107 may include a hardware component. The NFC tags may include both hardware and software. The NFC tag 107 may be provided as an NXP tag (e.g., chip type: NTAG 424 DNA). The NFC tag 107 may be encoded with a URL, version number, tag ID, and read counter, which may be used together with a securely stored, managed private key to generate a unique CMAC signature every time the chip is read. The tag ID of the NFC tag 107 and current read counter may be run through an AES-128 CMAC cipher (with a private key for a particular tag version (which is the same private key for every tag of that version) as the input key) to generate a session key. Then the entire URL (base URL, version, id, counter) is run through another round of AES-128 CMAC with the session key. The result of that calculation may be truncated and appended to the URL. The result is a unique response every time the tag is read. This ensures that the tag cannot be copied. When a tag is scanned, the backend module 103 performs the same operation and compares results. Only when they are equal and the read counter is within certain bounds, tag authenticity is confirmed. The version number may be a number of versions connected with a specific private key. The Tag ID may be the unique identifier of a particular tag. The tag private key may be AES-128 key, stored in inaccessible memory.)
Claims 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bulawski et al. (US 20220284447) in view of Anastas et al. (US 20220398601) and Oliveira (US 20220036019).
Referring to claims 11 and 16,
Bulawski in view of Anastas does not teach, wherein the tag is a dual NFC/RFID tag.
However Oliveira, which is directed to an improved RFID system teaches wherein the tag is a dual NFC/RFID tag. (Oliveira paragraph 47 teaching FIG. 6 shows an example RFID system of the present invention utilising a tag for dual use NFC and RFID, where the tag is selectively useable as NFC tag (e.g. with mobile phones), but also as a “long distance” RFID tag (e.g. with HF readers for supply chain tracking). Oliveira paragraph 72 teaching the present invention provides for dual-use of NFC and other RFID protocol tags 102. An example might be the dual use of NFC and supply chain tracking. A dual NFC/supply chain tracking IC may therefore be only marginally more complex than any one of the other suitable IC's and may enable a tag 102 to work as an NFC tag with mobile phones (NFC reader), but also to work as a “long”-distance supply chain tracking tag when exposed to a suitable reader. So, the same tag 102 could then provide both customer engagement/authentication and stock control/management.)
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 manner of authenticating a product using a NFC tag and blockchain technology as taught in Bulawski in view of Anastas to incorporate wherein the tag is a dual NFC/RFID tag as taught in Oliveira with the motivation of modifying the NFC tag to incorporate additional functionality to support consumers and supply chain personnel. (See Oliveira paragraphs 47 and 72)
No Prior Art Applied
The Examiner finds that the identified prior art from the performed search fails to disclose or teach at least the limitations of claims 3, 10, and 17: whereupon, based on the initial blockchain transaction identifier, sending a subsequent request to the blockchain to record the one or more tap interaction data generated from the tap interaction, and whereupon receiving the subsequent request, the blockchain records the one or more tap interaction data on the blockchain in a subsequent transaction, generates a subsequent blockchain transaction identifier for the subsequent transaction.
The other identified prior art is as follows:
Sun et al. (US 20220405770) - directed to verifying merchandise authenticity. Sun paragraph 49 teaching producers 101B will first register with the system 100 and provide information on one or more merchandise instances 107 that they desire to be capable of having its authenticity verified. Once registered, producers 101B will be able to register an instance identification code for each merchandise instance 107, such as which may be encoded in a merchandise tag 108. Merchandise tag 108 may comprise a barcode, Quick Response (QR) code, Near-field communication (NFC) tag, Radio Frequency Identification (RFID) tag, etc., that may encode an instance identification code unique to a merchandise instance 107. Each merchandise instance manufactured by a producer 101B may have a merchandise tag 108 attached to it, attached to its packaging, or otherwise coupled together. Each instance identification code may be entered into a system database 120, by using a producer application 142 (FIGS. 4 and 6), as an instance identification code 123. Consumers 101A, preferably once having purchased a merchandise instance 107, will be able to use a consumer application 141 (FIGS. 4 and 6) to verify the authenticity of the merchandise instance 107 using system 100 generated hash outputs that may be stored in a blockchain database 113 (FIGS. 4 and 6). In some embodiments, the system 100 may verify the authenticity of a merchandise instance 107 by outputting information to the consumer 101A that bought the merchandise instance 107 that describes the merchandise instance 107 as being authentic, being counterfeit (not authentic), or as being authentic but that the consumer 101A is not the first owner of the merchandise instance 107 (the merchandise instance is secondhand 107). Sun paragraph 76 teaching an instance identification code 123 data record may comprise an alphanumeric string which may be unique to a specific merchandise instance. For example, an instance identification code 123 data record may comprise a serial number of the merchandise instance 107 described by a particular merchandise instance 122 data record. Each merchandise tag 108 used by the system 100 may encode the data in an instance identification code 123 data record. In preferred embodiments, each registered merchandise instance 107 may comprise a seal which may be created or formed by the manufacturer 101B prior to the merchandise instance 107 leaving the manufacturer 101B and which may prevent access to the merchandise tag 108 and its instance identification code of a respective merchandise instance 107. For example, a registered merchandise instance 107 may comprise a shrink wrap or bubble packaging seal which may prevent the reading of the instance identification code of its merchandise tag 108 by a consumer client device 400A until the seal is broken. Sun paragraphs 80-82 teaching a first hash output 127 data record may comprise the output of a hash function that may be performed using the instance identification code 123, merchandise descriptor 124, and manufacturer wallet address 125 data records of a merchandise instance 122 data record. The first hash output 127 data record may be stored in a blockchain database 113 of a blockchain network 111 and optionally in the system database 120. Any suitable hash function may be used to generate the first hash output 127, such as MD5 (MD5CryptoServiceProvider with hash length of 128 bits, SHA-1 with hash length of 160 bits, SHA-256 with hash length of 256 bits, SHA-384 with hash length of 384 bits, SHA-512 with hash length of 512 bits, etc. In preferred embodiments, the first hash output 127 may be generated using a hash function that provides at least a 128 bit output. In further preferred embodiments, the first hash output 127 may be generated using a SHA-256 hash function. A second hash output 128 data record may comprise the output of a hash function that may be performed using the instance identification code 123, merchandise descriptor 124, and manufacturer wallet address 125 data records of a merchandise instance 122 data record using an instance identification code stored in a merchandise tag 108 received from a consumer client device 400A. The second hash output 128 data record may be stored in a blockchain database 113 of a blockchain network 111 and optionally in the system database 120. Any suitable hash function may be used to generate the second hash output 128. In preferred embodiments, the second hash output 128 may be generated using a hash function that provides at least a 128 bit output. In further preferred embodiments, the second hash output 128 may be generated using a SHA-256 hash function. A third hash output 129 data record may comprise the output of a hash function that may be performed using the instance identification code 123, merchandise descriptor 124, and consumer wallet address 126 data records of a merchandise instance 122 data record. In preferred embodiments, a third hash output 129 data record may comprise a third hash output for each owner of a merchandise instance having a merchandise instance 122 data record. The third hash output 129 data record may be stored in a blockchain database 113 of a blockchain network 111 and optionally in the system database 120. Any suitable hash function may be used to generate a third hash output 129. In preferred embodiments, a third hash output 129 may be generated using a hash function that provides at least a 128 bit output. In further preferred embodiments, a third hash output 129 may be generated using a SHA-256 hash function. Sun paragraph 84 teaching preferably, information of a consumer metrics 131 data record may comprise information about the first ownership of the merchandise instance, such as a time stamp (such as which may describe the time and date that a third hash 129 was generated, which may describe the time and date that a third hash 129 was stored in the blockchain 113, etc.) of one or more third hash functions, which can provide valuable information about the sale progression of the merchandise type/merchandise instance, and this information together with other analytics may be provided to one or more producers 101B to provide manufacturer insights on the timing and popularity of their product among consumers 101A. As an example, if a third hash output for a merchandise instance 107 is not found in the blockchain 113 (and the first and second hash outputs match), an authenticity output 130 may describe that the merchandise instance 107 is authentic and brand-new, and the third hash output is registered in the blockchain 113. The next time the merchandise tag 108 is scanned the authenticity output 130 will describe that the merchandise instance 107 is no longer brand-new. By scanning the time stamp when third hash output is registered in the blockchain 113, the time stamp generally describes the time the merchandise instance 107 was sold.
Larsson et al. (US 20240160868) – directed to authenticating an assets having an NFC tag. Larsson paragraphs 26-29 teaching FIG. 1 is a schematic illustration of an authentication system 100 for authenticating an asset 200. The asset 200 may be consumer products, or any other manufactured item to be reliably identified, such as machine parts, building parts etc. The asset 200 has an associated Near Field Communication NFC tag 201. The NFC tag 201 is referred to as a tag 201 in the disclosure for brevity. The asset 200 may be formed by additive manufacturing, such as by 3D printing, where layer upon layer of material sequentially added to form the 3D object. The asset 200 may be a 3D printed device with the NFC tag 201 embedded in the printed material of the asset 200. The tag 201 may thus be integrated and hidden inside the asset 200 in some examples of the disclosure. The authentication system 100 comprises an authentication server 101 as schematically shown in FIG. 1 . The authentication system 100 comprises a controller 102 in communication with the authentication server 101 and an NFC enabled device 300. The NFC enabled device 300 may communicate wirelessly with the authentication server 101 via the controller 102. The NFC enabled device 300 is configured to read and write data to a memory 202 of the tag 201. The NFC enabled device 300 may be an NFC enabled smartphone or tablet in one example. The controller 102 is configured to request reading of a tag identification number (ID) from the memory 202 of the tag 201, when an NFC connection is established between the NFC enabled device 300 and the tag 201. The tag identification number (ID) is referred to as the tag ID in the disclosure for brevity. The controller 102 is configured to generate a tag record 103 of the tag 201 on the authentication server 101, so that the tag record 103 is associated with the tag ID. FIG. 2 a is a schematic illustration of the tag ID being read from the memory 202 by the NFC enabled device 300, and the tag record 103 associated with the tag ID being generated, via the controller 102. The controller 102 is configured to generate a token (TS) corresponding to the NFC tag 201. The token (TS) is generated by an algorithm 104 based on the tag ID which has been read from the tag 201. The controller 102 may be configured to instruct the algorithm 104 to generate the token (TS), and the algorithm 104 may run on the authentication server 101 in one example. The algorithm 104 receives the token ID as input, comprising a plurality of characters, such as a plurality of numbers, letters, and/or symbols, and generates the token (TS) as output, which is a different set of characters, such as a plurality of numbers, letters, and/or symbols. The token (TS) may comprise at least 32 characters in one example. The token (TS) can be generated based on a rule set defined in the algorithm 104. The algorithm 104 may comprise an encryption algorithm. The controller 102 is configured to request writing of the token (TS) to the memory 202 of the tag 201, when an NFC connection is established between the NFC enabled device 300 and the tag 201. FIG. 2 b is a schematic illustration of the generated token (TS) being communicated to the NFC enabled device 300 and written to the memory 202 via the controller 102. The tag 201 may be locked from further writing to the memory 202 thereof. The controller 102 is configured to associate the token (TS) with the tag ID in the tag record 103 of the tag 201. The token (TS) is thus also stored in the tag record 103 of the tag 201, as schematically indicated in FIG. 2 b . The tag 201 has thus been assigned a new digital identity with the token (TS) which uniquely links the tag 201 of the asset 200 with the corresponding tag record 103 in the authentication server 101, in a highly efficient, robust and secure manner. A user may thus subsequently validate the authenticity of the asset 200. The controller 102 is configured, upon such authentication, to request reading the token (TS) from the memory 202, such as by the NFC enabled device 300 or another user device 301, as schematically indicated in FIG. 1 . The user device 301 may be configured for NFC read-only communication. Hence, in one example, the token (TS) may be generated and stored as described above via the NFC enabled device 300 by a manufacturer, while the subsequent check of the authenticity may be done by a consumer having user device 301, such as an NFC enabled smartphone or tablet. A consumer or other end user may need to be assigned the required user rights to be enabled to validate the authenticity of the asset 200. FIG. 2 c is a schematic illustration of the token (TS) being read from the memory 202 of the tag 201 by any of the aforementioned NFC enabled devices 300, 301. The token (TS) being read from the memory 202 is communicated to the controller 102. The controller 102 is configured to verify the token (TS) read from memory 202 against the tag record 103 for the tag ID of the tag 201. The controller 102 is thus configured to verify the token (TS) comprising comparing said token (TS), received from the memory 202 of the tag 201, with the associated token (TS) stored in the tag record 103 on the authentication server 101 under the tag ID of the tag 201, as schematically indicated in FIG. 2 c . The authentication server 101 may store a plurality (n) of tag records 103 . . . 103 n, associated with a respective plurality of tags 201 and their respective tag ID (ID . . . IDn). Each tag record 103 n, may thus store a corresponding token TSn, associated with the tag ID (IDn). Generating a unique token (TS) as described above based on the tag ID for verification at an authentication server 101 allows for a manufacturer or other user to label the asset 200 with a unique identity irrespectively of what particular serial number, i.e. tag ID, the NFC tag 201 may have. Larsson paragraphs 31-34 teaching the controller 102 may be configured to generate a tag URL for the NFC tag 201 based on the tag ID. FIG. 3 a is a schematic illustration of the tag ID being read from the memory 202 of the tag 201, and the URL being generated based on the tag ID, via the controller 102. The controller 102 may be configured to instruct an algorithm 104 to generate the tag URL and the algorithm 104 may run on the authentication server 101 in one example. The algorithm 104 may generate the tag URL and the token (TS) as described above. It should be understood however that the tag URL may be generated according to a different rule set, and thus by a separate algorithm, although indicated with the same reference numeral 104 in the example of FIG. 3 a as in the examples described with reference to FIGS. 2 a -c. The controller 102 may be configured to request writing of the tag URL to the memory 202 of the tag 201, when an NFC connection is established between the NFC enabled device 300 and the tag 201. FIG. 3 b is a schematic illustration of the generated tag URL being communicated to the NFC enabled device 300 and written to the memory 202 via the controller 102. The memory 202 may accordingly store both the token (TS) as described above and the tag URL. The controller 102 may be configured to associate the tag URL with the tag ID in the tag record 103 of the tag 201, as schematically indicated in FIG. 3 b . A user having an NFC enabled device 301 may accordingly be directed to the URL as defined in the tag URL when reading the tag 201, as schematically illustrated in FIG. 1 . The aforementioned URL and associated data downloadable by the user of device 301 may be managed via the authentication server 101 and the controller 102, e.g. via an interface on the NFC enabled device 300 (FIG. 1 ) which may be controlled by the manufacturer. The manufacturer may thus continuously monitor and manage the content of the URL accessed by the user device 301, e.g. to keep product information of the authenticated asset 200 up to date or to provide other customized product services to an end user throughout the product life cycle. Having the tag URL generated based on the tag ID provides for further validation of the asset 200. For example, as a user proceeds to validate the asset 200, the controller 102 may be configured to request reading the tag URL from the memory 202, such as by any of the user devices 300, 301, described above, and verify the tag URL against the tag ID stored on the memory 202 of the tag 201. The tag 201 is validated as being authentic if the tag URL matches the tag ID, e.g. as defined by the rule set by which the tag URL has been originally generated as described above in relation to FIG. 3 a . FIG. 3 c is a schematic illustration of the tag URL being read from the memory 202 and checked against the tag record 103 for the particular tag 201 and its associated tag ID. It is conceivable however that in one example the tag URL which is read from the memory 202 of the tag 201 is checked directly against the tag ID which is also stored on the memory 202 of the tag 201, without having to cross-check with the tag record 103. As the tag URL has been validated as authentic the controller 102 may be configured to proceed further with the authentication of the tag 201 by comparing the token (TS) stored on the memory 202 with the token (TS) stored on the tag record 103 for the particular tag 201, as described above in relation to FIGS. 2 a-c . This provides for a particularly efficient and robust validation of the asset 200. The controller 102 may be configured to direct the user device 301 to the tag URL upon having determined that the asset 200 is authentic. For example, once a user has scanned the tag 201 with the user device 301, such as by a mobile phone, and the asset 200 has been determined as being authentic based on the validation of the token (TS) as described above in relation to FIGS. 2 a-c , and in some examples in combination with the validation of the tag URL as described in relation to FIGS. 3 a-c , the user may be directed to the URL as defined by the tag URL. Content on a connected server resource, such as the authentication server 101, associated with the URL may be downloaded on the user device 301. It is conceivable that the user is directed to an alternative URL informing the user that the asset 200 is not authentic if the authentication fails.
McKenzie et al. (US 20210248653) – directed to authenticating products. McKenzie paragraphs 20-25 teaching 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. 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. 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. 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. Each additional ownership transfer of the product can include a fee back to the original authenticator or authenticators paid for by the buyer, the seller, or both (e.g., one dollar, five dollars, ten percent of the cost to purchase the product, twenty percent of the cost to purchase the product, tokens, points, and so on). Thus, the product authentication system expands the authentication services through the lifespan of the authenticated product. The product authentication system includes several components for managing and verifying authentications, including a product authentication blockchain, tagging hardware and software, a scanner application, and/or cryptography and encryption. In some embodiments, the product authentication blockchain manages digital identities and NFC tags, maintains records of ownership of products, manages fees payments for transfer of ownership and product purchase through smart contracts, manages and authenticates buyers and sellers' identities, manages messaging system to log offers from potential buyers, manages and keeps record of products within a virtual marketplace or selling/trading platform, logs stolen, lost, and/or tampered-with products, etc. The tagging hardware and software can include any type of smart tags and related tagging software, including tags described in U.S. Provisional Patent Application No. 63/125,893, NFC tags with Secure Unique NFC (SUN) mechanisms, such as SMARTRAC's CIRCUS PRO (equipped with NXP's NTAG 424 DNA), etc. The scanner application is a mobile application in communication with the product authentication system that reads NFC tags and serves as an interface between resellers, buyers, sellers, products, and the blockchain. Users of the product authentication system can use the application to authenticate and verify products, transfer ownership of products, connect to buyers and sellers of products through, for example, a messaging component, view products, flag products as stolen, personalized experiences can be displayed through a scan of the tag on the product, and products can be automatically uploaded to the online marketplace through scanning or tapping the NFC tag. The product authentication uses cryptography and encryption for messaging, authentication of products, authentication of buyers, authentication of sellers, transaction settlement on the blockchain, NFC tag communication, and so on. 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. 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. It also reduces authentication costs as the items are already identified and can be automatically authenticated once they re-enter the market. One of ordinary skill in the art will recognize that physical tags can be attached to products using any number of means for attaching including, for example, adhesives, sewing, stitching, gluing, ironing on, tying, buttoning, fastening, pinning, injecting, embedding, welding, stamping, silk screening, molding, screwing, nailing, and so on. The product authentication system provides features that make it easier for buyers to learn about products and for sellers to make their product available. By scanning a tag associated with a product a potential buyer can trigger the product authentication system to send relevant information about the product, including virtual experiences involving the product. For example, scanning a physical tag associated with a hand bag using, for example, a scanner application installed on a mobile device computing system may prompt a user to select from among any number of virtual opportunities, such as a live (or pre-recorded) virtual fashion show of the brand, and so on. Alternatively, by scanning a tag associated with a product a seller can be prompted with an easy to use interface for making their product available for sale in a marketplace, such as a form that allows the user to enter a price for the product, a picture of the product, a description of the product, and so on. Once this information is provided, the scanner application can provide this information to the product authentication system so that the product can be made available for purchase. McKenzie paragraph 32 teaching FIG. 2 is a flow diagram illustrating the steps of an initial authentication component in accordance with some embodiments of the disclosed technology. The steps facilitate authentication of a product in one or more categories and register the authenticated product with the product authentication system. In block 210, the product is sent to an authenticator for authentication. In block 220, the authenticator attempts to authenticate the product. For example, the authenticator may determine that the product was manufactured by a particular manufacturer, is composed of genuine materials (e.g., genuine leather), is certified by a particular certification authority (e.g., a sustainability certification), and so on. In decision block 230, if the authenticator verifies that the product is authentic, then the component continues at block 240, else the component completes. 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.
Mulas et al. (US 20230031817) - directed to authenticating and certifying a physical item. Mulas paragraph 21 teaching in order to ensure that the aims of the invention are achieved, each jersey is uniquely identified both in the physical and in the digital world. To do this, an identification tag, for example a radio-frequency readable tag, and a graphic identification code of the item or an identification code of the item stored electronically according to a predetermined format, for example an NDEF format, is associated with the jersey. The identification tag is expediently a radio-frequency readable RFID tag coupled to a heat-pressable patch, and even more advantageously, instead of the identification tag, is an identification tag assembly comprising a combination of an RFID tag and an NFC tag, wherein one safeguards the authentication code of the other. The patch may be, for example, a patch of a certifying body or company inserted inside the jersey. The graphic identification code of the jersey is, for example, a barcode such as a two-dimensional barcode or QR code which, for example by means of a link generated by a computer system, represents at least part of the identifier code (serial code) programmed in the RFID tag or in the identification tag assembly. In a step during which the jerseys are prepared before the event, the patches to which the identification tag or the identification tag assembly is coupled are inserted into the jersey, and each jersey, the relative patch and the event in question are uniquely associated and recorded, for example by means of an application. Moreover, a corresponding non-funigble token (NFT) is created in a digital register distributed in a plurality of nodes of a public or private processor network (hereinafter in blockchain), for example a token produced according to the ERC721 standard, for example on the Ethereum blockchain platform, which token is adapted to store at least the identifier code of the tag and possibly data or information that are representative of the item with which the tag is associated, including public data and cryptographic private data. Lastly, on the way out of the tunnel that leads from the changing rooms to the field entrance, through which tunnel the players who are preparing to play the match have to pass, a barrier for detecting the RFID tags or the identification tag assembly on each jersey is installed, and associated processing means are provided in order to detect the presence of the recognized jersey by reading the relevant identifier code and to record the jersey entering the field (and therefore classify said jersey as a “match worn” jersey) in the corresponding token. The presence of the jersey is detected by means of a geolocalized and non-manipulable reader. Mulas paragraphs 71-81 teaching in step 100, the unique code of the item, or serial code, GUID, is generated by the remote processing system S, i.e. by the web platform of an entity that owns the authentication and certification system, and is intended to be associated with a single identification tag; said code may be revoked if the item is destroyed or if the item is removed from the platform, and may no longer be reused. This serial code also constitutes an identification code of the item for subsequent searching through user interface computer environments by constructing a URL (Uniform Resource Locator) that contains it. The URL is indelibly marked on the item by means of appropriate marking methods that allow it to be optically read (if it is marked in a barcode, QR code or similar) or is included in a predetermined digital format, for example the NDEF format (NFC Data Exchange Format), in a microcircuit for remote reading, for example via NFC protocol. In step 200, two methods for initializing the identification tag are possible, according to currently preferred alternative embodiments. A first possible initialization method involves pre-assigning the GUID. In step 200, the identification tag integrated in the item to be traced is labelled by a unique code, UID, consisting of a non-modifiable and proprietary part of the tag, the identifier TID, and a second part containing a code MINIGUID uniquely paired with the identification tag. During the initialization step, the identifier TID and the code MINIGUID are read by a unique code of the item, or serial code, GUID, which represents its guarantee of authenticity. The MINIGUID is written on the tag, for example by means of an RFID or NFC writing system if the tag is provided with an active/passive electronic microcircuit that is readable using one of the aforementioned protocols, and the tag is subsequently locked by means of a randomly generated access password or by irreversibly configuring the write lock parameters, thus preventing the tag from being reprogrammed. The identifier TID of the tag is read by an RFID/NFC reader device and sent to the remote processing system S in order to verify the presence of the tag data. If this is the case, the remote system S responds by communicating the code MINIGUID to be programmed inside the identification tag and the code GUID to be included in the optical identification system (for example QR code), which is then printed. The remote system S unmarks the tag as “processed.” The QR code is subsequently paired to the jersey J by means of the remote processing system S. The code MINIGUID of the tag is not used by the remote processing system S for the functionalities offered to a user, but may be used for counterchecking if there are disputes over the authenticity of the item associated with the tag. At the end of the initialization method, there are the following elements: identification tag comprising unique code UID composed of the tag identifier TID and the unique code MINIGUID; an optical or NFC reading element which represents a URL containing the unique code of the tag GUID; and an entry in the database DB maintained by the remote processing system S that associates the unique code of the tag GUID and the code MINGUID with the identifier TID. In the currently preferred embodiment in which the patch is associated with an identification tag assembly comprising both an RFID microcircuit and an NFC microcircuit, the following NFC tag writing operations are performed to ascertain the authenticity of said tag. An encrypted, password-protected and non-clonable message is written into the NFC microcircuit. Mulas paragraphs 86 teaching a registered operator of the sports club, by means of an application, reads the NFC tag and checks whether or not the tag has already been initialized. If the tag has not been initialized, the application makes a call to a backend system of the authentication and certification system by passing the serial code of the tag to said system. The backend system takes a first private key and concatenates the serial code of the tag to the key, and then hashes the result, and the resulting hash is the AppMasterKey of that tag. Then, the backend system takes the second private key and concatenates the serial code of the tag to the key, and then hashes the result, and the resulting hash is the AppKey. The backend system takes the serial code of the tag and concatenates a “GENUINO” (constant) string thereto. This is the content to be inserted into the tag, encrypted using the previously generated AppKey. Mulas paragraphs 92-100 teaching in step 200, the identification tag integrated in the item to be traced is labelled by a unique code, UID, consisting of a non-modifiable and proprietary part of the tag, the identifier TID, and a second part containing a code MINIGUID uniquely paired with the identification tag. During the initialization step, the identifier TID and the code MINIGUID are read by a unique code of the item, or serial code, GUID, which represents its guarantee of authenticity. The MINIGUID is written on the tag, for example by means of an RFID or NFC writing system if the tag is provided with an active/passive electronic microcircuit that is readable using one of the aforementioned protocols, and the tag is subsequently locked by means of a randomly generated access password or by irreversibly configuring the write lock parameters, thus preventing the tag from being reprogrammed. The identifier TID of the tag is read by an RFID/NFC reader device and sent to the remote processing system S in order to verify the presence of the tag data. If this is the case, the remote system S responds by communicating the code MINIGUID to be programmed inside the identification tag. Using an optical reader, a local system reads the URL contained in a QR code from said QR code, extracting therefrom a previously printed code GUID. The extracted code and the identifier TID are sent to the remote system S which uniquely pairs them. The code MINIGUID of the tag is not used by the remote processing system S for the functionalities offered to a user, but may be used for counterchecking if there are disputes over the authenticity of the item associated with the tag. At the end of the initialization method, there are the following elements: identification tag comprising unique code UID composed of the tag identifier TID and the unique code MINIGUID; an optical or NFC reading element which represents a URL containing the unique code of the tag GUID; and an entry in the database DB maintained by the remote processing system S that associates the unique code of the tag GUID and the code MINGUID with the identifier TID. Step 300 includes physically applying the previously prepared tag to the item and, by means of a computer system, the unique code of the tag is linked to the unique code of the item to be traced. In step 400, the item thus identified and connected to the relative tag is generated in digital format on blockchain (token) with a further unique, non-modifiable identification code of the relative digital identity. Additional process information may be linked to this digital identity. The token contains any other serial codes of the components of the item, thus becoming a digital twin of the physical item in question. In step 500, the item recorded in blockchain is automatically paired to the manufacturer of the physical item, who holds initial ownership thereof.
Levy et al. (US 20200184162) - directed to tracking and authentication of products via distributed ledgers and NFC tags. Levy paragraphs 40-42 teaching in particular, a product 105A—which in FIG. 1A appears as an automobile vehicle 110A—includes an NFC tag 110A. The NFC tag 110A may be, for example, embedded in a portion of the vehicle 105A, such as along the dashboard, or on an exterior or interior surface of a door. The user device 120A, which in most cases is a computing device 800, communicates with the NFC tag 110A via one or more short-range wireless signals 115A. The user device 120A may provide electrical power wirelessly to the NFC tag 110A, in response to which the NFC tag 110A conveys data/information to the user device 120A via NFC signals 115A. For example, the NFC tag 110A can provide the user device 120A with a code that the user device 120A would otherwise not know. The code may be a unique identifier corresponding to that particular NFC tag 110A. The NFC tag 110A can alternately or additionally provide the user device 120A with an address or other information identifying or pointing to a particular distributed ledger 130A in a way that makes the particular distributed ledger 130A accessible. While the code may store information about characteristics of the object, memory of NFC tags may sometimes be hardcoded and immutable or difficult to change. Thus, information that may change over time, such as ownership of the vehicle 105A, is better stored externally from the NFC tag 110A, such as via the distributed ledger 130A. The user device 120A can use the address or identifier identifying the distributed ledger 130A provided by the NFC tag 110A to access the distributed ledger 130A, copies of which are stored at each device of a distributed architecture 125A having multiple computing devices 800. As illustrated in FIG. 1A, the information identifying the product 105A as a “X200 Luxury Sedan” is conveyed to the user device 120A either encoded directly in the wireless signals 115A, in the distributed ledger 130A, or both. The distributed ledger 130A stores information keeping track of the ownership history of the vehicle 105A. The ownership history illustrated in FIG. 1A identifies that the vehicle 105A was owned by Avery (who paid $3400 for the vehicle 105A) from 1994 to 2001, was owned by Bob (who paid $2900 for the vehicle 105A) from 2001 to 2009, and was owned by Chuck (who paid $1800 for the vehicle 105A) from 2009 to 2018. The user device 110A reads and parses this ownership history from the distributed ledger(s) 130A, then displays this ownership history. Levy paragraph 49 teaching in the case where the product 105 is a vehicle 105A as in FIG. 1A, or where the product 105 is another structure with doors like a building (not pictured), the NFC tag 110A may be reachable from the exterior of the product 105 and may be electrically connected to circuitry of the product 105 in a way that makes it necessary to interact with the NFC tag 110A for a new user to open doors the product 105, and can even in some cases make it necessary for a user device 120A to provide confirmation to the NFC tag 110A (especially when the NFC tag 110A is an active NFC device) that it is the user device 120A of the current owner of the product 105 as identified in the distributed ledger 130A. This can be done by the user device 120A encrypting data, such as the code from the NFC tag 110A, using its private key, and sending the encrypted data to the NFC tag 110A to decrypt using the public key to confirm identity. Levy paragraph 79 teaching the distributed architecture 125 illustrated in FIG. 2A includes various computing devices 800 that each optionally store copies of various distributed ledger(s) 130, each of which may on occasion request transactions to be added to the distributed ledger(s) 130, verify requested transactions for the distributed ledger(s) 130, generate new blocks that each store one or more verified transactions for the distributed ledger(s) 130, append new blocks to the distributed ledger(s) 130, distribute new blocks to the other computing devices 800 of the distributed architecture 125, or combinations thereof. Each of these computing devices 800 of the distributed architecture 125 may also be referred to as a user device 120 corresponding to a particular user or type of user. Levy paragraphs 85-86 teaching the customer user device 240 may include an NFC reader. A product 105 or object 105 with an NFC tag 110, which may be collectively referred as a product 260 or object 260, may include NFC Manufacturing URL Data—that is, an address (e.g., Uniform Resource Locator or URL or another type of hyperlink or pointer) of one or more distributed ledger(s) 130 relevant to the object 260—and may also include an NFC customer code or NFC code as discussed above. The distributed architecture may optionally also include one or more computing devices 800 referred to as an upsell security network 255, which may store information about groupings of related products (see e.g., FIG. 1F) and which may include an Upsell Security Database, an Ordering Website Protection Module, a Retail Protection Module, and a Comm Portal. The distributed ledger(s) 130 themselves may each include or correspond to blockchain data (e.g., headers and transactions), pre-mined tokens (e.g., cryptocurrency as discussed in step 730 of FIG. 7A), and a blockchain security module for using the distributed ledger(s) 130 as a way to securely store information about the transactions discussed herein. Levy paragraph 91 teaching each block 305/335/365 of the blockchain 300 also includes a list of one or more transaction(s) 330/360/390. Each of these transactions 330/360/390 may be identified in a similar matter to the transactions 410 or 425 of FIG. 4A and FIG. 4B. These transactions may convey information corresponding to, for example, an ownership history as in FIG. 1A, a shipping history as in FIG. 1B, a manufacturing history as in FIG. 1C, a distribution history as in FIG. 1D, a history of user purchases of related products as in FIG. 1E, an item usage history as in FIG. 1F, a location/position history as in FIG. 1G, other characteristics or conditions of a product/object/item 105 that change over time, or combinations thereof. Levy paragraphs 108-109 teaching while FIG. 3, FIG. 7A, and FIG. 7B discuss use of a blockchain ledger, it should be understood that a non-linear ledger structure, such as the directed acyclic graph (DAG) ledger structure of FIG. 6, may be used instead of a blockchain ledger discussed herein. That is, the term “distributed ledger” as used herein should be understood to refer to at least one of a blockchain ledger (as in FIG. 3), a DAG ledger (as in FIG. 6), or a combination thereof. In a DAG ledger, each block header includes the hashes of block headers of a predetermined number of other “parent” blocks in the DAG ledger selected either at random or in some other non-linear manner, rather than the hash of a single previous block in the blockchain. Each block header may alternately or additionally include hashes of the entire parent blocks instead of hashes of just the headers of the parent blocks. Where each block header includes multiple hashes corresponding to different parent blocks or their headers, these hashes can be combined together into a Merkle root much like the hashes A 518, B 520, C 522, D 524, E 526, F 528, G 530, and H 532 of FIG. 5. For example, in the DAG ledger of FIG. 6, the predetermined number is two, at least after the first two blocks are generated. In the web DAG ledger of FIG. 6, the parent blocks are indicated using arrows. Block 610 includes hashes of the block headers of parent blocks 620 and 650. Block 620 includes hashes of the block headers of parent blocks 640 and 660. Block 630 includes hashes of the block headers of parent blocks 620 and 660. Block 640 includes hashes of the block headers of parent blocks 610 and 630. Block 650 includes hashes of the block headers of parent blocks 610 and 620. Block 660 includes hashes of the block headers of parent blocks 610 and 650. The resulting structure is a directed acyclic graph (DAG) of blocks, where each vertex block includes a hash of its parent vertex block(s), rather than a linear stream of blocks as in a blockchain. A DAG ledger may sometimes be referred to as a “web,” a “tangle,” or a “hashgraph.” Levy paragraph 147 teaching step 910 includes receiving, from a first computing device, an indication of proximity (e.g., NFC communications 115) between the first computing device and the object (e.g., product 105 with NFC tag 110), wherein the indication of proximity between the first computing device (e.g., user device 120) and the object also identifies a characteristic or a condition of the object (e.g., unfinished, finished, stage of manufacture, stage of distribution, stage along a supply chain, location, shipping status, delivery status, unsold status, sold status, current or previous ownership, related products, sales of related products, sales of the object itself). Step 910 may also optionally involve receipt of one or more intended transactions as in step 705 of FIG. 7A. The indication of proximity, the intended transactions, or both may be encrypted using a private key associated with the first computing device and/or with a user of the first computing device as in step 710 of FIG. 7A. These may be decrypted with a corresponding public key in step 915 as part of the verification processes, as also discussed with respect to step 720 of FIG. 7A, as well as with respect to FIGS. 1A-1G.
Dattawadkar (US 20200045538) - directed to techniques for verifying the authenticity an item. Dattawadkar paragraphs 49-50 teaching the authenticity infrastructure may include one or more computing systems communicatively coupled to each other via one or more communication networks. The authenticity infrastructure may store information about items and this information is used to perform the authenticity verification. For example, information regarding the items may be stored in one or more databases accessible to computing systems within the authenticity infrastructure. The authenticity infrastructure can thus store information that can be queried by a user to determine the authenticity of an item. The authenticity infrastructure enables information related to items whose authenticity can be verified to be stored and tracked in a distributed and secure manner. The item-related information is stored by the authenticity infrastructure in a manner that makes it difficult to be hacked or changed. For example, certain embodiments involve generating a cryptographic hash based on details of a transaction and storing the cryptograph hash in a record created for the transaction so that alterations in the recorded details of the transaction can be detected using the hash. In some embodiments, a unique code is stored in association with a product identifier by a trusted entity and an item is deemed authentic only if the same unique code is also stored in associated with the product identifier in a database associated with a retailer. Accordingly to a typical use case, a user may, prior to the purchase of a particular item, send a request to the authenticity infrastructure to determine the authenticity of the item. The authenticity infrastructure may then, based upon the stored information, respond to the user's request with authenticity information that is indicative of the item's authenticity. In some embodiments, the authenticity information may include an authenticity certificate as proof that the authenticity of the item has been successfully verified by the authenticity infrastructure. Dattawadkar paragraph 60 teaching registry 109 is further configured to store information about items whose authenticity is verifiable using the authenticity infrastructure. In certain embodiments, in order for the authenticity verification functionality to be provided by the authenticity infrastructure for an item, the item is first registered with the authenticity system 102. As part of the item registration process, information about the item (e.g., a product identifier, a product description, and/or other product attributes) is communicated to the authenticity system 102 for storage in registry 109. The item information can be supplied by the item manufacturer. An example of item registration is depicted in FIG. 28 and involves storage of a product identifier and, optionally, a unique code generated for the item or a class of items (e.g., a batch of the same type of product). Dattawadkar paragraph 63 teaching in general, information stored in any of the databases 108 for a transaction involving an item may include information identifying the participants in the transaction (e.g., name, location and/or country), information identifying the item (e.g., product identifier, serial number, and/or batch number), a date and/or timestamp for the transaction, and other transaction related information. Additionally, in some embodiments, each transaction record may include a cryptographic hash generated based on details of the transaction (e.g., a timestamp of when the transaction was executed, a serial number of the item, and/or other transaction information). Because the hash is generated based on details of the transaction, attempts to alter the recorded details of the transaction can be detected by, for example, regenerating the hash using the same algorithm and comparing the regenerated hash to the hash in the transaction record. If the hashes do not match, this indicates that the record has been altered. Further, in some embodiments, each participant may be issued a digital certificate with which a transaction record for a transaction involving that participant is signed. For example, a record for sale of an item from a distributor to a retailer may be signed by the distributor and the retailer (and optionally, the manufacturer) as proof that the transaction was authorized or accepted by the distributor and the retailer.)
Hanis et al. (US 20180189528) -directed to tracking assets with a blockchain. Hanis paragraphs 14-22 teaching example embodiments provide storing asset information in a blockchain, to storing asset status information in a blockchain and requiring certain security measures prior to permitting asset status modifications. Further embodiments include using a blockchain public ledger to track assets. Assets may be shipments, products, devices, multiple products, etc. The tracked assets may be identified by a serial number or product identifier (ID) that is used to uniquely identify each specific asset. The serial number can be the main identifier used in the ledger when determining if a ledger update for a particular asset is from a source that actually has possession of the asset. The identifier may be mismanaged by a source that merely has knowledge of the asset's serial number and which is trying to modify/hack/control the asset status remotely based on the serial number. By using serialization technology, such as RFID tags or other wireless tags, which include readable and writable memory, the security and authorization is able to read and write to the tag. This process may include a user memory reading a permanent serial number from the tag and a nonce. The nonce may be a random or pseudo-random number that may only be used once to perform a blockchain transaction. By including a memory portion of the tag, an identifier and a secret or limited knowledge measure may also be included to provide a second level of validation to ensure that a person attempting a ledger update actually has the asset in their possession and is able to extract the dynamic variable, which in this example is a dynamic nonce. This dynamic nonce, which was updated the last time the asset was identified in a shipment chain, custody chain, or other transfer of ownership or supervision type chain, is configured to periodically scan the identifier information on the wireless or RFID tag affixed to the asset and update a central tracking system with product shipment information. When the nonce is identified from the RFID tag and an asset update occurs in the blockchain, the nonce that is written to the tag after every ledger update is an updated nonce which is unique, new and has not been used to add asset data to the blockchain. Any attempted update to the ledger is required to produce an expected nonce value that is identified from the RFID tag and which is known to the blockchain data. If found to be valid, the next expected nonce value will be updated in the blockchain and in the RFID tag so an entity that identifies the product ID may not have access to the latest nonce stored in the RFID and in the blockchain during a previous asset log operation. In operation, the new nonce is arbitrarily assigned by the reader device after an update to the blockchain. FIG. 1 illustrates an asset identification and update operation 100 using a blockchain according to example embodiments. Referring to FIG. 1, the asset 110 may be a box, crate, product, etc., and the tag 112, may be a wireless tag with one or more of a processor, a memory, a receiver, a transceiver, and a transceiver. The tag may be a RFID tag that is affixed to the asset 110 via a stick adhesive, magnet or other affixing mechanism. In other embodiments, the tag 112 may be integrated in the body of the asset 110. The tag 112 may include radio communication functions 114 along with a memory 116 that is capable of storing product ID information, nonce data, and other data. In operation, a RF device 120 or reader may be in communication with a computer system (not shown) which can communicate with a blockchain or other data storage systems. When a product is dispatched from a location (such as a factory), received at another location (such as a shipping facility), dispatched to a driver, etc., the product/asset and the asset status may be updated in the blockchain for an immutable record of the asset's existence and updated existence. The tag memory 116 may contain a nonce value or an empty nonce value if the asset has never been updated (prior to first update). A nonce is a random or pseudo-random number that may only be used once when hashing a blockchain entry for finalization. The reader 120 may scan the tag 112 and extract the product ID 132, the nonce value 134 and other application ledger data 136 which is partially or wholly extracted from the asset 110 or which is substituted from other information sources to complement the asset data when storing the data in the blockchain. Information may include time, number of transactions, asset specification data, blockchain related information, etc. An assigned serial number can be read from the tag and “user memory” which permits for updateable data to be written to the tag. With this approach, a nonce can be included in the user memory portion 116 of the tag 112 that will provide a second level validation to ensure that a person attempting a ledger update actually does have the asset in their possession and has the serial number and the current nonce value that matches the current nonce value stored in the blockchain, which is dynamically assigned and re-assigned. The nonce that is written to the tag is dynamically updated after every ledger update. The ledger of the blockchain then becomes a validation source for any attempted update to the ledger which includes the expected nonce value which is also stored in the ledger. In this example, a ledger update may include various pieces of information as validators including the serial number of the tag, which is the asset ID read from the tag, the nonce value read from the tag, and a newly updated nonce value, which is the new nonce value that will be updated on the tag once the previous nonce value is used to validate the blockchain transaction. For standard usages and tracking, an update to the ledger may be performed to identify where an item is with respect to the rest of the logistics chain. The update to the ledger could be performed to establish a pedigree (i.e., anti-tampering) in a supply chain (i.e., provenance). The update could also be performed for operational controls, such as establishing a transit time, dwell time, “cohort” analysis, etc. With regard to issuing the new nonce, consider two portions of identifying information are needed to update a ledger. One is a serial number, which is fixed and could easily be “known” by various parties. The other is a rotating value (nonce) that changes at every transaction. The nonce is then be available with the object on its tag and is also known to the ledger. In operation, the tag will be read to extract both the serial number and the current nonce. A transaction update to the ledger will be requested with those two pieces of information for validation. In addition, that transaction request will contain a “next nonce” value that the ledger will maintain. The reader device will update the tag with the “next nonce” value. As such, when the tag is read at the next stop on its path, the process continues and the tag's serial and nonce are read, sent to the ledger in a transaction to be validated along with a newly created “next nonce” value that will be updated in the ledger and updated on the tag. The nonce value is found to be valid when the one in the tag matches a same value in the blockchain. The ledger can then determine for a given serial numbered tag if the nonce value that was provided in the ledger update request was the expected nonce value by comparing that nonce value to the one stored in the blockchain. Also, such a value could only be obtained from the tag itself. If the nonce value is found to be valid, the ledger will update its next expected nonce value reference with the new nonce provided. This permits the next update request to go through the same validation. In order to protect against fraudulent absent-observation ledger updates, the two-factor identification mechanism for tag identification reduces the chances of fraud. In this case, a tag is successfully reference-able to the ledger using two pieces of information including an assigned asset tag serial ID and a rotating identification key (nonce). The nonce is used to provide ‘originality’ to a given ledger request against replay attacks and confederate systems attempting to record tag observations by knowing only the tag serial number. In one example, an asset is tracked at location ‘A’ with tag ‘T’. This is an initial tracking operation. At location ‘A’ an object with tag ‘T’ is read, the read information from tag ‘T’ contains tag ID, for example, “12345678” and nonce: <blank>. Location A (reader device, server, etc.) generates a new random number nonce, for example, “858469071245” to be used as the next nonce, and makes an update request to the ledger (blockchain) for object with tag ID “12345678”. In this example, the current nonce is blank due to an initial asset identification and logging operation of the RFID tag which has not yet been performed, and then a next nonce is “858469071245”. Application specific information for the ledger is included as well as part of the ledger update. The ledger retrieves the latest reference for tag ID “12345678” and in this case the value is null or non-existent which indicates that this is the first entry attempt. No further validation is required. The ledger is updated to include a reference for tag ID “12345678” which also specifies its next expected nonce value as “858469071245”. Application specific information is also added to the ledger entry to identify the other transaction details. As a result, location ‘A’ updates tag T user information, setting the tags' nonce value to “858469071245”.
Therefore, there is no current art rejection applied for claims 3-8. 10, and 17; however, the Examiner notes the outstanding double patenting rejection for claims 1-16 and the 35 USC § § 101 and 103 rejections for claims 1-2, 9, and 11-16. Therefore, the claims are not indicated as allowable at this time.
Conclusion
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
Prosecution Insights