Digital watermarking for linking between NFTs and associated digital content

Abstract

[0001] The present disclosure generally relates to digital watermarking, non-fungible tokens ("NFTs"), and smart contracts. One aspect of the present disclosure describes embedding a digital watermark in digital content, the digital watermark including a message that can be used to verify the authenticity, provenance, content integrity, and / or creator associated with the NFT. The present technology may be useful for protecting and authenticating NFTs and their digital content. Related technologies and methodologies are also described.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) Related application data This application claims the benefit of U.S. Provisional Patent Application No. 63 / 445,635, filed February 14, 2023, and No. 63 / 435,043, filed December 23, 2022. This application is generally related to the assignee's U.S. Patent Application No. 17 / 992,823, filed November 22, 2022, and PCT Application No. PCT / US22 / 50767, filed November 22, 2022 (published as WO2023 / 096924). Each of the above patent documents is incorporated herein by reference in its entirety.

[0002] The disclosed technology generally relates to complex signal processing, including digital watermarking, blockchain, non-fungible tokens, and authentication. [Background technology]

[0003] Background and Overview So-called "non-fungible tokens" or "NFTs" are sold for digital content such as digital artwork, digital images, 3D models, digital photographs, and digital designs, but the link between such digital content and its associated NFT is weak—i.e., it is merely a link within the NFT's metadata. This compromises the association (via the link) between the NFT and its underlying digital content. In this patent document, we use the term "digital content" to mean one or more digital assets associated with an NFT. Examples of digital assets include images and photographs, digital art, digital images generated by artificial intelligence ("AI"), graphics, logos, digital designs, 3D models, documents and presentations, video (including one or more video frames), audio, etc. Summary of the Invention [Means for solving the problem]

[0004] One aspect of the present disclosure describes embedding so-called digital watermarks within digital content, which include signed messages that can be used to verify the provenance, content integrity, and creator of the NFT. This technology would be useful, for example, to protect against "right-click" copying of digital content, since such copies of the digital content would also include the original watermark, thus proving that the digital content was copied.

[0005] Before we go any further, I want to take a step back and review some blockchain, NFT, and digital watermarking concepts.

[0006] A blockchain can be likened to a "digital ledger" that records information about transactions. The digital ledger is stored online in a decentralized manner. Decentralization generally means that copies of the blockchain (or "digital ledger") are stored simultaneously in many online locations, with no single central point controlling the content. Another way to look at blockchains is to consider them as a distributed database that maintains a growing list of ordered records called "blocks." These blocks are linked using cryptography. For example, each block contains a cryptographic hash of the previous block in the chain, as well as, for example, a timestamp and possibly transaction data. The previous block hash links the blocks together and prevents any block from being altered or, for example, from being inserted between two existing blocks. A common use of blockchains is to record and store transaction information for cryptocurrencies such as Bitcoin.

[0007] "Distributed ledger technology" is a more general version of blockchain. DLT typically includes a public or private distributed ledger, a consensus algorithm (to ensure all copies of the ledger are identical), and optionally a framework for incentivizing and rewarding network participation. A consensus algorithm is generally a method or technique for synchronizing ledgers across a distributed system.

[0008] A related term is NFT or "non-fungible token." Such non-fungible tokens are a type of asset on a blockchain that is characterized by being unique and non-exchangeable for one another for equal value. For example, a non-fungible token could be a video game asset, a work of art, a collectible card or image, or any other "unique" object stored and managed on a blockchain.

[0009] Another related term includes a "smart contract," which is an agreement or set of rules (e.g., contained within a software program) that governs a transaction or event. Smart contracts are typically stored on a blockchain and can be automatically executed as part of a transaction or event.

[0010] Next, we turn to digital watermarking. The term "steganography" generally implies data hiding. One form of data hiding includes digital watermarking. For purposes of this disclosure, the terms "digital watermark," "watermark," and "data hiding" are used interchangeably. We sometimes use the terms "embedding," "embedding," and "data hiding" to mean modulating or transforming data representing digital content to include information therein. For example, data hiding may attempt to hide or embed an information signal (e.g., a multi-bit payload or a modified version of the same, e.g., a 2D error-corrected spread spectrum signal) within a host signal. This can be accomplished, for example, by modulating a host signal (e.g., representing digital content) in some manner to carry the information signal. Similarly, we sometimes use the terms "decoding," "detecting," and "reading" (and their various forms) to mean analyzing content to obtain the payload or signal elements embedded within the payload.

[0011] Digimarc Corporation, headquartered in Beaverton, Oregon, USA, is a pioneer in the field of digital watermarking. Some of Digimarc's work in steganography, data hiding, and digital watermarking is described in, for example, U.S. Patent Nos. 11,410,262, 11,410,261, 11,188,996, 11,188,996, 11,062,108, 10,652,422, 10,453,163, 10,282, This is reflected in patents such as Nos. 801, 6,947,571, 6,912,295, 6,891,959, 6,763,123, 6,718,046, 6,614,914, 6,590,996, 6,408,082, 6,122,403, and 5,862,260, and published PCT specification WO2016153911. Each of these patent documents is incorporated herein by reference in its entirety. Of course, numerous other approaches will be familiar to those skilled in the art. Those skilled in the art are considered to be familiar with the full range of literature on steganography, data hiding, and digital watermarking.

[0012] One aspect of the present disclosure is a method of image processing that includes obtaining digital content comprising a visual element; minting a non-fungible token (“NFT”) associated with the digital content, the minting resulting in a token identifier generated by a smart contract deployed on a distributed ledger technology (“DLT”), the smart contract having an associated smart contract address, and the DLT associated with the DLT identification; generating a hash of the token identifier, the smart contract address, and the DLT identification, the hash comprising a bit-reduced representation of the token identifier, the smart contract address, and the DLT identification; and embedding the hash as a digital watermark payload within the digital content using a digital watermark embedder, whereby the digitally watermarked digital content comprises a link between the digital content and the NFT via the hash.

[0013] Another aspect of the disclosure is a method of image processing that includes obtaining digital content comprising a visual element, the digital content comprising a first digital watermark embedded therein, the first digital watermark comprising a first multi-bit payload carrying a creator signature comprising a cryptographic relationship between a smart contract address and a target blockchain by a first private key, the digital content being associated with a non-fungible token (“NFT”); decoding the first multi-bit payload to obtain the creator signature; and embedding a second digital watermark within the digital content, the second digital watermark comprising a second multi-bit payload carrying a first owner signature, the first owner signature comprising a hashed version of the creator signature using the second private key, wherein the embedding of the second digital watermark is associated with a transfer of ownership of the digital content from the creator to the first owner.

[0014] Yet another aspect of the present disclosure includes a method for creating a cryptographic chain of ownership for a non-fungible token using digital watermarking, the method including: obtaining digital content comprising a visual element, the digital content comprising a first digital watermark embedded therein, the first digital watermark comprising a first multi-bit payload carrying a creator signature comprising a cryptographic relationship between a smart contract address and a target blockchain by a first private key, the digital content being associated with a non-fungible token (“NFT”); decoding the first multi-bit payload to obtain the creator signature; and embedding a second digital watermark within the digital content, the second digital watermark comprising a second multi-bit payload carrying a first owner signature, the first owner signature comprising a hashed version of the creator signature using a second private key, the embedding of the second digital watermark being associated with a transfer of ownership of the digital content from the creator to the first owner.

[0015] Yet another aspect of the present disclosure is to provide two different digital watermarks to facilitate associating information with a non-fungible token (“NFT”), wherein a first of the two different digital watermarks comprises a synchronization signal aligned at a first starting point relative to host digital content, the first starting point indicating a first NFT marketplace, the first of the two different digital watermarks does not carry a payload component, and a second of the two different digital watermarks comprises only a payload component and no synchronization signal, the payload component relies on the synchronization signal of the first of the two different digital watermarks for decoding, and the payload component comprises NFT ownership information. and searching the digital content using a digital watermark decoder to locate a first of the two different digital watermarks and a second of the two different digital watermarks, and making a determination according to the decoding results provided by the digital watermark decoder as follows: when only the first of the two different digital watermarks is found, determine a first NFT marketplace; and when both the first of the two different digital watermarks and the second of the two different digital watermarks are found, determine a current owner of the digital watermark from the NFT ownership information.

[0016] Another aspect of the disclosure is an image processing method that includes obtaining digital content comprising a visual element; minting a non-fungible token (“NFT”) associated with the digital content, where the minting results in a token identifier corresponding to a smart contract, a hosting address for the NFT, and a distributed ledger technology (“DLT”) identifier; generating data representing the token identifier, the hosting address, and the DLT identifier; embedding the generated data in the digital content using a digital watermark embedder, where the embedding alters at least some portions of the visual element, where the embedding results in digitally watermarked digital content; and publishing the digitally watermarked digital content on the hosting address of the NFT. In some implementations, the generated data comprises a hash of the token identifier, the hosting address, and the DLT identifier, where the hash comprises a bit-reduced representation of the token identifier, the hosting address, and the DLT identifier.

[0017] A related image processing method may also include receiving data representing the digitally watermarked digital content from a hosting address using one or more multi-core processors; analyzing the data representing the digitally watermarked digital content and decoding a hash using a digital watermark decoder, wherein the analyzing results in a decoded hash; scraping information from the data associated with the hosting address of the NFT, wherein the scraping results in a scraped token identifier, a scraped hosting address, and a scraped DLT identifier; generating a comparison hash based on the scraped token identifier, the scraped hosting address, and the scraped DLT identifier; and comparing the decoded hash to the comparison hash to determine whether the NFT is authentic.

[0018] Additional aspects, features, and advantages will become readily apparent with reference to the following figures and detailed description. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 1 is a block diagram of a signal encoder for encoding a data signal into host digital content. [Figure 2] FIG. 2 is a block diagram of a signal decoder for extracting a data signal from host digital content. [Figure 3] FIG. 3 is a flow diagram illustrating the operation of the signal generator. [Figure 4] FIG. 4 is a block diagram illustrating an example of private / public key based signature generation. [Figure 5A] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5B] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5C] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5D] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5E] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5F] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5G] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5H] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5I] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5J] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5K] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5L] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5M] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5N] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5O] Figures 5A-5P are screenshots showing an NFT verification system. [Figure 5P] Figures 5A-5P are screenshots showing an NFT verification system. DETAILED DESCRIPTION OF THE INVENTION

[0020] Detailed Description There are two (2) main sections that follow in this detailed description: I. Signal Encoding and Decoding, and II. Digital Watermarking for Proof of NFT Authenticity. These sections and their assigned headings are provided merely to help organize the detailed description. It should be understood that descriptions and implementations under one such section are intended to be combined with and implemented using descriptions and implementations from other such section headings. Accordingly, the sections and headings herein should not be construed as limiting the scope of the description. I. Signal Encoding and Decoding

[0021] Figure 1 is a block diagram of a signal encoder for encoding a signal into digital content (e.g., a digital image, digital video, metaverse asset, digital artwork, digital 3D model, digital photograph, digital audio, digital graphic or design). We sometimes refer to the signal as an "encoded signal," "embedded signal," or "digital watermark signal." Figure 2 is a block diagram of a compatible signal decoder for extracting payload from a signal encoded into digital content.

[0022] Encoding and decoding are typically applied digitally. For example, an encoder generates an output, including an embedded signal that can be converted into a rendered form such as viewable digital content, a PDF, a displayed image or video, or other viewable digital form. Prior to decoding, a decoding device takes an image or stream of images and converts it (if in analog form) into an electronic signal, which is digitized and processed by a signal decoding module.

[0023] Inputs to the signal encoder include a host signal 150 and auxiliary data 152. The host signal in this context may be the target digital content. The encoder's objectives include encoding a robust signal with a desired capacity per unit of host signal while maintaining perceptual quality within perceptual quality constraints. In some cases, the host signal may be very slightly variable or present, in which case there is little host interference, but also little host content to visually mask the presence of the data channel. Some embodiments include areas of digital content lacking much pixel variability (e.g., a single uniform color).

[0024] Ancillary data 152 includes variable data information (eg, payload) to be conveyed within the data channel, possibly along with other protocol data used to facilitate communication.

[0025] A protocol defines the manner in which a signal is structured and encoded for robustness, perceptual quality, or data capacity. For any given application, a single protocol or more than one protocol may exist. Examples of multiple protocols include cases where different versions of channels or different channel types (e.g., several signal layers within a host signal) exist. Different protocol versions may employ different robustness encoding techniques or different data capacities. The protocol selector module 154 determines the protocol to be used by the encoder to generate the data signal. It may be programmed to employ a particular protocol depending on input variables such as user control, application-specific parameters, or derivation based on analysis of the host signal.

[0026] The perceptual analyzer module 156 analyzes the incoming host signal and, as appropriate, determines parameters for controlling signal generation and embedding. While this is not necessary in some applications, in others it may be used to select protocols and / or modify signal generation and embedding operations. For example, when encoding within a host signal that will be printed or displayed, the perceptual analyzer 156 may be used to ascertain the color content and masking capabilities of the host digital content.

[0027] The embedded signal may be included in one of the layers or channels of the digital content, for example, corresponding to: In luminance, chrominance, or CIELAB channels (L*, a*, b*) YUV channel · The color channels of the digital content, e.g., Red, Green, Blue (RGB) Color model components (Lab, HSV, HSL, etc.) Channels corresponding to cyan, magenta, yellow, and / or black spot color layers (e.g., corresponding to Pantone colors) that are specified to be used to print the digital content Coatings (e.g. varnishes, UV layers, lacquers, sealants, extenders, primers, etc.) Other material layers (metallic substances, e.g., metallic ink or stamped foil where the embedded signal is formed by punching holes in the foil or by removing the foil and leaving dots of foil), etc.

[0028] The above are typically specified within a digital content file and manipulated by an encoder. For example, an encoder is implemented as a software module that plugs into Adobe Photoshop® or Illustrator processing software. Such software can be specified in terms of image layers or image channels. The encoder can modify existing layers, channels, or insert new ones. Plug-ins can be utilized with other image processing software, for example, for Adobe Illustrator.

[0029] The perceptual analysis performed in the encoder depends on various factors, including the color or colors of the embedded signal, the resolution of the encoded signal, the dot structure and screen angle used to print the image layer with the encoded signal, the content within the layer of the encoded signal, the content in the layers below and above the encoded signal, etc. The perceptual analysis can lead to the selection of a color or color combination for encoding the signal that minimizes the visual difference resulting from inserting the embedded signal within the layer or layers of ink within the digital content. This selection can vary for each embedded location of each signal element. Similarly, the amount of signal at each location can also be varied to control visual quality. The encoder can vary the embedded signal depending on the associated printing technology it employs by controlling parameters such as: Dot shape Signal amplitude at the dot The amount of ink in a dot (e.g., diluting the ink density and reducing the ink percentage) The construction and arrangement of dot clusters or "bump" shapes at the location of a signal element or region of elements. An arrangement of ink applied to an x ​​x y two-dimensional array of neighboring locations can be used to form "bumps" of various shapes or signal amplitudes, as further described below.

[0030] The ability to control printed dot size and shape is a particularly difficult issue and varies with printing technology. Dot size can vary due to an effect called dot gain. The ability of a printer to reliably reproduce dots below a certain size is also a constraint.

[0031] The encoded signal may also be fitted according to a blending model that describes the effect of blending the ink in the signal layer with other layers and the substrate.

[0032] In some cases, the designer may specify that the encoded signal be inserted into a particular layer, while in other cases the encoder may select the layer or layers into which it is encoded to achieve the desired robustness and visibility (visual quality of the digital content into which it is inserted).

[0033] The output of this analysis, along with the rendering method (display or printing device) and rendered output form (e.g., inks and substrate), may be used to define encoding channels (e.g., one or more color channels), perceptual models, and signaling protocols to be used with those channels. See, for example, the work on visibility and color models used in perceptual analysis in U.S. Application Nos. 14 / 616,686 (U.S. Pat. No. 9,380,186), 14 / 588,636 (U.S. Pat. No. 9,401,001), and 13 / 975,919 (U.S. Pat. No. 9,449,357), Patent Application Publication No. 20100150434 (now U.S. Pat. No. 9,449,357), and U.S. Pat. No. 7,352,878 (each of which is incorporated herein by reference in its entirety).

[0034] The signal generator module 158 operates on the auxiliary data and generates a data signal according to the protocol. It may also employ information derived from a host signal, such as that provided by the perceptual analyzer module 156, to generate the signal. For example, the selection of data code signals and patterns, modulation functions, and the amount of signal to apply at a given embedding location may be adapted in response to the perceptual analysis, particularly in response to the perceptual model and the perceptual mask it generates. See below and the incorporated patent documents for additional aspects of this process.

[0035] The embedder module 160 takes a data signal and combines it with a host signal, modulating it onto a channel. The combining operation may be a fully digital signal processing operation, such as when the data signal digitally modulates a host signal, may be a mixed digital and analog process, or may be a purely analog process (e.g., when rendered output layers are combined). As described, the encoded signal may occupy a separate layer or channel of a digital content file. This layer or channel may become combined with the image in a raster image processor (RIP) prior to printing, or may be combined as the layer is printed under or over other image layers on the substrate.

[0036] A variety of different functions exist for combining data and host signals in digital operations. One approach is to adjust host signal values ​​as a function of the corresponding data signal values ​​at the embedding location, controlled according to the perceptual and robustness models for that embedding location. The adjustment modifies the host channel by adding a scaled data signal or multiplying the host value by a scale factor dictated by the data signal value corresponding to the embedding location, with weights or thresholds set according to the perceptual model, robustness model, available dynamic range, and the amount of adjustment due to available adjustments to elementary ink structure (e.g., control of halftone dot structure generated by a RIP). The adjustment may also be by setting or quantizing the value of a pixel to a specific signal element value.

[0037] As described in further detail below, a signal generator produces a data signal with data elements that are mapped to embedding locations within a data channel. These data elements are modulated onto the channel at the embedding locations. Again, see the documents incorporated herein for more information regarding variations.

[0038] The act of combining a signal with other digital content may involve one or more iterations of adjustment to optimize the modulated host with respect to perceptual quality or robustness constraints. One approach is, for example, to modulate the host such that it satisfies a perceptual quality metric as determined by a perceptual model (e.g., a visibility model) for the embedding locations across the signal. Another approach is to modulate the host such that it satisfies a robustness metric across the signal. Yet another is to modulate the host according to both a robustness metric and a perceptual quality metric derived for each embedding location. The incorporated documents provide examples of these techniques. Below, we highlight some examples.

[0039] For digital content containing color images or color elements, the perceptual analyzer generates a perceptual model that evaluates the visibility of the adjustments made by the embedder to the host and sets the level of control for governing the adjustments (e.g., the level of adjustment per color direction and per masking region). This may include evaluating the visibility of the color adjustments at the embedding location (e.g., units of noticeable perceptual difference in color direction in terms of CIE Lab values), contrast sensitivity functions (CSFs), spatial masking models (e.g., using the techniques described by Watson in U.S. Published Patent Application No. US 2006-0165311 A1, incorporated herein by reference in its entirety), etc. One way to address constraints per embedding location is to combine data with the host at the embedding location and then analyze the differences between the encoded host and the original. The rendering process may be digitally modeled to produce a modeled version of the embedded signal as it will appear when rendered. The perceptual model then defines whether the adjustment is noticeable based on the difference between a visibility threshold function calculated for the embedding location and the change at that location due to embedding. The embedder can then vary or limit the amount of adjustment per embedding location to satisfy the visibility threshold function. Of course, there are various methods for calculating adjustments that satisfy the visibility threshold using different sequences of operations. See, for example, U.S. Application Nos. 14 / 616,686, 14 / 588,636, and 13 / 975,919, Patent Application Publication No. 20100150434, and U.S. Patent No. 7,352,878.

[0040] In some embodiments, the embedder also calculates a robustness model. Calculating the robustness model may include calculating a detection metric for the embedding location or region of location. The approach is to model the extent to which a decoder would be able to successfully recover the data signal at that location or region. This may involve applying one or more decoding operations and measurements of the decoded signal to determine a degree of strength or reliability of the extracted signal. Reliability and strength may be measured by comparing the extracted signal to a known data signal. Below, we detail several decoding operations that are candidates for detection metrics within the embedder. One example is an extraction filter that exploits differential relationships between signal elements and neighboring content to recover the data signal in the presence of noise and host signal interference. At this stage of encoding, host interference can be derived by applying an extraction filter to the modulated host. The extraction filter models the data signal extraction from the modulated host and assesses whether the detection metric is sufficient for reliable decoding. If not, the signal may be re-inserted with different embedding parameters such that the detection metric is met for each region in the host digital content to which the signal is applied.

[0041] The detection metric may be evaluated by measuring signal strength as a measure of correlation between the modulated host and variable or fixed data components within a region of the host, or by measuring strength as a measure of correlation between the output of an extraction filter and variable or fixed data components, etc. Depending on the strength measure at a location or region, the embedder may modify the amount and location of host signal modification to improve the correlation measure. These modifications may be tailored specifically to establish sufficient detection metrics for both the payload and synchronization components of the embedded signal within specific regions of the host digital content.

[0042] The robustness model may also model the distortion expected to be caused by a modulated host, apply the distortion to the modulated host, measure visibility and detection metrics, and repeat the above process of adjusting the amount of modification so that the data signal will withstand the distortion. See, for example, Patent Nos. 9,380,186, 14 / 588,636, and 13 / 975,919 (each of which is incorporated herein by reference) regarding image-related processing.

[0043] This modulated host signal is then output as output signal 162 with an embedded data channel. The combining operation may also occur in the analog domain, where the data signal is converted into a rendered form, such as a layer of ink, including overprint or underprint, or a stamped, etched, or engraved surface marking. In the case of a video display, one example is a data signal combined as a graphic overlay with other video content on a video display by a display driver. Another example is a data signal overprinted as a layer of material, engraved into, or etched onto a substrate, which may be mixed with other signals applied to the substrate by similar or other marking methods. In these cases, the embedder employs predictive models of distortion and host signal interference and adjusts the data signal strength so that it will be more reliably restored. Predictive modeling can be performed by a classifier that classifies the type of noise source or class of host signal, and adapts the signal strength and data pattern configuration to be more reliable for the noise source and class of host signal.

[0044] The output signal 162 from the embedder is typically subject to various forms of distortion throughout its distribution or use, which requires robust encoding and complementary decoding operations to reliably recover the data.

[0045] 2, a signal decoder receives a suspect host signal 200 and operates on it with one or more processing stages to detect the data signal, synchronize it, and extract the data. The detector is paired with an input device, where a sensor or other form of signal receiver captures the signal in analog form and an analog-to-digital converter converts it to digital form for digital signal processing. While aspects of the detector may be implemented as analog components, such as pre-processing filters that attempt to isolate or amplify the data channel against noise, the majority of the signal decoder is implemented as a digital signal processing module.

[0046] The detector 202 is a module that detects the presence of embedded signals and other signaling layers. Incoming digital content is referred to as a suspect host because it may not have a data channel or may be so distorted that the data channel is undetectable. The detector communicates with the protocol selector 204 to obtain the protocol it uses to detect the data channel. It may be configured to detect multiple protocols by either detecting the protocol in the suspect signal and / or inferring the protocol based on attributes of the host signal or other sensed contextual information. A portion of the data signal may be intended to indicate the protocol of another portion of the data signal. Therefore, the detector is shown as providing a protocol indicator signal back to the protocol selector 204.

[0047] The synchronizer module 206 synchronizes the incoming signal to enable data extraction. Synchronization includes, for example, determining and compensating for distortions relative to the host signal. This process provides the location and alignment of the signal's encoded data elements within the digital content.

[0048] The data extractor module 208 obtains this location and sequence and the corresponding protocol to demodulate the data signal from the host. The location and sequence provide the location of the encoded data element. The extractor obtains an estimate of the encoded data element and performs a series of signal decoding operations.

[0049] As detailed in the examples below and incorporated documents, the detector, synchronizer, and data extractor may share common operations and, in some cases, may be combined. For example, the detector and synchronizer may be combined so that initial detection of a portion of a data signal used for synchronization indicates the presence of a candidate data signal, and determination of synchronization of that candidate data signal provides synchronization parameters that allow the data extractor to apply an extraction filter at the correct orientation, scale, and starting location. Similarly, a data extraction filter used in a data extractor may also be used to detect portions of the data signal within the detector or synchronizer module. The decoder architecture may be designed with a data flow in which common operations are repeatedly reused, or may be organized in separate stages within pipelined digital logic circuitry so that host data flows efficiently through a pipeline of digital signal operations with little need to move partially processed versions of the host data to and from shared memory, such as RAM memory. signal generator

[0050] 3 is a flow diagram illustrating the operation of the signal generator. Each block in the diagram depicts a processing module that converts input auxiliary data (e.g., payload) into a data signal structure. For a given protocol, each block provides one or more processing stage options that are selected according to the protocol. In processing module 300, the auxiliary data is processed to calculate error detection bits, such as cyclic redundancy checks, parity, or similar error detection message symbols. Additional fixed and variable messages, such as synchronization signals, used to identify the protocol and facilitate detection may be added at this stage or subsequent stages.

[0051] The error correction encoding module 302 converts the message symbols into an array of encoded message elements (e.g., binary or M-ary elements) using an error correction method. Examples include block codes, convolutional codes, etc.

[0052] The repetition encoding module 304 repeats strings of symbols from a previous stage to improve robustness. For example, certain message symbols may be repeated at the same or different rates by mapping them to multiple locations within a unit area of ​​the data channel (e.g., a unit area is a tile of a bit cell, bump, or "waxel," as described further below).

[0053] Next, the carrier modulation module 306 receives the message elements from the previous stage and modulates them onto a corresponding carrier signal. For example, the carrier can be an array of pseudo-random signal elements. The data elements of the embedded signal can also be multi-valued. In this case, M-ary or multi-valued encoding is possible for each signal element through the use of different colors, ink volumes, dot patterns, or shapes. Signal application is not limited to brightening or darkening an object at the signal element location (e.g., brightness or shading changes). Various adjustments can be made to produce changes in optical properties such as brightness. These include modulating layer thickness, surface shape (surface depressions or peaks), layer translucency, etc. Other optical properties, such as chromaticity shifts, changes in reflection angle, polarization angle, or other forms of optical variation, can also be modified to represent the signal element. As will be described, limiting factors include both the limitations of the marking or rendering technology and the ability of the capture device to detect changes in optical properties encoded within the signal. We provide further details regarding signal construction below.

[0054] The mapping module 308 maps signal elements of each modulated carrier signal to locations within the channel. In the case where a digital host signal is provided, the locations correspond to embedding locations within the host signal. The embedding locations may be within one or more coordinate system domains in which the host signal is represented in the signal encoder's memory. The locations may correspond to regions in the spatial domain, the time domain, the frequency domain, or some other transform domain. In other words, the locations may correspond to vectors of host signal features into which signal elements are inserted.

[0055] Various detailed examples of protocols and processing steps of these protocols are provided, for example, in U.S. Patent Nos. 6,614,914, 5,862,260, 6,345,104, 6,993,152, and 7,340,076 (incorporated herein by reference in their entireties), and U.S. Patent Publication No. 20100150434 (previously incorporated). Further background on signaling protocols and schemes for managing compatibility between protocols is provided in U.S. Patent No. 7,412,072 (incorporated herein by reference in its entirety).

[0056] The above description of signal generator module options demonstrates that the form of the signal used to convey auxiliary data varies with the needs of the application. As introduced earlier in this document, signal design involves balancing the required robustness, data capacity, and perceptual quality. This also involves addressing many other design considerations, including compatibility, printing constraints, scanner constraints, etc. We now turn to a consideration of signal generation schemes, particularly schemes that employ signaling and schemes to facilitate detection, synchronization, and data extraction of data signals within the host channel.

[0057] One signaling approach, detailed in U.S. Patent Nos. 6,614,914 and 5,862,260, is to map signal elements to pseudo-random locations within a channel defined by the domain of the host signal. See, for example, FIG. 9 in U.S. Patent No. 6,614,914. In particular, elements of the watermark signal are assigned to pseudo-random embedding locations within an array of sub-blocks (called "tiles") within a block. The watermark signal elements correspond to the error correction coding bits output from the implementation of step 304 in FIG. 3. These bits are modulated onto a pseudo-random carrier to produce watermark signal elements (block 306 in FIG. 3), which are then assigned to pseudo-random embedding locations within the sub-blocks (block 308 in FIG. 3). The embedder module modulates the watermark signal onto the host signal by adjusting the host signal values ​​at these locations for each error correction coding bit according to the value of the corresponding element of the modulated carrier signal for that error correction coding bit.

[0058] The signal decoder estimates each coded bit by accumulating evidence across pseudo-random locations obtained after non-linear filtering of the suspect host digital content. Estimates of coded bits at the signal element level are obtained by applying extraction filters that estimate signal elements at specific embedding locations or regions. The estimates are aggregated through demodulating the carrier signal, performing error correction decoding, and then reconstructing the payload, which is validated using error detection.

[0059] This pseudo-random sequence spreads the data signal so that it has a uniform spectrum across the tile. However, this uniform spectrum may not be the best option from a signal communication perspective, as the energy of the host digital content may be concentrated near DC. Similarly, the auxiliary data channel in the high-frequency components is more prone to being disturbed by blurring or other low-pass filtering-type distortions than other frequency components. Various signal sequences are detailed in U.S. Patent Application No. 14 / 724,729 (now U.S. Patent No. 9,747,656) (each of which is incorporated herein by reference in its entirety). This application details several signaling strategies that can be utilized in the design of encoded signals in conjunction with the techniques herein. Differential encoding is applied to signal elements by encoding the differential relationship between the signal element and other signals, such as background, host elements, or other signal elements (e.g., synchronization elements).

[0060] U.S. Patent No. 6,345,104, which builds on the disclosure of U.S. Patent No. 5,862,260, explains that the embedding location can be modulated by inserting an ink droplet at that location, reducing the brightness in that area, or modulating the thickness or presence of linework. Additionally, brightness can be increased by removing ink or applying lighter ink relative to neighboring ink. This also teaches that the synchronization pattern can act as a carrier pattern for variable data elements in the message payload. The synchronization component can be a visible design into which a sparse data signal (see, e.g., U.S. Patent No. 11,062,108) or a dense data signal is merged. The synchronization component can also be designed to be imperceptible using the methodology disclosed in U.S. Patent No. 5,862,260.

[0061] The inventors further discuss signal design, encoding, and decoding in more detail. As introduced above, one consideration in the design of an encoded signal is the allocation of signals with respect to data transport and synchronization. Another consideration is compatibility with other signaling schemes in terms of the processing flow of both the encoder and the decoder. With respect to the encoder, the encoder should be compatible with various signaling schemes, including dense and sparse signaling, so that each signaling scheme can be adaptively applied to different regions of the digital content design as represented within the digital content according to the characteristics of those regions. This adaptive approach allows the user of the encoder tool to select different methods for different regions, and / or the encoder tool can be programmed to automatically select the signaling strategy for different regions that will provide the most robust signal while maintaining the highest quality image.

[0062] One example of the benefit of this adaptive approach is in designs with different regions that require different encoding strategies: one region may be blank, another blank with text, another with solid-tone graphics, another with specific spot colors, and another with variable image content.

[0063] With respect to the decoder, the present approach simplifies decoder deployment since a common decoder can be deployed that decodes various types of data signals, including both dense and sparse signals.

[0064] As introduced above with reference to FIG. 3, there are modulation / demodulation stages in the encoder, and therefore it is useful to clarify different types of modulation. One stage is where data symbols are modulated onto an intermediate carrier signal. Another stage is where the modulated carrier is inserted into the host by modulating an element of the host. In the first case, the carrier can be a pattern, for example, a pattern in the spatial domain or a transform domain (e.g., the frequency domain). The carrier may be modulated in amplitude, phase, frequency, etc. The carrier may be a pseudorandom string of ones and zeros, or multi-valued elements, inverted or not (e.g., XORed or sign-reversed) to carry payload or synchronization symbols, as described.

[0065] As described in U.S. Patent Application No. 14 / 724,729, the carrier signal may have a structure that facilitates both synchronization and variable data-carrying capacity. Both functions may be encoded by arranging signal elements in the host channel so that data is encoded in the relationship between signal elements within the host. Application No. 14 / 724,729 specifically details a modulation technique called differential modulation. In differential modulation, data is modulated onto the differential relationship between signal elements. In some watermarking implementations, this differential relationship is particularly advantageous because it allows a decoder to minimize host signal interference by calculating the difference between differentially encoded elements. With sparse data signaling, the host signal may lack information at the embedding location, so there may be little host interference to begin with.

[0066] Another form of modulating data is through the selection of different carrier signals to carry distinct data symbols. One such example is a set of frequency-domain peaks (e.g., impulses in the Fourier magnitude domain of the signal) or sinusoids. In such an arrangement, each set carries a message symbol. Variable data is encoded by inserting several sets of signal components corresponding to the data symbols to be encoded. A decoder extracts the message by correlating with the different carrier signals or filtering the received signal with a filter bank corresponding to each message carrier, and identifies the set of message symbols encoded at the embedding locations.

[0067] Having thus far illustrated methods for modulating data into a watermark (either densely or sparsely), we now turn to design issues related to synchronization. For purposes of discussion, we classify synchronization as explicit or implicit. An explicit synchronization signal is one in which the signal is clearly distinct from the data signal and is designed to facilitate synchronization. A signal formed from an impulse function, a frequency domain peak, or a sinusoidal pattern is one such example. An implicit synchronization signal is one that is inherent in the structure of the data signal.

[0068] An implicit synchronization signal may be formed by a sequence of data signals. For example, in one encoding protocol, a signal generator repeats a pattern of bit cells representing data elements. We sometimes refer to the repetition of bit cell patterns as "tiling," because it implies a continuous repetition of elementary blocks adjacent to each other along at least one dimension in the coordinate system of the embedding domain. The repetition of a pattern of data tiles or a pattern of data across tiles (e.g., the bit cell patterning in U.S. Pat. No. 5,862,260) creates a structure in the transform domain that forms a synchronization template. For example, redundant patterns can create peaks in the frequency domain, autocorrelation domain, or some other transform domain, and these peaks form a template for alignment. See, for example, U.S. Pat. No. 7,152,021 (incorporated herein by reference in its entirety).

[0069] The concepts of explicit and implicit signaling merge easily because both techniques can be included in a design and, ultimately, both provide an expected signal structure that a signal decoder detects to determine geometric distortion.

[0070] In one arrangement for synchronization, the synchronization signal forms a carrier for variable data. In such an arrangement, the synchronization signal is modulated with variable data. An example includes a synchronization pattern modulated with data.

[0071] Conversely, in another arrangement, the modulated data signal is arranged to form a synchronization signal. Examples include repeating bit cell patterns or tiles.

[0072] The variable data and synchronization components of the encoded signal may be chosen to be conveyed through orthogonal vectors. This approach limits interference between the data-carrying elements and the synchronization components. In such an arrangement, a decoder correlates the received signal with the orthogonal synchronization component to detect the signal and determine the geometric distortion. The synchronization component is then filtered out. The data-carrying elements are then sampled, for example, by filtering with a filter adapted to correlate with or extract data elements from the orthogonal data carriers. Signal encoding and decoding, including decoder strategies employing correlation and filtering, are described in U.S. patent application Ser. No. 14 / 724,729.

[0073] Additional examples of explicit and implicit synchronization signals are provided in the above-cited Patents Nos. 6,614,914 and 5,862,260. In particular, one example of an explicit synchronization signal is a signal consisting of a set of sine waves with pseudo-random phase, which appear as peaks in the Fourier domain of the suspect signal. See, for example, Nos. 6,614,914 and 5,862,260, which describe the use of synchronization signals in conjunction with robust data signals. See also U.S. Patent No. 7,986,807, which is incorporated herein by reference in its entirety.

[0074] U.S. Publication No. 20120078989 (incorporated herein by reference in its entirety) provides additional methods for detecting embedded signals with this type of structure and recovering rotation, scale, and translation from these methods.

[0075] Additional examples of implicit synchronization signals and their uses are provided in U.S. Patent Nos. 9,747,656, 7,072,490, 6,625,297, 6,614,914, and 5,862,260, which are incorporated by reference herein in their entireties. II. Digital Watermarking for Proof of NFT Authenticity

[0076] Unlike coins in cryptocurrencies, non-fungible tokens ("NFTs") are blockchain tokens designed to be unique and non-fungible. This means that a first NFT token is uniquely distinguishable from a second NFT, a third NFT, and so on. NFTs are often implemented according to a standard, such as the ERC721 standard, which allows an NFT to be owned by a single owner at any given time and allows for secure transfer from one owner to another. For example, the ERC721 standard provides an application programming interface (API) that allows computer programs to interface with each other. Using this standard, it is possible to trace all transactions associated with an NFT from its transfer between owners to its current value in the market. Another NFT standard is the ERC1155 standard, which allows for the creation and transfer of multiple tokens simultaneously. As mentioned above, we use the term "digital content" to mean one or more digital assets associated with an NFT. Examples of digital assets include images and photographs, digital art, digital images generated by artificial intelligence (“AI”), graphics, logos, digital designs, 3D models, documents and presentations, video (including one or more video frames), audio, metaverse assets, etc. NFTs typically include associated metadata. With respect to this patent document, NFT metadata includes associated data, such as a document (e.g., a JSON document) or file containing elements. The following is an example of an NFT metadata document:

[0077] {"Name":"Grumpy Cat","Description":"This is a remastered version of an original photograph of Grumpy Cat. This one-of-a-kind keepsake is offered as a one-of-a-kind, certified edition NFT. \n\nGrumpy Cat is perhaps the most famous cat on the planet, a New York Times bestselling author, star of his own Lifetime Christmas movie, and the first cat ever to be exhibited as a wax figure at Madame Tussauds. Grumpy became a pop culture icon after a photo of his "sulky" expression was posted to Reddit on September 23, 2012. \n\n1626x1957 pixels\n\nThe largest NFT ever. “Image”: “ipfs: / / ipfs / QmfWtxAM2qwKrEXVoeasArDBrR12qL7HCuD2B4Tqe5R8Bs / nft.jpg”}

[0078] Due to their non-fungibility, NFTs are often used in conjunction with digital content in the metaverse or video games. However, while NFTs are guaranteed to be unique, the link between an NFT and its associated digital content is cryptographically weak. This technical problem allows someone to simply copy the digital content ("DC1") attached to an NFT ("NFT1") and create a new NFT ("NFT2") attached to the same digital content (i.e., the same "DC1"). Thus, there may be two NFTs (NFT1 and NFT2) linked to the same digital content (DC1).

[0079] For popular NFT collections, such as Bored Apes (https: / / opensea.io / collection / boredapeyachtclub), this weak link is an issue that can be mitigated somewhat by ensuring that NFTs are minted via the well-known Bored Apes smart contract. However, for the majority of users and NFTs, this weak link is a serious issue that can lead to fraud and counterfeiting. Current solutions to the counterfeiting problem involve manual authentication ("Proof of Democracy") of the digital content tied to the NFT (see, for example, https: / / wakweli.com / ).

[0080] One aspect of our described technology provides a cryptographic method for irreversibly linking an NFT to its digital content. This protects the digital content tied to the NFT through the use of a digital watermark that may only have been generated or authorized by the creator of the digital content. In a first embodiment, the creator creates the digital content and then creates a cryptographic link between i) the digital content, ii) a blockchain used for minting, and iii) the creator.

[0081] Our implementation is provided below in steps 1-7.

[0082] 1. Creators create digital content.

[0083] 2. The creator mints the NFT on blockchain "B" via smart contract "C." The creator wallet (e.g., Metamask) is connected to an NFT marketplace (e.g., OpenSea). The creator wallet issues a transaction to an NFT smart contract connected to the marketplace. Typically, the wallet is used to pay fees for smart contract execution. The smart contract then returns a unique identifier (e.g., "tokenId" in the minting function below) that will be linked in the NFT metadata. An example minting function is provided below. [ka] Here, a. "recipient" is the public address of the wallet that will receive the minted NFT. b. "tokenURI" is a string that points to a document (e.g., JSON) that describes the metadata of the NFT. c. "newItemId" is a unique identifier for the newly minted NFT.

[0084] 3. The creator creates a signed message of the digital content that can be used to cryptographically bind the digital content to the creator, the NFT, the blockchain, and the smart contract that created (minted) the NFT. Below is an example of such a signed message in JSON format: [ka] Here, a. "blockchain" is the blockchain (here Ethereum) used to mint the NFT, which can also be used as the blockchain's identifier (or DLT identifier). b. "contractAddress" is the address of the smart contract used to mint the NFT. c. "tokenId" is the actual NFT ID (here "12") returned by the smart contract. d. "contentHash" is a perceptual, image-based, or other hash of the digital content prior to digital watermark insertion. e. "signature" is the JSON message content (contentHash, blockchain, contractAddress, tokenId) that will be signed using the creator's private key.

[0085] In one embodiment, this message is added to or referenced by the NFT metadata. The fields "blockchain" and "contractAddress" help ensure that the creator cannot mint the NFT corresponding to the digital content on several blockchains and / or via several smart contracts. This and the field "tokenID" uniquely bind the tokenID to the selected blockchain and smart contract. The field "contentHash" adds an additional layer of security that the digital watermark is not placed on the wrong artwork. The field "signature" ensures that only the creator (the owner of the private key) signed the message. The private key is preferably generated using an asymmetric public / private key cryptography scheme, such as one based on Elliptic Curve Cryptography (ECC) or Rivest-Shamir-Adleman (RSA). For example, the Elliptic Curve Digital Signature Algorithm (ECDSA) uses the ECC key to ensure that each user is unique. Other signature algorithms include, for example, Schnorr signatures and BLS (Boneh-Lynn-Shacham) signatures. SECP, or specifically SECP256k1, is the name of an elliptic curve. Examples of SECP include the above-mentioned Elliptic Curve Digital Signature Algorithm (ECDSA) and Schnorr signatures. The ECDSA and Schnorr signature algorithms work with the SECP256k1 curve in many blockchains.

[0086] 4. The signed message (e.g., the signature) is hashed using a cryptographic hash function such as, for example, SHA-1, SHA-2, SHA-3, MD5, NTLM, Whirlpool, BLAKE2, BLAKE3, or LANMAN 8, resulting in, for example, 41d0b2c646c49a42b3f678b869dc2b72089378190b5ecec992986d1c3b178252, and the hash is embedded within the digital content as a digital watermark payload. Suitable digital watermark embedding is discussed above in Section I and in the patent documents incorporated by reference. (In an alternative embodiment, two digital watermarks are used in step 4. The first digital watermark identifies the smart contract intermediary (or NFT network). This digital watermark may be embedded using a public encoder, meaning that decoding access is widely available for public use. The second digital watermark carries a cryptographic hash of the signed message. The second digital watermark may be embedded using a more restricted embedder, e.g., one with a spreading or encoding key corresponding to the restricted detector. The restricted detector includes a corresponding key that allows the detector to locate and / or decode the cryptographic hash. This is useful for allowing smart contract intermediaries to make limited distribution of restricted decoders to users directed to them via the first digital watermark.)

[0087] 5. The digital content is uploaded to the URI referenced in the URI metadata.

[0088] 6. The creator adds the NFT to a marketplace (e.g., OpenSea) (e.g., lists it for sale).

[0089] 7. Potential purchasers can verify the authenticity and uniqueness of the NFT and associated digital content by decoding the digital watermark and comparing it to a hash of the relevant JSON fields referenced or included in the NFT metadata. Suitable digital watermark decoding is discussed above in Section I and in the patent documents incorporated by reference.

[0090] 8. The buyer purchases the NFT and transfers ownership (ownership transfer authorized by the creator), for example, using the following transfer function: [ka]

[0091] For verification, for example, a user of an NFT marketplace or a social network that uses NFTs provides the watermarked digital content to a corresponding digital watermarking decoder. The decoder locates and decodes the digital watermark and obtains the payload (e.g., comprising a cryptographic hash as in section 4 above). This decoded cryptographic hash value can then be compared to corresponding hashes of the associated NFT "metadata" fields (e.g., contentHash, blockchain, contractAddress, tokenId).

[0092] To verify private key-based signatures, a mapping between creators and their addresses can be maintained by the NFT network or pointed to in the NFT metadata. To verify the signature, the corresponding public key or address of the signer, here the creator, is required. For example, referring to Figure 4, the steps for secure signing include: The sender uses a cryptographic hash function to create a message digest, which is a condensed or bit-reduced version of the data that is unique to that particular NFT. The sender uses their private key to sign the message digest and produce a digital signature that is unique to the combination of the private key and the message digest. The sender then sends the NFT along with a digital signature to the receiver, which can be an NFT network or a social media platform. The receiver verifies the digital signature using the sender's public key, which is publicly available. If the signature is valid, this indicates that the transaction data has not been altered in any way and was indeed sent by the owner of the private key.

[0093] One example of a creator signature is a message containing a string of alphanumeric symbols such as "I authenticate as creator XXX for use in digital watermarking for NFT tools." The creator or artist then posts this signed message on one or several social networks (e.g., X (formerly Twitter)). An alternative implementation uses a DID (Disjoint Identifier) ​​to identify the creator and their public key.

[0094] Digital watermarking can also be used to indicate transfer of ownership using a series of chained watermarks, one for each person in the chain. Consider the following implementation:

[0095] 1. After digital content has been minted and digitally watermarked to carry cryptographic information as discussed above (e.g., a hash as in section 4 above), the watermarked digital content, along with associated metadata, can be stored within the Interplanetary File System (or “IPFS”). This is the initial version or “version 0” of the digital content, which is similar to the vehicle identification number or VIN in the car analogy. Anyone with access to IPFS can view the digital content. (IPFS is a file-sharing system that can be leveraged to efficiently store and share large files. It relies on cryptographic hashes, which can be easily stored on the blockchain. Storing the metadata here provides fixed metadata, as alterations to the original metadata can be easily detected via cryptographic means.)

[0096] 2. As part of the transfer of ownership of the NFT, e.g., the initial sale of the digital content, version 0 of the digital content is digitally watermarked. This is a second digital watermarking of the digital content, since the creator has already marked version 0. This second digital watermarking includes a signature created with the private key of the first owner and, possibly, transaction details. This would be like adding a new license plate to a car. As with our car example, the VIN remains unchanged, but the registered owner is reflected by the addition of the new plate.

[0097] 3. The resulting digital content now contains two digital watermarks: the creator and the registered owner at the time of the initial transfer of ownership.

[0098] 4. Upon resale, the digital content is digitally watermarked again. This becomes a third digital watermarking of the digital content, since the creator and first purchaser have already marked the digital content. This third digital watermarking includes a signature created with the second owner's private key and possibly transaction details. While the third digital watermark may not necessarily determine who owns the work, since there may be additional watermark layers, all registered watermarks can be evaluated to determine the current registrant, whoever they are, since the entire ownership history is contained within the layered digital watermark.

[0099] This makes it possible to have a chain of ownership that is directly verifiable from the content of the watermark, which can be useful for fraud tracing and licensing models where media is licensed by narrow field of use (production music, stock photo agencies, etc.).

[0100] Consider another implementation in which a digital watermark payload is added or updated to reflect the chain of ownership. The creator creates a signature using their private key: s1 = signature(smart contract address + target blockchain, private key). This creator signature represents at least the smart contract address and target blockchain, signed with the creator's private key. The signature may include additional data, such as an NFT identifier, a perceptual hash or fingerprint of the digital content, creator information, public key information, etc. s1 is embedded within the digital content as the first payload with the first digital watermark. A subsequent owner (e.g., initial purchaser of the digital content) creates a second signature using their private key: s2 = signature(s1, private key). This s2 is then embedded within the digital content with the digital watermark. s2 can be embedded into the digital content using a second digital watermark layered with the first digital watermark, for example, using a different protocol or a different spreading key; however, s2 can replace s1 when using so-called reversible digital watermarking. That is, s1 (and the digital watermark carrying such) is removed from the digital content, and s2 is then embedded. Thus, when using reversible digital watermarking, the digital content has only one digital watermark, carrying s2. However, because the s2 signature utilizes s1 + the first buyer's private key, the cryptographic link with s1 still persists. The subsequent owner can then create a signature using their private key: s3 = signature(s2, private key). As above, s3 can be layered into the digital content, which would contain three different digital watermarks, carrying s1, s2, and s3, respectively. Alternatively, if reversible digital watermarking is used, s2 may be removed and replaced with a digital watermark that carries only s3 as payload.This methodology makes it possible to have a chain of ownership that is directly verifiable from the content of the watermark. Examples of reversible digital watermarking are described, for example, in U.S. Patent Nos. 8,098,883, 8,059,815, 8,032758, 7,187,780, and published PCT application WO2004102464A3, each of which is incorporated herein by reference in its entirety.

[0101] In a related implementation, the watermark embedder for handling the embedding is only available from an address associated with the data carried by or accessed through the smart contract. This creates a contractual lock on who and under what conditions the digital watermark can be embedded into the digital content. This approach may also request the current version of the digital content from a digital content intermediary associated with the sale, for example, to watermark for the first or second buyer. The digital watermark embedder preferably includes or communicates with a digital watermark decoder that can read the previous digital watermark from the current version to retrieve s1 or s2. This decoder check ensures that s1 or s2, depending on the sale status, are present in the digital content before proceeding to embed s2 or s3. This contractual embedder access and previous signature check helps prevent spoofed attempts to "overwrite" the watermark with a forged signature payload.

[0102] For assets that are traded meaningfully (e.g., in-game artwork) or have fractional ownership via NFTs, the same digital watermark infrastructure as described above (starting with unmarked content) can be applied, but each time a new fractional owner is added, an update to the Merkle tree can be made, allowing for the provenance of the item (who all the owners were / are).

[0103] We now consider several additional digital watermarking implementations, including those that use two (2) different types of digital watermarks embedded within the same digital content.

[0104] Digital Watermark 1: Digital Watermark 1 contains only a synchronization component, without a message signal, as described above in Section I and in the patent documents incorporated by reference. This is essentially a one-bit digital watermark, as determined by the presence or absence of the synchronization component. However, the bit-carrying capacity of a synchronization-only watermark can be extended by varying the alignment or starting location (or starting locations) of the signal relative to the digital content. For example, suppose the synchronization signal is aligned with the top corner of the image. This is translation position 00. If the synchronization component translation is shifted from the top left corner of the image to, for example, the top right corner of the image, this is position 01 (10 = bottom right, 11 = bottom left). The translation or orientation of the synchronization signal relative to the digital content now carries information. Naturally, slight shifts and offsets can be used as the signal origin instead of the corner of the image. In an extreme case, the synchronization component is aligned within the digital content according to 128 x 128 shift positions, i.e., a 16,000 address space. In a less extreme case, there are only 64x64 translation positions, or 4,000 address spaces. This allows a digital watermark to convey a relatively small address space meant to indicate, for example, an NFT marketplace, a smart contract intermediary, or a target blockchain.

[0105] Digital Watermark 2: Digital Watermark 2 contains only a message component, which is intended to be aligned with the synchronization component of Digital Watermark 1. Using Digital Watermark 2 is useful, for example, when a widely distributed low-resolution version of digital content directs potential buyers back to an NFT marketplace, smart contract intermediary, or target blockchain via Digital Watermark 1. The NFT marketplace or smart contract intermediary can offer a high-resolution version of the low-resolution digital content for sale (preferably including Digital Watermark 1).

[0106] Upon sale of high-resolution digital content, Digital Watermark 2 is embedded within the digital content, and the embedding can be aligned with the synchronization component carried by Digital Watermark 1. Digital Watermark 2 preferably includes a multi-bit payload (e.g., including the creator information or chain of ownership discussed above).

[0107] Using such a digital watermark-based approach, an NFT marketplace (e.g., OpenSea) makes all digital content widely available, but only Digital Watermark 1 can be embedded within the digital content. A synchronized component of Digital Watermark 1 referenced within the digital content at a specific origin (e.g., the center or upper right corner) indicates that the NFT marketplace is the intermediary. A perceptual or image-based hash can also be written to the blockchain in some form when the creator registers with the NFT marketplace. Instead of a low-resolution version as discussed above, we now consider a high-resolution version of the digital content embedded with Digital Watermark 1 that is made freely available on the internet. There are three possible actions that can occur upon encountering watermarked digital content: a. If any digital watermarks1 are not detected using a digital watermark reader, continue business as usual with respect to the Digital Content. b. If the watermark reader decodes digital watermark 1, the digital content is potentially for sale. The reader is programmed to compare the translation or origin of the synchronization signal and determine the NFT marketplace hosting the digital content. c. When the watermark reader decodes the digital watermark 2, it now knows, via a smart contract, who the current owner is and what rights are associated with it. Reviewing the smart contract can yield unexpected benefits, for example, it allows printing t-shirts for free, but disallows any other use.

[0108] At popular content site ingests, a digital watermark detector can be employed as a filter looking for Digital Watermark 1 and / or Digital Watermark 2 in response to digital content uploads. Once a digital watermark is found, action can be taken. A benefit of using Digital Watermark 2 in conjunction with a smart contract is that licensing can be automated no matter where the image is sent, if the contract allows, rather than just through the sale of the asset via an intermediary. This allows for tracking and tracing of digital content and collecting fees when the digital content is encountered. An associated smart contract can be referenced in response to finding Digital Watermark 2 to verify appropriate use of the digital content. For example, the smart contract may indicate whether the digital content is licensed for a particular region or network site. In an extreme example, using a so-called “whitelist” structure, an automated removal request is generated if the digital content is found anywhere not included on the whitelist (e.g., carried by the smart contract).

[0109] In some embodiments, the information intended to be included in the digital watermark (e.g., the tokenID) may not necessarily be known prior to minting the NFT. However, once the NFT is minted, all data (including the digital content) is preferably fixed and therefore cannot be modified. Consider the following example.

[0110] With regard to on-chain watermarking, a digital watermark can be added to the digital content by the smart contract code itself. In this embodiment, a watermark embedder is included within the smart contract code such that the smart contract can add the digital watermark to the NFT digital content as part of (or immediately after) the minting process.

[0111] In another embodiment, the NFT metadata includes only the NFT token ID ("tokenID"), the smart contract address, and the blockchain identifier. In most cases, the token ID can be predicted through an audit of the smart contract, but this is not always possible, for example, in the case of non-sequential token IDs or when facing race conditions.

[0112] In a related embodiment, if you know the smart contract address but cannot predict the token ID, the token ID can be replaced by the minter's (e.g., digital content creator's) address and transaction nonce. A transaction nonce is a value (usually a number) included in a transaction and is used to prevent replay attacks. The value can be incremented each time a transaction is sent by a particular blockchain account or wallet. When encoding this information, verifying whether the NFT is authentic can be slightly different. In effect, you retrieve the minter's address and transaction nonce from the contract address, chain ID, and token ID you already have. To do this, you find the transaction in which this particular token ID was minted on this particular contract address.

[0113] Similarly, the contract address may not be known because the digital content is already incorporated into (e.g., included with) the contract prior to deployment when the address is assigned. In this case, the contract address may be replaced by the artist address (the address where the smart contract is deployed) and the transaction nonce. When encoding this information, verifying whether the NFT is authentic will be slightly different. Indeed, the minter's address and transaction nonce are retrieved from the contract address, chain ID, and token ID that you already have. To do this, find the transaction in which this particular token ID was minted on this particular contract address. From there, the minter and transaction nonce can be obtained. A flag (e.g., a bit equal to 1 or greater than 1) can be used to distinguish the version of the NFT metadata used. This is useful when you want to protect digital content in an NFT collection that is linked to a smart contract that will be deployed. Typically, a link to such an image is included in the smart contract prior to deployment.

[0114] Another embodiment leverages a concept called "lazy minting." Lazy minting generally means that NFTs are not minted when they are created, but rather when they are sold. However, once created, NFT marketplaces (e.g., Opensea) already provide a reserved token ID (and reserved contract address), meaning such can be known prior to minting. A solution utilizing lazy minting creates an NFT without fixed NFT metadata, copies its token ID, blockchain identifier, and contract address, embeds this information within the associated digital content using digital watermarking, updates the NFT's image, and then fixes the metadata (e.g., using an IPFS URI). This can be implemented using web extensions and / or APIs.

[0115] The first option, as discussed above, is to hash the NFT metadata file and embed such within the digital watermark. The second option is to store this metadata within a manifest file attached to the digital content (e.g., via an EXIF ​​header in the case of a JPEG image) by extending a standard manifest format, such as C2PA content authentication information. The digital watermark can then include a hash of this manifest. The third option is to include the complete or entire NFT metadata as the digital watermark payload. In relevant (or optional) cases, the complete or entire NFT metadata is signed with a private key. In this relevant case, for digital content found on the Internet, it will know whether this will be linked to an NFT. That is, a digital watermark detector analyzes the found digital content and retrieves the encoded data. The encoded data may include the entire NFT data. This scenario avoids having to reconstruct the NFT metadata and corresponding hash (the first option) to know whether the NFT is original or reminted.

[0116] A fourth option is to host an unhashed version of the NFT metadata file within a decentralized file system (e.g., IPFS), copy the file ID or the entire IPFS Web URI (e.g., ipfs: / / bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi), and encode this (the file ID or the entire IPFS Web URI) into the digital content as a digital watermark payload. (As mentioned above, IPFS is a file-sharing system that can be leveraged to efficiently store and share large files. It relies on cryptographic hashes, which can be stored on the blockchain. Storing the metadata here provides “fixed” metadata, since alterations to the original metadata can be easily detected via cryptographic means.) Once decoded from the digital watermark embedded within the digital content, the file ID or IPFS Web URI is used to access the fixed, unhashed version of the NFT metadata file. In some implementations, the first n bits or the last n bits (n is a positive integer) of the digital watermark payload can be reserved to identify the decentralized file system used, and then at least some of the remaining bits would be a file ID. Alternatively, a decentralized URI within the digitally watermarked digital content may be encoded as the digital watermark payload. If a person finds digital content in a location without any context, they can open their digital watermark decoding app (e.g., Digimarc Discover, offered by Digimarc Corporation, located in Beaverton, Oregon, USA), scan the digital content (e.g., an image, graphic, or video), and they will be redirected to an NFT marketplace with an NFT associated with the digital content.Regarding identifying bits, in one embodiment, a record is defined that uniquely and imperatively maps a blockchain to a code (or DLT identifier / identification) in the NFT metadata file. For EVM (Ethereum Virtual Machine) compatible chains, their chain ID is used, which is common practice (a list of chain IDs is available on chainlist.org). For other chains, codes can be established. Below is an example: [Table 1-1] [Table 1-2]

[0117] Now consider contextual redirection with respect to NFTs. It is somewhat common practice for people to post new NFTs on their social media networks, for example, using the NFT's digital content as their social network profile picture. A user wishing to access or test the authenticity of a displayed NFT may open a digital watermark detector (e.g., the Digimarc Discover app running on an iPhone® or Android® smartphone) and capture an image representing the digital content. The watermark detector analyzes the captured digital content (e.g., an image, graphic, or video) and locates and decodes the digital watermark embedded within the digital content. The digital watermark may include or link to an NFT exchange, such as OpenSea (or equivalent), which provides detailed information such as the NFT's cost, attributes, and creator. Additionally, the digital watermark can be used to determine the authenticity of the NFT.

[0118] Relatedly, an artist can log in to the platform and configure where to redirect people based on context (e.g., redirect them to a new artwork that will be put up for auction in the future, e.g., two days from now). In this case, a digital watermark detector running on, for example, a smartphone, directs the user to the platform. The decoded tokenID can be used to access an associated NFT data record stored on the platform, which includes a redirection link provided by the artist. The redirection link is communicated from the platform to, for example, a smartphone-based digital watermark detector. The redirection link is provided to a web browser hosted by the smartphone, which connects to the redirection link. Redirection can also be location-based. For example, the data record has a redirection link to direct everyone from the United States to a first website, e.g., for auctioning physical art. Alternatively, a user can use a browser extension to automatically verify the NFT redirection as well as its authenticity.

[0119] In addition to containing or linking to NFT metadata, the digital watermark may also contain or link to license, ownership, and copyright information associated with the NFT.

[0120] Our technical solution is also applicable to so-called dynamic NFTs (dNFTs), which are non-fungible tokens (NFTs) with encoded smart contract logic that allows them to automatically change their meta-data based on external conditions. In some cases, the underlying digital content itself is dynamically modified. The original digital watermark may be replaced, but in one embodiment, a second digital watermark may be added to the modified digital content. The second digital watermark preferably includes a nexus or link (e.g., a cryptographic link) between the original digital content (e.g., a hash of such) or the first digital watermark (or a hash of such) and the modified digital content or the second digital watermark.

[0121] Upon resale of an NFT, a technical mechanism can be established to help remit royalty payments back to the original creator. The creator originally maintains a list or record of all digital watermark hashes and corresponding artist addresses for their NFTs. Such a list or record can be included within the smart contract itself. Upon resale, the digital watermark hash from the resold digital content is checked against the list or record. If found, the system allocates a portion of the sales proceeds to the artist address for royalty payments. Of course, instead of including a record or list within the smart contract, the mapping could be centralized. This would allow artists to earn royalties when someone sells a copy of their NFT.

[0122] An NFT verification system will now be discussed with reference to Figures 5A-5P. The NFT verification system operates to protect the integrity of NFT offerings through digital watermarking. The NFT verification system includes two main components: an NFT authorization module and an NFT verification module. The NFT authorization system embeds digital watermarking (including a multi-bit payload) within NFT digital content. The payload comprises information for verifying the authenticity of the NFT, as discussed below. The information can be encrypted, for example, using a cryptographic hash. Alternatively, the hash can be a bit-reduced representation of the information to help accommodate watermark payload capacity requirements. The NFT verification module includes a digital watermark detector, which analyzes the NFT digital content for the embedded digital watermark.

[0123] An NFT authorization module is provided for authorizing NFTs. The NFT authorization module may include software instructions running on one or more multi-core processors, e.g., two or more multi-core parallel processors, that provide, for example, a graphical hosting environment. The graphical hosting environment includes multiple graphical user interfaces. The software instructions may include, invoke, and / or communicate with various other modules, networks, and systems, e.g., digital watermarking embedders, digital watermark decoders, NFT networks (e.g., blockchains), and payment services and wallets. The NFT authorization module may be stored locally to the NFT creator, but, like various other modules, is typically hosted on a remote network.

[0124] Referring to FIG. 5A, the NFT authorization module provides a graphical interface for uploading digital content, such as digital images. While digital images are discussed with respect to FIGS. 5A-5P, it should be understood that other forms of digital content, such as videos, photographs, graphics, artwork, metaverse assets, and audio, may alternatively be protected using the described NFT verification system. The uploaded digital content will be minted to create an NFT. Once an interface button is selected, a file search window is presented (see FIG. 5B), through which the creator can select a digital image for minting. Of course, the digital image may be stored locally to the creator, but is often located remotely, for example, in a cloud drive. FIG. 5C illustrates an interface through which the creator can select a preferred mechanism for minting their NFT. The "Mint from our interface" mechanism is specifically discussed below, although options for other minting services also apply. For example, when using the "Mint from OpenSea" or "Mint from Elsewhere" options, the creator may have a button, link, or interface through which they can provide NFT metadata, for example, via the "Fill in NFT Metadata" interface (see circled link in Figure 5D). NFT metadata may include, for example, a contract address, blockchain ID, and NFT token ID. This metadata, or a hash of it, can be carried by a digital watermark payload. We now want to follow the "Mint from our interface" flow path.

[0125] Once the "Mint from our interface" option is selected, a user interface is provided that allows the NFT creator to link a payment session for minting the NFT (see Figure 5E). After successful payment, the creator selects the "Sign" option (Figure 5F). The signing step uniquely links the payment transaction to the current session, ensuring that a third party cannot use or forge a payment transaction from a different transaction.

[0126] The creator is prompted to add other information in Figure 5G, such as a name and description for the NFT, and NFT attributes such as type and value. (This interface is provided here because it follows a path along the "Mint from our interface." This entered information is used only for the NFT minting process, which may be done elsewhere, for example, if you previously selected the "Mint from OpenSea" interface. Once completed, the process proceeds to embedding metadata (e.g., digital watermarking) into the digital content. See FIG. 5H. The NFT authorization module may include a digital watermark embedding module, or alternatively, communicate with or invoke a remotely located digital watermarking embedding module. Suitable digital watermark embedding techniques are discussed above in Section I of this patent document, including in the patent documents incorporated by reference. After successful payment for the transaction, a digital watermark is added to the original digital image. For example, in one implementation discussed above, the watermark data includes a cryptographic or other hash of the NFT's TokenID, blockchain identifier, and smart contract address. The hash is carried as a digital watermark payload. In another implementation, the watermark data includes the smart contract, blockchain identifier, and NFT address. It comprises a plain text representation of the TokenID or a cryptographically encoded version using, for example, a public / private key pair. Other digital watermark data and signature options are also available, for example, as discussed in this patent document. NFT metadata can be fixed, for example, by uploading such to an IPFS URI.

[0127] After digital watermarking, the NFT is ready to be minted. See Figure 5I. This may involve additional fees. The NFT authorization tool includes, communicates with, or invokes a digital wallet to facilitate payment. Payment may also include a so-called "gas" fee to prompt the blockchain validator / minter to process the NFT minting transaction. Once minted, the NFT can be viewed on known marketplaces, such as OpenSea. See Figure 5J. (Typically, to the extent that a particular NFT utilizes a standard, such as ERC 721 on the EVM, the minted NFT should be visible on all compliant marketplaces built on the EVM / Ethereum standard.) The minted NFT includes a digital watermark embedded within the digital content. The digital watermark provides a link between the NFT metadata and the NFT's associated digital content.

[0128] The NFT validation module is used to help determine the authenticity of NFTs and their associated digital content. The NFT validation module deploys a digital watermark detector to verify the authenticity of newly minted NFTs. One implementation of the NFT validation module includes a dedicated web browser extension. Such extensions are typically software programs that can modify and enhance the functionality of a web browser. Extensions can be written using, for example, HTML, CSS (Cascading Style Sheets), and / or JavaScript. The web browser extension can deploy a digital watermark detector, for example, via decoder code embedded within the extension via software instructions, or alternatively, invoked from the web browser extension. When the web browser extension invokes a remotely located digital watermark detector, the extension can provide the digital content to the digital watermark detector. In another embodiment, the web browser extension provides an address hosting the digital content to the digital watermark detector, which accesses the digital content by visiting that address. The web browser extension allows users to verify the authenticity of non-fungible tokens (NFTs) and associated digital content on a marketplace website. For example, the web browser extension, running in the background and / or once activated (e.g., by clicking on an icon or displayed widget), deploys a digital watermark detector and analyzes the digital content of the NFT. The digital watermark detector analyzes digital images to locate and decode multi-bit payloads carried therein. The web browser extension includes functionality, provided by, for example, software instructions, for scraping web pages for information and comparing it against the decoded watermark payload.For example, some NFT marketplaces display text corresponding to the NFT token ID, blockchain identifier, and contract address. Additionally or alternatively, such information is typically found on the web page (e.g., in HTML or CSS) at a given marketplace URL or can be accessed via a marketplace API. If the digital watermark payload includes a hash of such values, the web browser extension can generate a hash of the scraped or collected information using the same algorithm (or key set) used to create the digital watermark payload. Alternatively, the web browser extension can invoke a third-party authentication service and provide the scraped information to that service, which generates a corresponding hash when used to check against the hash of the decoded watermark payload. In FIG. 5K, the NFT is verified when the digital watermark payload and the generated hash (or plaintext, if that is what is carried by the payload) correspond in an expected manner (e.g., match, match within a tolerance, or are related through a cryptographic relationship). A pop-up window generated by the web browser extension can display the NFT metadata and whether the NFT was verified.

[0129] Now, with reference to Figures 5L-5P, consider an NFT forgery attempt. A screenshot (or simply a "right-click" copy function) is taken of the digital content of the displayed NFT (Figure 5L). To confirm, this is an unauthorized copy of the digital content. However, the unauthorized copy also carries a digital watermark. That digital watermark contains a payload that directly links to the original NFT. The malicious creator now creates a different NFT (termed the "copied NFT") using the screenshot of the digital content (Figure 5M) and successfully mints the copied NFT (Figure 5N). The copied NFT is listed for sale on a marketplace platform, e.g., OpenSea (see Figure 5O, the "O" as in "Oscar"). Fortunately, dedicated web browser extensions are available for validation checks. Running in the background and / or once activated (e.g., by clicking on an icon or displayed widget), the web browser extension deploys a digital watermark detector and analyzes the digital content of the copied NFT. The digital watermark detector analyzes the digital image to locate and decode the multi-bit payload carried therein. In this example, the payload includes the hashed metadata of the original NFT: i) the NFT TokenID, ii) the blockchain identifier, and iii) the contract address. All of these elements correspond to the original NFT, but will not match all of the metadata in the copied NFT. (For example, the copied NFT may i) have the same TokenID and contract address but not the same blockchain ID, or ii) have the same contract address and blockchain ID but not the same tokenID, or iii) have the same tokenID and blockchainID but not the same contract address.)) The web browser extension scrapes or collects information from the web page hosting the copied NFT regarding the information and compares it against the decoded digital watermark payload. The web browser extension finds the copied NFT's NFT TokenID, blockchain identifier, and contract address. At least a portion of the original NFT's metadata is not identical to the copied NFT. Therefore, any cryptographic hash, bit-reduced representation hash, or other digital watermark payload comparison will fail. In FIG. 5P, the generated hash from the decoded digital watermark payload (decoded from the copied NFT but corresponding to the original NFT) and information about the copied NFT do not correspond in an expected manner (e.g., do not match, do not match within a tolerance, or are not related through a cryptographic relationship), indicating that the NFT is not authentic. A pop-up window generated by the web browser extension can display the NFT metadata and that the NFT is not authentic.

[0130] An alternative validation scenario involves finding no digital watermark within the digital content of the NFT. A pop-up window or other display can be generated to communicate that no digital watermark was found within the digital content. This does not mean that the NFT is a copy, only that the NFT minting did not include digital watermarking.

[0131] Instead of using a web browser extension for the NFT validation module, a smartphone running an NFT validation app can be used to retrieve the digital watermarking included with the NFT digital content. For example, the smartphone captures an image of the NFT digital content from a computer or smartphone display and then decodes the embedded digital watermark payload. The user can capture another image of the NFT text for comparison or manually enter or link to the NFT metadata. A digital watermark comparison can be performed as discussed above to determine authenticity.

[0132] Instead of using a browser extension, an NFT validation module, including the detection and validation features discussed above with reference to Figures 5K-5P, can be incorporated into a standalone application or service that queries a particular marketplace URI. For example, an NFT marketplace (e.g., OpenSea) may incorporate an NFT validation module into their platform, e.g., as a feature available to listed NFTs. In an alternative, a plug-in (e.g., a marketplace plug-in) is used instead of a browser extension. In yet another alternative, the detection and validation features are provided by a web page or web service that queries a particular marketplace URI.

[0133] Creators may wish to determine whether their NFT digital content has been copied. They can initiate a search on a monitoring platform that accesses blockchain nodes. Such nodes can then crawl for digital content and, upon encountering such, analyze the digital content for digital watermarking embedded therein. If the digital watermark payload is signed, the signature decoded from the digital watermarking can be compared against the signature of that particular creator to identify potential copies. Signature comparison (using the decoded signature and a generated signature from the NFT metadata) can identify unauthorized copies. Alternatively, technology such as Google Lens can be deployed to find copies. Similar digital watermark payload comparisons can be performed to test found copies. Alternatively, the validation module can notify the artist when a copied NFT is found. This notification can be “crowdsourced” by plugins, extensions, or application users browsing the NFT marketplace and authenticating NFTs and their associated digital content. conclusion

[0134] The techniques, modules, functionality, methods, processes, and systems described above may be implemented in hardware, software, or a combination of hardware and software. For example, the NFT authorization module and NFT validation module described above may be implemented as instructions (including both software and firmware instructions) stored in memory and executed in one or more processors, as digital logic circuitry in special-purpose digital circuitry, or as a combination of instructions executed in one or more multi-core processors, one or more parallel processors, and / or one or more digital logic circuit modules. For example, the NFT authorization module and NFT validation module described above may be implemented as instructions (including both software and firmware instructions) stored in memory and executed in one or more multi-core processors, as digital logic circuitry in special-purpose digital circuitry, or as a combination of instructions executed in one or more multi-core processors, one or more parallel processors, and / or one or more digital logic circuit modules. The techniques, modules, methods, services, functionality, and processes described above may be implemented in a program executed from a system's memory (a non-transitory computer-readable medium, such as an electronic, optical, or magnetic storage device). The methods, instructions, and circuitry operate on signals in electronic or other electromagnetic form. These signals further represent physical signals, such as image signals captured in an image sensor, audio captured in an audio sensor, and other physical signal types captured in sensors of that type. These electromagnetic signal representations are transformed into different states as detailed above to detect signal attributes, perform pattern recognition and matching, determine relative attributes of scans, etc.

[0135] Exemplary hardware and communication flows between electronic devices, networks, and cloud-based services (provided by a cloud-based computer) are further detailed in our PCT Application No. PCT / US22 / 50767, published as WO2023 / 096924 (which is incorporated herein by reference, including all drawings, and in particular Figures 14, 15, and 16 of that PCT Application), and we expressly contemplate using those described computing environments with the technology described in this patent document as if reproduced verbatim herein. For example, an NFT authorization module may be hosted on a cloud resource. Another example is hosting an author hash or list on a cloud resource. Another example is hosting a digital watermark embedder and / or a digital watermark detector on a cloud resource.

[0136] Although the principles of the present technology have been described and illustrated with reference to particular implementations, it should be recognized that the present technology can be implemented in many other different forms. In order to provide a comprehensive disclosure without unduly lengthening the specification, applicants incorporate by reference the above-referenced patents and patent applications in their entirety, including all drawings and any appendices.

[0137] The particular combinations of elements and features in the embodiments detailed above are exemplary only, and substitutions and permutations of these teachings with other teachings in this patent / application and those patents / applications incorporated by reference are also contemplated. Any headings used herein are for the convenience of the reader and are not intended to limit the disclosure. The inventors expressly contemplate combining subject matter under various headings.

Claims

1. 1. An image processing method, comprising: Obtaining digital content having a visual element; minting a non-fungible token ("NFT") associated with the digital content, wherein the minting results in a token identifier generated by a smart contract deployed on a distributed ledger technology ("DLT"), the smart contract having an associated smart contract address, and the DLT being associated with a DLT identification; generating a hash of the token identifier, the smart contract address, and the DLT identification, the hash comprising a bit-reduced representation of the token identifier, the smart contract address, and the DLT identification; embedding the hash as a digital watermark payload within the digital content using a digital watermark embedder, the embedding resulting in digitally watermarked digital content, whereby the digitally watermarked digital content comprises a link between the digital content and the NFT via the hash; An image processing method comprising:

2. The image processing method of claim 1 , further comprising adding the digitally watermarked digital content to a marketplace associated with the NFT.

3. The image processing method of claim 1 , wherein the digital watermark embedder comprises a reversible digital watermarking embedder.

4. The image processing method of claim 1 , wherein the digital watermark embedder embeds a synchronization signal within the digital content, the synchronization signal serving to determine scale and rotation for successful payload decoding.

5. 2. The image processing method of claim 1, further comprising generating a fingerprint representative of the visual element of the digital content, wherein said generating generates a hash of the fingerprint, the token identifier, the smart contract address, and the DLT identification.

6. 6. The image processing method of claim 5, further comprising, prior to said generating, generating a signature using a private key, the signature comprising a cryptographic relationship based on the private key of the fingerprint, the token identifier, the smart contract address, and the DLT identification, and said generating producing a hash of the signature, whereby the digitally watermarked digital content comprises a link between the digital content and the NFT via the cryptographic relationship.

7. 2. The image processing method of claim 1, further comprising, prior to said generating, generating a signature using a private key, said signature comprising a cryptographic relationship based on said private key of the token identifier, the smart contract address, and the DLT identification, and said generating producing a hash of said signature, whereby said digitally watermarked digital content comprises a link between the digital content and the NFT via said cryptographic relationship.

8. 1. A method of creating a cryptographic chain of ownership for a non-fungible token using digital watermarking, the method comprising: Obtaining digital content comprising a visual element, the digital content comprising a first digital watermark embedded therein, the first digital watermark comprising a first multi-bit payload carrying an author signature comprising a cryptographic relationship between a smart contract address and a target blockchain with a first private key, the digital content being associated with a non-fungible token ("NFT"); decoding the first multi-bit payload to obtain the creator signature; embedding a second digital watermark within the digital content, the second digital watermark comprising a second multi-bit payload carrying a first owner signature, the first owner signature comprising a hashed version of the creator signature using a second private key, the embedding of the second digital watermark being associated with a transfer of ownership of the digital content from the creator to the first owner; A method comprising:

9. 9. The method of claim 8, wherein the first digital watermark is embedded within the digital content using reversible digital watermarking, and wherein the decoding further comprises removing the first digital watermark from the digital content such that after the embedding, the digital content no longer comprises the first digital watermark.

10. 9. The method of claim 8, wherein said embedding layers the second digital watermark within the digital content such that after said embedding, the digital content comprises both the first digital watermark and the second digital watermark.

11. 9. The method of claim 8, further comprising: decoding the second digital watermark to obtain the first owner signature; and embedding a third digital watermark payload within the digital content, the third digital watermark comprising a third multi-bit payload carrying a second owner signature, the second owner signature comprising a hashed version of the first owner signature using a third private key, and the embedding of the third digital watermark is associated with a transfer of ownership of the digital content from the first owner to a second owner.

12. 12. The method of claim 11, wherein the second digital watermark is embedded within the digital content using reversible digital watermarking, and wherein decoding the second digital watermark further comprises removing the second digital watermark from the digital content such that after the embedding, the digital content no longer comprises either the first or second digital watermark.

13. 9. The method of claim 8, wherein said embedding layers the third digital watermark within the digital content such that after embedding the third digital watermark, the digital content comprises each of the first digital watermark, the second digital watermark, and the third digital watermark.

14. 9. The method of claim 8, wherein the creator signature comprises a cryptographic association between the smart contract address, a target blockchain, and a fingerprint of the visual element, all by the first private key.

15. 1. A method comprising: providing two different digital watermarks to facilitate associating information with a non-fungible token ("NFT"), wherein a first of the two different digital watermarks comprises a synchronization signal aligned at a first starting point relative to host digital content, the first starting point indicating a first NFT marketplace, the first of the two different digital watermarks does not carry a payload component, and a second of the two different digital watermarks comprises only a payload component and no synchronization signal, the payload component relying on the synchronization signal of the first of the two different digital watermarks for decoding, the payload component comprising NFT ownership information; using a digital watermark decoder to search the digital content and locate the first of the two different digital watermarks and the second of the two different digital watermarks, and making a decision according to the decoding results provided by the digital watermark decoder as follows: when only the first of the two different digital watermarks is found, determine the first NFT marketplace; and when both the first of the two different digital watermarks and the second of the two different digital watermarks are found, determine the current owner of the digital watermark from the NFT ownership information; A method comprising:

16. 16. The method of claim 15, wherein the synchronization signal can be aligned within the digital content at 16,000 different starting points.

17. 16. The method of claim 15, wherein the synchronization signal can be aligned within the digital content at 4,000 different starting points.

18. 16. The method of claim 15, wherein the synchronization signal can be aligned within the digital content at four different starting points.

19. 16. The method of claim 15, wherein the synchronization signal can be aligned within the digital content at between 4 and 16,000 different starting points.

20. 16. The method of claim 15, wherein the second of the two different digital watermarks is layered within the digital content so as to be aligned with the synchronization signal.

21. 1. An image processing method, comprising: Obtaining digital content having a visual element; minting a non-fungible token ("NFT") associated with the digital content, wherein the minting results in a token identifier corresponding to a smart contract, a hosting address for the NFT, and an identifier associated with a distributed ledger technology ("DLT"); generating data representing the token identifier, the hosting address, and the identifier; embedding the generated data within the digital content using a digital watermark embedder, wherein the embedding alters at least some portions of the visual elements, the embedding resulting in digitally watermarked digital content; and publishing the digitally watermarked digital content on the hosting address of the NFT; An image processing method comprising:

22. 22. The image processing method of claim 21, wherein the generated data comprises the token identifier, the hosting address, and a hash of the identifier, the hash comprising a bit-reduced representation of the token identifier, the hosting address, and the identifier.

23. 22. The image processing method of claim 21, wherein the generated data comprises the token identifier, the hosting address, and a clear text representation of the identifier.

24. Use one or more multi-core processors accessing data representing the digitally watermarked digital content from the hosting address; analyzing the data representing the digitally watermarked digital content using a digital watermark decoder and decoding the hash, wherein the analyzing results in a decoded hash; scraping information from data associated with the hosting address of the NFT, wherein the scraping results in a scraped token identifier, a scraped hosting address, and a scraped DLT identifier; generating a comparison hash based on the scraped token identifier, the scraped hosting address, and the scraped DLT identifier; comparing the decoded hash to the comparison hash to determine whether the NFT is authentic; 23. The image processing method of claim 22, further comprising:

25. Use one or more multi-core processors accessing data representing the digitally watermarked digital content from the hosting address; analyzing the data representing the digitally watermarked digital content using a digital watermark decoder and decoding the generated data, wherein the analyzing results in decoded generated data; scraping information from data associated with the hosting address of the NFT, wherein the scraping results in a scraped token identifier, a scraped hosting address, and a scraped DLT identifier; generating comparative scraping data based on the scraped token identifiers, the scraped hosting addresses, and the scraped DLT identifiers; comparing the decoded generated data with the comparative scraped data to determine whether the NFT is authentic; 22. The image processing method of claim 21, further comprising:

26. 22. The method of claim 21, wherein the hosting address of the NFT comprises a URL, and the data associated with the hosting address comprises data found from HTML code, an API, CSS code, or a JavaScript element associated with the URL.

27. 25. The method of claim 24, wherein the scraping includes searching within APIs, HTML code, JavaScript elements, and / or CSS code associated with the hosting address.

28. 25. The method of claim 24, wherein said analyzing invokes a remotely located digital watermark decoder.

Images