WO2023183256A1 - Système d'authentification de produit basé sur une chaîne de blocs - Google Patents

Système d'authentification de produit basé sur une chaîne de blocs Download PDF

Info

Publication number
WO2023183256A1
WO2023183256A1 PCT/US2023/015682 US2023015682W WO2023183256A1 WO 2023183256 A1 WO2023183256 A1 WO 2023183256A1 US 2023015682 W US2023015682 W US 2023015682W WO 2023183256 A1 WO2023183256 A1 WO 2023183256A1
Authority
WO
WIPO (PCT)
Prior art keywords
product
user
instance
token
content
Prior art date
Application number
PCT/US2023/015682
Other languages
English (en)
Inventor
Thomas Chen
Jonathan Ko
Original Assignee
Touch Point Worldwide, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/700,938 external-priority patent/US20220215382A1/en
Application filed by Touch Point Worldwide, Inc. filed Critical Touch Point Worldwide, Inc.
Publication of WO2023183256A1 publication Critical patent/WO2023183256A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06395—Quality analysis or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0607—Regulated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Buyer or seller confidence or verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0623—Item investigation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/04—Manufacturing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present specification generally relates to providing enhanced services associated with physical product based on blockchain.
  • FIG. 1 is a block diagram illustrating a networked system that includes a product verification system according to an embodiment of the present disclosure
  • FIG. 2 is a block diagram illustrating a product verification module according to an embodiment of the present disclosure
  • FIG. 3 is a schematic view illustrating an electronic token according to an embodiment of the present disclosure
  • FIG. 4 is a schematic view illustrating a token transaction ledger according to an embodiment of the present disclosure
  • FIG. 5A is a schematic view illustrating interactions between a user device and the product verification system according to an embodiment of the present disclosure
  • FIG. 5B illustrates an example user interface provided by the product verification module according to an embodiment of the present disclosure
  • FIG. 6 is a flowchart showing a process of tokenization for a product according to an embodiment of the present disclosure
  • FIG. 7 is a flowchart showing a process of performing authentication of a product according to an embodiment of the present disclosure.
  • FIG. 8 is a block diagram of a system for implementing a device according to an embodiment of the present disclosure.
  • a product verification system may use blockchain technologies to track the supply chain process of each instance (e.g., each copy) of a product. For example, either automatically or upon a request by a manufacturer of the product, the product verification system may generate tokens for different instances (e.g., copies) or anticipated instances of the product. In some embodiments, a unique token is generated for each anticipated instance of the product. The token may also be referred to as a non- fungible token as each token is associated with a unique instance of a physical product. Furthermore, the content that is added to the blockchain in association with each token can be unique as well, as will be explained in more detail below.
  • the token may be initially stored in (and associated with) a digital wallet (also referred to as “wallet”) associated with the product verification system or a digital wallet associated with the manufacturer.
  • a digital wallet also referred to as “wallet”
  • the product verification system may transfer the tokens to a digital wallet associated with a first entity in the supply chain process of the product (e.g., the entity that begins the manufacturing process, such as an entity that harvest raw materials for the product).
  • the transfer of the tokens to the wallet associated with the first entity causes a new transaction block to be recorded in a product blockchain structure (also referred to as a “blockchain” or a “ledger”).
  • the new transaction block indicates a transfer of the corresponding tokens from the manufacturer (or the product verification system) to the first entity.
  • the product blockchain structure is generated by the product verification system and is associated with the product or products produced by the manufacturer such that any transactions (e.g., transfer of tokens) associated with instances of the product or products produced by the manufacturers will be recorded in the product blockchain structure.
  • the product blockchain structure is not associated with any particular product or manufacturer, and any transactions associated with any products may be recorded in the product blockchain structure or as metadata associated with the corresponding tokens.
  • the first entity may add content for the instances of the product. For example, via a user interface provided by the product verification system, the first entity may generate and add the content in association with the token.
  • the content may be stored in a new transaction block that is recorded in the product blockchain structure, stored in the transaction block that indicates the transfer of the corresponding token from the manufacturer to the first entity, or stored in a separate data structure (e.g., a record in a separate database) that is associated with the token.
  • the content may include information associated with the preparing of the materials, the origins of the materials, quality or other specifications associated with the materials, etc.
  • the first entity may also transfer the corresponding tokens from the wallet associated with the first entity to a wallet associated with the second entity.
  • the transfer of the corresponding tokens may cause a new transaction block to be recorded in a product blockchain structure.
  • the new transaction block indicates a transfer of the corresponding tokens from the first entity to the second entity.
  • the first entity may affix codes associated with the instances of the products in the unfinished instances of the product (e.g., an RFID tag, an NFC chip, a bar code, a QR code, etc.).
  • the second entity may scan the unfinished instances of the product (e.g., using an RFID reader, an NFC reader, an image scanner, etc.). The scanning of the code may trigger the transfer of the corresponding tokens from the wallet associated with the first entity to the wallet associated with the second entity.
  • the second entity may perform additional processes on the unfinished instances of the product received from the first entity. As the second entity performs the additional processes, the second entity may also add content for the instances of the product. Similar to how content can be added by the first entity, the second entity may, via the user interface provided by the product verification system, generate and add the content in association with the tokens now in the possession of the second entity. The content may be stored in a new transaction block that is recorded in the product blockchain structure or stored in the transaction block that indicates the transfer of the corresponding token from the first entity to the second entity.
  • the content added by the second entity may be associated with the additional processes that are performed by the second entity, such as methods and processes being used by the second entity, skills of personnel involved in the process or specifications of machines that are involved in the process, qualities of the materials being added to the instances of the product, etc.
  • the second entity may pass the unfinished instances of the product to a third entity in the supply chain.
  • the second may also transfer the corresponding tokens from the wallet associated with the second entity to a wallet associated with the third entity.
  • the transfer may cause a new transaction block to the recorded in the production blockchain.
  • the new transaction block indicates a transfer of the corresponding tokens from the second entity to the third entity.
  • the tokens corresponding to the instances of the product may continue to be passed among the entities in the supply chain of the product in a similar manner as described herein until the manufacturing of the instances of the product is complete.
  • the instances of the product as well as the corresponding tokens may be transferred back to the manufacturer after the manufacturing process is complete.
  • the manufacturer may also insert content for the instances of the product. For example, via a user interface provided by the product verification system, the manufacturer may generate and add the content in association of the token.
  • the content may be stored in a new transaction block that is recorded in the product blockchain structure, stored in the transaction block that indicates the transfer of the corresponding token from the last entity in the supply chain to the manufacturer, or stored in a data structure separate from the blockchain but associated with the token (e.g., a record in a database having an index associated with a token identifier of the token).
  • the content added by the manufacturer may include information associated with the product (e.g., a serial number of the product, dimensions, colors, visual characteristics, edge-based attributes for object recognition, instruction manual, etc.), information associated with the manufacturer (e.g., a mission statement, etc.), advertisement content (e.g., text and/or multi-media content related to recommended products, etc.) and other information.
  • the content generated and stored in association with the token by the manufacturer and/or the entities in the supply chain of the product may include text data, multi-media data (e.g., audio data, video data, etc.) and augmented reality data.
  • the content can be incorporated within an image or video of the corresponding instance of the product. Since each instance of the product may be made from different materials (e.g., materials from a different source or origin, etc.) or made using a different process, the individualized tokens and their associated transaction blocks (or metadata) may include information that is specific to that instance of the product.
  • the product verification system may use the tokens and the transaction blocks in the product blockchain to (i) track ownership of the instances of the product, (ii) verify the supply chain of the product, and (iii) provide additional information (e.g., information related to the supply chain of the product to the consumers or other users, information that the manufacturer wants to provide to the consumer, such as information about the product, information about other products produced by the manufacturer, etc., and user-generated data that is generated and added by previous owner(s) of the instances of the product).
  • additional information e.g., information related to the supply chain of the product to the consumers or other users, information that the manufacturer wants to provide to the consumer, such as information about the product, information about other products produced by the manufacturer, etc., and user-generated data that is generated and added by previous owner(s) of the instances of the product.
  • Each instance of the product may include a unique code that is associated with a token assigned to the instance of the product.
  • the code may be incorporated within a data storage mechanism, such as an RFID tag, an NFC chip, that can be affixed and/or attached onto the instances of the product.
  • the code may also be visually presented, such as a bar code, a QR code, etc. that can be shown or attached to the instances of the product.
  • the unique code may be generated based on hashing a token identifier of the token corresponding to the instance of the product.
  • the unique code may be placed on the instance of the product (e.g., printed, engraved, embedded within an RFTD tag, embedded within an NFC chip, etc.) or attached to the instance of the product (e.g., tied in a tag, etc.).
  • a consumer of the product or others may use the product verification system to access enhanced services (e.g., enhanced user experiences, etc.) related to an instance of the product based on the code.
  • a user may use a user device to scan the code (e.g., obtaining an image of the bar code or QR code using a camera, reading the code using an RFID reader and/or an NFC reader, etc.).
  • the user may submit the code to the product verification system (e.g., via a product verification application of the user device).
  • the product verification system may provide a product verification application that can be installed in any user devices (e.g., personal computers, mobile devices, etc.).
  • a user who becomes an owner of an instance of the product e.g., the user purchases the product
  • users who are not owners of the instance of the product, but are in proximity e.g., within a predetermined distance based on the technical capability of scanning the code, etc.
  • the product verification system may provide additional services and/or enhanced user experience related to the instance of the product. For example, the product verification system may determine whether the instance of the product from which the code is captured can be authenticated based on the code and other information. The product verification system may prompt the user to capture an image of the instance of the product. The product verification system may also retrieve device attributes associated with the user device that submitted the code.
  • the device attributes retrieved by the product verification system may include a geographical location detected by a geographical component of the user device (e.g., a GPS component), a network address (e.g., an Internet Protocol (IP) address, a media access control (MAC) address, etc.) of the user device, an identifier of the user of the user device (e.g., an account identifier, a name, an international mobile equipment identifier (IMEI), etc.), and other attributes.
  • a geographical component of the user device e.g., a GPS component
  • IP Internet Protocol
  • MAC media access control
  • identifier of the user of the user device e.g., an account identifier, a name, an international mobile equipment identifier (IMEI), etc.
  • IMEI international mobile equipment identifier
  • the product verification system may attempt to determine a token corresponding to a particular instance of a product based on the code. For example, the product verification system may use a hash table or a “chain explorer” (a UI interface attached with an archive node of the blockchain which would contain all historical data of the chain) to map the code to a corresponding token. If no token is found from the code, the product verification system may determine that the instance of the product captured by the user device cannot be authenticated. If a token is determined based on the code, the product verification system may traverse the product blockchain to access data associated with the token (e.g., the data stored in transaction blocks associated with the token).
  • data associated with the token e.g., the data stored in transaction blocks associated with the token.
  • the data retrieved from the blockchain may include identities of entities that possessed the token in the past (e.g., the entities in the supply chain of the product, the manufacturer, the previous owner(s), the current owner, etc.), the content generated and added by the manufacturer and the entities in the supply chain, and other information.
  • the product verification system may also access a product authentication history associated with the instance of the product corresponding to the token.
  • the product verification system may attempt to authenticate the instance of the product based on the data retrieved from the product blockchain, the product authentication history, the device attributes of the user device, and the image of the instance of the product captured by the user device. For example, the product verification system may analyze the image of the instance of the product and determine whether the image corresponds to physical attributes of the instance of the product. In some embodiments, the product verification system may use an object recognition algorithm (e.g., a scale-invariant feature transform (SIFT) algorithm, etc.) to extract features (e.g., edge-based features) of the instance of the product from the image. The product verification system may then compare the extracted features against the features of the instance of the product stored in the product blockchain.
  • SIFT scale-invariant feature transform
  • the product verification system may determine that the image captured by the user device corresponds to the instance of the product when the extracted features match the stored features by a threshold (e.g., 70%, 80%, etc.). If the product verification system determines that the image fails to correspond to the attributes stored in the product blockchain, the product verification system may determine that the instance of the product captured by the user cannot be authenticated.
  • a threshold e.g. 70%, 80%, etc.
  • the product verification system may also detect suspicious activities regarding the instance of the product. For example, upon receiving the code, the product verification system may check the device attributes (e.g., the device identifier, the time when the code is received, the geographical location of the user device that submitted the code, etc.) against device attributes of previously authentication requests that include the code. If another request for authenticating the same instance of the product (e.g., including the same code) was submitted within a time threshold by another device (e.g., having a different device identifier) from another geographical location, the product verification system may determine that the instance of the product captured by the user device is likely a counterfeit, and would not authenticate the instance of the product.
  • the device attributes e.g., the device identifier, the time when the code is received, the geographical location of the user device that submitted the code, etc.
  • the product verification system may transmit an authentication failure notification to the user device.
  • the product verification application on the user device may present the notification to the user.
  • the product verification system may provide the user device access to the data associated with the corresponding token retrieved from the product blockchain.
  • the product verification system may transmit an authentication success notification to the user device.
  • the product verification application of the user device may present the authentication success notification on the user device.
  • the product verification system may also transmit the data retrieved from the product blockchain, in association with the token, to the user device.
  • the product verification application may present the data on the user device.
  • the data that has been added and stored on the blockchain in association with the token may include data supply chain data added by different entities within the supply chain for producing the instance of the product.
  • the supply chain data may include illustrations of how the instance of the product was made.
  • the product verification application may present an interactive interface that illustrates the process of manufacturing the instance of the product based on the data received from the product verification system.
  • the interactive interface may show the entities involved in the supply chain of manufacturing the instance of the product, the materials and the methods being used to manufacture the instance of the product, the standards/specifications/rules that they follow during the manufacturing of the instance of the product, etc.
  • the data may also include augmented reality data.
  • the content that is added to the blockchain in association with the instance of the product e.g., by an entity within the supply chain of the instance of the product, by the manufacturer, by an owner or a previous owner, by the product verification system, etc.
  • the product verification application may store the augmented reality data (which may include programming code) on the user device when the augmented reality feature is not activated.
  • the user device may execute the programming code to perform the augmented reality function.
  • the user device may activate the augmented reality feature in response to one or more trigger (e.g., when an image of a scene is detected on the display of the user device, etc.).
  • the product verification application may monitor images and videos being captured by the user device.
  • the product verification application may superimpose augmented reality data onto the image.
  • the product verification application may analyze the image, and may superimpose augment reality data onto the image based on the analysis.
  • the augmented reality data may include multi-media data (e.g., audio data, video data, etc.).
  • the product may be a ring (e.g., a diamond ring, etc.).
  • the product verification application may automatically superimpose an image of the ring onto a finger of the hand in the image.
  • the product verification application may adjust the size of the image of the ring based on a size of the hand in the image.
  • the product may be a vehicle (e.g., a sports car).
  • the product verification application may superimpose alternative configurations (e.g., an upgraded engine component, an upgraded exhaust system, etc.) onto the image.
  • the augmented reality data may include audio data (e.g., the sound of the engine with the upgraded component, the sound of the upgraded exhaust system on the instance of the product, etc.), the product verification application may cause the user device to play the audio data as well.
  • the interactive interface that illustrates information of the supply chain of the instance of the product and the additional content that is presented to the user provides an enhanced user experience in association with the instance of the product, which cannot be accomplished without the use of the embodiments in the disclosure.
  • the corresponding token is also transferred to a wallet of the first consumer. The possession of the token enables the first consumer to access the information associated with the instance of the product, and also add additional user-generated content for the instance of the product.
  • multi-media data such as images or videos that the first consumer generates (e.g., photos/videos of the instance of the product, of any modification or enhancement to the instance of the product, etc.) can be added for the instance of the product, via a user interface provided by the product verification system.
  • a celebrity may record a movie she is shooting and/or an event in which she is performing from her perspective (e.g., using a camera affixed to her apparel). After the movie shoot or the performance, the celebrity may add the recording to the blockchain in association with a token corresponding to an instance of the product that she owns (e.g., a watch, a hat, a piece of jewelry, etc.). When she subsequently sells the instance of the product to another person (and transfer the token to the subsequent owner), the subsequent owners may have access to those recordings based on the token.
  • other user-generated data e.g., digital art, audio recording, biometric data, etc.
  • the user-generated content can also be stored in the same manner as the content provided by the manufacturer and/or the entities in the supply chain such that the first consumer, other users who uses the product verification system to submit authentication request for the instance of the product, and subsequent purchasers of the instance of the product can access the content.
  • records of the maintenance may also be added for the instance of the product by the first consumer as proof of maintenance in the future.
  • data associated with the life cycle of each instance of the product can be stored by the product verification system. This information can be provided to the manufacturer (after stripping sensitive data associated with the consumers) as feedback.
  • the product verification system may still allow other entities to continue to add new content to the blockchain in association with those instances of the product.
  • the manufacturer may add new content to the blockchain in association with the instances of the product for consumption by the owners or other people who scan the codes.
  • the new content may include promotional data for promoting the product or other related products from the manufacturer (e.g., discount offers, advertisements, etc.).
  • the product verification platform e.g., the product verification system and the product verification applications
  • the manufacturers can directly communicate with their consumers and others who may be interested in their products (e.g., the people who scan the codes associated with different instances of the product).
  • the manufacturer may upload different promotional data to the blockchain at different times to provide new promotional content to the owners and other potential consumers of the product.
  • the product verification platform may enable the manufacturer to provide targeted promotional data.
  • the product verification platform may allow the manufacturer to provide different versions of promotional materials (e.g., for different products, for different discounts, for different incentives, etc.), and configurations for when the different versions of the promotional materials can be presented to user devices.
  • the configurations may be locationspecific (e.g., show a particular promotional material when the requesting device is located within a certain geographical area, etc.), time-specific (e.g., show a particular promotional material when the request is made at a specific time, etc.), demographic-specific (e.g., show a particular promotional material when the requester is within a certain age-range, is a particular gender, has a certain income range, etc.) or dependent on any attribute of the requester and/or the requesting device.
  • the configurations and the different versions of the promotional materials may be stored in the blockchain (or in a data storage linked to the blockchain) and may be retrieved by a product verification application of a user device as the product verification application scans a code corresponding to an instance of the product.
  • the product verification application may select and present one or more of the promotional materials. For example, the product verification application may determine a location of the user device, a time of day when the code is scanned, attributes of a user of the user device (e.g., an age, a gender, an income, etc.), and/or other attributes, and may select the appropriate promotional materials based on the attributes. This way, the manufacturers can provide targeted advertisement to the public through the product verification platform.
  • the product verification application may determine a location of the user device, a time of day when the code is scanned, attributes of a user of the user device (e.g., an age, a gender, an income, etc.), and/or other attributes, and may select the appropriate promotional materials based on the attributes. This way, the manufacturers can provide targeted advertisement to the public through the product verification platform.
  • the production verification platform may act as a managed service provider for facilitating advertisement space.
  • the product verification platform may enable third-party access to add additional content to the blockchain in association with instances of a particular product for a fee.
  • an aftermarket accessory manufacturer for a particular product e.g., an aftermarket exhaust for a car model, etc.
  • the product verification platform may enable the aftermarket accessory manufacturer to add promotional content associated with the aftermarket accessory to the blockchain in association with instances of the particular product, for a fee.
  • the content may include interactive data that enables the viewer to interact with a server associated with the aftermarket accessory manufacturer. This way, the product verification platform may enable the third-party to directly access potential consumers on a personal level.
  • the production verification platform may provide access control to the content associated with the instance of the product. For example, based on an identity of the requester (e.g., an owner of the instance of the product, a person who is in proximity of the instance of the product and scans the code, etc.), the product verification platform may provide the requester accesses to different portions of the content.
  • the product verification platform may allow the owner of the instance of the product accesses to all content on the blockchain in association with the token but may only allow other users who scan the code to access only a portion of the content (e.g., excluding content generated by previous and current owners, excluding special content generated by the manufacturer, etc.).
  • a token representing an instance of a product, or the combination of the token and the content stored on the blockchain in association with the token are referred to as a non- fungible token (NFT), which are transferrable between different users separate from the instance of the product, or in connection with the instance of the product.
  • NFT non- fungible token
  • a first user who is the owner of the NFT may decide to sell the instance of the product to a second user.
  • the first user may transfer the token (the NFT) from a wallet of the first user to a wallet of the second user.
  • the first user may transfer the NFT (e.g., the token and all the content stored on the blockchain in association with the token) to the second user without transferring the physical copy of the product (e.g., keeping the instance of the product).
  • the token the NFT
  • the token can be treated as a separate asset independent of the corresponding physical copy of the product.
  • the content that is added to the blockchain in association with the token may include a digital version of the instance of the product (which can be generated by the manufacturer, the product verification platform, or other entities), which can be manipulated within a computer virtual environment.
  • the digital version of the instance of the product may include a digital object having a set of attributes.
  • the set of attributes may describe the characteristics of the instance of the product as presented in the virtual environment (e.g., a size, a color, a style, a shape, etc.).
  • the digital object may include a three-dimensional view of the copy of the product such that the digital object can be rendered as a three-dimensional object within the virtual environment.
  • the digital object may also include the code that is attached to the physical instance of the product.
  • the product verification system may also facilitate the transport of the digital object into a virtual environment and between different virtual environments.
  • the product verification system may establish communications with different virtual environment platforms (e.g., virtual environment platforms that support different computer games that can be played within different virtual environments, etc.).
  • the product verification system may communicate with the different virtual environment platforms through a set of application programming interfaces (APIs) and may be configured to receive requests for importing digital objects associated with different real- world physical instances of products.
  • APIs application programming interfaces
  • the request may be forwarded to the product verification system through the set of APIs.
  • the product verification system may request the user to submit proof of ownership of the corresponding token (e.g., by being authenticated as the owner of the digital wallet account that owns the token, such as encoding a message using a private key of the digital wallet account, etc.).
  • the user may use the product verification application to communicate credential data to the gaming console for completing the authentication process.
  • the product verification system may transfer data associated with the digital object to the virtual environment platform.
  • the virtual environment platform may render the digital object within the game that the user is playing. Based on the characteristics specified in the digital object, the user may manipulate the rendering of the digital object within the game (e.g., wearing the digital object, carrying the digital object, presenting the digital object to other users in the virtual environment, using the digital object within the virtual environment, etc.). For example, if the instance of the product is a car, the user may drive the digital object rendered as a virtual car. If the instance of the product is a purse, the user may carry the digital object rendered as a virtual purse. In some embodiments, the user may also present other content that is stored on the blockchain in association with the token, such as the content added by the entities associated with the supply chain, the manufacturers, third-party entities, and previous/current owners of the token. The user may present the content within the virtual environment (e.g., in the game) or in a chat room associated with the game.
  • the user may also transfer (e.g., sell) the digital object to another user within the game.
  • the request to transfer the digital object may be transmitted to the product verification system via the virtual environment platform, and the product verification system may facilitate the transfer of the token from the digital wallet of the user to a digital wallet of the buyer in the game.
  • the product verification system may establish communication with multiple virtual environment platforms such that the user may transport the digital object from one virtual environment to another virtual environment seamlessly.
  • Other players in the game may also initiate the product verification process as the avatars (e.g., virtual representations of the players) are in proximity (e.g., within a threshold distance) with the digital object in the game.
  • a player who is in proximity from the digital object may “scan the code” of the digital object by performing a predetermined action and/or motion in the game (e.g., waving at the digital object, jumping in front of the digital object, etc.).
  • the virtual environment platform may transmit a product verification request to the product verification system via the set of APIs along with the code that is attached to the digital object.
  • the product verification system may traverse the blockchain to perform the verification process in a similar manner as discussed here, and may present to the player (e.g., via the set of APIs) an indication of whether the digital object is authenticated or not.
  • the product verification system may also present, on a gaming console of the player who scanned the code of the digital object, certain selective content stored on the blockchain in association with the token.
  • Fig. 1 illustrates a networked system 100, within which the product verification system may be implemented according to one embodiment of the disclosure. Note that the present techniques may be applied in many different computing and technological environments, however, and are not limited to those shown in the figures.
  • the networked system 100 includes a service provider server 130, a user device 110, a manufacturer server 120, and vendor servers 180 and 190 that may be communicatively coupled with each other via a network 160.
  • the network 160 in one embodiment, may be implemented as a single network or a combination of multiple networks.
  • the network 160 may include the Internet and/or one or more intranets, landline networks, wireless networks, and/or other appropriate types of communication networks.
  • the network 160 may comprise a wireless telecommunications network (e.g., cellular phone network) adapted to communicate with other communication networks, such as the Internet.
  • a wireless telecommunications network e.g., cellular phone network
  • the user device 110 may be utilized by a user 140 to interact with the service provider server 130 over the network 160.
  • the user 140 may use the user device 110 to submit a request for authenticating an instance of a product via a website hosted by, or a mobile application associated with, the service provider server 130.
  • the user device 110 in various embodiments, may be implemented using any appropriate combination of hardware and/or software configured for wired and/or wireless communication over the network 160.
  • the user device 110 may include at least one of a wireless cellular phone, wearable computing device, PC, laptop, etc.
  • the user device 110 includes a user interface (UI) application 112 (e.g., a web browser, a mobile application, etc.), which may be utilized by the user 140 to interact with the service provider server 130 over the network 160.
  • UI user interface
  • the user interface application 112 includes a software program (e.g., a mobile application) that provides a graphical user interface (GUI) for the user 140 to interface and communicate with the service provider server 130 via the network 160.
  • GUI graphical user interface
  • the user interface application 112 includes a browser module that provides a network interface to browse information available over the network 160.
  • the user interface application 112 may be implemented, in part, as a web browser to view information available over the network 160.
  • the user device 110 may include a location component 116 configured to determine, track, monitor, and/or provide an instant geographical location of the user device 110.
  • the geographical location may include GPS coordinates, zip-code information, area-code information, street address information, and/or various other generally known types of location information.
  • the location information may be directly entered into the user device 110 by the user via a user input component, such as a keyboard, touch display, and/or voice recognition microphone.
  • the location information may be automatically obtained and/or provided by the user device 1 10 via an internal or external monitoring component that utilizes a global positioning system (GPS), which uses satellite-based positioning, and/or assisted GPS (A-GPS), which uses cell tower information to improve reliability and accuracy of GPS-based positioning.
  • GPS global positioning system
  • A-GPS assisted GPS
  • the location information may be automatically obtained without the use of GPS.
  • cell signals or wireless signals are used.
  • the user device 110 may include at least one identifier 114, which may be implemented, for example, as operating system registry entries, cookies associated with the user interface application 112, identifiers associated with hardware of the user device 110 (e.g., a media control access (MAC) address), or various other appropriate identifiers.
  • the identifier 114 may be passed with a user login request to the service provider server 130 via the network 160, and the identifier 114 may be used by the service provider server 130 to associate the user 140 with a particular user account (e.g., and a particular profile) maintained by the service provider server 130.
  • the user 140 is able to input data and information into an input component (e.g., a keyboard) of the user device 110.
  • an input component e.g., a keyboard
  • the user 140 may use the input component to interact with the UI application 112 (e.g., to submit a code associated with a product, to retrieve content from third-party servers such as the service provider server 130, etc.).
  • the manufacturer server 120 may be maintained by a business entity that produces and sells one or more products. Examples of business entities include a car manufacturer, a jewelry manufacturer, an accessory manufacturer, etc., which produces various products that can be sold to consumers directly or via retailers.
  • the manufacturer may use the manufacturer server 120 to interact with the service provider server 130 and the vendor servers 180 and 190. For example, the manufacturer may use the manufacturer server 120 to submit, to the service provider server 130, a request for tokens for anticipated instances of a product to be manufactured. In addition, upon receiving the corresponding tokens, the manufacturer may use the manufacturer server to add, via a user interface provided by the service provider server 130, content for the instances of the product.
  • While only one manufacturer server 120 is shown in Fig. 1, it has been contemplated that multiple manufacturer servers, each associated with a different manufacturer, may be connected to the user device 110 and the service provider server 130 via the network 160.
  • Each of the vendor servers 180 and 190 may be associated with a different entity that is part of a supply chain of a product produced by the manufacturer of the manufacturer server 120.
  • a first entity associated with the vendor server 180 may be tasked to prepare raw materials for the product (e.g., steel for a car, diamond for a ring, etc.).
  • a second entity associated with the vendor server 190 may be tasked to perform processing to the raw materials provided by the first entity.
  • Each one of the vendor servers 180 and 190 may be used by the corresponding entity to interact with the service provider server 130.
  • the entities may use the vendor servers 180 and 190 via a user interface provided by the service provider server, to add content for the instances of the product, to receive the corresponding tokens from the manufacturer or another entity, and to transfer the corresponding tokens to another entity or back to the manufacturer.
  • the service provider server 130 may be maintained by an online service provider, which may provide product authentication and user experience enhancement services for the user 140 of the user device 110.
  • the service provider server 130 may also include an interface server 134 that is configured to serve content (e.g., web content, product content, augmented reality content, etc.) to users and interact with users.
  • the interface server 134 may include a web server configured to serve web content in response to HTTP requests.
  • the interface server 134 may include an application server configured to interact with a corresponding application (e.g., a product verification mobile application) installed on the user device 110 via one or more protocols (e.g., RESTAPI, SOAP, etc.).
  • the interface server 134 may include pre-generated electronic content ready to be served to users.
  • the interface server 134 may provide a user interface that enables the manufacturer of the manufacturer server 120 to submit a request for tokens.
  • the interface server 134 may also provide a user interface that enables the manufacturer of the manufacturer server 120 and the entities associated with the vendor servers 180 and 190 to add content to the product blockchain for different instances of a product.
  • the interface server 134 may also communicate with the UI application 112 and provide, via the UI application 112, a user interface that enables the user to submit a request for authenticating an instance of a product.
  • the service provider server 130 may be configured to maintain one or more user accounts and merchant accounts in an account database 136, each of which may be associated with a profile and may include account information associated with one or more individual users (e.g., the user 140 associated with user device 110) and manufacturers.
  • account information may include private information of users and manufacturers, such as one or more account numbers, passwords, digital wallets information, transaction history, Internet Protocol (IP) addresses, device information associated with the user account.
  • IP Internet Protocol
  • a user may have identity attributes stored with the service provider server 130, and the user may have credentials to authenticate or verify identity with the service provider server 130.
  • User attributes may include personal information, banking information and/or funding sources.
  • the user attributes may be passed to the service provider server 130 as part of a login or a request, and the user attributes may be utilized by the service provider server 130 to associate the user with one or more particular user accounts maintained by the service provider server 130 and used to determine the authenticity of a request from a user device.
  • the service provider server 130 includes a product verification module 132 that implements product verification system as discussed herein.
  • the product verification module 132 may issue (e.g., mint) tokens corresponding to various instances (or anticipated instances) of a product automatically or upon receiving a request from a manufacturer.
  • the product verification module 132 may transfer the tokens to a digital wallet associated with a first entity in the supply chain of the product.
  • the tokens may be transferred among the entities in the supply chain as the instances of the products are being manufactured/processed by the various entities.
  • the product verification module 132 of some embodiments may record the transaction in a new transaction block of a product blockchain (e.g., a ledger).
  • the product verification module 132 may receive requests for authenticating the instances of the products, for example, from the user device 110.
  • the request may include a code captured (e.g., scanned, etc.) by the user device 110, which is located on or attached to the instance of the product.
  • the product verification module 132 may determine a corresponding token based on the code.
  • the product may authenticate the instance of the product based on device attributes of the user device 110, an image of the instance of the product captured by the user device 110, and/or data retrieved from the product ledger in association of the token.
  • the product verification module 132 may work with the UI application 112 to present enhanced user content on the user device 110.
  • Fig. 2 illustrates a block diagram of the product verification module 132 according to an embodiment of the disclosure.
  • the product verification module 132 includes a verification manager 202, a minting module 204, an authentication module 206, a counterfeit detection module 208, and a content management module 210.
  • the product verification module 132 is communicatively coupled with a data storage 260 that is configured to store one or more ledgers for recording transaction records associated with various tokens issued by the minting module 204.
  • the verification manager 202 may provide a user interface (e.g., a website, a user interface application, a dashboard, etc.) on the manufacturer server 120 for interacting with the manufacturer.
  • a user interface e.g., a website, a user interface application, a dashboard, etc.
  • the manufacturer may provide information associated with a product that the manufacturer plans to produce.
  • the verification manager 202 may receive product information that is entered into various fields shown on the user interface. The various fields may be customized to the specific industry of the manufacturer. In some embodiments, additional information fields can be created by the manufacturer.
  • the manufacturer may also automate this process by uploading a formatted CSV/xlsx file from their existing inventory software's database which contains populated fields corresponding to product information fields within the user interface. The automated uploading of the CSV/xlsx file will batch load product information to the product verification module 132.
  • the information may include a category of the product, a size of the product, a name and description of the product, and data associated with entities within the supply chain of the product.
  • the information may also include a number of anticipated instances of the product to be produced (e.g., how many copies of the product does the manufacturer is producing).
  • the minting module 204 may begin issuing (e.g., minting) tokens for the anticipated instances of the product being produced by the manufacturer.
  • the minting module 204 may be configured to mint one token for each anticipated instance of the product.
  • the tokens that are minted for each instance of the product may be referred to as non-fungible tokens (NFTs).
  • NFTs non-fungible tokens
  • Fig. 3 illustrates an example electronic token 300 according to one embodiment of the disclosure.
  • the electronic token (or simply as “token”) 300 may be issued by the minting module 204 and may correspond to an instance of the product.
  • the electronic token 300 is an electronic product that is transferrable among different parties based on a particular protocol.
  • the electronic token 300 may be defined as a chain of digital signatures provided by previous owners of the electronic token 300 to subsequent owners of the electronic token.
  • the electronic token 300 is owned by an owner 312, and Fig. 3 illustrates how the electronic token 300 is defined by the digital signatures of the previous owners 314, 316, and 318.
  • a hash of the public key of owner 316 i.e., the owner receiving, as a result of transaction A, the electronic token 300i defined by digital signatures provided up to transaction A
  • the previous transaction not illustrated, but occurring prior to transaction A
  • owner 18 i.e., the owner providing, as a result of transaction A, the electronic token 300i defined by digital signatures provided up to transaction A
  • owner 18 i.e., the owner providing, as a result of transaction A, the electronic token 300i defined by digital signatures provided up to transaction A
  • an initial electronic token which was defined by digital signatures provided up to the transaction prior to transaction A
  • a hash of the public key of owner 314 i.e., the owner receiving, as a result of transaction B, an electronic token 3002 defined by digital signatures provided up to transaction B
  • transaction A was signed by owner 316 using a private key and added to the electronic token 3001 such that the electronic token 300 was transferred to owner 314.
  • a hash of the public key of owner 312 i.e., the owner receiving, as a result of transaction C, the electronic token 3003 defined by digital signatures provided up to transaction C
  • the transaction B was signed by owner 314 using a private key and added to the electronic coin 3002 such that the electronic token 300 was transferred to owner 312.
  • any payee receiving an electronic token e.g., owner 316 in transaction A, owner 314 in transaction B, and owner 312 in transaction C
  • the minting module 204 may record the token (e.g., the token 300) in a ledger (e.g., a blockchain) 262 in the data storage 260.
  • the minting module 204 may also store the information received from the manufacturer via the user interface in the ledger 262 (e.g., store the information in a new transaction block and append the new transaction block to the ledger 262, etc.) or in a separate data structure (e.g., a database) in association with the token (e.g., indexed using a token identifier of the token).
  • a network address (e.g., a uniform resource identifier (URI), a web address, etc.) may be assigned to each of the newly issued tokens and point to the information associated with the token in the data storage 260.
  • a hash of the product information from the data storage 260 in string format is stored as metadata on the corresponding token in the ledger 262.
  • the newly issued tokens are transferred to a wallet associated with the product verification module 132 (e.g., the wallet 264).
  • the transfer of the tokens to the wallet 264 may be recorded as new transaction blocks in the ledger 262.
  • Fig. 4 illustrates an example ledger 400 according to one embodiment of the disclosure.
  • the ledger 400 operates to verify previous transactions (e.g., transfer) and ownership of electronic tokens (e.g., referring back to Fig. 3, owner 316 in transaction A, owner 314 in transaction B, and owner 312 in transaction C) such that owners did not “double-spend” (e.g., use a private key to sign any previous transactions involving) that electronic token.
  • a single device e.g., the service provider server 130
  • a distributed network of devices may operate to agree on a single history of transactions in the order in which they were received such that it may be determined that a transaction between a transferrer and a transferee of a token is the first transaction associated with that electronic token from the transferrer.
  • Each device in the distributed network operates to collect new transactions into a block, and then to increment a proof-of work system that includes determining a value that when hashed with the block provides a required number of zero bits.
  • a device in the distributed network may increment a nonce in the block 402 until a value is found that gives a hash of the block 402 the required number of zero bits. The device may then “chain” the block 402 to the previous block 404 (which may have been “chained” to a previous block, not illustrated, in the same manner).
  • That block (e.g., block 402) is broadcast to the distributed network, and other devices in the distributed network will accept that block if all the transactions in it are valid and not already transferred (which may be determined by creating the next block using the hash of the accepted block 402).
  • the distributed network will always consider the longest chain of blocks to be the correct one and will operate to continue to extend it.
  • PoS Proof of Stake
  • a device If a device receives two different versions of a block, it will work on the first block received, but save the second block received in case the branch of the chain that includes the second block becomes longer (at which point that device with switch to working on the branch of the chain that includes the second block).
  • the minting module 204 may also generate corresponding codes (e.g., bar codes, QR codes, codes that can be stored within an RFID tag and/or an NFC chip, etc.) for the tokens, and the mapping between the codes and the tokens are stored in the data storage 260.
  • the code may be generated based in part on hashing the token identifier of the token.
  • the codes can be stored as images and may be downloaded to be printed in an NFC printer or uploaded individually to NFC chips.
  • the minting module 204 may present the tokens and the corresponding codes on the manufacturer server 120 to indicate the successful minting of the tokens.
  • the verification manager 202 may transfer the tokens to the wallet associated with a first entity within the supply chain of the product (e.g., the entity associated with the vendor server 180).
  • the transfer of the tokens may cause a new transaction block to be recorded in the ledger 262.
  • the new transaction block indicates the transfer of the token from the wallet 264 to the wallet of the first entity.
  • the verification manager 202 may provide a user interface on the vendor server 180, which enables the first entity to add content for the tokens. In some embodiments, different content may be added (and associated) with different tokens.
  • the first entity may provide content for a token that is specifically associated with the corresponding instance of product.
  • the content management module 210 may store the content in association with the token.
  • the content management module 210 may store the content in a new transaction block in association with the token and chain the new transaction block to the ledger 262.
  • the content management module 210 may store the content in a database that is indexed by the token identifier of the token.
  • the first entity may also, via the user interface, initiate a transfer of the tokens from the wallet associated with the first entity to a wallet associated with a second entity in the supply chain.
  • the verification manager may record the transfer in the ledger 262 and provides a notification on the vendor server 190 of the second entity indicating the transfer of the tokens.
  • the transfer of the tokens from the wallet associated with the first entity to a wallet associated with the second entity may be triggered by a scan of the codes associated with the instances of the product (unfinished instances of the product) at a site of the second entity.
  • the verification manager 202 may provide a user interface on the vendor server 190 that enables the second entity to add content for the different tokens that have been transferred to the second entity, and to transfer the tokens from the wallet associated with the second entity to a wallet associated with a third entity in the supply chain.
  • the content manager 210 may store the content provided by the second entity in association with the corresponding tokens.
  • the verification manager 202 may facilitate the transfer of the tokens.
  • the tokens may continue to be transferred to different entities in the supply chain of the product until the manufacturing of the instances of the product is complete.
  • the tokens may then be transferred back to a wallet associated with the manufacturer.
  • the tokens may follow the ownership (or possession) of the corresponding instances of the product.
  • the corresponding tokens may be transferred to the retailer.
  • the corresponding token may also be transferred to a wallet associated with the consumer. Since each of the transfer of the token is recorded in the ledger 260, the transactions indicated by the transaction blocks in the ledger 260 may be used to determine a chain of ownership (or possessions) of each instance of the product.
  • codes that correspond to the tokens may be provided with the instances of the product (e.g., printed, engraved, attached an RFTD tag and/or NFC chip to the product, etc.).
  • a request may be initiated via the UI application 112 (e.g., the BerifyTM mobile application) by obtaining the code that is provided with the instance of the product (e.g., scanning the code, swiping the NFC chip, reading the RFID tag, etc.).
  • Fig. 5A illustrates the initiation of a request according to some embodiments of the disclosure.
  • the user 140 may have purchased an instance of the product 502 from a retailer or is in close proximity of the instance of the product owned/worn by another person.
  • the instance of the product 502 in this example is a pair of shoes.
  • the user 140 may use the user device 110 to obtain a code provided with that instance of the product 502.
  • the user device 1 10 may include a camera for capturing an image of a bar code or a QR code.
  • the user device 110 may also include an RFID reader for reading an RFID tag, and/or include an NFC reader for reading an NFC chip.
  • the UI application 112 of the user device 110 may transmit the request (which may include the code) to the service provider server 130.
  • the authentication module 206 may retrieve (or otherwise obtain) additional information from the user device 110 via application programming interface (API) calls.
  • the authentication module 206 may obtain device attributes of the user device 110 such as a geographical location of the user device 110 determined by the location component 116, a network address of the user device 110, a device identifier of the user device 110, a wallet account number of a wallet associated with the user 140, a device screen size, a default language, a color depth of a display, and other device specific data.
  • the authentication module 206 may also prompt the user 140 to capture an image of the instance of the product 502.
  • the authentication module 206 may attempt to match the code with a token that was minted by the minting module 204. For example, the authentication module 206 may map the code to a token identifier in the data storage 260. If the code cannot be mapped to a token identifier, the authentication module 206 may determine that the code is invalid, and thus would not authenticate the instance of the product 502. The easiest example of how counterfeits are detected is when an unregistered code is scanned. This occurs when a fake code is sent to the product verification module 132 and the code does not match any of the token identifier on the ledger 262. Thus, the authentication module 206 may flag the code as invalid.
  • the authentication module 206 may also store the invalid code in a blacklist within the data storage 260 such that any subsequent requests including the invalid code can be detected quickly. It is noted that the chance of generating a random token ID that happens to be the same as a registered token (aka a collision) would be astronomically small as 2 A 256-1 combinations are possible, and even with even billions of tags generated a random collision from a third party would be highly unlikely.
  • the counterfeit detection module 208 may also perform a series of security measures to ensure that the code being obtained from the user device 1 10 corresponds to the instance of the product 502 associated with the request. For example, the counterfeit detection module 208 may use a combination of a history of previous authentication requests and device attributes to check a validity of the code.
  • the counterfeit detection module 208 may use a machine learning model that is configured to provide a likelihood of validity of the request based on the code, the attributes of the user device 110 obtained by the authentication module 206, and the history of authentication requests received by the product verification module 132.
  • the machine learning model may output a lower likelihood of validity when a previous authentication request that includes the same code is received (i) from a device having different device attributes and located at a location that exceeds a threshold distance from the location of the user device 110 and (ii) within an amount of time less than a threshold amount.
  • the machine learning model may also output a lower likelihood of validity when a previous authentication request that includes the same code is received at the same time as the request from the user device 110 from another device having different device attributes.
  • the machine learning model may also output a lower likelihood of validity when a number of authentication requests including the same code exceeding a threshold number have been received from devices with different attributes.
  • the machine learning model may output a lower likelihood of validity when the request from the user device 110 was received at a time that is past an expiration date of the token (e.g., corresponding instance of the product is perishable, and the expiration date of the token corresponds to an expiration date of the instance of the product).
  • the machine learning model may also output a lower likelihood of validity when a number of invalid authentication request that may or may not include the same code has been received from devices located within a predetermined distance threshold from the location of the user device 1 10.
  • the counterfeit detection module 208 may traverse the ledger 262 to access data associated with the token corresponding to the token identifier while performing the security measures.
  • the authentication module 206 may not authenticate the instance of the product when the ledger 262 indicates that the mapped token has not been transferred to a retailer (e.g., not available for sale) at the time the authentication request is received from the user device 110. Additional security measures can be performed, such as checking hashes of a product identifier embedded in the token against a rehash of the product information database. Suspicious activity associated with the code (and/or the token) is given a specific weight within product verification module 132. Once the total of a weight reaches above a predetermined threshold for suspicious activity, the product verification module 132 will flag the token and all future authentication request associated with the token will be denied.
  • Anti-counterfeit measures will stop large sales of counterfeit products attempting to use forged codes but may not be able to stop small scale counterfeits, or "one- off” situations where a valid code is copied once in order to make a single sale. "One-offs are much more likely in scenarios where malicious actors target low-volume, high value items such as designer bags, jewelry, expensive cosmetics or limited edition items like a signed jersey for counterfeiting.
  • an enhanced code may be provided to an additional layer of protection. The process of generating the enhanced code differs from a normal code in several ways:
  • the physical tag containing the seed code is physically hardened against anyone attempting to read the code. This includes a tamper-proof seal on top of the seed code, or a RFID/NFC blocking material wrapped around the NFC chip containing the seed code that must be broken to be read by a device.
  • a version of an enhanced security tag that alleviates both overhead of registration processes by the user and the overhead of issuing a token to the user at the point of registration is by just having physical security.
  • This tag would be better suited for larger volume items that still need high security.
  • This is a trade-off of security by putting the onus of security solely on the physical construction of the tag, while keeping the authentication of the tag by the user as simple as possible.
  • the tag is in the form factor of a sealed folded tag or an envelope- style form factor. The tag is sealed by adhesive, with perforations to open the tag.
  • the envelope has tamper resistant material - for tags including a NFC chip, foil or similar NFC-blocking material over the front and back of the chip would prevent scanning through the exterior of the tag.
  • tags including a NFC chip, foil or similar NFC-blocking material over the front and back of the chip would prevent scanning through the exterior of the tag.
  • the foil on one side of the NFC chip would be removed, allowing the chip to be readable.
  • QR codes inside the interior of the tag a construction of the tag in a thicker material or security print on the interior of the tag would prevent a malicious actor from scanning the QR code through the sealed tag. When opened the tag can be scanned as a normal code with the U1 application 112.
  • the authentication module 206 may determine that the item associated with the authentication request is a counterfeit.
  • the product verification module 132 may perform one or more actions, such as (1) collecting metrics regarding counterfeit activities and geographical region (e.g., which can be used to determine what regions have the highest amount of counterfeit activity, (2) providing a warning about a potential counterfeit item as a response to all subsequent authentication requests comprising the same code, and (3) if the token is not in possession of a user’s wallet, the product verification module 132 may bum the token (e.g., removing any data associated with the token in the ledger 262).
  • the legitimate owner may request a new token for that instance of the product. They are reissued a valid token for the product they purchased if they provide proof of ownership through credit card statements, receipt of purchase, etc.
  • the authentication module 206 may transmit a notification to the user device 110 indicating that the instance of the product is authenticated.
  • the content management module 210 may generate and/or retrieve content for providing an enhanced user experience to the user 140 via the user device 110.
  • the content management module 210 may determine a history of the instance of the product based on traversing the ledger 262 and accessing data associated with the corresponding token within the ledger 262 and in the data storage 260.
  • the content management module 210 may generate and/or retrieve content from the blockchain that is associated with the token corresponding to the instance of the product.
  • the content management module 210 may present, on the user device 1 10 via the UI application 1 12, an interactive user interface to illustrate the content.
  • the content that has been added to the blockchain may include data added by entities associated with the supply chain that manufactured the instance of the product.
  • the content presented by the content management module 210 on the user device 110 may include the history of the instance of the product, including the materials and methods used to produce the instance of the produce.
  • the history of the instance of the product is presented in a graphical chain, which shows the transfer of the instance of the product from one entity to another entity.
  • the user 140 may select the different entities that have been involved (e.g., take possessions) of the instance of the product to learn more about it.
  • the content management module 210 may present, on the user device 110 via the UI application 112, the content that was provided by the corresponding entity during the manufacturing of the instance of the product.
  • Interaction data associated with how the user 140 interacts with the user interface provided through the UI application 112 may be transmitted to the product verification module 132, which enables the product verification module to determine additional metrics (e.g., what product information the user is scrolling to the most, what they select to see more in detail, how many users migrate to the user's website from the app to browse items, etc.). This information may be presented on a device associated with the service provider server 130.
  • the product verification module 132 may detect changes of product information associated with the instance of the product (e.g., recalls, maintenance updates, etc.), and may relay the changes to customers through the UI application 112, ensuring accountability to data integrity on consumer products.
  • Product data is hashed and stored on a token upon creation, therefore any changes of the product data will result in a mismatch of the hash with the changed product data.
  • hashed product data from the scanned token on the blockchain is compared to the product data stored on servers. A result of a mismatch will let the consumer know that a product has had their product information changed.
  • the producer can include a statement addressing why product information has changed intentionally, for instance in the event of a product recall or defect. Optimizations such as utilizing merkle trees for numerous products' data in batches for groups of produced products is also utilized to minimize database load.
  • the content provided by the supply chain and/or the manufacturers for the instance of the product may include augmented reality (AR) content.
  • the AR content may be presented on the user device 110 after the instance of the product is authenticated.
  • the UI application 112 may detect (e.g., using one or more object recognition algorithms) that the instance of the product is included in an image captured by the user device 110.
  • the UI application 112 may then superimpose (e.g., overlay) the AR content on the image.
  • the UI application may detect the product within the image and generate a three- dimensional (3D) model that matches the placement of the instance of the product within the image in a 3D space.
  • additional AR features are unlocked such as personalized messages to the user or premium content such as exclusive videos and renderings. Additionally, unlocked features can also be available only after registering or collecting tokens of certain products.
  • the content may also include past and current ownership information of the instance of the product.
  • the content management module 210 may present the ownership chain of the instance of the product on the user device 110.
  • the content may also include user-generated content provided by previous and/or current owners of the instance of the product.
  • a current owner may access a user interface provided by the product verification module 132 and may upload user-generated content via the user interface.
  • the user-generated content may include data associated with the ownership of the instance of the product (e.g., enhancement, modifications done to the instance of the product by the owner, videos/audios recording ownership experience of the instance of the product, etc.).
  • an owner of the product may access the user-generated content from previous and current owners via the product verification application.
  • the type of content provided to the user device 110 may depend on whether the user device 110 is associated with a digital wallet that has possession of the token corresponding to the instance of the product.
  • the current owner of the instance of the product may access certain content (e.g., certain user-generated content from previous owners, certain proprietary data from the manufacturer, etc.) that is inaccessible by a non-owner.
  • the content management module 210 may select portions of the content from the blockchain in association with the instance of the product based on whether the requesting device has possession of the token.
  • the manufacturer of the instances of the product may continue to provide new content to the blockchain in association with the instances of the product even after the instances of the product have been sold to consumers.
  • the manufacturer server 120 via the UI provided by the product verification module 1 2, may add new content to the blockchain in association with the instances of the product for consumption by the owners or other people who scan the codes.
  • the new content may include promotional data for promoting the product or other related products from the manufacturer (e.g., discount offers, advertisements, etc.).
  • the manufacturers can directly communicate with their consumers and others who may be interested in their products (e.g., the people who scan the codes associated with different instances of the product).
  • the manufacturer may upload different promotional data to the blockchain at different times to provide new promotional content to the owners and other potential consumers of the product.
  • the product verification module 132 may enable the manufacturer to provide targeted promotional data.
  • the product verification module 132 may allow the manufacturer to provide different versions of promotional materials (e.g., for different products, for different discounts, for different incentives, etc.), and configurations for when the different versions of the promotional materials can be presented to user devices.
  • the configurations may be location-specific (e.g., show a particular promotional material when the requesting device is located within a certain geographical area, etc.), time-specific (e.g., show a particular promotional material when the request is made at a specific time, etc.), demographic-specific (e.g., show a particular promotional material when the requester is within a certain age-range, is a particular gender, has a certain income range, etc.) or dependent on any attribute of the requester and/or the requesting device.
  • location-specific e.g., show a particular promotional material when the requesting device is located within a certain geographical area, etc.
  • time-specific e.g., show a particular promotional material when the request is made at a specific time, etc.
  • demographic-specific
  • the configurations and the different versions of the promotional materials may be stored in the blockchain (or in a data storage linked to the blockchain) and may be retrieved by a product verification application of a user device as the product verification application scans a code corresponding to an instance of the product. Based on the configurations and attributes of the user device, the product verification application may select and present one or more of the promotional materials. For example, the product verification application may determine a location of the user device 110 that scans the code, a time of day when the code is scanned, attributes of a user of the user device (e.g., an age, a gender, an income, etc.), and/or other attributes, and may select the appropriate promotional materials based on the attributes. This way, the manufacturers can provide targeted advertisement to the public through the product verification platform.
  • Fig. 5B illustrates an example user interface 520 provided by the product verification module 132 that enables different entities (e.g., an entity within the supply chain of an instance of a product, a manufacturer, an owner of an instance of a product, a third- party, etc.) to provide content to the blockchain in association with the instance of the product.
  • the content may be received by the product verification module 132 via the user interface 520.
  • the product verification module 132 may store the content in the blockchain 262 in association with the instance of the product and may provide different users access to the content upon detecting an event (e.g., scanning of a code corresponding to the instance of the product, etc.).
  • an event e.g., scanning of a code corresponding to the instance of the product, etc.
  • Ownership For example, using the UI application 112, the user associated with a wallet may claim ownership of items (instances of products) via tokens (if this functionality is defined and enabled by the client minting the tokens). They can do this by transferring the token corresponding to the instance of the product to their personal wallet managed by the UI application 112, by requesting a token transfer within the UI application 112 via services provided by the product verification module 132. If they want to resell an item, they can transfer the token by cryptographically signing with their private key that they own a certain product - ownership can be verified by any other users (or through the use of a blockchain explorer connected to the ledger 262 if federated). Signing a product can be done by the UI application 112 via a simple push-button interface.
  • Client Rewards - Users can collect tokens on the products they own. Once they claim ownership of the items, rewards can be given out by the client to the user depending on several metrics. For instance, a consumer who bought 5 products from the client's store and claimed ownership of all the products will get a gift sent to them by the client or are invited to a product unveiling. Another example is where clients who own n-number of items claimed will have premium AR features unlocked for their product in the UI application 112. Or if users claim certain types of items will have specific rewards and discounts unlocked.
  • Trading - users who wish to participate can allow trading of claimed tokens.
  • the rewards system along with trading can incentivize users to trade tokens to claim rewards. Allowing cross-client trading using the ERC-721 standard between other tokenized items can allow users to generate a cross-product token trading market. If desirable, cross-token trading can also be performed if product verification module 132 creates tokens on Ethereum mainnet, allowing for token-for-crypto trading.
  • Example 1 - A car is tokenized by product verification module 132.
  • a consumer buys the car and claims ownership of the car's token, transferring the token to the consumer’s wallet.
  • the consumer puts the car on a third-party market and prove ownership by digitally signing with their digital wallet that they own that car.
  • Another user buys the car and gets the token transferred to the buyer’s wallet upon purchase.
  • the current owner who already owns the same brand of car, now owns two of those car tokens (their previous car and the second-hand car they just purchased).
  • the Ul application notifies them they are now eligible to go to the next car unveiling.
  • Example 2 - Another example is a consumer buys many different cosmetic products that are all tokenized by the product verification module 132.
  • the consumer claims the tokens, but rather than trading them for rewards from the cosmetic shop, the consumer trades tokens with another user for tokens from a boutique bag store in order to claim a significant discount for a bag.
  • the user they traded with who now claims the cosmetic product tokens gets a discount on their next cosmetics purchase.
  • Example 3 A consumer buys a pair of pants tokenized by the product verification module 132. However, rather than trading with another user for other tokens, the consumer decide that she wants a fraction of a Bitcoin. She goes on an exchange and trade the token for Bitcoin, which she receives via her digital wallet.
  • Entity registration on the product verification system in a public and private blockchain implementation There are two implementations of how the entities in the supply chain are correlated with the instances of the products. The first case is for a private blockchain and the second is for a public blockchain network.
  • the product verification module 132 is registering the supply chain entities to their wallets.
  • a private federated chain would be selected for many different reasons. These would include:
  • the product verification module 132 creates wallets equivalent to the number of entities in each supply chain and registers the entities by storing their relevant information (name, role in the supply chain such as producer, manufacturer, shipper, licenses, certifications, etc.), and their associated wallet address onto a database.
  • relevant information name, role in the supply chain such as producer, manufacturer, shipper, licenses, certifications, etc.
  • their relevant information name, role in the supply chain such as producer, manufacturer, shipper, licenses, certifications, etc.
  • their associated wallet address onto a database.
  • All transactional history of the tokens is stored by a blockchain transaction indexer stored on a database (within the data storage 260).
  • the indexer is attached to a blockchain explorer, which organizes the data into wallet histories, token histories, and token inspectors.
  • a genesis smart contract (or chaincode contract) will create all tokens within a genesis wallet and send them to the wallet that represents the first entity in the supply chain. When the first entity is finished with their part in the supply chain, they transfer the token to the next wallet owned by the next entity in the supply chain.
  • the product verification system 132 or the white-labeler will create and hold all wallets associated with entities of the supply chain.
  • Any action performed by wallets i.e., transferring tokens received to another entity
  • the product verification module 132 gives entities their respective private keys for their associated wallet and a light wallet client
  • clients pass tokens to the next entity's wallet in the supply chain.
  • the passing of the token from wallet to wallet mirrors the product moving from supply chain entity to the next entity, effectively storing a tokenized product's history that mirrors the physical product's history.
  • the product verification module 132 In the case where the product verification module 132 or the white-labeler holds all of the wallet's private keys, during manufacturing process, the product verification module 132 will pass the tokens through each wallet, mirroring the transfer of the product through the supply chain on behalf of the entities and effectively recording the supply chain history on the chain.
  • the product verification module 132 can also create a multi- sig wallet where both the product verification module 132 and the white labeler need to sign off on every transaction to guarantee that the product has gone through proper processes before sending the tokens through the sequence of wallets.
  • the wallets could be created independently by entities, such as through Ledger, Metamask, and MEW and registered on a smart contract that maintains a record for every entity for a specific supply chain process.
  • a new smart contract would be created for every new group of entities.
  • Entity metadata would be stored on a distributed file system such as IPFS in addition to the product verification module 132 to guarantee transparency as the product verification module 132 would not be able to edit or change the entity metadata.
  • Token transaction history would be cataloged by public blockchain explorers such as etherscan.io or c-hound.ai databases, and optionally stored on the data storage 260 for fail- over reliability or for speed of retrieval on authentication.
  • Entities would hold onto their own private keys to their wallets and would be responsible for sending tokens through to the next in line for the supply chain using their choice of wallet, removing the possibility of the product verification module 132 or the whitelabeler as a possible bad actor in the process.
  • a smart contract will create all tokens and place them in a genesis wallet, with a smart contract automating the process of sending the tokens to the first supply chain entity in batches as they produce their goods and offload products to other entities.
  • the QR/NFC chip When the QR/NFC chip is scanned the token authentication process begins.
  • the token information is first sent from the UI application 112 to the product verification module 132.
  • the process of the retrieving the supply history and matching it with specific entities occurs in order:
  • the token transaction history is retrieved from the indexed database linked to a blockchain explorer.
  • the transaction data includes all previous wallets the token was transferred from, and the sequence in order of how the token was transferred. Date information is also retrieved.
  • the product verification module 132 matches the token wallet addresses with entity metadata (such as name of the entity and their role in the supply chain) and retrieves it
  • the product verification module 132 sends the retrieved information to the
  • the product information and supply chain are arranged in a graphical chain, where the user can select into a specific entity to read more information.
  • Information can be listed on the entity such as: name, date established, certifications, location, what they are classified as in the supply chain (source/producer/manufacturer/packager, etc.) product, date of entities' processes, additional information the entity, etc.
  • Fig. 6 illustrates a process 600 for issuing tokens for instances of a product according to various embodiments of the disclosure.
  • the process 600 may begin by obtaining (at step 605) data associated with a product.
  • the verification manager 202 may obtain product information associated with a product from the manufacturer via a user interface provided on the manufacturer server 120.
  • the process 600 then stores (at step 610) the data in association with a network address.
  • the verification manager 202 may store the data in the data storage 260.
  • the verification manager may also generate a network address (e.g., a URI, etc.) that points to the data stored in the data storage 260.
  • a network address e.g., a URI, etc.
  • the process 600 generates (at step 615) multiple tokens for multiple copies of the product. Based on the number of anticipated instances of product being manufactured by the manufacturer, the minting module 204 may issue (e.g., mint) tokens, where each token may correspond to each anticipated instance of the product.
  • the process 600 then sends (at step 620) the tokens to a genesis wallet and performs (at step 625) transactions to transfer the tokens to a first entity in the supply chain of the product.
  • the verification manager 202 may initially transfer the tokens to a genesis wallet 264 associated with the product verification module 132. The verification manager 202 may then transfer the tokens to a wallet associated with a first entity in the supply chain of the product.
  • Fig. 7 illustrates a process 700 for authenticating an instance of a product based on a token according to various embodiments of the disclosure.
  • the process 700 may begin by obtaining (at step 705) a code that is scanned by a user device.
  • the product verification module 132 may receive a request for authenticating an item from a UI application 112 of the user device 110.
  • the process 700 then retrieves (at step 710) device attributes from the user device.
  • the authentication module 204 may retrieve attributes from the user device 110, such as a geographical location, a network address, a color depth of a display, a device identifier, or other device specific information.
  • the process 700 determines (at step 715) a token based on the code and determines (at step 720) whether the token exists in the blockchain. For example, the authentication module 206 may use an index to map the code to a token. The authentication module 206 may traverse the ledger 262 to determine whether transaction blocks associated with the token exists within the ledger 262. The process 700 denies (at step 740) an authentication request when it is determined that the token does not exist in the block chain. [000135] The process 700 then determines (at step 725) if the token is verified and denies (at step 740) the authentication request when the token is not verified.
  • the counterfeit detection module 208 may use the device attributes and a history of previous authentication requests to determine a likelihood that the item is a counterfeit. If it is determined that the likelihood that the item is a counterfeit exceeds a threshold, the verification manager 202 denies the authentication request. On the other hand, if the token is verified at step 725, the process 700 generates (at step 730) content based on data associated with the token and causes (at step 735) the user device to present the content.
  • Fig. 8 is a block diagram of a computer system 800 suitable for implementing one or more embodiments of the present disclosure, including the service provider server 130, the manufacturer server 120, and the user device 110, and the vendor servers 180 and 190.
  • the user device 110 may include a mobile cellular phone, personal computer (PC), laptop, wearable computing device, etc. adapted for wireless communication
  • each of the service provider server 130 and the manufacturer server 120 may include a network computing device, such as a server.
  • the devices/servers 110, 120, 130, 180, and 190 may be implemented as the computer system 800 in a manner as follows.
  • the computer system 800 includes a bus 812 or other communication mechanism for communicating information data, signals, and information between various components of the computer system 800.
  • the components include an input/output (I/O) component 804 that processes a user (i.e., sender, recipient, service provider) action, such as selecting keys from a keypad/keyboard, selecting one or more buttons or links, etc., and sends a corresponding signal to the bus 812.
  • the I/O component 804 may also include an output component, such as a display 802 and a cursor control 808 (such as a keyboard, keypad, mouse, etc.).
  • the display 802 may be configured to present a login page for logging into a user account or a checkout page for purchasing an item from a merchant.
  • An optional audio input/output component 806 may also be included to allow a user to use voice for inputting information by converting audio signals.
  • the audio FO component 806 may allow the user to hear audio.
  • a transceiver or network interface 820 transmits and receives signals between the computer system 800 and other devices, such as another user device, a merchant server, or a service provider server via a network 822, such as network 160 of Fig. 1 . Tn one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable.
  • a processor 814 which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on the computer system 800 or transmission to other devices via a communication link 824.
  • the processor 814 may also control transmission of information, such as cookies or IP addresses, to other devices.
  • the components of the computer system 800 also include a system memory component 810 (e.g., RAM), a static storage component 816 (e.g., ROM), and/or a disk drive 818 (e.g., a solid-state drive, a hard drive).
  • the computer system 800 performs specific operations by the processor 814 and other components by executing one or more sequences of instructions contained in the system memory component 810.
  • the processor 814 can perform the token issuance and item authentication functionalities described herein according to the processes 600 and 700.
  • Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to the processor 814 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media.
  • non-volatile media includes optical or magnetic disks
  • volatile media includes dynamic memory, such as the system memory component 810
  • transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise the bus 812.
  • the logic is encoded in non-transitory computer readable medium.
  • transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.
  • Some common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.
  • execution of instruction sequences to practice the present disclosure may be performed by the computer system 800.
  • a plurality of computer systems 800 coupled by the communication link 824 to the network e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks
  • the network e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks
  • various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software.
  • the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure.
  • the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure.
  • software components may be implemented as hardware components and vice-versa.
  • Software in accordance with the present disclosure may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
  • the various features and steps described herein may be implemented as systems comprising one or more memories storing various information described herein and one or more processors coupled to the one or more memories and a network, wherein the one or more processors are operable to perform steps as described herein, as non-transitory machine-readable medium comprising a plurality of machine-readable instructions which, when executed by one or more processors, are adapted to cause the one or more processors to perform a method comprising steps described herein, and methods performed by one or more devices, such as a hardware processor, user device, server, and other devices described herein.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Security & Cryptography (AREA)
  • Game Theory and Decision Science (AREA)
  • Tourism & Hospitality (AREA)
  • General Health & Medical Sciences (AREA)
  • Operations Research (AREA)
  • Educational Administration (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Manufacturing & Machinery (AREA)
  • General Engineering & Computer Science (AREA)
  • Primary Health Care (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Sont présentés des procédés et des systèmes permettant de fournir une authentification instantanée d'un produit et une expérience d'utilisateur améliorée avec le produit par l'intermédiaire de technologies de chaîne de blocs. Un système de vérification de produit utilise des technologies de chaîne de blocs pour suivre le processus de chaîne d'approvisionnement de chaque instance (par exemple, chaque copie) d'un produit. Lors de la réception d'une demande d'authentification d'un article, un code fourni avec l'article est balayé. Un jeton correspondant à une instance d'un produit est déterminé sur la base du code. Le système de vérification de produit traverse une chaîne de blocs pour accéder à des données associées au jeton. L'article est authentifié sur la base des données. Un contenu supplémentaire fourni par la chaîne d'approvisionnement et/ou le fabricant de l'instance du produit peut être présenté sur un dispositif utilisateur en réponse à l'authentification de l'article.
PCT/US2023/015682 2022-03-22 2023-03-20 Système d'authentification de produit basé sur une chaîne de blocs WO2023183256A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/700,938 2022-03-22
US17/700,938 US20220215382A1 (en) 2020-02-26 2022-03-22 Blockchain-based product authentication system

Publications (1)

Publication Number Publication Date
WO2023183256A1 true WO2023183256A1 (fr) 2023-09-28

Family

ID=88101841

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/015682 WO2023183256A1 (fr) 2022-03-22 2023-03-20 Système d'authentification de produit basé sur une chaîne de blocs

Country Status (1)

Country Link
WO (1) WO2023183256A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120066003A1 (en) * 2008-05-30 2012-03-15 Collier Ronald L Automobile sales training and promotion system
US20210090449A1 (en) * 2019-09-23 2021-03-25 Revealit Corporation Computer-implemented Interfaces for Identifying and Revealing Selected Objects from Video
US20210264444A1 (en) * 2020-02-26 2021-08-26 Byte to Byte LLC Blockchain-based product authentication system
US11201981B1 (en) * 2016-06-20 2021-12-14 Pipbin, Inc. System for notification of user accessibility of curated location-dependent content in an augmented estate
US20220075845A1 (en) * 2020-05-18 2022-03-10 Best Apps, Llc Computer aided systems and methods for creating custom products
US20220215382A1 (en) * 2020-02-26 2022-07-07 Byte to Byte LLC Blockchain-based product authentication system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120066003A1 (en) * 2008-05-30 2012-03-15 Collier Ronald L Automobile sales training and promotion system
US11201981B1 (en) * 2016-06-20 2021-12-14 Pipbin, Inc. System for notification of user accessibility of curated location-dependent content in an augmented estate
US20210090449A1 (en) * 2019-09-23 2021-03-25 Revealit Corporation Computer-implemented Interfaces for Identifying and Revealing Selected Objects from Video
US20210264444A1 (en) * 2020-02-26 2021-08-26 Byte to Byte LLC Blockchain-based product authentication system
US20220215382A1 (en) * 2020-02-26 2022-07-07 Byte to Byte LLC Blockchain-based product authentication system
US20220075845A1 (en) * 2020-05-18 2022-03-10 Best Apps, Llc Computer aided systems and methods for creating custom products

Similar Documents

Publication Publication Date Title
US11720907B2 (en) Blockchain-based product authentication system
US20220215382A1 (en) Blockchain-based product authentication system
US12086794B2 (en) Tokenization platform
US20220058633A1 (en) Tokenization platform
US11823121B2 (en) Systems and methods for processing, securing, and communicating industrial commerce transactions
US20160098723A1 (en) System and method for block-chain verification of goods
CA3177552A1 (fr) Billetterie facilitee par jeton, campagnes de prevente facilitees par jeton et gestion des droits numeriques pour jetons numeriques
US20220370778A1 (en) Robotic tattooing machine with an optical tattoo analyzer to analyze tattoos associated with non-fungible tokens
US20230123993A1 (en) System for validating ticket transactions via ticket nfts and methods for use therewith
US20230222490A1 (en) NFT PLATFORM FOR UPDATING NFTs AND METHODS FOR USE THEREWITH
US20230161847A1 (en) System and method for identifying ownership and managing transfer of ownership of premium goods
US20240185229A1 (en) Systems and methods for creating and using sustainability tokens
US20240033639A1 (en) Collecting coupon nft via a client device and methods for use therewith
JP2023061082A (ja) 物品の所有権管理システム及び所有権管理用識別コード
US20230396430A1 (en) Tag-based authentication system and methods for use therewith
US20230394455A1 (en) Nft transactions via nft and pos platforms and methods for use therewith
WO2023183256A1 (fr) Système d'authentification de produit basé sur une chaîne de blocs
US20230222519A1 (en) System for issuing nfts based on ticket data and methods for use therewith
US20230396442A1 (en) Nft-based authentication system for tagged objects and methods for use therewith
WO2023192380A1 (fr) Systèmes et procédés de création d'un jumeau physique de jnf authentifié et de génération d'une revendication de jnf original à partir d'un objet physique
KR20230074875A (ko) 물품의 소유권 관리 시스템 및 소유권 관리 식별코드

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23775519

Country of ref document: EP

Kind code of ref document: A1