TAG-BASED AUTHENTICATION SYSTEM AND METHODS FOR USE THEREWITH

An authentication system (AS) includes a radio frequency (RF) tag reader and operates by: assigning pairing data to be associated with an RF tag and a corresponding object to be authenticated wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number; pairing the authentication system to the RF tag associated with the object; receiving a request to authenticate the object; and when first tag hash matches first tag hash check data, generating first read event data that indicates authentication of the object.

TECHNICAL FIELD

The present disclosure relates to processing systems and applications used in the collection, generation, display and use of non-fungible tokens (NFTs) or other digital tokens.

DETAILED DESCRIPTION

FIG.1Apresents a block diagram representation of an example system in accordance with various examples. In particular, a system850is presented that includes an NFT collection platform800that communicates with client devices825via a network115. The network115can be the Internet or other wide area or local area network, either public or private. The client devices825can be computing devices such as laptops, smartphones, smart watches, tablets, desktops, or other computing devices associated with users, for example, buyers, sellers, collectors and/or users of NFTs.

NFT creation and ownership is growing worldwide. Existing platforms provide tools to create NFTs, marketplaces for buying and selling NFTs and wallets to securely hold them. Many NFT purchasers however, view NFTs similarly to cryptocurrency, purely as financial investments to be collected and later sold. Unlike cryptocurrencies which are fungible tokens, NFTs have a non-fungible (e.g. unique or limited) component that can correspond to photographs, graphics, art, video, games or other media or imagery that can be displayed, used in authentication and/or to provide other support for transactions and/or used in game play and for other utilitarian purposes, etc.

In the example shown, the NFT collection platform800includes a client device interface802for interacting with the client devices825, NFT marketplace tools804, NFT wallet tools806, NFT generation tools808, NFT collection display tools810, one or more games812that can be played using NFTs that have been collected including game NFTs that include and/or otherwise associated with, or correspond to, playable game content, and a database814for storing user and account information, preferences, display settings and other data associated with users of the NFT collection platform800. The NFT collection platform800can include or be implemented via one or more servers, a cloud computing system, an InterPlanetary File System (IPFS) or other decentralized or distributed computer system of individual computers and/or nodes and/or a centralized computing system.

For example, the client device interface802can operate in conjunction with each client device825and via network115to generate a graphical user interface. This graphical user interface is based on display data generated by the NFT collection platform800in a format for display on a display device associated with the client devices825. This graphical user interface generates input data that is received by the NFT collection platform800from the client devices825in response to user interaction with the graphical user interface.

In various examples, the NFT collection platform800can serve the needs of a collector of NFTs by providing a system that offers new experiences that support various collector and/or use behaviors in the NFT world and metaverse including the collection, display, and use of NFTs and their corresponding content. The NFT collection display tools810can include a high-fidelity customizable page builder so each collector can personalize and display their NFTs in an environment. The NFT collection platform800can provide and support a collection social media site that, for example, is similar to MySpace, Facebook, or OnlyFans, but specifically directed to the arrangement, posting, sharing and/or display of collections of NFTs.

In the most basic mode of operation, the NFT collection platform800improves the technology of NFT systems by allowing the user to collect, arrange and display NFTs they have purchased so that the user, and other users, can enjoy and admire the NFTs they have collected. The NFT collection platform800not only allows users to curate, display and use their collections, to play games associated with their NFTs and/or also allows users to create a social/professional profile of their NFT property—enabling users to get creative with how their collections are presented, used and displayed. In addition, when a group of NFTs is collected and/or when a personalized/curated collection page, set and/or collection display is built, the NFT collection platform800improves the technology of NFT systems by allowing the user to mint a new “collection NFT” using blockchain-based, distributed computer network, and/or other crypto-based NFT creation techniques, for example and authenticated based on the user's ownership of the underlying NFTs.

Furthermore, the NFT collection platform800allows users to buy, sell, loan, borrow and trade NFTs with other users, including their own collection NFTs created based on their own collections. In various examples, the NFT collection platform800may not include a NFT creator, marketplace or wallet itself. The NFT generation tools808, NFT wallet tools806and NFT marketplace tools804can reside on the NFT collection platform800and interface with one or more NFT wallet systems820, NFT marketplaces822and/or NFT creation systems824to enable transactions/interactions/abilities at a metaverse level, offering collectors new and unique experiences, pre and post purchase, across all different NFT's and blockchains in one place. The NFT collection platform800improves the technology of NFT systems by allowing the user to perform the functions above in a fashion, that can be blockchain, wallet, and marketplace agnostic.

It should be noted that the system850can operate via blockchain-based technologies. In blockchain, a growing list of records, called “blocks”, are linked together using cryptography and spread over a decentralized computer system/network or other distributed network of participants. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a Merkle tree). The timestamp proves that the transaction data existed when the block was published in order to get into its hash. As blocks each contain information about the block previous to it, they form a chain, with each additional block reinforcing the ones before it. Therefore, blockchains are resistant to modification of their data because once recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks. The distributed nature of this process over different nodes, the contemporaneous nature of geographically distinct calculations, coupled with the extreme computational complexity of the required calculations means that these blockchain-based technologies cannot practically be performed by the human mind.

It should be noted, that while the NFT wallet system820, NFT marketplace822and NFT creation system824are shown as separate entities and as being external to the NFT collection platform800, other configurations are possible where two or more of these entities share a common platform and/or the functions and features of one or more of these entities can be incorporated within the NFT collection platform800itself.

It should also be noted that while client device interface802, NFT marketplace tools804, NFT wallet tools806, NFT generation tools808, NFT collection display tools810, games812and database814are shown as being internal to the NFT collection platform800, in other examples, any subset of the various elements of the NFT collection platform800can be implemented external to the NFT collection platform800and coupled to the other components via the network115. Furthermore, the NFT collection platform800can be implemented in a cloud computing configuration with any or all of the various elements of the NFT collection platform800implemented within the cloud.

The further operation of this system will be described in greater detail in conjunction with the figures that that follow, including many optional functions and features and examples thereof.

FIG.1Bpresents a block diagram representation of an NFT collection platform800in accordance with various examples. In particular, the NFT collection platform800includes a network interface820such as a 3G, 4G, 5G or other cellular wireless transceiver, a Bluetooth transceiver, a WiFi transceiver, UltraWideBand transceiver, WIMAX transceiver, ZigBee transceiver or other wireless interface, a Universal Serial Bus (USB) interface, an IEEE 1394 Firewire interface, an Ethernet interface or other wired interface and/or other network card or modem for communicating for communicating via the network115.

The NFT collection platform800also includes a processing module830and memory module840that stores an operating system (O/S)844such as an Apple, Unix, Linux or Microsoft operating system or other operating system, client device interface802, NFT marketplace tools804, NFT wallet tools806, NFT generation tools808, NFT collection display tools810, games812and database814. In particular, the O/S844, the client device interface802, NFT marketplace tools804, NFT wallet tools806, NFT generation tools808, NFT collection display tools810, and games812each include operational instructions that, when executed by the processing module830, cooperate to configure the processing module830into a special purpose device to perform the particular functions of the NFT collection platform800described herein.

The NFT collection platform800may include a user interface (I/F)862such as a display device, touch screen, key pad, touch pad, joy stick, thumb wheel, a mouse, one or more buttons, a speaker, a microphone, an accelerometer, gyroscope or other motion or position sensor, video camera or other interface devices that provide information to an administrator of the NFT collection platform800and that generate data in response to the administrator's interaction with NFT collection platform800.

The processing module830can be implemented via a single processing device or a plurality of processing devices. Such processing devices can include a microprocessor, micro-controller, digital signal processor, microcomputer, central processing unit, quantum computing device, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on operational instructions that are stored in a memory, such as memory840. The memory module840can include a hard disc drive or other disc drive, read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that when the processing device implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. While a particular bus architecture is presented that includes a single bus860, other architectures are possible including additional data buses and/or direct connectivity between one or more elements. Further, the NFT collection platform800can include one or more additional elements that are not specifically shown.

FIG.2presents a block diagram representation of an example client device in accordance with various examples. In particular, a client device825is presented that includes a network interface220such as a 3G, 4G, 5G or other cellular wireless transceiver, a Bluetooth transceiver, a WiFi transceiver, UltraWideBand transceiver, WIMAX transceiver, ZigBee transceiver or other wireless interface, a Universal Serial Bus (USB) interface, an IEEE 1394 Firewire interface, an Ethernet interface or other wired interface and/or other network card or modem for communicating for communicating via network115.

The client device825also includes a processing module230and memory module240that stores an operating system (O/S)244such as an Apple, Unix, Linux or Microsoft operating system or other operating system, NFT data246associated with one or more NFTs owned by the user, and/or a collection applications248. In particular, the O/S244and collection application248each include operational instructions that, when executed by the processing module230, cooperate to configure the processing module into a special purpose device to perform the particular functions of the client device825described herein.

The client device825also includes a user interface (I/F)262such as a display device, touch screen, key pad, touch pad, joy stick, thumb wheel, a mouse, one or more buttons, a speaker, a microphone, an accelerometer, gyroscope or other motion or position sensor, video camera or other interface devices that provide information to a user of the client device825and that generate data in response to the user's interaction with the client device825.

The processing module230can be implemented via a single processing device or a plurality of processing devices. Such processing devices can include a microprocessor, micro-controller, digital signal processor, microcomputer, central processing unit, quantum computing device, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on operational instructions that are stored in a memory, such as memory240. The memory module240can include a hard disc drive or other disc drive, read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that when the processing device implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. While a particular bus architecture is presented that includes a single bus260, other architectures are possible including additional data buses and/or direct connectivity between one or more elements. Further, the client device825can include one or more additional elements that are not specifically shown.

The client device825operates, via network interface220, network115and NFT collection platform800. In various examples, the client device825operates to display a graphical user interface generated based on display data from the NFT collection platform800, including corresponding screen displays. Furthermore, the graphical user interface can operate in response to interactions by a user to generate input data that is sent to the NFT collection platform800to control the operation of the NFT collection platform800and/or to provide other input.

It should be noted that while the client devices825and NFT collection platform800are shown as separate devices that communicate via the network115, it should be noted that any and all of the functionality attributed to the NFT collection platform800, including the NFT marketplace tools804, NFT wallet tools806, NFT generation tools808, NFT collection display tools810, games812, and database814, etc. can likewise be incorporate directly into the client device825. In this fashion, a client device825through the application of its operating system244and one or more applications can provide a graphical user interface to operate via network115but independently from any NFT collection platform to perform any of the functions and features described herein. In particular, the client device825can perform the functions of both the client device and the NFT collection platform800without requiring communications to be sent to the client device825from a NFT collection platform and communications sent to a NFT collection platform from the client device825.

FIG.3Apresents a flowchart representation of an example method in accordance with various examples. In particular, a method300for use in conjunction with any of the functions and features described herein for generating a collection NFT based on NFTs in a user's collection.

Step302includes importing, via a network interface, a plurality of NFTs associated with the user of the client device. Step304includes generating, via a processor and in response to user interactions with the graphical user interface, display data associated with a customized collection display that contains the plurality of NFTs. Step306includes sending, via the network interface, the display data associated with the customized collection display via the client device of the user. Step308includes facilitating creation of a collection NFT corresponding to the customized collection display that contains the plurality of NFTs.

FIGS.3B-3F and3Hpresent pictorial representations of example screen displays. In particular, screen displays of a graphical user interface generated based on display data from the NFT collection platform800are shown. In the example below, three NFTs are used to design and create a new collection NFT based on a common theme, the 1999 Chicago Bulls team in the National Basketball association.

InFIG.3B, the user “Bruce Stuckman” is logged into the NFT collection platform800. The user has interacted with NFT wallet tools, such as NFT wallet tools804, to import NFTs100and102from his wallet residing in NFT wallet system820. In this example, the NFTs100and102are blockchain authenticated original photographs depicting two different images of the 1999 Chicago Bulls.

InFIG.3C, the user has interacted with the NFT marketplace tools, such as NFT marketplace tools804, to select a new NFT104for purchase via an NFT marketplace such as NFT marketplace822. InFIG.3D, the wallet tools are used again, this time to export the NFT104to the user's wallet. InFIG.3E, the user has selected and used NFT collection display tools, such as NFT collection display tools810, to create a customized collection display110contain all three 1999 Chicago Bulls-related NFTs he now owns. In the example shown, the user has “dragged and dropped” NFTs he owns in a custom display window and has sized and arranged them into the particular collage that is shown. In other examples, the NFT collection display tools810can operate, based on metadata associated with the NFTs of a user indicating content, theme, color themes, subject matter, dates of creation, authorship, ownership, prior ownership, number of prior owners, size, resolution, and other NFT information and metadata, to automatically generate arrangements of custom collection display110that may be accepted by the user and/or that may be further arranged by the user to create the final customized collection display110.

InFIG.3F, the user has selected NFT generation tools, such as NFT generation tools808, in order to facilitate, via NFT creation system824for example, the creation of a collection NFT from the customized collection display110.

FIG.3Gpresents a flow diagram representation of an example process. In the example shown, the collection NFT120is created from the customized collection display110. As previously discussed, the NFT generation tools can operate by, for example, first authenticating the user's rights in the three NFTs and then creating, via NFT creation system824, a new NFT of the unique customized image with its own blockchain authentication. In various examples, the collection NFT120can contain metadata indicating, for example attributions to the sources of the original NFTs in the collection, the creator of the collection NFT, a date of creation, promotion data and coupons related to offers, privileges and/or discounts, title data with respect to title to tangible or intangible real or personal property, warrant data with respect to tangible or intangible real or personal property, transaction data regarding one or more transactions, and/or other metadata. This metadata can be protected via the blockchain and/or other crypto-based NFT creation technology that is employed to create and protect the collection NFT itself—with or without associated image data. InFIG.3H, the wallet tools are used again, this time to export the collection NFT120to the user's wallet.

FIG.3Ipresents a flowchart representation of an example method in accordance with various examples. In particular, a method310is presented for use in conjunction with any of the functions and features described herein for generating a collection NFT based on NFTs in a user's collection.

Step312includes importing, via a network interface, a plurality of NFTs associated with the user of the client device. Step314includes generating, via a processor and in response to metadata associated with the plurality of NFTs, display data associated with a customized collection display that contains the plurality of NFTs. Step316includes sending, via the network interface, the display data associated with the customized collection display via the client device of the user. Step318includes facilitating creation of a collection NFT corresponding to the customized collection display that contains the plurality of NFTs.

FIG.4Apresents a flowchart representation of an example method. In particular, a method400for use in conjunction with any of the functions and features described herein in generating a collection NFT based on at least one NFT accessed via a temporary micro-loan.

Step402includes facilitating, via a processor and in response to user interactions with the graphical user interface, a temporary micro-loan of at least one NFT. Step404includes generating, via the processor and in response to user interactions with the graphical user interface, display data associated with a customized collection display that contains a plurality of NFTs including the at least one NFT. Step406includes sending, via the network interface, the display data associated with the customized collection display via the client device of the user. Step408includes facilitating creation of a collection NFT corresponding to the customized collection display that contains the plurality of NFTs including the at least one NFT.

FIG.4Bpresents a pictorial representation of an example screen display. In particular, the user has used the marketplace tools to select NFTs100-1,102-1, and104-1. Instead of putting these NFTs up for purchase, the original owners have made them available for temporary micro-loan. This process allows the users can engage to, in exchange for a fee, “borrow” NFTs in order to create a collection NFT. After the Collection NFT is created, or upon the expiration of some predetermined time period (such as 15 minutes, 30 minutes, an hour, a day, etc.) the micro-loaned NFT(s) are returned, expire, deleted or destroyed. Transaction fees apply, a portion of which can be credited to the original NFT owner, the author, including an upfront cost, reward-based payment based on the use and/or performance of the micro-loaned NFT etc. In the alternative, a fixed fee could be charged to the user and credited to the original NFT owner. In various examples, the NFT collection platform800may be configured to operate with a single user and/or within a single wallet, and/or to otherwise prohibit the sale or borrowing of micro-loaned NFTs to avoid dilution of the value of the original itself. Furthermore, original and/or derivative NFTs can include restrictions on the total number of micro-loan transactions, the number of simultaneous/contemporaneous micro-loans, restrictions on types of microloan transactions such as normal use loans, staking loans, death match loans, loans less than a predetermined length of time, loans greater than a predetermined length of time, etc.

Consider the following example where an NFT is put up for loan. The proposed loan transaction can include restrictions including an expiration time and/or date, one or N time use in creating a collection NFT or in a game, tournament or challenge, etc. Once the loan is accepted by the borrower, an additional NFT, such as a derivative NFT of the original NFT being loaned, is created on a side chain, layer1or2blockchain (or “parachain”) that can be different from (and/or independent from) the blockchain used to create the original NFT. This new NFT can be created and transferred to the wallet of the borrower via a smart contract that is based on the restrictions. A cryptocurrency market can be used to fund the transaction and/or to collateralize the micro-loan. The new NFT can then be set via the smart contract to automatically expire (e.g. be deleted from the wallet, destroyed or otherwise disabled), when the restrictions are met. In this fashion, if the purpose of the micro-loan is the creation of a collection NFT, the borrowed NFT can automatically expire once the collection NFT is created. It should be noted that the collection NFT can be created via the same blockchain platform (e.g. Ethereum) used to create the original NFT (e.g. not the parachain).

FIG.4Cpresents a flow diagram representation of an example process where a collection NFT120-1is generated based on a customized collection display110-1created by the user based on the borrowed NFTs100-1,102-1and104-1. In various examples, the collection NFT120-1metadata can also indicate the original sources of the micro-loans as well as the micro-loaned status of NFTs100-1,102-1and104-1. While not expressly shown, the collection NFTs based on one or more micro-loaned NFTs, can be created with a visual indication of the original vs. micro-loaned status of the NFTs as appropriate.

FIG.5Apresents a flowchart representation of an example method. In particular, a method1300for use in conjunction with any of the functions and features previously described facilitates the collection of endorsements associated with an NFT. Step1302includes importing, via a network interface, an NFT associated with the user of the client device. Step1304includes collecting, via a processor and in response to user interactions with the graphical user interface, endorsement data associated with the NFT. Step1306includes generating, via the processor and in response to user interactions with the graphical user interface, display data associated with a customized collection display that contains the NFT and the endorsement data. Step1308includes sending, via the network interface, the display data associated with the customized collection display via the client device of the user. Step1310includes facilitating creation of a collection NFT corresponding to the customized collection display.

FIGS.5B and5Cpresent pictorial representations of example screen displays. InFIG.5B, the user is interacting with the graphical user interface to use the NFT marketplace tools to seek an endorsement for a selected NFT. After an endorsement in the form of a signature has been received it can be appended to the customized collection display of the NFT. InFIG.5C, the user interacts with the NFT generation tools to generate a collection NFT that includes both the NFT and the signature. In various examples, this collection NFT120-6metadata can also indicate an attribution associated the endorsement itself. Furthermore, the endorsement itself can be an original NFT, a derivative NFT, a micro-loaned NFT or other NFT.

FIG.6presents a block diagram/flow representation of an example of NFT generation. In the example shown, NFT generation tools808operate to convert display data1502and other data1504into an NFT1506. The display data1502can correspond to an original NFT, borrowed (e.g. temporary micro-loaned) NFT, a derivative NFT, a customized collection display110, an original image, and/or other derivatives or micro-loans thereof or other display or image data. In various examples, the NFT generation tools808can operate to verify the credentials of any NFTs whose images are contained in the display data1502, prior to creating the NFT1506. In this fashion, derivative NFTs can only be created when the source NFT or NFTs are verified—preventing the creation of unauthorized or counterfeit NFTs.

The other data1504, can be image data including signatures and other endorsement images, visual indications of derivative series, originality classification, attributions, or other image data, metadata of all kinds including metadata indicating one or more originality classifications, attributions, endorsement data, other derivative data indicating the series number and total number in a derivative series, restrictions on micro-loans or other derivatives, restrictions on derivatives with artistic effects, restrictions that derivatives must include attributions to the original source, restrictions on numbers of derivatives or micro-loans or the sizes of derivative series, restrictions on the creation of collection NFTs, the number of collection NFTs, the creation of collection NFTs including NFTs from other sources, from prohibited sources or with prohibited content, geographical restrictions, time restrictions (e.g., can be used to create derivatives or collection NFTs or can be temporarily micro-loaned for 1 month, one year, etc., other restrictions and/or other data associated with, or to be associated with, the display data1502.

This other data1504can be used to generate an NFT and/or combined with the display data1502to create a dataset that includes both the display data1502and the other data1504. This other data1504or combined dataset can be protected via the blockchain and/or other crypto-based NFT creation technology that is employed by the NFT generation tools808and via the NFT creation system824to create and protect the new NFT1506itself. It should be noted that the NFT1506can include a single derivative or a number of derivatives, including a limited series of derivatives. It should be noted further that some or all of the other data1504, including restriction data and/or attribution data, can be derived from one or more original NFTs whose images are associated with the display data1502. Furthermore, some or all of the other data1504can be generated in response to user interactions with a graphical user interface generated in conjunction with the NFT collection platform800.

FIG.7presents a block diagram representation of an example system. In particular, a system2850is presented that includes an NFT distribution platform2800that communicates with client devices825via a network115. The network115can be the Internet or other wide area or local area network, either public or private. The client devices825can be computing devices associated with users, for example, buyers, sellers, collectors, game players and/or other users of NFTs.

In the example shown, the NFT distribution platform2800includes a client device interface2802for interacting with the client devices825, NFTs2804to be distributed, and an operating system2844. One or more of the NFTs2804can have geographical restrictions as to distribution that are either part of the NFTs themselves or have restriction data that is stored separately.

The NFT distribution platform2800includes a network interface2820such as a 3G, 4G, 5G or another cellular wireless transceiver, a Bluetooth transceiver, a WiFi transceiver, UltraWideBand transceiver, WIMAX transceiver, ZigBee transceiver or other wireless interface, a Universal Serial Bus (USB) interface, an IEEE 1394 Firewire interface, an Ethernet interface or other wired interface and/or other network card or modem for communicating for communicating via the network115.

The NFT distribution platform2800also includes a processing module2830and memory module2840that stores an operating system (O/S)2844such as an Apple, Unix, Linux or Microsoft operating system or another operating system, the client device interface2802, and the NFTs2804. The O/S2844and the client device interface802each include operational instructions that, when executed by the processing module830, cooperate to configure the processing module830into a special purpose device to perform the particular functions of the NFT distribution platform2800described herein.

The NFT distribution platform2800may include a user interface (I/F)2862such as a display device, touch screen, key pad, touch pad, joy stick, thumb wheel, a mouse, one or more buttons, a speaker, a microphone, an accelerometer, gyroscope or other motion or position sensor, video camera or other interface devices that provide information to an administrator of the NFT distribution platform2800and that generate data in response to the administrator's interaction with NFT distribution platform2800.

The processing module2830can be implemented via a single processing device or a plurality of processing devices. Such processing devices can include a microprocessor, micro-controller, digital signal processor, microcomputer, central processing unit, quantum computing device, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on operational instructions that are stored in a memory, such as memory2840. The memory module2840can include a hard disc drive or other disc drive, read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that when the processing device implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. While a particular bus architecture is presented that includes a single bus2860, other architectures are possible including additional data buses and/or direct connectivity between one or more elements. Further, the NFT distribution platform2800can include one or more additional elements that are not specifically shown.

For example, the client device interface2802can operate in conjunction with each client device825and via network115to generate a graphical user interface. This graphical user interface is based on display data generated by the NFT distribution platform2800in a format for display on a display device associated with the client devices825. This graphical user interface generates input data that is received by the NFT distribution platform2800from the client devices825in response to user interaction with the graphical user interface.

In various examples, the NFT distribution platform2800can operate to respond to input data from client devices in the form of read requests for NFTs and geolocation data such as GPS coordinates, connection to or proximity with a network element of network115or other location data indicating a location of the client device825. The NFT distribution platform2800sends the requested NFT(s) to the requesting client device—only when the geolocation data conforms with restriction data—for example, when the geolocation data indicates a position of the requesting client device within a limited area or proximity indicated by the restriction data.

FIG.8presents a block diagram representation of an example client device. In particular, a client device825-1is presented that functions similarly to client device825, and includes several elements of client device825that are referred to by common reference numerals. The client device825-1is capable of operating to client device825described herein.

In addition, the memory module240includes a wallet application (app)250that is capable of engaging in financial transactions including credit card transactions and traditional digital payments, is capable of holding crypto-currency and engaging in crypto-currency transactions and is further capable of storing one or more NFTs that are either original NFTs, derivative NFTs, borrowed (temporarily micro-loaned) NFTs, collection NFTs and/or combinations thereof. In various examples, the wallet app250is capable of operating in conjunction with the NFT collection platform800, the NFT distribution platform2800, the NFT wallet system820, the NFT marketplace822, and/or the NFT creation system824via network115.

As will be understood by one skilled in the art, unlike a normal wallet, which can physically hold cash, credit cards, etc., NFT wallets “store” NFTs by storing the NFT data necessary to access the NFT. So, even though a wallet can be said to store an NFT, technically the NFT content is stored on the blockchain, which can only be accessed via the NFT data in the wallet. This NFT data includes metadata, other off-chain data corresponding to the NFT and in particular, a private key. This private key can be considered an indicator of ownership of the NFT and is required to access the NFT via the blockchain. If the NFT data (including the private key) is lost, the NFT can no longer be accessed—and the NFT is itself “lost” for all intents and purposes, even though it remains immutably stored on the blockchain.

Also, the memory module240includes one or more game apps252that represent either stand alone games of the client device825-1or that operate in conjunction with the games812of the NFT collection platform800and/or interface with the NFT distribution platform2800. This allows, for example, a user of client device825-1to engage in (e.g. play) games associated with NFT content, and engage in other activities that involve the acquisition, collection, display, distribution, and/or use of one or more NFTs that are either original NFTs, derivative NFTs, borrowed (temporarily micro-loaned) NFTs, collection NFTs and/or combinations thereof.

Furthermore, the network interface220includes one more geolocations elements222such as a GPS receiver, a ultra-wideband (UWB) transceiver, a Bluetooth transceiver and/or other component(s) that that facilitate the generation of geolocation data and/or facilitate other location-based services. Consider the case where the client device825is a smartphone or tablet and the wallet app250is an Apple or Android wallet or mobile wallet card that is in a Apple or Android wallet. Once the wallet app250is activated, NFTs can be easily added to the wallet. In addition, the wallet app250can access the location services of the device, and for example, generate push notifications regarding NFTs that are available near the current location.

In various examples, the geolocation data generating in such a fashion can facilitate the generation of geolocation data discussed in conjunction with the operation of NFT distribution platform2800. In particular, the NFT distribution platform2800can automatically detect the presence of the user at a venue based on geolocation data received from the user's client device825-1and automatically prompted the user to click to send a read request. In this fashion, the user can be geo-authorized, before the request. In other examples, the NFT distribution platform2800can distribute NFTs to client devices825based on payments, authentication and/or other criteria that does not rely on geolocation data.

Furthermore, while the client device825-1and NFT collection platform800(or NFT distribution platform) are shown as separate devices that communicate via the network115, it should be noted that any and all of the functionality attributed to the NFT collection platform800(or NFT distribution platform), including the NFT marketplace tools804, NFT wallet tools806, NFT generation tools808, NFT collection display tools810, games812, and database814, etc. can likewise be incorporate directly into the client device825. In this fashion, a client device825through the application of its operating system244and one or more applications can provide a graphical user interface to operate via network115but independently from any NFT collection platform to perform any of the functions and features described herein. In particular, the client device825can perform the functions of both the client device and the NFT collection platform800without requiring communications to be sent to the client device825from a NFT collection platform (or NFT distribution platform) and communications sent to a NFT collection platform (or NFT distribution platform) from the client device825.

In addition, NFT generation tools808can be used to protect, encrypt and/or authenticate any digital information that could be stored in the wallet app250, including for example rewards cards, coupons, movie tickets, event tickets, boarding passes, public transit cards, student ID cards, credit cards, debit cards, prepaid cards, and loyalty cards. In addition, the functionality of the wallet app250can be further expanded to protect other information such as vehicle titles, warranty cards, driver's licenses and other IDs, vaccination records, prescriptions, and/or other medical records, social security cards, financial records, authentication tokens, insurance cards, passwords, user IDs and/or other images and information of a personal and/or sensitive nature. Any of these types of digital information can be protected via an NFT or other blockchain transaction in conjunction, with or without associated image or display data, and with or without metadata and/or “other data” as that term has been used herein in association with the NFT generation tools808.

FIG.9Apresents a block diagram/flow representation of an example of NFT generation. In the example shown, an original metaverse real estate NFT4820corresponds to a portion/plot of real estate that is used in a game or metaverse application. An example is shown inFIG.9B. The original metaverse real estate NFT4820can be purchased by the user, created or leveled-up via game play or otherwise acquired by the user of a metaverse application or game.

The NFT generation tools808are used to generate a derivative NFT4824or other metaverse real estate NFT that is based on the improvements4822shown inFIG.9C. In the example shown the improvements4822correspond to a building or other structure, however, other real estate improvements can likewise be implemented. In various example, the derivative NFT4824with improvements shown inFIG.9Dcan be created on a parachain or other sidechain that is different from the blockchain on which the original metaverse real estate NFT4820resides or the same blockchain on which the original metaverse real estate NFT4820resides.

FIG.9Epresents a flowchart representation of an example method. In particular, a method4800is presented for use in conjunction with any of the functions and features described herein. Step4802includes receiving, via the processor, a metaverse real estate NFT associated with metaverse real estate. Step4804includes receiving, via the processor, improvements data associated with the metaverse real estate. Step4806includes facilitating creation of a derivative NFT associated with the metaverse real estate and having improvements associated with metaverse real estate.

FIG.10Apresents a block diagram/flow representation of an example of NFT generation. In the example shown, document image data4920and other data corresponding to a document are used to generate an authenticated document NFT4924via the NFT generation tools808. These authenticated document NFTs4924can be stored in an NFT wallet associated with the mobile phone or other client device associated with the user and can be used, for example, in place of coupons, cards, legal documents, medical documents, financial documents, IDs, credit cards, licenses and/or other important documents associated with a user that normally exist in non-digital, e.g. paper or plastic form. The authenticated document NFT4924can be used to prevent fraud and/or promote privacy in transactions via secure user and/or document authentication. In various examples, the authenticated document NFT4924can be presented and analyzed via secured blockchain or other crypto transactions at the time of a transaction in order to authenticate the identity of the user and/or to verify the accuracy and authentic nature of the other data4922and/or to facilitate the security of the transaction.

FIG.10Bpresents a flowchart representation of an example method. In particular, a method4900is presented for use in conjunction with any of the functions and features described herein. Step4902includes receiving, via the processor, a document image associated with a document. Step4904includes receiving, via the processor, other data, wherein the other data is also associated with the document. Step4906includes facilitating creation of an authenticated document NFT corresponding to the document.

FIG.11Apresents a block diagram/flow representation of an example of NFT generation. The NFT generation tools808are used to generate a derivative NFT5624based on an original metaverse real estate NFT5620and based on the enhancement data5622.

In the example shown inFIG.11B, an original metaverse real estate NFT5620corresponds to real estate having an interior room that is used in a game or metaverse application. The original metaverse real estate NFT5620can be purchased by the user, created or leveled-up via game play or otherwise acquired by the user of a metaverse application or game.

The NFT generation tools808are used to generate a derivative NFT5624or other metaverse real estate NFT that is based on the enhancements data5622shown inFIG.11C. In the example shown the enhancements5622-1and5622-2correspond to a Moet & Chandon vending machine and a Jackson Pollock painting that are acquired either as image data or as individual NFTs. While particular enhancements are shown, other real estate enhancements can likewise be implemented including statues and other art, rugs, lamps, furniture and other furnishings and accessories, outdoor objects, appliances, knick-knacks, machinery and other virtual objects for decorating or finishing an office, home, factory, venue or other real estate.

In the example shown inFIG.11D, the user has placed the enhancements5622-1and5622-2as desired before creating the derivative NFT5624. The derivative NFT5624with improvements shown can be created on a parachain or other sidechain that is different from the blockchain on which the original metaverse real estate NFT5620resides or the same blockchain on which the original metaverse real estate NFT5620resides.

FIG.11Epresents a flowchart representation of an example method. In particular, a method5600is presented for use in conjunction with any of the functions and features described herein. Step S602includes receiving, via the processor, a metaverse real estate NFT associated with metaverse real estate. Step S604includes receiving, via the processor, enhancement data associated with the metaverse real estate. Step S606includes facilitating creation of a derivative NFT associated with the metaverse real estate and having enhancements associated with metaverse real estate.

FIG.12Apresents a block diagram of an example system. In particular, a system is shown that can be implemented similarly to, or in conjunction with, NFT collection platform800. The system includes an NFT transaction authenticator6022and a secure real-time NFT metadata repository6024. In various examples, the NFT transaction authenticator6022and the secure real-time NFT metadata repository6024can be implemented via one or more modules that include a network interface, processing circuitry and memory. The secure real-time NFT metadata repository6024stores NFT metadata received in conjunction with NFTs created via metadata source6026, such as one or more NFT creation systems824. The NFTs are associated with one or more users6020.

In operation, the NFT transaction authenticator6022responds to transaction requests from a user associated with an NFT to authenticate the NFT and the user and to otherwise determine the validity of the transaction that is requested. If the user and the NFT are both authenticated, and the requested transaction is otherwise permissible (e.g. not restricted by conditions on use or other transaction restrictions), then the NFT transaction authenticator6022responds by issuing credentials to facilitate the transaction with a third party6028. As will be discussed herein, the maintenance and use of the secure real-time NFT metadata repository6024allows authentication of NFT related transactions in real-time—avoiding possible delays in performing, for example, complex blockchain transactions via an NFT source6026where the NFT was minted and/or otherwise maintained.

Consider the following example where an NFT is created via NFT source6026. In addition to other NFT data, the NFT has metadata that uniquely identifies the NFT, a hash or other NFT authentication metadata that can be used to authenticate the NFT and/or transaction restriction metadata indicating possible restrictions on transactions/use conditions involving the NFT. Furthermore, when the NFT is created and/or acquired by a user, user-specific user authentication metadata is acquired or created and stored on the blockchain with the NFT with the other metadata. This user authentication metadata can include one or more passwords, answers to security questions, identifiers of recognized devices such as a device identifier of a personal cellphone, laptop, tablet, computer or other known and/or trusted device, one or more trusted networks of the user, other multifactor authentication data such as personal information, known answers to security questions, biometric data related to fingerprints, retinal scans, facial features or other biometrics of the user and/or other user authentication data that can be used to determine if a user is the owner of the NFT or otherwise an authorized user and in particular, whether or not the user is (or is not) who they claim to be.

The metadata associated with the NFT is indexed by NFT identifier and stored on the secure real-time NFT metadata repository6024for use by the NFT transaction authenticator6022in authenticating NFT-related transactions. This metadata is available from the repository on a real-time basis (e.g., is available with an acceptable amount of latency associated with a corresponding transaction). The metadata in the secure real-time NFT metadata repository6024is also synced periodically with the NFT via the NFT source6026to reflect any changes in the NFT itself. While some metadata, such as an NFT identifier, NFT authentication metadata and/or transaction restriction metadata may be made accessible to the user who holds the NFT, in various examples, the user authentication metadata in particular, can be encrypted in such a fashion that is decryptable by the secure real-time NFT metadata repository6024—but not by the user. In various examples, the secure real-time NFT metadata repository6024lacks a general network connection and is connected to the NFT transaction authenticator6022via a dedicated and/or otherwise secured connection or is otherwise walled-off from other network connections of the NFT transaction authenticator6022. This helps prevent unauthorized tampering with the sensitive data stored therein.

When a user6020proposes an NFT-related transaction, the NFT transaction authenticator6022collects from the user as part of the transaction request (a) an identifier of the NFT, and NFT authentication data corresponding to the NFT (b) user authentication data user, and (c) information on the proposed transaction. The NFT transaction authenticator6022determines whether or not the identifier corresponds to a valid NFT. If so, it retrieves the metadata associated with the NFT from secure real-time NFT metadata repository6024. The NFT transaction authenticator6022authenticates the NFT by comparing the NFT authentication data to the NFT authentication metadata to determine if they match. The NFT transaction authenticator6022can also authenticate the user6020to the NFT by comparing the user authentication data to the user authentication metadata to determine if they match. If authentication succeeds, the NFT transaction authenticator6022facilitates the transaction with the third party6028by authorizing completion of the transaction, e.g. by issuing a credential to the third party6028. The credential can include any message, object, or data structure that vouches for the identity of the user, the authenticity of the NFT and/or the validity of the transaction, through some method of security, trust and/or authentication.

In this fashion, the NFT transaction authenticator6022can authenticate transactions such as access to a flight via a driver's license or passport NFT, sale of a vehicle, real estate via a title NFT, a credit, debit or gift card transaction via a credit, debit or gift card NFT, the sale of a stock or bond via a stock or bond certificate NFT, warranty transactions via a warranty card NFT, access to events via venue ticket NFTs and/or vaccination card NFTs, coupon redemption via a coupon NFT, access to a vehicle, dwelling or office via a key NFT, etc. Furthermore, the NFT transaction authenticator6022can authenticate transactions such as sales and/or micro-loans of NFTs itself.

It should be noted that some NFTs are conditional, e.g. that have restrictions on their use and/or the transactions that are permitted. Depending on the type of transaction, the NFT transaction authenticator6022can also operate to compare transaction data received from the user to transaction restrictions metadata to determine if a transaction is permitted—before it is authorized. In this fashion, a credit, debit or gift card transaction can be halted if an expiration date or transaction limit has been exceeded. A warranty transaction can be halted if the warranty has expired. A key access for a pool, gym or office can be halted based on date, day of week or time of day restrictions, etc.

Furthermore, in sales transactions and/or micro-loans that have been authorized, the NFT transaction authenticator6022can also operate to note the pending sale or micro-loan in the secure real-time NFT metadata repository6024or otherwise place a hold on the NFT to prevent another sales or micro-loan until the repository is updated in a future sync with the NFT source6026. Furthermore, in some cases the NFT corresponds to an expendable asset such as a venue ticket, gift card, coupon, etc. The NFT transaction authenticator6022can also operate to determine that the NFT is expended, based on the transaction restrictions metadata and the transaction data. In response to such a determination, NFT transaction authenticator6022can then update the secure real-time NFT metadata repository to indicate the NFT is expended. In any of these cases above, the secure real-time NFT metadata repository may facilitate updating of the NFT source6026to reflect an authorized transaction via notifications and/or that an NFT has been expended.

FIG.12Bpresents a flowchart representation of an example method. In particular, a method6000-4is presented for use in conjunction with any of the functions and features described herein. Step6002-4includes receiving, at the processor, a transaction request from a user associated with an NFT minted via a blockchain, wherein the transaction request includes NFT identification data identifying the NFT, NFT authentication data, user identification data and transaction data associated with the transaction. Step6004-4includes receiving, from a secure real-time NFT metadata repository and in response to the NFT identification data, NFT authentication metadata for authenticating the NFT, user authentication metadata for authenticating an authorized user of the NFT, and transaction restrictions data associated with the NFT, wherein the secure real-time NFT metadata repository is separate from the blockchain.

Step6006-4includes determining, via the processor, that the NFT is authenticated when the NFT authentication data compares favorably to the NFT authentication metadata. Step6008-4includes determining, via the processor, that the user is authenticated when the user authentication metadata compares favorably to the user identification data. Step6010-4includes determining, via the processor, that the transaction is authorized when the transaction restrictions metadata compares favorably to the transaction data. Step6012-4includes generating credentials data to facilitate the transaction when the NFT is authenticated, the user is authenticated and the transaction is authorized.

FIG.12Cpresents a pictorial block diagram/flow representation of a further example of transaction authentication. In this case, the transaction request6054-1includes NFT identification data identifying the NFT, NFT authentication data, and also user identification data that includes both a user device identifier and user biometric data that was collected via the client device825as part of its own user authentication process.

Again, the NFT transaction authenticator6022can in operate in conjunction with the secure real-time NFT metadata repository6024for example, to authenticate the transaction with the third party6028. In this additional case, the user authentication mechanisms of the client device are used in the transaction of the authentication process. Once the user is identified by a trusted device, the device identifier of the trusted device can be in combination with the user biometrics collected by that device to provide further security for the proposed transaction.

FIG.12Dpresents a flowchart representation of an example method. In particular, a method6000-10is presented for use in conjunction with any of the functions and features described herein. Step6002-10includes receiving, at the processor, a transaction request from a user associated with an NFT minted via a blockchain, wherein the transaction request includes NFT identification data identifying the NFT, NFT authentication data and user identification data that includes a user device identifier. Step6004-10includes receiving, from a secure real-time NFT metadata repository and in response to the NFT identification data, NFT authentication metadata for authenticating the NFT and user authentication metadata for authenticating an authorized user of the NFT, wherein the secure real-time NFT metadata repository is separate from the blockchain.

Step6006-10includes determining, via the processor, that the NFT is authenticated when the NFT authentication data compares favorably to the NFT authentication metadata. Step6008-10includes determining, via the processor, that the user is authenticated when the user authentication metadata compares favorably to the user identification data. Step6010-10includes generating credentials data to facilitate the transaction when the NFT is authenticated and the user is authenticated.

FIG.13Apresents a block diagram representation of an example authentication system. In particular, an authentication system7030is shown that includes a processing system7040having a processor and a memory and an RF tag reader7042that facilitates communications authentication data between an RF tag7034associated with an object to be authenticated and the authentication system. The RF tag includes a near-field communication (NFC) transceiver or other transceiver configured to communicate with the RF tag reader7042. The RF tag includes a processing system7044having a processor and a non-volatile memory. Energy can be harvested from the RF tag reader7042and stored, or the power from the reader can directly power the processing system7044to respond to read requests.

In the example shown, the RF tag7034is embedded in, attached to or otherwise associated with an object to be authenticated, in this case an autographed baseball. During set-up/initialization, the RF tag7034undergoes a unique one-time pairing with authentication system7030that makes secure and coordinated exchanges possible. The RF tag7034is easy to initialize, difficult to duplicate, and detectible if a duplicate (e.g. a counterfeit tagged object) is read by the authentication system7030. A portion of non-volatile memory can be encrypted and the decryption key can be stored in a special register or memory location that has electronic and/or physical intrusion protections. While the object to be authenticated is represented as a collectable, RF tags7034can be associated with other items such as OEM parts, art works, toys, home goods, produce and other food items, pharmaceuticals, luxury items such as designer clothing and accessories, wristwatches and other jewelry, antiques and/or other things that could be the subject of potential counterfeiting.

In various examples, the authentication system7030and RF tag7034provide a counterfeit-resistant process for verifying the authenticity of the object to be authenticated. When the RF tag reader7042comes in range of the RF tag7034as part of attempt (e.g., a request) to authenticate the object, the RF tag7034and the authentication system7030exchange authentication data7032that includes an immutable and universally unique identifier of the tag, and a non-repeating, apparently random number. If the request originates from the authentication system7030and is not a replay of a previous request, the RF tag7034generates a response that reflects the entire sequence of valid exchanges between tag and authentication system—otherwise tag's response contains diagnostic information about the invalid request, decipherable only by authentication service itself.

The authentication service7030assesses and publicly reports on the validity of tag responses in a registry of read events7052that, for example, includes an event timeline that is stored via the blockchain system7050. Other ancillary services and apps may use this registry to implement features useful and germane features related to authentication via this high-security process.

In various examples, the authentication system operates by:assigning, via the authentication system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number;pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash;receiving a first request to authenticate the object;generating, in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key;sending, via the RF tag reader, the second AS hash and the signature of the second random number to the RF tag, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key;receiving, via the RF tag reader, the signature of the first tag hash;recovering the first tag hash based on the signature of the first tag hash and the private key;generating, via the authentication system, first tag hash check data based on the second random number and based on the first AS hash; andwhen the first tag hash matches the first tag hash check data, generating first read event data via the authentication system that indicates authentication of the object.

In various examples, the first request to authenticate the object is initiated in response to the RF tag reader coming in range of the RF tag and/or in response to receiving, from the RF tag, the tag identifier. The RF tag can generate the first tag hash based on the second random number and based on the first AS hash and generates the signature of the first tag hash based on the public key in response to determining a hash of the second random number matches the second AS hash. The RF tag can generate the first tag hash based on the second random number and based on the first AS hash and generates the signature of the first tag hash based on the public key further in response to determining that the second random number differs from the first random number.

The method can further include:receiving, via the authentication system, a second request to authenticate the object;generating, via the authentication system and in response to the second request, a third random number, a third AS hash based on the third random number and a signature of the third random number generated based on the private key;sending, via the RF tag reader, the third AS hash and the signature of the third random number to the RF tag, wherein the RF tag recovers the third random number based on the signature of the third random number and the public key, generates a second tag hash based on the third random number and based the first tag hash, and generates a signature of the second tag hash based on the public key;receiving, via the RF tag reader, the signature of the second tag hash;recovering, via the authentication system, the second tag hash based on the signature of the second tag hash and the private key;generating, via the authentication system, second tag hash check data based on the third random number and based on the first tag hash; andwhen the second tag hash matches the second tag hash check data, generating second read event data via the authentication system that indicates authentication of the object.

The RF tag can generate the second tag hash based on the third random number and the first tag hash and generates the signature of the second tag hash based on the public key in response to determining that the third random number differs from the second random number. The RF tag can generate the second tag hash based on the third random number and the first tag hash and generates the signature of the second tag hash based on the public key further in response to determining a hash of the third random number matches the third AS hash. The authentication system can maintain a registry of read events that includes the first read event data and the second read event data.

In various examples, the method can further include: when the second tag hash fails to match the second tag hash check data, determining via the authentication system whether or not the read request corresponds to a counterfeit tag; and when the read request corresponds to the counterfeit tag, generating third read event indicating the read of the counterfeit tag.

Consider the following further example,The RF tag7034and the authentication system7030undergo an initial pairing, privately exchanging encryption keys and setting an initial shared state.The authentication system generates a random number at each request to authorize a read cycle, cryptographically signs it, and securely sends the random number and its signature to the tag.The tag deciphers the random number, confirms the signature, determines whether or not the random number is a duplicate, updates a hash-chain of random numbers, and securely sends hash-chain to the system.The system independently computes its own hash-chain and compares it to the tag's reported hash-chain, confirming the tag's response is valid.Communication errors, data corruption, the existence of counterfeit copies of a tag, and the like, may cause authentication system and the tag to have different sequences of random numbers and thus hash-chain values. The authentication system is able to reconcile or properly interpret these differences.The system publicly reports the status of each read event on a timeline (such as registry of read events7052).

Consider the further example that follows. The authentication system7030(or more simply, the “system”) assigns or records the unique identifier k of each RF tag7034(or more simply “tag”), generates a unique private key ekand its matching public key dkoperating on a field of size nk, selects an initial random number rk0, computes its hash Hk0=hash(rk0), and assigns:

At the start of a read event(authentication request), the authentication system7030generates a random number rkj, such that rkj>rkj-1, to authorize the jthread event of tag k, privately shares a cryptographically signed copy of rkjwith tag, and updates its own state after a successful response from tag k:

likewise tag updates its state after confirming the signature of rkj, and confirming rkjis not a duplicate or playback of a previous read event:

Consider the further example.1. The RF tag reader7042(or more simply, the “reader”) queries the tag's unique identity k and forwards it to the authentication system;2. The system receives k, generates a new random number rkj, (for example, if rkjis a 256-bit number, we may reserve the most significant 32 bits of rkjto embed j and use the least significant 224 bits for the random portion) such that rkj>rkj-13. The system computes its hash hkj=hash(rkj), and its ciphertext Ckjusing the private key {ek, nk}, and returns the privately signed rkjas {hkj, Ckj};4. The reader forwards signed read authorization code {hkj, Ckj} to the tag;5. The tag receives {hkj, Ckj}, recovers rkjusing the public key {dk, nk}, and tests that hkj=hash(rkj) and rkj>rkj-1; if true, the tag computes Hkj=hash(Hkj-1, +rkj) and its ciphertext Ckjusing the public key {dk, nk}, updates {k, dk, nk, Hkj-1, rkj-1}⇒{k, dk, nk, Hkj, rkj}, and returns {k, Ckj′}; otherwise, tag generates a partially random number r′, reserving two bits to indicate test results—for example, if a diagnostic value contains 64 bits, 62 random bits plus 2 error bits, and a chained hash contains many more bits, say 256, the mere differential in size makes a diagnostic value distinguishable from a hash value. However, the ciphertext of either will have roughly the same number of bits. The net effect is, lacking access to the private key, the tag's public response to valid read requests is indistinguishable from its response to invalid requests.6. The tag computes its ciphertext Ckjwith the public key {dk, nk}, and returns {k, Ckj};7. The reader forwards {k, Ckj} to the authentication system;8. The authentication system receives tag's response, deciphers Ckjusing the private key {ek, nk}, and determines if the response is a diagnostic or a hash value. If a hash value is detected, taking into account that one or more rkmay be lost to tag, the system seeks a subset of random numbers, {r1′ . . . ri′}m∈{rk0. . . rkj}, that produces a match to tag's reported hash-chain, Hm=Hkj, in which case tag is proved valid; if two or more m distinct sequences of random numbers produce a match, a counterfeit tag is in play.9. The authentication system publishes a timeline of tag read events on a public ledger (such as a blockchain system7050) with an informative status code, for example: {timestamp, k, status_code}; read events not sanctioned by system may or may not be published, and the system may take or recommend remedial actions.

The following methodology can be employed in step 8 above to correct for missing rkat the tag, and for system missing one or more Hktag generated but did not reach system.The authentication system maintains an ordered list of all random rkissued to tag k, {rk0. . . rkj}. Since, system must account for tag missing one or more rkit also constructs sequences of rk′ that are subsets, {rk0′ . . . rki′}m∈{rk0. . . rkj}, i≤j, that result in system's calculation of hash-chain, Hm, matching tag's, Hki.If more than one valid sequence of rk′ exists (m≥2) between a tag and system, then one or more counterfeit copies of tag k are in play. There may be utility in tracking when a counterfeit copy emerges, a new distinct sequence forms, tracking these branches separately. This includes tracking the node (a specific rkn′ in a sequence m), when the node (random number) was originally issued, and when the branching tag first contacted system with a response to a read request. The system also decides if, when and how this information is publicly revealed, leaving the option to privately share information in a different form with a registered tag owner.

Search Algorithm1. When the system receives a new Hkifrom the tag, it selects a prior valid sequence from among the m available and tries all combinations of “unclaimed” random numbers from the master set, {rkq. . . rkj}, where rkqis the first random number larger than rki′ from the selected subset sequence {rk0′ . . . rki′}m. If a match is found, the selected sequence m is updated, if not, the next sequence is selected and the process (1) is repeated.2. If no match is produced as described in 1 above, it may be a tag branched at an earlier node in a sequence. To resolve, we walk backward through each sequence, {rk0′ . . . rki′}m⇒{rk0′ . . . rki-1′}m, and repeat 1 until a match is found or options are exhausted.

Each sequence is indexed by its cumulative hash-chain values for efficiency in implementing step 2:

In various examples, detectable status codes and error conditions include at least the following:

StatusTagDescription of published statuscodebitscodes (can be summed)1service received a valid response2service received a valid response outsidethe allotted time interval (timed-out)4service received a response that is areplay of a previous valid response8service has detected a duplicate (counterfeit) tag16service received an invalid hash value from tag3211service received an invalid diagnosticcode, expected a hash value instead6400|10tag received an invalid read authorization code12801tag received a replay of a previousvalid read authorization code

Consider the further example where an alternate read cycle is constructed that does not rely on authentication system knowing tag identifier k in advance. In this case there is an additional public key, {d, n}, shared with every tag, which does not need to be kept private. Initial pairing information becomes:

to system: {k,e,d,n,ek,dk,nkHk0,{rk0}};The reader requests a read authorization code from the authentication system;The system receives reader's request and generates a new random number rj, such that rj>rj-1, computes its hash hj=hash(rj), and its ciphertext Cjusing the general private key {e, n}, and returns the signed rjas {hj, Cj};

Tag:bitsrfkhfkDescription tag error codes/responses00invalidinvalidrkj≤ rkj−1, hkj≠ hash(rkj), possible malicious actor10validinvalidrkj> rkj−1, hkj≠ hash(rkj), possible malicious actor01invalidvalidrkj≤ rkj−1, hkj= hash(rkj), possiblemalicious actor, replay of a previous readauthorization code11validvalidrkj> rkj−1, hkj= hash(rkj)valid read request,tag returns chained-hashThe reader forwards signed read authorization code {hj, Cj} to the tag;The tag receives {hj, Cj}, recovers rjusing the general public key {d,n}, and tests that hj=hash(rj) and rj>rj-1; if true, tag encrypts rjusing its specific public key {dk, nk} to generate rkjand computes Hkj=hash(Hkj-1+rkj) and its ciphertext Ckjusing its specific public key {dk, nk}, updates {k, d, n, dk, nk, Hkj-1, rj-1}⇒{k, d, n, dk, nk, Hkj, rj}, and returns {k, Ckj′}; otherwise, the tag generates a partially random number r′, reserving two bits to indicate test results, computes its ciphertext Ckj′ with the public key {dk, nk}, and returns {k, Ckj′};The reader adds rjand returns {k, rj, Ckj′} to the authentication system;The authentication system receives reader's response, deciphers Ckj′ using the private key {ek, nk}, converts rjinto rkjusing its copy of tag k's public key {dk, nk}, and determines if the response is a diagnostic or a hash value; if a hash value is detected, taking into account that one or more rjmay be lost to tag, system seeks a subset of random numbers, {r1′ . . . ri′}m∈{rko. . . rkj}, that produces a match to tag's reported hash-chain, Hm=Hkj, in which case tag is proved valid; if two or more m distinct sequences of random numbers produce a match, a counterfeit tag is in play;The authentication system takes the additional step to record, and places in rjorder, the computed sequence for tag k: {rk0. . . rkj}. It also track rjthat remain unclaimed by a tag, those that are claimed by a single tag, and those that are claimed by more than one tag (which is evidence of malicious action). Again, there may be utility in allowing these branches to exist, so as to monitor potentially illicit activity;The authentication system publishes a timeline of tag read events on a public ledger (such as a blockchain) with an informative status code, for example: {timestamp, k, status_code}; read events not sanctioned by system may or may not be published, and the system may take or recommend remedial actions.

FIG.13Bpresents a flowchart representation7000-1of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system or other system that includes a processor and a memory to perform various steps of the method. Step7002-1includes assigning, via the authentication system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number. Step7004-1includes pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash. Step7006-1includes receiving, via the authentication system, a first request to authenticate the object. Step7008-1includes generating, via the authentication system and in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key.

Step7010-1includes sending, via the RF tag reader, the second AS hash and the signature of the second random number to the RF tag, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key. Step7012-1includes receiving, via the RF tag reader, the signature of the first tag hash. Step7014-1includes recovering, via the authentication system, the first tag hash based on the signature of the first tag hash and the private key. Step7016-1includes generating, via the authentication system, first tag hash check data based on the second random number and based on the first AS hash. Step7018-1includes, when the first tag hash matches the first tag hash check data, generating first read event data via the authentication system that indicates authentication of the object.

In various examples, the first request to authenticate the object is initiated in response to the RF tag reader coming in range of the RF tag and/or in response to receiving, from the RF tag, the tag identifier.

The RF tag can generate the first tag hash based on the second random number and based on the first AS hash and generates the signature of the first tag hash based on the public key in response to determining a hash of the second random number matches the second AS hash. The RF tag can generate the first tag hash based on the second random number and based on the first AS hash and generates the signature of the first tag hash based on the public key further in response to determining that the second random number differs from the first random number.

The method can further include:receiving, via the authentication system, a second request to authenticate the object;generating, via the authentication system and in response to the second request, a third random number, a third AS hash based on the third random number and a signature of the third random number generated based on the private key;sending, via the RF tag reader, the third AS hash and the signature of the third random number to the RF tag, wherein the RF tag recovers the third random number based on the signature of the third random number and the public key, generates a second tag hash based on the third random number and based the first tag hash, and generates a signature of the second tag hash based on the public key;receiving, via the RF tag reader, the signature of the second tag hash;recovering, via the authentication system, the second tag hash based on the signature of the second tag hash and the private key;generating, via the authentication system, second tag hash check data based on the third random number and based on the first tag hash; andwhen the second tag hash matches the second tag hash check data, generating second read event data via the authentication system that indicates authentication of the object.
The RF tag can generate the second tag hash based on the third random number and the first tag hash and generates the signature of the second tag hash based on the public key in response to determining that the third random number differs from the second random number. The RF tag can generate the second tag hash based on the third random number and the first tag hash and generates the signature of the second tag hash based on the public key further in response to determining a hash of the third random number matches the third AS hash. The authentication system can maintain a registry of read events that includes the first read event data and the second read event data.

In various examples, the method can further include: when the second tag hash fails to match the second tag hash check data, determining via the authentication system whether or not the read request corresponds to a counterfeit tag; and when the read request corresponds to the counterfeit tag, generating third read event indicating the read of the counterfeit tag.

FIG.13Cpresents a flowchart representation7000-2of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system or other system that includes a processor and a memory to perform various steps of the method. Step7002-2includes assigning, via the processing system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number. Step7004-2includes communicating with a RF tag reader to, pair the authentication system to the RF tag associated with the object, wherein the communicating includes sending to the RF tag via the RF tag reader, the tag identifier, the public key, the first random number, and the first AS hash. Step7006-2includes receiving, from the RF tag reader, a first request to authenticate the object. Step7008-2includes generating, via the processing system and in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key.

Step7010-2includes sending, to the RF tag reader for communication with the RF tag, the second AS hash and the signature of the second random number, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key. Step7012-2includes receiving, from the RF tag reader, the signature of the first tag hash. Step7014-2includes recovering, via the processing system, the first tag hash based on the signature of the first tag hash and the private key. Step7016-2includes generating, via the processing system, first tag hash check data based on the second random number and based on the first AS hash. Step718-2includes, when the first tag hash matches the first tag hash check data, generating first read event data via the processing system that indicates authentication of the object.

FIG.13Dpresents a flowchart representation7000-3of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with a tag reader or other system that includes a processor and a memory to perform various steps of the method. Step7002-3includes receiving from an authentication system (AS), pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a public key having an associated private key, a first random number and a first AS hash based on the first random number. Step7004-3includes pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash. Step7006-3includes receiving a first request to authenticate the object, wherein the authentication system responds to the first request by generating a second random number, a second AS hash based on the second random number and by generating a signature of the second random number generated based on the private key. Step7008-3includes sending, the second AS hash and the signature of the second random number to the RF tag, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key.

Step7010-3includes receiving the signature of the first tag hash from the RF tag. Step7012-3includes sending the signature of the first tag hash to the authentication system, wherein the authentication system recovers the first tag hash based on the signature of the first tag hash and the private key, generates first tag hash check data based on the second random number and based on the first AS hash and generates, when the first tag hash matches the first tag hash check data, first read event data via the authentication system that indicates authentication of the object.

FIG.13Epresents a flowchart representation7000-4of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an RF tag or other system that includes a processor and a memory to perform various steps of the method. Step7002-4includes pairing the RF tag to an authentication system (AS) having a RF tag reader, wherein the pairing includes receiving, from the authentication system, pairing data to be associated with the authentication system, wherein the pairing data includes a tag identifier, a public key having an associated private key, a first random number and a first AS hash based on the first random number. Step7004-4includes sending to the RF tag reader, a first request to authenticate the object, wherein the authentication system responds to the first request by generating a second random number, a second AS hash based on the second random number and by generating a signature of the second random number generated based on the private key. Step7006-4includes receiving, from the RF tag reader, the second AS hash and the signature of the second random number. Step7008-4includes recovering the second random number based on the signature of the second random number and the public key.

Step7010-4includes generating a first tag hash based on the second random number and based on the first AS hash. Step7012-4includes generating a signature of the first tag hash based on the public key. Step7014-4includes sending the signature of the first tag hash to the authentication system, wherein the authentication system recovers the first tag hash based on the signature of the first tag hash and the private key, generates first tag hash check data based on the second random number and based on the first AS hash and generates, when the first tag hash matches the first tag hash check data, first read event data via the authentication system that indicates authentication of the object.

FIG.13Fpresents a flowchart representation7000-6of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system or other system that includes a processor and a memory to perform various steps of the method. Step7002-6includes assigning, via the authentication system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number. Step7004-6includes pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash. Step7006-6includes receiving, via the authentication system, a first request to authenticate the object from an unknown RF tag associated with the tag identifier. Step7008-6includes generating, via the authentication system and in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key; Step7010-6includes sending, via the RF tag reader, the second AS hash and the signature of the second random number to the unknown RF tag, wherein the unknown RF tag generates response data.

Step7012-6includes receiving, via the RF tag reader, the response data. Step7014-6includes generating, via the authentication system, a first tag hash based on the response data and the private key. Step7016-6includes generating, via the authentication system, first tag hash check data based on the second random number and based on the first AS hash. Step7018-6includes, when the first tag hash fails to match the second tag hash check data, determining via the authentication system when the unknown RF tag corresponds to a counterfeit tag. Step7020-6includes, when the unknown RF tag corresponds to the counterfeit tag, generating third read event indicating the read of the counterfeit tag.

FIG.13Gpresents a flowchart representation7000-5of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system or other system that includes a processor and a memory to perform various steps of the method. Step7002-5includes assigning, via the authentication system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number. Step7004-5includes pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash. Step7006-5includes receiving, via the authentication system, a first request to authenticate the object. Step7008-5includes generating, via the authentication system and in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key.

Step7010-5includes sending, via the RF tag reader, the second AS hash and the signature of the second random number to the RF tag, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key. Step7012-5includes receiving, via the RF tag reader, the signature of the first tag hash. Step7014-5includes recovering, via the authentication system, the first tag hash based on the signature of the first tag hash and the private key. Step7016-5includes generating, via the authentication system, first tag hash check data based on the second random number and based on the first AS hash. Step7018-5includes, when the first tag hash matches the first tag hash check data, generating first read event data via the authentication system that indicates authentication of the object. Step7020-5includes facilitate updating, in a blockchain system, a registry of read events based on the first read event data.

FIG.14Apresents a block diagram representation of an example authentication system. In particular, an authentication system is shown that includes many similar elements to the system ofFIG.13Athat are referred to by common reference numerals. In this system however, the blockchain system7050stores the registry of read events7054as an NFT that is updated when new read events are added to the timeline.

FIG.14Bpresents a flowchart representation7100-1of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system, an NFT platform or other system that includes a processor and a memory to perform various steps of the method. Step7102-1includes assigning, via the authentication system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number. Step7104-1includes pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash. Step7106-1includes receiving, via the authentication system, a first request to authenticate the object. Step7108-1includes generating, via the authentication system and in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key.

Step7110-1includes sending, via the RF tag reader, the second AS hash and the signature of the second random number to the RF tag, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key. Step7112-1includes receiving, via the RF tag reader, the signature of the first tag hash. Step7114-1includes recovering, via the authentication system, the first tag hash based on the signature of the first tag hash and the private key. Step7116-1includes generating, via the authentication system, first tag hash check data based on the second random number and based on the first AS hash. Step7118-1includes, when the first tag hash matches the first tag hash check data, generating first read event data via the authentication system that indicates authentication of the object. Step7120-1includes facilitate updating, in a blockchain system, a registry of read events based on the first read event data.

FIG.14Cpresents a block diagram representation of an example of NFT generation. In the example shown, NFT generation tools808operate to convert NFT data7122-1associated with an RF tag corresponding to an object to be authenticated via an authentication system—into an NFT7124-1associated with the tagged object. The NFT data7122-1used to create/mint the NFT7124-1can include imagery of the object to be authenticated, pairing data used to pair the RF tag to the authentication system and/or other authentication data of either the authentication system or the owner.

The NFT7124-1can be stored on a blockchain system or other immutable storage and “held” by the owner in a wallet or similar application. The association of the NFT7124-1with the owner can be used in an NFT transaction to establish the owner's rights in the authenticated object. Furthermore, the NFT7124-1and the owner's ownership thereof can be used in conjunction with the authentication of the object via the authentication system to not only authenticate the object but to also validate the owner's ownership of other interest in the object. In this fashion, if an authenticated object is stolen, while it could otherwise be authenticated as part of a sale transaction as being authentic, the authentication can be denied, and/or the transaction can be nevertheless flagged as illegitimate in absence of an additional validation of the NFT held by the true owner as part of the transaction.

FIG.14Dpresents a flowchart representation7100-4of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system, an NFT platform or other system that includes a processor and a memory to perform various steps of the method. Step7102-4includes receiving a request to authenticate an object having an associated RF tag. Step7004-4includes determining, via the authentication system and based on authentication data communicated with the RF tag, when authentication of the object is confirmed. Step7006-4includes determining when an NFT is validated, wherein the NFT is associated with the object to be authenticated and is stored in a wallet associated with a user. Step7008-4includes verifying the authentication of the object and ownership of the object by the user when the authentication of the object is confirmed and the NFT is validated.

FIG.14Epresents a flowchart representation7100-3of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system, an NFT platform or other system that includes a processor and a memory to perform various steps of the method. Step7102-3includes pairing, based on pairing data, with an RF tag associated with an object to be authenticated, wherein the pairing data includes a tag identifier.7104-3includes facilitating generation of a non-fungible token (NFT) based on NFT data that includes the pairing data, at least one image associated with the object to be authenticated and ownership information associated with the object to be authenticated.

FIG.14Fpresents a flowchart representation7100-2of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system, an NFT platform or other system that includes a processor and a memory to perform various steps of the method. Step7102-2includes assigning, via the authentication system, pairing data to be associated with an RF tag and a corresponding object to be authenticated, wherein the pairing data includes a tag identifier, a private key, a public key, a first random number and a first AS hash based on the first random number. Step7104-2includes pairing the authentication system to the RF tag associated with the object, wherein the pairing includes sending to the RF tag, the tag identifier, the public key, the first random number, and the first AS hash. Step7106-2includes receiving, via the authentication system, a first request to authenticate the object. Step7108-2includes generating, via the authentication system and in response to the first request, a second random number, a second AS hash based on the second random number and a signature of the second random number generated based on the private key.

Step7110-2includes sending, via the RF tag reader, the second AS hash and the signature of the second random number to the RF tag, wherein the RF tag recovers the second random number based on the signature of the second random number and the public key, generates a first tag hash based on the second random number and based on the first AS hash, and generates a signature of the first tag hash based on the public key. Step7112-2includes receiving, via the RF tag reader, the signature of the first tag hash. Step7114-2includes recovering, via the authentication system, the first tag hash based on the signature of the first tag hash and the private key. Step7116-2includes generating, via the authentication system, first tag hash check data based on the second random number and based on the first AS hash. Step7118-2includes, when the first tag hash matches the first tag hash check data, generating first read event data via the authentication system that indicates authentication of the object. Step7120-2includes facilitating generation of a non-fungible token (NFT) based on NFT data that includes the tag identifier, at least one image associated with the object to be authenticated and ownership information associated with the object to be authenticated.

FIGS.14G-14Hpresent a block/flow diagram representations of example systems. As previously discussed, ownership, validation and/or authentication of NFTs can be used to as part of the authentication of an object and/or to enable/prevent a sale transaction based on validation of the true owner. In the example shown inFIG.14G, authentication system7030has an authentication system NFT7124-1associated therewith. The authentication system7030includes at least one memory that stores operational instructions that, when executed by at least one corresponding processing circuit, control the operation of the authentication system.

In operation, the application execution device7030operates in response to a request to authenticate7132as part of a transaction request for example. This request to authenticate7132can be received (internally) from a user interface associated with the authentication system7030and/or via a RF tag reader associated therewith. Once the operational instructions are executed in response to the request to authenticate7132, launch metadata7134is generated, for example, to determine if the request is associated with a valid NFT associated with the owner. The launch metadata7134is sent to the wallet7125containing a private key associated with the MS/NFT7123-1associated with a user, such as a user of the application execution device and/or the authentication system7030. The authentication system7030receives from the wallet7125, a launch response7135that is generated based on the private key. The authentication system generates, based on the launch response7135, an ownership check7136that is sent to the blockchain system7140that stores the NFT7124-1. An ownership validation response7138is received from the blockchain system7120that indicates whether or not the NFT7124-1is validated (e.g. ownership is verified, the NFT is authenticated, restrictions/conditions are met and/or the NFT has not expired, etc.)

In various examples, the launch metadata7134can include a current date and time, expiration information (if any) and an identification of the authentication system, a counter that indicates a number of times the application has been executed, and/or other data corresponding to the NFT7124-1, the authentication system7030, the user, the intended use and/or the request to authenticate. The launch response7135can include a public key associated with the MS/NFT7124-1, a signed hash that is based on the private key, the launch metadata7134, and/or other NFT data/metadata to be used to validate the NFT data from the wallet7125to the NFT7124-1. In this fashion, the private key is not shared directly with the authentication system7030—and instead is merely used by the wallet7125in a secure fashion.

The ownership check7136can include information from the launch response7135, additional owner/user information, such as user authentication data, associated with the user and/or owner of the NFT7122-1and or other and/or other NFT data/metadata to be used to validate the NFT data from the wallet7125to the NFT7124-1. In various examples, the blockchain system7140can include an NFT transaction authenticator6022, a secure real-time NFT metadata repository6024and an NFT source6026that actually stores the NFT7124-1on a blockchain, IPFS, immutable storage or other decentralized computer system/network and user authentication/NFT validation can take place, for example as described in conjunction withFIGS.12A-12D.

The authentication system7030can use this indication of whether or not the NFT is validated as part of the overall authentication process. For example, a transaction can be validated/approved and/or authentication validated, only when both the object itself is authenticated via communications with the RF tag and further when the ownership of the corresponding NFT is also validated. Furthermore, the registry of read events7052(and/or NFT7054) can be updated to not only indicate object authentication, but also reads associated with valid or invalid NFTs. In this fashion, records of valid sales can be immutably stored, as well as authentication attempts of counterfeit objects and attempts to sell authentic (but stolen) goods.

FIG.14Hpresents a block diagram representation of an example system. This system operates similarly to the system ofFIG.14G, however, the request to authenticate7132is received directly from the wallet7125.

FIG.14Ipresents a flowchart representation7100-5of an example method. In particular, a method is presented for use in conjunction with one or more functions or features described herein. For example, the method can be used with an authentication system, an NFT platform or other system that includes a processor and a memory to perform various steps of the method. Step7102-5includes receiving, from a radio frequency (RF) tag reader, a request to authenticate an object having an associated RF tag. Step7104-5includes generating launch metadata associated with the request. Step7106-5includes sending the launch metadata to a wallet associated with a user of the client device, the wallet containing a private key associated with an NFT. Step7108-5includes receiving, from the wallet, a launch response that is generated based on the private key.

Step7110-5includes generating, based on the launch response, an ownership check. Step7112-5includes sending the ownership check to a blockchain system that stores the NFT. Step7114-5includes receiving, from the blockchain system, an ownership validation response. Step7116-5includes determining, via the authentication system and based on authentication data communicated with the RF tag via the RF tag reader, when authentication of the object is confirmed. Step7118-5includes verifying the authentication of the object and ownership of the object by the user when the authentication of the object is confirmed and the ownership validation response indicates the NFT is validated.

As used herein “blockchain” and “blockchain node” refer to traditional blockchain technology. However, other decentralized computer network technologies that, for example, maintain a secure, immutable and decentralized record of transactions and/or otherwise protect the security of digital information can likewise be employed. In various examples, a blockchain can operate to collect information together in groups, such as blocks, that hold sets of information. These blocks have certain storage capacities and, when filled, are closed and linked to the previously filled blocks, forming a chain of data. New information that follows that freshly added block is compiled into newly formed blocks that, once filled, can also be added to the chain.

As used herein the term “tool” corresponds to a utility, application and/or other software routine that performs one or more specific functions in conjunction with a computer.

As may be used herein, the term “compares favorably”, indicates that a comparison between two or more items, signals, etc., indicates an advantageous relationship that would be evident to one skilled in the art in light of the present disclosure, and based, for example, on the nature of the signals/items that are being compared. As may be used herein, the term “compares unfavorably”, indicates that a comparison between two or more items, signals, etc., fails to provide such an advantageous relationship and/or that provides a disadvantageous relationship. Such an item/signal can correspond to one or more numeric values, one or more measurements, one or more counts and/or proportions, one or more types of data, and/or other information with attributes that can be compared to a threshold, to each other and/or to attributes of other information to determine whether a favorable or unfavorable comparison exists. Examples of such an advantageous relationship can include: one item/signal being greater than (or greater than or equal to) a threshold value, one item/signal being less than (or less than or equal to) a threshold value, one item/signal being greater than (or greater than or equal to) another item/signal, one item/signal being less than (or less than or equal to) another item/signal, one item/signal matching another item/signal, one item/signal substantially matching another item/signal within a predefined or industry accepted tolerance such as 1%, 5%, 10% or some other margin, etc. Furthermore, one skilled in the art will recognize that such a comparison between two items/signals can be performed in different ways. For example, when the advantageous relationship is that signal1has a greater magnitude than signal2, a favorable comparison may be achieved when the magnitude of signal1is greater than that of signal2or when the magnitude of signal2is less than that of signal1. Similarly, one skilled in the art will recognize that the comparison of the inverse or opposite of items/signals and/or other forms of mathematical or logical equivalence can likewise be used in an equivalent fashion. For example, the comparison to determine if a signal X>5 is equivalent to determining if −X<−5, and the comparison to determine if signal A matches signal B can likewise be performed by determining −A matches −B or not(A) matches not(B). As may be discussed herein, the determination that a particular relationship is present (either favorable or unfavorable) can be utilized to automatically trigger a particular action. Unless expressly stated to the contrary, the absence of that particular condition may be assumed to imply that the particular action will not automatically be triggered. In other examples, the determination that a particular relationship is present (either favorable or unfavorable) can be utilized as a basis or consideration to determine whether to perform one or more actions. Note that such a basis or consideration can be considered alone or in combination with one or more other bases or considerations to determine whether to perform the one or more actions. In one example where multiple bases or considerations are used to determine whether to perform one or more actions, the respective bases or considerations are given equal weight in such determination. In another example where multiple bases or considerations are used to determine whether to perform one or more actions, the respective bases or considerations are given unequal weight in such determination.

The one or more examples are used herein to illustrate one or more aspects, one or more features, one or more concepts, and/or one or more examples. A physical example of an apparatus, an article of manufacture, a machine, and/or of a process may include one or more of the aspects, features, concepts, examples, etc. described with reference to one or more of the examples discussed herein. Further, from figure to figure, the examples may incorporate the same or similarly named functions, steps, modules, etc. that may use the same or different reference numbers and, as such, the functions, steps, modules, etc. may be the same or similar functions, steps, modules, etc. or different ones.

As may further be used herein, a computer readable memory includes one or more memory elements. A memory element may be a separate memory device, multiple memory devices, or a set of memory locations within a memory device. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, a quantum register or other quantum memory and/or any other device that stores data in a non-transitory manner. Furthermore, the memory device may be in a form of a solid-state memory, a hard drive memory or other disk storage, cloud memory, thumb drive, server memory, computing device memory, and/or other non-transitory medium for storing data. The storage of data includes temporary storage (i.e., data is lost when power is removed from the memory element) and/or persistent storage (i.e., data is retained when power is removed from the memory element). As used herein, a transitory medium shall mean one or more of: (a) a wired or wireless medium for the transportation of data as a signal from one computing device to another computing device for temporary storage or persistent storage; (b) a wired or wireless medium for the transportation of data as a signal within a computing device from one element of the computing device to another element of the computing device for temporary storage or persistent storage; (c) a wired or wireless medium for the transportation of data as a signal from one computing device to another computing device for processing the data by the other computing device; and (d) a wired or wireless medium for the transportation of data as a signal within a computing device from one element of the computing device to another element of the computing device for processing the data by the other element of the computing device. As may be used herein, a non-transitory computer readable memory is substantially equivalent to a computer readable memory. A non-transitory computer readable memory can also be referred to as a non-transitory computer readable storage medium.

One or more functions associated with the methods and/or processes described herein can be implemented via a processing module that operates via the non-human “artificial” intelligence (AI) of a machine. Examples of such AI include machines that operate via anomaly detection techniques, decision trees, association rules, expert systems and other knowledge-based systems, computer vision models, artificial neural networks, convolutional neural networks, support vector machines (SVMs), Bayesian networks, genetic algorithms, feature learning, sparse dictionary learning, preference learning, deep learning and other machine learning techniques that are trained using training data via unsupervised, semi-supervised, supervised and/or reinforcement learning, and/or other AI. The human mind is not equipped to perform such AI techniques, not only due to the complexity of these techniques, but also due to the fact that artificial intelligence, by its very definition—requires “artificial” intelligence—i.e. machine/non-human intelligence.

One or more functions associated with the methods and/or processes described herein involve NFTs that are generated (“minted”) and secured via blockchain or other decentralized computer network technology. The distributed nature of these technologies over different nodes, the contemporaneous nature of geographically distinct calculations, coupled with the extreme computational complexity of the required calculations means that these decentralized computer network technologies cannot practically be performed by the human mind.

One or more functions associated with the methods and/or processes described herein can be implemented as a large-scale system that is operable to receive, transmit and/or process data on a large-scale. As used herein, a large-scale refers to a large number of data, such as one or more kilobytes, megabytes, gigabytes, terabytes or more of data that are received, transmitted and/or processed. Such receiving, transmitting and/or processing of data cannot practically be performed by the human mind on a large-scale within a reasonable period of time, such as within a second, a millisecond, microsecond, a real-time basis or other high speed required by the machines that generate the data, receive the data, convey the data, store the data and/or use the data.

One or more functions associated with the methods and/or processes described herein can require data to be manipulated in different ways within overlapping time spans. The human mind is not equipped to perform such different data manipulations independently, contemporaneously, in parallel, and/or on a coordinated basis within a reasonable period of time, such as within a second, a millisecond, microsecond, a real-time basis or other high speed required by the machines that generate the data, receive the data, convey the data, store the data and/or use the data.

One or more functions associated with the methods and/or processes described herein can be implemented in a system that is operable to electronically receive digital data via a wired or wireless communication network and/or to electronically transmit digital data via a wired or wireless communication network. Such receiving and transmitting cannot practically be performed by the human mind because the human mind is not equipped to electronically transmit or receive digital data, let alone to transmit and receive digital data via a wired or wireless communication network.

One or more functions associated with the methods and/or processes described herein can be implemented in a system that is operable to electronically store digital data in a memory device. Such storage cannot practically be performed by the human mind because the human mind is not equipped to electronically store digital data.

One or more functions associated with the methods and/or processes described herein may operate to cause an action by a processing module directly in response to a triggering event—without any intervening human interaction between the triggering event and the action. Any such actions may be identified as being performed “automatically”, “automatically based on” and/or “automatically in response to” such a triggering event. Furthermore, any such actions identified in such a fashion specifically preclude the operation of human activity with respect to these actions—even if the triggering event itself may be causally connected to a human activity of some kind.

While particular combinations of various functions and features of the one or more examples have been expressly described herein, other combinations of these features and functions are likewise possible. The present disclosure is not limited by the particular examples disclosed herein and expressly incorporates these other combinations.