Safety Tags

Abstract

To provide systems and methods for decoding secure tags using an authentication server and a secure tag reader.SOLUTION: A system can include at least one processor and at least one non-transitory memory. The memory can contain instructions that, when executed by the at least one processor, cause the secure tag reader to perform operations. The operations can include detecting a potential secure tag in an image and generating a normalized secure tag image using the image and a style sheet. The operations can further include providing an identification request to an authentication server, the identification request including the normalized secure tag image. The operations can additionally include receiving rules for decoding tag data encoded into the secure tag as tag feature options and decoding the tag data using the received rules.SELECTED DRAWING: Figure 25A

Description

[Technical Field]

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 535,201, filed July 20, 2017, which is incorporated herein by reference in its entirety. [Background technology]

[0002] Authenticating things currently creates many problems for brands, merchants, and consumers. Existing inventory tracking approaches leave brands susceptible to counterfeiting and sales through unauthorized channels ("gray market"), suffer supply chain management issues, and deal with end-user related issues (e.g., tracking and verifying sales, managing product recalls, and performing after-sales service). Retailers and resellers deal with similar issues, such as identifying counterfeit products, accessing information about products, and managing customer relationships (e.g., returns, receipts, customer support, special offers or discounts, customer relationship management). Consumers may also face issues with existing systems, such as identifying counterfeit products, receiving accurate information about products, managing warranties, redeeming proof of purchase, product registration, and reselling products as genuine.

[0003] Traditional tags, such as barcodes and QR codes, have various weaknesses. For example, traditional tags are primarily used for identifying stock-keeping units (SKUs) and are typically read-only. Furthermore, the stored information is freely accessible to readers as stored binary encoded data. Information can only be written to traditional tags using a single method. Tags must be oriented in a specific direction to be read. Furthermore, traditional tags typically contain information of a fixed size. These tags can be easily reused and cloned. Traditional tags also pose security risks, as QR codes have been used in the past to transmit viruses / malware. Summary of the Invention [Problem to be solved by the invention]

[0004] The secure tags disclosed herein solve many of the problems faced by brands, merchants, and consumers surrounding the authentication of individual objects. These secure tags allow individual objects to be connected to a blockchain or similar database, enabling individual verification. Each product has a unique, never-repeated secure tag, allowing for individual item identification instead of SKU identification. Because each item can be verified using the secure tag, the individual item's identification allows for proof of authenticity. This form of unique identification is due in part to high-resolution smartphones with significant computing power and online connectivity, digital printing, and blockchain and secure database technology. [Means for solving the problem]

[0005] The unique safety tags disclosed herein offer significant advantages over existing QR codes and barcodes, the only similarity being that each has a binary-based ID layer. Unlike traditional tags, safety tags each contain a unique, unobtrusive key, have dynamic and flexible storage, and are integrated with digital ledgers, among many other advantages. For example, safety tags are not limited to one shape or form but can exist in multiple design states to meet customer needs. Furthermore, safety tags can exist across many form factors, including digital, printed, engraved, and animated. Another advantage of safety tags is that they are readable by a variety of optical devices, including smartphones, greatly expanding the number of users who can scan them.

[0006] Safety tags contain both binary and analog information and can be read in multiple ways. Their unique design allows for a large amount of binary information to be encoded on the tag, as well as a visual “fingerprint” that does not return data but can be used to authenticate the safety tag on the blockchain. Safety tags can have additional layers of authenticity by pairing and / or sequencing the safety tag with another safety tag or by using information in its vicinity (i.e., proximity fingerprinting). Different levels of access can be provided to different users throughout the supply chain. For example, customers can be given access to view specific information regarding authenticity, safety, and proof of warranty, while retailers can be given access to view specific information regarding product data, customer data, and product tracking. The ease of use and effectiveness of safety tags make them useful in countless cases and can reduce the challenge of authenticating things throughout the supply chain.

[0007] Disclosed embodiments include an authentication server for interacting with secure tags. The authentication server may comprise at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the authentication server to perform operations including: receiving a tag identification request including a tag image, identifying a secure tag in the received tag image using a stored hash of the image of the secure tag generated using a style sheet, generating tag data using the received tag image and decoding rules for decoding the tag generated using the style sheet, and providing the tag data in response to the tag identification request.

[0008] In some embodiments, identifying the secure tag using the stored hash and the received tag image may further include generating a hash of the received tag image and determining that a difference between the stored hash and the generated hash meets a threshold criterion. Generating a hash of the received tag image may further include converting the received tag image to an image having a predetermined number of pixels. The predetermined number of pixels may be equal to or greater than 64 pixels and equal to or less than 1,048,576 pixels. The stored hash may be used to identify the secure tag as a perceptual hash, and the difference between the stored hash and the generated hash is the Hamming distance. Furthermore, the received tag image may be a vector image file, and generating a hash of the received image may include rasterizing at least a portion of the vector graphics file.

[0009] In some embodiments, identifying a safety tag in the received tag image may include generating a hash of the received tag image, selecting a first safety tag using a difference between the generated hash and a stored hash of the image of the first safety tag, generating a second hash of a predetermined segment of the received tag image, and selecting a safety tag from the first safety tag using a difference between the generated second hash and the stored second hash of the predetermined portion of the image of the first safety tag. In other embodiments, identifying a safety tag in the received tag image may include generating hashes of progressively smaller segments of the received tag image.

[0010] In other embodiments, identifying the secure tag in the received tag image may include generating a hash of the received tag image, generating a second hash of a first segment of the received tag image corresponding to a first predetermined segment of the secure tag, determining that a difference between the generated hash and a stored hash of the image of the secure tag does not meet a threshold criterion, selecting the secure tag using the difference between the generated second hash and the stored second hash of the image of the first predetermined segment of the secure tag, generating a third hash corresponding to the second predetermined segment of the secure tag, and verifying the secure tag using the difference between the generated third hash and the stored third hash of the image of the second predetermined segment of the secure tag. In certain aspects, the third hash may be generated over the second segment of the received tag image corresponding to the second predetermined segment of the secure tag. In other aspects, the third hash may be generated over the second received tag image corresponding to the second predetermined segment of the secure tag.

[0011] In other embodiments, identifying a safety tag in a received tag image may include comparing a hash of an image of a predetermined segment of the safety tag with hashes of segments of one or more received tag images comprising the received tag image, where the segments of the one or more received tag images correspond to the predetermined segments of the safety tag, and selecting the safety tag based on the comparison. The comparison may include determining a segment distance between the hash of the image of the predetermined segment of the safety tag and the corresponding hash of the segments of the one or more received tag images, and at least one of an overall distance using the segment distances or a count of segment distances that meet a threshold criterion. The operations may further include determining a confidence value using the number of hashes of the image of the predetermined segment of the safety tag, the count of segment distances that meet the threshold criterion, and the segment distances. Furthermore, the one or more received tag images may include a first image showing at least some of the tags at a first level of detail and a second image showing at least some of the tags at a second level of detail greater than the first level of detail.

[0012] In some embodiments, the operations may further include receiving a stored hash of the image from the personal system; and providing a decode request to the personal system, the decode request including an identifier of the secure tag, and the decode rule may be received from the personal system in response to the decode request.

[0013] In some embodiments, the tag identification request may include an authentication key, the decoding request may include the authentication key, and the decoding rules may correspond to the authentication key. In other embodiments, the tag identification request may be received from a client device, and the operations may further include receiving public decoding rules for decoding a public portion of the tag generated using the stylesheet and providing the public decoding rules to the client device. In yet other embodiments, the decoding rules may enable decoding of a subset of the tag features defined by the stylesheet. In yet other embodiments, the decoding rules may enable decoding of a portion of the secure tag defined by the stylesheet.

[0014] In some embodiments, the decoding rules may include a first decoding rule that enables decoding of at least one of a first portion of the secure tag defined by the style sheet or a first subset of the tag features defined by the style sheet, and a second decoding rule that enables decoding of at least one of a second portion of the secure tag or a second subset of the tag features. Further, generating tag data using the received tag image and the decoding rules may include generating first tag data using the first decoding rule, and generating second tag data using the first tag data and the second decoding rule.

[0015] In some embodiments, the operations may further include tracking tag identification requests. In other embodiments, the operations may further include storing tag identification request information. In yet other embodiments, the operations may further include providing instructions to update the distributed database to reflect the tag data.

[0016] Disclosed embodiments include a system for generating secure tags that may comprise at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause an authentication server to perform operations including receiving a style sheet describing a class of secure tags, obtaining a numeric seed, generating a secure tag layout using the numeric seed and the style sheet, the secure tag layout specifying a combination of tag feature options based on the numeric seed and the style sheet, receiving tag data, generating a secure tag that encodes the tag data by selecting tag feature options according to a value of the tag data, generating a perceptual hash of the secure tag, storing the hash and an identifier of the secure tag in a database, and providing the secure tag.

[0017] In some embodiments, the secure tag layout may specify a reference portion that indicates one or more reference locations within the secure tag layout for encoding data. In other embodiments, the secure tag layout may specify an unreferenced portion within the secure tag layout for encoding data. In yet other embodiments, the secure tag layout may specify a junk portion of the secure tag layout for encoding random data. In yet other embodiments, the secure tag layout may specify a key portion of the secure tag layout for encoding an encryption key.

[0018] In some embodiments, tag feature options may include the presence or absence of a tag feature at a location specified by the secure tag layout. In other embodiments, tag feature options may include the size, color, or shape of a tag feature. In yet other embodiments, tag feature options may include deviations from a location specified by the secure tag layout. In yet other embodiments, tag feature options may include some tag feature present at a location specified by the secure tag layout.

[0019] In some embodiments, tag feature options may include the presence of a spline encoding on the tag feature. The spline encoding may include tag feature units that span various distances from a reference point or line. The various distances may encode one or more spatially multiplexed tag data values. Additionally, the various distances may encode repetitions of one or more spatially multiplexed tag data values.

[0020] In some embodiments, the tag feature options may include the presence of microstructures on the tag feature. In other embodiments, the tag feature may include a rim, and the tag feature options for the rim include rim breakage, rim deformation, and rim connection. In yet other embodiments, the tag feature may include rim breakage, and the tag feature options for the rim breakage include rim break edge shape. In yet other embodiments, the tag feature may include connections between tag features of a given type, and the tag feature options for the connection include connection width and connection asymmetry. In yet other embodiments, the tag feature may include connections between tag features, and the tag feature options for the connection include connection width and connection asymmetry.

[0021] In some embodiments, generating a secure tag that encodes tag data by selecting tag feature options may include selecting the first tag feature option according to a value of the first tag data, wherein selecting the first tag feature option creates a second tag feature option, and selecting the second tag feature option according to the value of the second tag data. Further, the first tag feature option may include the presence or absence of a point, the second tag feature option may include the presence or absence of a connection between the points according to the value of the first tag data, and the third tag feature option that encodes the third tag data may include the width of the connection according to the value of the second tag data. In other embodiments, generating a secure tag that encodes tag data by selecting tag feature options according to the value of the tag data may include encrypting the tag data with an encryption key, selecting a tag feature option according to the value of the encrypted tag data, and encoding the encryption key into the secure tag.

[0022] In some embodiments, the secure tag may include a vector graphics file. In other embodiments, providing the secure tag may include rasterizing the secure tag. In yet other embodiments, providing the secure tag may include labeling an object with the secure tag or incorporating the secure tag into a digital product. In yet other embodiments, the operations may further include checking the generated hash for collisions with hashes of other secure tags before providing the tag data. In yet other embodiments, the stylesheet may include a public portion that generates a portion of the secure tag layout for encoding public data and a private portion that generates a portion of the secure tag layout for encoding private data. In yet other embodiments, the operations may further include generating perceptual hashes of different segments of the secure tag at multiple levels of detail and storing the perceptual hashes of the different segments of the secure tag in a database.

[0023] In some embodiments, the tag data may include one or more identifiers related to one or more other security tags. A first identifier in the one or more identifiers may further include a perceptual hash of the first security tag in the one or more other security tags. In other embodiments, the tag data may include an identifier of a multi-factor identification item. The multi-factor identification item may further include authentication credentials or a perceptual hash of the image. In certain aspects, the image shows a portion of an object labeled with the tag. In other aspects, the image shows a person associated with the tag. In other embodiments, providing the tag may include printing the tag on a substrate, with at least a first portion of the tag printed with fluorescent ink.

[0024] Disclosed embodiments include a secure tag reading device. The secure tag reading device may include at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the secure tag reading device to perform operations including: detecting potential secure tags in an image; generating a normalized secure tag image using the image and a stylesheet; providing an identification request including the normalized secure tag image to an authentication server; receiving rules for decoding tag data encoded in the secure tag as tag feature options; and decoding the tag data using the received rules. In some embodiments, the image can be received from a scanner of the secure tag reading device. In other embodiments, the scanner can be a camera.

[0025] In some embodiments, detecting potential safety tags in the image may include determining that a size of the potential safety tag satisfies a size constraint retrieved from the stylesheet. In other embodiments, the potential safety tags may be detected using at least one of geometric feature detection, kernel-based feature detection, template matching, or a convolutional neural network. Detecting potential safety tags in the image using geometric feature detection may further include thresholding the image to generate a binary image, detecting geometric features in the binary image using target parameter values ​​retrieved from the stylesheet, and determining a reference point for the potential safety tag using the geometric features. Further, the geometric features may include concentric ellipses, and the reference point may include a focus of the concentric ellipses.

[0026] In some embodiments, generating a normalized image of the potential safety tag may include converting the image to a black-and-white or grayscale image. In other embodiments, generating a normalized image of the potential safety tag may include flattening the image using an image warp transform and target parameter values ​​retrieved from a style sheet. Flattening the image using the image warp transform may further include correcting at least one of fisheye distortion, barrel distortion, or angular distortion. Additionally, the target parameter values ​​may include inner or outer tag rim shape. In yet other embodiments, generating a normalized image of the potential safety tag may include detecting image gaps by determining tag feature options for potential image gaps and comparing the tag feature option values ​​to target parameter values. The target parameter values ​​may include inner or outer tag rim thickness-to-diameter ratios, or inner or outer tag rim thickness-to-tag rim break width ratios. In yet other embodiments, generating a normalized image of the potential safety tag may include determining tag feature orientations and rotating the image based on the determined tag feature orientations and target parameter values ​​retrieved from a style sheet. The tag feature may be a central logo and the target parameter value may include the orientation of the central logo.

[0027] In some embodiments, the normalized image of the potential safety tag may include a vector graphics image. In other embodiments, the image may include a plurality of potential safety tags, and the identification request may include a stream of vector graphics images corresponding to the plurality of potential safety tags. In yet other embodiments, the identification request includes a public key of the security tag reader, and at least a portion of the identification request is encrypted with a private key of the security tag reader. In yet other embodiments, generating the normalized security tag image using the image may include providing instructions to a user interface of the security tag reader to display the image and an indication highlighting the potential security tag, receiving instructions to generate a second zoomed-in image of the potential security tag, and generating the normalized image from the second zoomed-in image of the potential security tag.

[0028] In some embodiments, the operations may further include providing instructions to display, on a user interface of the secure tag reading device, the image and an indication highlighting the potential secure tag, receiving a selection of the potential secure tag, and providing a procedure for displaying the secure tag data on a user interface of the secure tag reading device. The indication highlighting the potential secure tag may be a bounding box surrounding the potential secure tag in the image.

[0029] In some embodiments, the publicly available portion of the stylesheet can provide rules for decoding public tag data encoded in the secure tag as tag feature options. The public tag data can further include at least one of an authentication server address, a product type, a brand name, an inventory number, or an error correction code.

[0030] Disclosed embodiments include a safety tag system that may include at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the safety tag system to perform operations including scanning safety tags that encode tag data as a selection of potential tag feature options, interacting with an authentication server to decode the safety tags, and receiving status information of the safety tags stored in a distributed database, the status information indicating a validity status of the tags.

[0031] In some embodiments, interacting with the authentication server to decode the secure tag may include providing an image of the secure tag to the authentication server. In other embodiments, interacting with the authentication server to decode the secure tag may include providing a perceptual hash of the secure tag to the authentication server. In yet other embodiments, interacting with the authentication server to decode the secure tag may include providing an authentication key to the authentication server. Status information can be received from the authentication server, the status information being dependent on the authentication key. In yet other embodiments, interacting with the authentication server to decode the secure tag may include receiving, from the authentication server, decoding instructions indicating tag feature options encoding tag data, and generating tag data using the decoding instructions, the tag data including a tag identifier. Furthermore, receiving status information for the secure tag from the distributed database further includes providing the authentication key to an oracle, the received status information being dependent on the authentication key. In certain aspects, the authentication key can correspond to a manufacturer, and the status information can include at least one of tracking information, sales information, customer data, usage information, activity information, or location information. In other aspects, the authentication key can correspond to a wholesaler, and the status information can include at least one of authenticity information, destination information, or manufacturer information. In other aspects, the authentication key can correspond to a retailer, and the status information can include at least one of authenticity information, transaction information, product information, or tracking information. In other aspects, the authentication key can correspond to a purchaser, and the status information can include at least one of authentication information, product information, or ownership information.

[0032] In some embodiments, the operations may further include providing updated state information of the secure tag for storage in a distributed database. The updated state information of the secure tag may further be provided to an oracle for writing to the distributed database along with an authentication key. Further, the updated state information of the secure tag may indicate that the secure tag is invalid. In other embodiments, the updated state information may include updated accessibility options for the state information. In yet other embodiments, the state information of the secure tag may indicate at least one of tracking information, sales information, customer data, usage information, activity information, location information, authenticity information, destination information, updated manufacturer information, transaction information, product data, or proof of ownership information. In yet other embodiments, the state information of the secure tag may indicate pairing between the secure tag and another secure tag.

[0033] Disclosed embodiments include a safety tag system that may include at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the safety tag system to perform operations including receiving a transaction request for a product associated with a first safety tag that encodes first tag data as a selection of a potential first safety tag feature option, generating a second safety tag for the product that encodes second tag identification data as a selection of a potential second safety tag feature option, the second tag data including an identifier of the first safety tag and an identifier of a purchaser, receiving an indication of transfer of ownership to the purchaser, and creating an entry for the second safety tag in a database, the created entry indicating the transfer of ownership.

[0034] In some embodiments, the product may include a digital product. The first security tag may be further embedded in or displayed with the digital product. In other embodiments, the product may include a physical product. The first security tag may further label the physical product.

[0035] In some embodiments, the operations may further include updating an entry for the first secure tag in the database. The entry may be further updated to indicate at least one of a transfer of ownership, an identifier of the second tag, transaction information related to the transfer of ownership, or a validity status of the first secure tag. In other embodiments, the identifier of the first secure tag may include a hash of at least some of the first tag data. In yet other embodiments, generating the second secure tag may include decoding the first secure tag to retrieve the first tag data. In yet other embodiments, the second secure tag may be generated using a stylesheet associated with the first secure tag. In yet other embodiments, the second secure tag may be generated using a unique numeric seed.

[0036] In some embodiments, the database may be a distributed database, and creating an entry for the second secure tag in the database includes providing an authentication key and an identifier of the second tag to an oracle for writing to the blockchain.

[0037] Disclosed embodiments include a server for interacting with a safety tag, the server may comprise at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the server to perform operations including: receiving a request for a first safety tag that encodes first tag data as a selection of potential first safety tag feature options, the first tag data including stored contextual information; decoding the stored contextual information; receiving the contextual information; authenticating the request using the received contextual information and the stored contextual information; and indicating successful authentication in response to the request.

[0038] In some embodiments, the stored contextual information may include at least one of authentication credentials, a biometric identifier, an audio file, a tag identifier, or a perceptual hash of the image. The biometric identifier may further include a fingerprint or a voiceprint. In certain aspects, the first security tag may label the item and the image may depict a portion of the item. Further, the labeled item may be an ID card and the portion of the item may be an ID photo on the identification card. In other aspects, the first security tag may label the item and the image may depict a person associated with the item or the texture of the item.

[0039] In some embodiments, authenticating the request may include determining that the received contextual information and the stored contextual information satisfy a similarity criterion. The sufficiency of the similarity criterion may further depend on a Hamming distance between the received contextual information and the stored contextual information. In other embodiments, the operation may further include requesting the contextual information, and the received contextual information may be received in response to the request.

[0040] In some embodiments, the indication of successful authentication may include at least some of the first tag data. In other embodiments, the indication of successful authentication may include decoding instructions for at least some of the first tag data. In yet other embodiments, the indication of successful authentication may include status information retrieved from a distributed database. In yet other embodiments, an oracle may be used to retrieve the status information from the distributed database.

[0041] Disclosed embodiments include a two-part label. The two-part label may comprise a substrate labeled with a first safety tag encoding first tag data as a selection of a potential first safety tag feature option; and an overlay removably adhered to the substrate, the overlay including a transparent portion and an opaque portion aligned with the first safety tag, the opaque portion aligned with the first safety tag encoding second tag data as a selection of a potential second safety tag feature option. In some embodiments, the potential first safety tag feature option may be different from the potential second safety tag feature option. In other embodiments, the aligned opaque portion may obscure the selected potential first safety tag feature option. In yet other embodiments, the aligned opaque portion may select the potential first safety tag feature option. In still other embodiments, the potential first safety tag feature option may include the presence or absence of a tag feature at a location specified by the first safety tag layout. Furthermore, the potential second safety tag feature option may include the presence or absence of a tag feature at a location specified in a second safety tag layout that is different from the first safety tag layout.

[0042] Disclosed embodiments include a method for generating a two-part label that may include generating a first safety tag using first tag data, a first numeric seed, and a first style sheet to encode the first tag data as a selection of potential first safety tag feature options, generating a second safety tag using second tag data, a second numeric seed, and a second style sheet to encode the second tag data as a selection of potential second safety tag feature options, determining a difference image between the first safety tag and the second safety tag, labeling a substrate with the first safety tag, and removably adhering an overlay to the substrate, over-labeled with the difference image and aligned with the first safety tag.

[0043] In some embodiments, the overlay may obscure portions of the first safety tag that are not present on the second safety tag. In other embodiments, the overlay may indicate portions of the second safety tag that are not present on the first safety tag. In yet other embodiments, the overlay may transmit portions of the second safety tag that are present on the first safety tag. In yet other embodiments, the substrate may include a consumer good. The first safety tag may correspond to a post-purchase state of the consumer good and the second safety tag may correspond to a pre-purchase state of the consumer good.

[0044] Disclosed embodiments include a method for providing a document. The method may include generating a first secure tag paired with the document, the first secure tag encoding an identifier of the document using a selection of latent tag feature options; receiving a request to access the document from a first device; providing the first secure tag to the first device; receiving a verification request from a second device including a secure tag image; comparing the first secure tag with the secure tag image; and providing the document to the first device based on the comparison. In certain aspects, the document identifier may include a hash of the document. Additionally, the second device may be a mobile device.

[0045] In some embodiments, comparing the first safety tag with the safety tag image may include generating a perceptual hash of the first safety tag, generating a perceptual hash of the safety tag image, and determining that a difference between the stored perceptual hash and the generated perceptual hash meets a threshold criterion. In other embodiments, comparing the first safety tag with the safety tag image may include generating a perceptual hash of the safety tag image, selecting the first safety tag using a difference between the generated perceptual hash and the stored perceptual hash of the image of the first safety tag, generating a second perceptual hash of a predetermined segment of the safety tag image, and selecting the first safety tag from the plurality of first safety tags using a difference between the generated second perceptual hash and the stored second perceptual hash of the predetermined portion of the image of the first safety tag.

[0046] In some embodiments, the confirmation request may include a confirmation request identifier, and providing the document to the first device based on the comparison may further include generating a second secure tag paired with the request, the second secure tag may include encoding the confirmation request identifier using a selection of latent tag feature options, and watermarking the document with the second secure tag.

[0047] In some embodiments, the method may further include determining that receipt of the security tag image satisfies an authentication criterion. In certain aspects, the authentication criterion may relate to a number of verification requests associated with the first security tag. In other aspects, the authentication criterion may relate to an amount of time elapsed since providing the first security tag to the first device. In yet other aspects, the authentication criterion may relate to a geographic origin of the verification request. In yet other aspects, the verification request may include a verification request identifier, and the authentication criterion may relate to the verification request identifier. Furthermore, the authentication criterion may be satisfied if the access identifier of the access request matches the verification identifier of the verification request.

[0048] Disclosed embodiments include a system for generating variable security tags. The system may include at least one processor and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the system to perform operations including: generating a first security tag that encodes tag data as a selection of tag feature options responsive to a value of the tag data; receiving a request from a scanner of a second device, the request including a sequence of tag images including the first tag image; authenticating the request using the first security tag and the first tag image; and providing an indication of authentication of the request. In certain aspects, the scanner may be a camera. In other aspects, the trigger may be a rollover event or a click event.

[0049] In some embodiments, the operations may further include providing instructions for displaying a sequence of tags including the first secure tag on a display of the first device. In certain aspects, providing instructions for displaying a sequence of tags including the first secure tag may include embedding the sequence of tags in a digital product. In other aspects, the instructions may provide for displaying the sequence of tags on a display of the first device in response to a trigger.

[0050] In some embodiments, authenticating the request may include comparing one or more perceptual hashes of the first secure tag to one or more corresponding hashes of the first tag image. In other embodiments, authenticating the request may include matching a plurality of secure tags, including the first secure tag, to a plurality of corresponding tag images, including the first tag image. Authentication may further require matching the plurality of secure tags to a plurality of corresponding tag images according to a predetermined order of appearance. In yet other embodiments, authenticating the sequence of tags may include junk tags.

[0051] In some embodiments, the indication of authenticity of the request may include at least some of the tag data. In other embodiments, the indication of authenticity of the request may include decoding instructions for decoding at least some of the first tag data. In yet other embodiments, the indication of authenticity of the request may include status information retrieved from a database. In yet other embodiments, the database may be a distributed database, and the status information is obtained from the distributed database using an oracle.

[0052] Disclosed embodiments include a method for tracking a product. The method for tracking a product includes labeling the product with a computer-readable, secure tracking tag that encodes product identification data as a selection of tag feature options based on a combination of a numeric seed and a style sheet. In some embodiments, the tag feature options may include the presence or absence of a tag feature at a location specified by the combination of the numeric seed and the style sheet. In other embodiments, the tag feature options may include the size, color, or shape of the tag feature. In yet other embodiments, the tag feature options may include deviations from the location specified by the combination of the numeric seed and the style sheet. In yet other embodiments, the tag feature options include several tag features present at the location specified by the combination of the numeric seed and the style sheet.

[0053] In some embodiments, the tag feature options include the presence of spline encoding on the tag feature. The spline encoding may further include tag feature edges extending at various distances from a reference point or line. Furthermore, the various distances may encode one or more spatially multiplexed tag data values, and the various distances may encode repetition of one or more spatially multiplexed tag data values. In other embodiments, the tag feature options may include the presence of microstructure on the tag feature. In still other embodiments, the tag feature may include a rim, and the rim tag feature options include rim breakage, rim deformation, and rim connection. In still other embodiments, the tag feature may include rim breakage, and the rim breakage tag feature options include rim break end shape. In still other embodiments, the tag feature may include connections between tag features of a predetermined type, and the connection tag feature options may include connection width and connection asymmetry. In still other embodiments, the tag feature may include connections between tag features, and the connection tag feature options may include connection width and connection asymmetry. In still other embodiments, the tag feature may include a central logo, and the tag feature options may include displacement of the central logo from the center point of the security tag.

[0054] In some embodiments, the method may further include generating a computer-readable secure tracking tag. In certain aspects, generating the computer-readable secure tracking tag may further include selecting a first tag feature option according to a first value of the product identification data, where selecting the first tag feature option creates a second tag feature option, and selecting the second tag feature option according to a second value of the product identification data. The first tag feature option may further include the presence or absence of points, and the second tag feature option may include the presence or absence of connections between the points according to the first value, and the width of the connections according to the second value, which may include a third tag feature option encoding a third value of the product identification data. In other aspects, generating the computer-readable secure tracking tag may include encrypting at least a portion of the product identification data with an encryption key, selecting the first tag feature option according to the value of the encrypted portion of the product identification data, and encoding the encryption key into the computer-readable secure tracking tag.

[0055] In some embodiments, the computer-readable secure tracking tag can include a vector graphics file, and labeling the product with the computer-readable secure tracking tag can include rasterizing the vector graphics file. In other embodiments, the method can further include providing an identification of the computer-readable secure tracking tag to an authentication server. The method can further include generating a hash of the computer-readable secure tracking tag and checking the hash for collisions with hashes of other computer-readable secure tracking tags before providing the identification information to the authentication server.

[0056] Disclosed embodiments include a label for tracking a product. The label for tracking a product may include a substrate having printed thereon a computer-readable secure tracking tag that encodes product identification data as a selection of tag feature options based on a combination of a numeric seed and a style sheet. In some embodiments, the tag feature options may include the presence or absence of a tag feature at a location specified by the combination of the numeric seed and the style sheet. In other embodiments, the tag feature options may include the size, color, or shape of the tag feature. In yet other embodiments, the tag feature options may include deviations from the location specified by the combination of the numeric seed and the style sheet. In yet other embodiments, the tag feature options may include several tag features present at a location specified by the combination of the numeric seed and the style sheet.

[0057] In some embodiments, the tag feature options may include the presence of a spline encoding on the tag feature. The spline encoding may further include tag feature edges extending at various distances from a reference point or line. Furthermore, varying distances may encode one or more spatially multiplexed tag data values, and varying distances may encode repetitions of one or more spatially multiplexed tag data values. In other embodiments, the tag feature options may include the presence of microstructures on the tag feature. In still other embodiments, the tag feature may include a rim, and the rim tag feature options may include rim breakage, rim deformation, and rim connection. In still other embodiments, the tag feature may include rim breakage, and the rim breakage tag feature options may include rim break end shape. In still other embodiments, the tag feature may include connections between tag features of a given type, and the connection tag feature options may include connection width and connection asymmetry. In still other embodiments, the tag feature may include connections between tag features, and the connection tag feature options may include connection width and connection asymmetry. In still other embodiments, the tag feature may include a central logo, and the tag feature options may include displacement of the central logo from the center point of the secure tag.

[0058] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.

[0059] The accompanying drawings are not necessarily to scale or exhaustive. Instead, emphasis is generally placed on illustrating the principles of the inventions described herein. These drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments consistent with the present disclosure and, together with the detailed description, serve to explain the principles of the disclosure. [Brief explanation of the drawings]

[0060] [Figure 1] 1 illustrates an exemplary system for interacting with a secure tag. [Figure 2] 1 shows an exemplary schematic diagram of an authentication server for interacting with secure tags. [Figure 3] 1 shows an exemplary schematic diagram of tag data. [Figure 4] 1 shows an exemplary diagram illustrating components of an exemplary computing device generally suitable for implementing the disclosed systems and methods. [Figure 5] 1 shows an exemplary schematic diagram of a database for storing tag information. [Figure 6] 1 shows a flowchart illustrating an exemplary process for tag generation. [Figure 7] 1 shows a flowchart illustrating an exemplary iterative encoding process. [Figure 8] 1 shows a flowchart illustrating an exemplary process for tag reading. [Figure 9] 1 shows a flowchart illustrating an exemplary process for tag identification. [Figure 10] 1 shows a flowchart illustrating an exemplary process for multi-resolution tag identification. [Figure 11] 10 shows a flowchart illustrating an example process for multi-resolution tag identification with modified tags. [Figure 12]1 shows a flowchart illustrating an exemplary data structure for performing multi-resolution tag identification. [Figure 13] 10 illustrates an exemplary user interface showing the results of tag identification. [Figure 14] 1 illustrates an exemplary process for decoding tag feature selection. [Figure 15] 1 illustrates an exemplary authentication process using contextual information. [Figure 16A] Shows pair and sequence safety tags. [Figure 16B] Shows a security tag paired with context information. [Figure 17] 1 illustrates an exemplary overlay tag. [Figure 18] 1 illustrates an exemplary process for multi-channel document authentication using secure tags. [Figure 19] 1 illustrates an exemplary secure tag sequence for authentication. [Figure 20] 1 illustrates an exemplary process for inventory management using a database. [Figure 21] 1 illustrates an exemplary process for modifying a tag. [Figure 22] 1 illustrates an exemplary process for inventory control using paired tags. [Figure 23] 1 illustrates an exemplary process for documenting a transfer of ownership. [Figure 24A] 1 illustrates an exemplary security tag. [Figure 24B] 1 shows a portion of a graphics file corresponding to an exemplary secure tag. [Figure 25A] Shows safe tags generated using the same stylesheet but different data. [Figure 25B] Shows safe tags generated using different style sheets but the same data. [Figure 26A] Indicates the secure tag feature options. [Figure 26B] Potential safety tag options are detailed below. [Figure 26C] Potential safety tag options are detailed below. [Figure 26D] Potential safety tag options are detailed below. [Figure 26E] Potential safety tag options are detailed below. [Figure 26F] Potential safety tag options are detailed below. [Figure 26G] Potential safety tag options are detailed below. [Figure 26H] Potential safety tag options are detailed below. [Figure 26I] Potential safety tag options are detailed below. [Figure 26J] Potential safety tag options are detailed below. [Figure 26K] Potential safety tag options are detailed below. [Figure 26L] Potential safety tag options are detailed below. [Figure 26M] Potential safety tag options are detailed below. [Figure 26N] Potential safety tag options are detailed below. [Figure 27A] 1 illustrates the generation of an exemplary secure tag. [Figure 27B] 1 illustrates the creation of an exemplary secure tag. [Figure 27C] 1 illustrates the creation of an exemplary secure tag. [Figure 27D] 1 illustrates the creation of an exemplary secure tag. [Figure 27E] 1 illustrates the generation of an exemplary secure tag. [Figure 27F] 1 illustrates the generation of an exemplary secure tag. [Figure 27G] 1 illustrates the generation of an exemplary secure tag. [Figure 27H] 1 illustrates the generation of an exemplary secure tag. [Figure 27I] 1 illustrates the generation of an exemplary secure tag. [Figure 27J] 1 illustrates the generation of an exemplary secure tag. [Figure 28A] 1 illustrates the creation of an exemplary secure tag. [Figure 28B] 1 illustrates the creation of an exemplary secure tag. [Figure 28C] 1 illustrates the creation of an exemplary secure tag. [Figure 28D] 1 illustrates the creation of an exemplary secure tag. [Figure 28E] 1 illustrates the creation of an exemplary secure tag. [Figure 28F] 1 illustrates the creation of an exemplary secure tag. [Figure 28G] 1 illustrates the creation of an exemplary secure tag. [Figure 28H] 1 illustrates the creation of an exemplary secure tag. [Figure 28I] 1 illustrates the creation of an exemplary secure tag. [Figure 28J] 1 illustrates the creation of an exemplary secure tag. [Figure 28K] 1 illustrates the creation of an exemplary secure tag. [Figure 28L] 1 illustrates the creation of an exemplary secure tag. [Figure 28M] 1 illustrates the creation of an exemplary secure tag. [Figure 28N] 1 illustrates the creation of an exemplary secure tag. [Figure 29A] 1 illustrates an exemplary user interface. [Figure 29B] 1 illustrates an exemplary user interface. DETAILED DESCRIPTION OF THE INVENTION

[0061] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the disclosed exemplary embodiments. However, those skilled in the art will understand that the principles of the exemplary embodiments may be practiced without all the specific details. Well-known methods, procedures, and components have not been described in detail so as not to obscure the principles of the exemplary embodiments. Unless explicitly stated, the exemplary methods and processes described herein are not constrained to a particular order or sequence, or to particular system configurations. In addition, several of the described embodiments or elements thereof may occur or be performed simultaneously, at the same time, or concurrently. Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. Unless explicitly stated, transmitting and receiving, as used herein, should be understood to have a broad meaning to include transmitting or receiving with or without a specific request. Thus, these terms cover both active and passive forms of transmitting and receiving.

[0062] FIG. 1 illustrates an exemplary system 100 for interacting with a secure tag. The exemplary system may include a secure tag 105, a client device 110, a verification server 115, a personal system 120, and a public database 125. The components of the system 100 may be configured to communicate using a network 130. In some embodiments, the secure tag's image, style sheet, and numeric seed may be used to decode the secure tag 105. To reduce the likelihood that an attacker able to compromise one of these systems will be able to decode the secure tag, this information may be distributed between the personal system 120 and the client device 110. For example, the personal system 120 may be configured to store the style sheet and numeric seed, and the client device 110 may be configured to retrieve the secure tag's image. In some embodiments, the authentication server 115 may be configured to perform the decryption, retrieve the secure tag's image from the client device 110, and decrypt the instructions from the personal system 120. In this manner, the system may distribute the information necessary to decrypt the secure tag 105 while ensuring that the decryption occurs on a secure system (the authentication server 115).

[0063] A security tag 105 can be a tag configured to label a product. The product can be a physical product (e.g., shoes) or a digital product (e.g., a website or video stream). As described herein, the product can be configured to encode tag data using a selection of tag feature options. The potential tag feature options for selection depend on the style sheet and numeric seed. In this way, a style sheet can define a class of similar security tags, but the use of different numeric seeds keeps each tag unique.

[0064] Client device 110 may comprise a mobile device that includes a scanner. For example, client device 110 may be a mobile phone, such as a smartphone, a tablet computer, or a portable computer. As a further example, client device 110 may be an optical scanner, such as a handheld optical scanner (e.g., a SIMATIC or MOTOROLA optical scanner). Client device 110 may be configured to generate images of secure tag 105 and provide those images to authentication server 115.

[0065] Authentication server 115 may include one or more computing systems, such as a server, a general-purpose computer, or a mainframe computer. Authentication server 115 may be standalone or may be part of a subsystem, which may be part of a larger system. For example, authentication server 115 may include distributed servers that are remotely located and communicate over a public network (e.g., network 130) or a dedicated private network. In some embodiments, authentication server 115 may be configured to communicate with components of system 100 over network 130. In some aspects, authentication server 115 may comprise one or more containers or virtual machines hosted in a cloud computing environment, such as Amazon Web Services.

[0066] The authentication server 115 may be configured to identify secure tags based on images received from the client device 110 and to decode instructions received from the personal system 120 or another system. The authentication server 115 may be configured to interact with the public database 130 to read and write status information about the identified tags. In some embodiments, the authentication server 115 may be configured to interact with the public database 130 indirectly via an oracle (e.g., when the public database 130 is the Ethereum blockchain). The authentication server 115 may be configured to provide the decoded tag information or specific decoding instructions to the client device 110 in response to an identification request.

[0067] Personal system 120 may include one or more computing systems, such as a server, a general-purpose computer, or a mainframe computer. Personal system 120 may be standalone or may be part of a subsystem, which may be part of a larger system. For example, personal system 120 may include distributed servers located remotely and communicating over a public network (e.g., network 130) or a dedicated private network. In some embodiments, personal system 120 may be configured to communicate with components of system 100 over network 130. In some aspects, personal system 120 may comprise one or more containers or virtual machines hosted in a cloud computing environment, such as Amazon Web Services.

[0068] The personal system 120 can be configured to generate secure tags for use by the system 100. In some embodiments, the personal system 120 can be configured to store style sheet information and numeric seeds for creating secure tags. Consistent with disclosed embodiments, the personal system 120 can be configured to respond to requests from the authentication server 115. The request can include a secure tag identifier. The personal system 120 can be configured to provide decoding instructions for a secure tag corresponding to the secure tag identifier. In some embodiments, the decoding instructions can include at least some style sheets and numeric seeds. The decoding instructions can include a specific correspondence between tag feature options and tag data for the secure tag.

[0069] Public database 125 may include one or more databases hosted by a computing device (e.g., a laptop, a desktop, a workstation, a server, a general-purpose computer, a mainframe computer, a cloud computing platform). Public database 125 may be a distributed database. For example, public database 125 may be a blockchain database. In some embodiments, public database 125 may be the Ethereum blockchain or a similar smart contract blockchain.

[0070] 2 shows an example schematic diagram of an authentication server for interacting with secure tags, consistent with disclosed embodiments. The authentication server 115 may be configured in some aspects to include an authentication database 205. The authentication database 205 may include records 220 in various aspects. In some embodiments, the records may associate one or more hashes of the secure tag with tag identification data. In various embodiments, in addition to the authentication database, the authentication server 115 may be configured to include general access rules. The general access rules may include application key requirements, authentication credential requirements, session token requirements, or similar restrictions on access to the authentication server.

[0071] FIG. 3 illustrates an example schematic diagram of tag identification data consistent with disclosed embodiments. In some embodiments, the tag identification data may include tag-specific access rules 305. For example, a particular secure tag may require a specific application key for decoding. As a further example, another secure tag may not require a specific application key for decoding. Some secure tags may include time-, geographic-, local-network-, or user-based access rules. The authentication server 115 may be configured to enforce these access rules by rejecting identification requests that do not satisfy the secure tag-specific access rules 305 for that secure tag. In some embodiments, the tag identification data may include a tag identifier 310. In some aspects, the tag identifier 310 may be unique to a particular secure tag. For example, the tag identifier 310 may be a hash of information encoded in the secure tag. As a further example, the tag identifier 310 may be a perceptual hash of the secure tag. In such embodiments, the authentication server 115 may be configured to simply store the tag identifier 310 rather than storing a hash associated with the tag identifier. In various embodiments, the tag identifier may store public data 315 and private data 320. Public data 315 may include metadata about interactions with secure tags, such as tracking or location data, that an operator of authentication server 115 wants to make publicly available. Private data 320 may include metadata about interactions with secure tags that an operator of authentication server 115 wants to restrict access to production or customer data collected by manufacturers, distributors, and retailers. While public data can be provided in response to an inquiry, authentication server 115 can restrict access to private data. For example, authentication server 115 can be configured to provide private data 320 in response to an identification request that includes an appropriate application key or authentication certificate. The amount and type of private data 320 provided will depend on the application key or authentication credentials received.In some embodiments, authentication server 115 can be configured to store links to at least one of tag-specific access rules 305, tag identifiers 310, public data 315, or private data 320. For example, at least some of this information can be stored in public database 130 or a separate database. Whether the links or the actual tag-specific access rules 305, tag identifiers 310, public data 315, or private data 320 are stored in authentication server 115 depends on performance and security considerations.

[0072] 4 shows an exemplary diagram illustrating components of an exemplary computing device generally suitable for implementing the disclosed systems and methods. According to some embodiments, the exemplary device may include a processor 410, a memory 415, an I / O interface 420, and a network adapter 425. These units may communicate with each other via a bus 405 or wirelessly. The components shown in FIG. 4 may reside in a single device or in multiple devices.

[0073] Processor 410 may be one or more microprocessors, central processing units, or graphics processing units that perform various methods in accordance with the disclosed embodiments. Memory 415 may include one or more computer hard disks, random access memory, removable storage, or remote computer storage. In various embodiments, memory 415 stores various software programs executed by processor 410. I / O interface 420 may include a keyboard, mouse, audio input device, touch screen, or similar human interface device. Network adapter 425 enables the exemplary device to exchange information with the components of FIG. 1 over network 130. In various embodiments, network adapter 425 may be configured to support wireless or wired networks. In certain aspects, network adapter 425 may comprise modules for supporting one or more local area networks, personal area networks, or short-range networks. In some aspects, network adapter 425 may comprise a hub for supporting a computer bus. For example, network adapter 425 may comprise one or more USB hubs.

[0074] FIG. 5 shows an exemplary schematic diagram of a database for storing tag information. In some embodiments, the public database may include individual accounts 515 and bundle accounts 520. Consistent with disclosed embodiments, high-value items may store status information in individual accounts (e.g., homes, jewelry, cars, etc.), while multiple low-value items may store status information in a single bundle account (e.g., shoes, clothing, personal electronics, digital products such as movies, etc.). In some aspects, each transaction involving a secure tag for a high-value item may be written to the public database 130, and a group of transactions involving low-value items may be stored in a personal database and periodically written to the corresponding bundle account 520. In some embodiments, if the public database 130 is a distributed database, the requester 501 (e.g., the authentication server 115) must interact with an oracle 510 to read and write information to the public database. In various aspects, the requester and oracle may be combined into a single program (e.g., the authentication server 115 may function as both the requester 501 and the oracle 510). In some embodiments, users of system 100 can read information directly from public database 130 without having to contact authentication server 115. For example, system 100 may include a portal for reading information about secure tags contained in public database 130.

[0075] 6 shows a flowchart illustrating an example process 600 for secure tag generation consistent with disclosed embodiments. While described below as being performed by the personal system 120, the process 600 may be performed by the authentication server 115 or another system in some embodiments. The process 600 may include generating a secure tag, generating a secure tag layout, generating a secure tag using the secure tag layout and tag data, registering the secure tag with the authentication server 115, and receiving the numeric seed and style sheet necessary to provide the tag with the appropriate form for tracking the product. In this manner, a unique identifier for the product can be generated that encodes the tag data as a selection of tag feature options.

[0076] After starting, process 600 may proceed to step 601. In step 601, the persona system 120 may receive a style sheet. The style sheet may describe a class of security tags. In some embodiments, the class of security tags is similar in appearance, purpose, or use. For example, the style sheet may describe a class of security tags that a particular manufacturer (e.g., a shoe manufacturer) uses to label a particular product (e.g., a shoe model). In some embodiments, the manufacturer may use the same style sheet to generate security tags for instances of the same product. This allows the manufacturer to achieve visual uniformity among the security tags used to label their products and ensure that each individual tag is unique.

[0077] The style sheet can define tag data locations, tag features, and tag feature options available for this class of security tag. In some aspects, spatial options (e.g., tag feature size, tag feature location within the security tag, etc.) can be defined by normalized values ​​such as ratios or angles. As a non-limiting example, the style sheet can be configured to define a first diameter option for a point as 10% of the distance from the center of the security tag to the outer edge of the security tag, while a second diameter option for the point would be 15% of the distance from the center of the security tag to the outer edge of the security tag. As a second non-limiting example, the style sheet can be configured to define potential tag feature locations according to a radial coordinate frame with the tag center as the origin. A potential location for a particular tag feature is 5 degrees clockwise from the orientation line and 50% of the distance from the center point to the edge of the tag. As another example, a break in the edge of a tag could be twice the width of the tag. The width of the tag rim can be defined as a fraction of the distance from the center point to the edge of the tag. In this way, stylesheets can be used to define a set of constraints on tag characteristics that can be used to authenticate a tag, regardless of whether the tag can be decoded.

[0078] Consistent with disclosed embodiments, a style sheet can describe potential mappings of data to tag feature options. For example, a style sheet can describe the correspondence between a particular tag feature option and a particular bit in a binary number. In some aspects, a style sheet can describe the correspondence between a particular value of a tag feature option and a particular value of a bit in a binary number. For example, if a tag feature option has a particular value (or a particular range of values, or a value selected from a particular set of potential values), the value of the corresponding bit in the binary number is 1. If a tag feature option has a different particular value (or a different particular range of values, or a value selected from a different particular set of potential values), the value of the corresponding bit in the binary number is 0. In various aspects, a style sheet can describe alternative options for a secure tag layout and the correspondence between tag feature options and tag data values. In some aspects, a style sheet can describe the possibility of a tag feature being present or absent in a particular location. For example, a style sheet can identify locations within a secure tag where a dot may be present or locations within a secure tag rim where a break may be present. These options are mutually exclusive. For example, in a first option, a specific portion of the safety tag can be reserved for tag data, while in a second option, a specific portion of the safety tag can be reserved for a reference to another portion of the safety tag, and according to a third option, a specific portion of the safety tag can be filled with random tag features to prevent unauthorized tag decoding.

[0079] In some embodiments, a stylesheet can be configured with data and / or instructions for selecting from multiple secure tag layout options (e.g., layout options, tag data to tag feature option correspondences, presence or absence of tag features at particular locations, etc.). This selection process can depend on a randomly generated numeric value. For example, the stylesheet can be configured to select a first use of a particular secure tag location (e.g., storing data) and a second use of a particular secure tag location (e.g., storing junk values) depending on the value of a randomly generated numeric value. The stylesheet can be configured to use a vector of such randomly generated numeric values ​​for a particular secure tag layout (e.g., a particular layout option, tag data to optional feature correspondences, presence or absence of tag features at particular locations, etc.). The stylesheet can also be configured with a vector of parameters. For example, the stylesheet can be configured to select a first correspondence between tag data and tag feature options if the value of the randomly generated numeric value exceeds the value of a parameter α, and select a second correspondence between tag data and tag feature options otherwise. To continue this example, a stylesheet can be configured to select a first location in a secure tag for encoding tag data when another randomly generated number exceeds the value of parameter β, and to select a second location in a secure tag for encoding tag data other than the specified value. In this example, α and β are stylesheet parameters. These parameters may take default values, values ​​received from the user, or values ​​obtained from another system or configuration file.

[0080] In some embodiments, stylesheets can be configured to include parameters for how the tag will look, minimum, maximum, and tolerance values ​​for preset, variable, or randomly generated features. Stylesheets can be configured to generate different safety tag layouts depending on the intended use of the safety tag (e.g., the intended size of the safety tag, the printed safety tag since small tags may be difficult to read using a cell phone camera, the intended color and surface finish of the safety tag). In some embodiments, the person system 120 can be configured to provide configuration tools that allow for the generation, export, and storage of stylesheets.

[0081] The personal system 120 can be configured to generate random numbers for use by the stylesheet in creating the secure tag layout. The random numbers can be generated using a pseudo-random number generator. In some aspects, the stylesheet can specify the pseudo-random number generator (e.g., a reference to a function library or web service, encoding the pseudo-random number generator into the stylesheet, etc.). In various aspects, the personal system 120 can specify the pseudo-random number generator.

[0082] In some embodiments, the pseudo-random number generator can be configured to generate a sequence of random numbers that depends on an initial seed. Given the same seed, the pseudo-random number generator can be configured to generate the same sequence of pseudo-random numbers. Thus, the secure tag layout generated by a stylesheet can depend on any parameters of the stylesheet and the seed, consistent with disclosed embodiments.

[0083] In various embodiments, a pseudo-random number represented as a binary number can provide a range of choices depending on its bits. For example, a binary number of 00110110 can select the "false" option for the first two options provided by the style sheet and the "true" option for the third option provided by the style sheet. Multiple bits can be used to select an option with more than two choices. For example, two bits can be used to select an option with four possible values.

[0084] In some embodiments, the style sheet may include a public portion. In some aspects, the system 100 may be configured to provision the public portion of the style sheet to client devices. In various aspects, the public portion of the style sheet is available at a known location (e.g., a known URL). The public portion of the style sheet may include at least some of the ratios that constrain the relationship of tag features. For example, the public portion may include the ratio between the width of the outer tag rim and the diameter (or major or minor axis, etc.) of the tag. This ratio can be used to determine whether the tag is authentic in some aspect without further processing. The public portion may also indicate the location of public tag data and how to decode that tag data. As a non-limiting example, the public portion of the style sheet may include a spline along the outer edge of the outer rim running from the 12 o'clock position to the 6 o'clock position that indicates the SKU, the URL of the authentication server, or a known value to use in determining whether the tag's image was processed correctly. Because the style sheet describes a class of tag, this public portion may describe information accessible to all secure tags belonging to this tag class.

[0085] In some embodiments, the stylesheet may include a private portion that may describe ratios that can be used to encode private tag data, secure tag layout information, the mapping of tag data to tag feature options, etc. In some aspects, the private portion of the stylesheet may be stored by the persona system 120.

[0086] After starting, process 600 may proceed to step 603. In step 603, the personal system 120 may obtain a numeric seed. The personal system 120 may be configured to generate the numeric seed using a random number generator. The personal system 120 may be configured to receive the numeric seed from a user of the system 100, a configuration file, or another system.

[0087] After steps 601 and 603, process 600 may proceed to step 605. In step 605, the person system 120 may generate a secure tag layout using the numeric seed and the style sheet. As discussed above, the style sheet may include multiple ways of encoding data as tag feature options. The selection of a particular way of encoding data as tag feature options (e.g., a secure tag layout) depends on the numeric seed.

[0088] In some embodiments, a random number generator (e.g., a Gibson Research Corporation Ultra-High Entropy Pseudo-Random Number Generator, etc.) can use a numeric seed to generate one or more pseudo-random numbers. These pseudo-random numbers can be used to select how to encode data as tag feature options. For example, if there are 32 binary options, two 16-bit binary bit values ​​can be used to select from the 32 binary options to generate a secure tag layout. As a further example, the 32 binary options can be selected based on comparing a randomly generated number to a threshold parameter. For example, the individual system 120 can be configured to select the first option if the value of the randomly generated number is greater than 0.95, and select the second option otherwise. As a further option, the random number generator can be used in combination with a card shuffling algorithm to generate a series of binary data (e.g., the presence or absence of a series of 20 tag features). As a non-limiting example, the personal system 120 may determine the number of tag features required, determine the number of potential locations for these tag features, create an array of size equal to the number of potential locations, and configure it to fill the required number of combinations of elements in the array with values ​​indicating the presence of the tag features. The array may then be shuffled to create a random sequence (e.g., using a Fisher-Yates shuffle algorithm, etc.). In this manner, a secure tag layout may specify a combination of tag feature options based on a numeric seed and style sheet selection.

[0089] In some embodiments, the secure tag layout may specify at least one of a reference tag portion, a reference portion, an unreferenced tag portion, a key portion, or a junk portion. These portions may include one or more locations in the secure tag that contain tag data. For example, a reference tag portion may include one or more locations in the secure tag that are identified by tag data stored elsewhere on the tag. A corresponding reference portion of the secure tag may store tag data necessary to locate the reference portion of the secure tag. Thus, decoding the reference portion of the secure tag may enable decoding of the corresponding reference portion of the secure tag. In some embodiments, additional information may be required to decode the reference portion of the tag. For example, data stored in the reference portion may enable locating the reference portion, but additional decoding instructions or a cryptographic key may be required to decode the tag data in the reference portion. As a further example, the unreferenced portion may include one or more locations in the secure tag that are not referenced by tag data stored elsewhere on the tag. Without instructions (such as an associated portion of a style sheet), such unreferenced portions may not be identifiable and may be much less easily decoded. As a further example, the key portion may include one or more locations in the secure tag where key material is stored. In some aspects, such key material can be used to decode tag data encoded in other portions of the secure tag. In various aspects, such key material can be used to request instructions for decoding other portions of the tag (e.g., such key material can include an application key, etc.). Key portions can be referenced or unreferenced portions, as described above. In some embodiments, a secure tag can include junk portions that store no data or random data lacking semantic meaning. Such junk portions prevent an attacker from simply assuming that all tag features have some associated meaning, making fraudulent attempts to decode the tag more difficult.

[0090] In some embodiments, a tag portion can describe a spatial region of the secure tag. For example, a physical quadrant of the secure tag. In various embodiments, a tag portion can describe a logical portion of the secure tag. For example, the secure tag is a vector graphics file and the tag portion is a logical division within that vector graphics file. For example, a tag portion can include an element that includes SVG tags that describe potential locations of dots in the secure tag in a particular order. The order of tags within the element can describe a mapping from a number of bits to the presence or absence of dots in the secure image, without reference to the actual location of the dots in the secure tag.

[0091] Consistent with disclosed embodiments, a security tag layout may include multiple different types of tag feature options. Tag feature options include the presence or absence of tag features at locations specified in the security tag layout. For example, a security tag layout may indicate that a dot can be placed at a particular location within the security tag. The presence of a dot at that location indicates that a corresponding bit in the tag data is set.

[0092] Tag feature options can include the size, color, or shape of the tag feature. For example, a secure tag layout may have large dots (or dots of a first color, or distorted tag features, etc.) corresponding to set bits and small dots (or dots of a second color, or distorted tag features, etc.) corresponding to null bits.

[0093] Tag feature options can include deviations from the location specified in the secure tag layout. For example, a secure layout can specify the relative location of tag features within a secure tag. Deviations from the specified location can encode one or more bit values ​​depending on the direction and magnitude of the deviation (e.g., one or more bits for deviation in the X direction and one or more bits for deviation in the Y direction).

[0094] Tag feature options can include multiple tag features present at specified locations in the secure tag layout. For example, multiple dots at a specified location can encode a bit. As a further example, the encoding can be a direct correspondence (e.g., the value of the bit contains the number of dots) or some indirect correspondence (e.g., the bit is set if 0-2 dots are present, and so on if 3 or more dots are present).

[0095] Tag feature options can include the presence of microstructures on the tag features. Such microstructures can include microprinted barcodes, QR codes, text, or other features. In some embodiments, the microstructures can be printed such that a scanner at a first distance from the security tag (e.g., greater than a distance between 5-20 cm) cannot resolve the microstructures, and a scanner at a second distance from the security tag (e.g., less than a distance between 1-10 cm) can resolve the microstructures.

[0096] Tag feature options can include the presence of spline encoding in the tag feature. In some embodiments, the spline encoding can include extension or variation of the tag feature edge. This extension or variation can extend various distances from a reference point or line. For example, the edge of an otherwise rounded dot can extend various amounts from the center of the dot or from the circumference of the dot, as specified in the tag layout. This variable distance can encode another spatially multiplexed tag data value.

[0097] For example, a fundamental spatial frequency can be multiplexed with the binary representation of a first tag value. Thus, the fundamental spatial frequency can contribute edge extensions or changes at locations corresponding to set bits of the first tag value but not at locations corresponding to null bits of the first tag value. Additional fundamental spatial frequencies can be multiplexed with the binary representation of additional tag values. These fundamental spatial frequencies differ by at least a factor of four (e.g., a first fundamental spatial frequency has a period of 2^12 micrometers, a second spatial frequency has a period of 2^10 micrometers, a third spatial frequency has a period of 2^8 micrometers, etc.). The secure tag layout can be configured to further specify an origin and number of repetitions for decoding the spline. Thus, repetitions of one or more spatially multiplexed tag data values ​​can be encoded as distances vary.

[0098] Tag features can include the rim of the safety tag, such as the inner rim or outer rim. Tag feature options for rim can include rim break, rim deformation, and rim connection. If the rim has rim break as an option, tag feature options for rim break can include rim break end shape.

[0099] Tag features can include connections between tag features of a given type. For example, such connections can include connections between dots and connections between dots and rims (e.g., connections between dots and inner or outer rims). Tag feature options for connections can include connection width and connection asymmetry.

[0100] Tag features can include a central logo. The central logo can be used to identify a general class of tag, for example, to allow a user to identify a public portion of a stylesheet that can be used to decode public data in the tag. Central logo tag feature options can include a displacement of the central logo from the center point of the secure tag. For example, a hash of the secure tag or a public key associated with the secure tag can be encoded by displacing the central logo from the center point of the secure tag.

[0101] After starting, process 600 may proceed to step 606. In step 606, the personal system 120 may be configured to receive tag data. The tag data may be received via a user interface from a user, an input file, memory in the personal system 120, another system, etc. The tag data may include data and / or instructions. The data and / or instructions may be represented by one or more numbers. The tag data may include an identifier for a multi-factor identification item. When an attempt is made to read the tag or perform an action using the tag, the tag may be decoded and the identifier may be compared with other data to determine whether the read or action is authenticated or authorized. For example, the multi-factor identification item may include authentication credentials (e.g., a password, API key, token, hash of a password, API key, or token). As an additional example, the multi-factor identification item may include contextual information, such as an image, a perceptual hash of the image, a voiceprint, or a hash of the voice. For example, the image may represent a portion of a product labeled with the tag. By including a perceptual hash of an image of a portion of a product labeled with the tag, the personal system 120 can be configured to prevent the tag from being moved to another product or multiple products from being labeled with copies of the security tag. As an additional example, the image can depict a person associated with the security tag. As a non-limiting example, the person can become the owner of the labeled product. In this way, the security tag can be used to verify ownership.

[0102] As a further example, the tag data may include one or more identifiers of one or more other secure tags. For example, a first identifier of the one or more identifiers may include a perceptual hash of a first of the one or more other secure tags. In this manner, the additional tags may be paired with the current tag. In some embodiments, the authentication server may be configured to require provision of images of these additional tags or perceptual hashes of these additional tags in order to authenticate or authorize requests related to the current tag.

[0103] After step 606, process 600 may proceed to step 607. At step 607, the personnel system 120 may generate a secure tag that encodes the tag data. In some aspects, the personnel system 120 may be configured to generate a secure tag that encodes the tag data by selecting tag feature options according to the value of the tag data. For example, if the secure tag layout provides tag feature options including multiple potential locations of dots or rim breaks, and the tag data includes a binary number, the dot or rim break may be present or null depending on whether the corresponding bit of the binary number is present or null. In some embodiments, at least a portion of the tag data may be encrypted using an encryption key. The secure tag may be generated by selecting tag feature options according to the value of the encrypted tag data. In some embodiments, an encryption key for decrypting the encrypted tag data may also be encoded in the secure tag (e.g., in the reference or non-reference key portion of the secure tag). In some embodiments, the secure tag may be a vector graphics file, such as a scalable vector graphics file, an encapsulated PostScript file, a portable document format file, or the like.

[0104] After step 607, process 600 may proceed to step 609. In step 609, the personal system 120 may generate a perceptual hash (e.g., a pHash) of the security tag. Generating the perceptual hash includes rasterizing the security tag. For example, if the security tag is stored as a vector graphics file, generating the perceptual hash includes converting the perceptual hash to a raster graphics file format. In some embodiments, the personal system 120 may be configured to check for hash collisions by comparing the generated pHash to a library of pHashes of existing security tags. If a hash collision exists, the personal system 120 may be configured to recreate the security tag using a new numeric seed. In various embodiments, the personal system 120 may be configured to generate additional perceptual hashes of different segments of the security tag at multiple levels of detail.

[0105] After step 609, process 600 may proceed to step 611. In step 611, the personal system 120 may store the perceptual hash of the secure tag in a database (e.g., a database of the authentication server 115). In some aspects, if the personal system 120 is configured to generate additional hashes of different segments of the secure tag, these additional hashes may be stored in the database along with the perceptual hash of the entire secure tag. The personal system 120 may be configured to store an identifier of the secure hash in the database along with the hash of the secure tag. This identifier may be configured to enable the personal system 120 to determine which style sheet and numeric seed were used to generate the secure tag. For example, the personal system 120 may be configured to maintain a database for tracking secure tags. This database may include secure tag identifiers as key values, an indication of the style sheet used to generate each secure tag, and the numeric seed used to generate each secure tag. In some embodiments, this database does not contain the tag data used to generate the secure tags or images of the secure tags. Thus, an attacker who is able to compromise this secure database cannot recreate the tag data from the store identifier, style sheet reference, and numeric seed.

[0106] After step 611, process 600 may proceed to step 612. In step 612, the personal system 120 may be configured to provide a security tag. In some embodiments, providing the security tag may include labeling an object with the tag or incorporating the security tag into a digital product, such as a video file or a web page. For example, providing the security tag may include providing instructions for displaying the security tag on a computer screen, etc. In various embodiments, providing the tag may include printing the tag on a substrate. For example, providing the security tag may include providing the security tag as a vector file or a raster file to a printing system that labels the product with the security tag. Thus, providing the security tag includes rasterizing the security tag. In some embodiments, the tag may be provided with multiple types of ink. For example, at least a first portion of the tag may be printed with fluorescent ink. This fluorescent ink may be visible only under certain lighting conditions, creating additional options for encoding tag data.

[0107] In some embodiments, authentication server 115 may be configured to retrieve tag status information from a database (e.g., database 130). For example, authentication server 115 may be configured to determine whether a secure tag is still valid, has been canceled, or includes authentication requirements for actions involving the secure tag (e.g., requiring a user to provide an application key or authentication credentials in order to perform a transaction involving the secure tag).

[0108] 7 shows a flowchart illustrating an exemplary iterative encoding process 700 consistent with disclosed embodiments. While described below as being performed by the persona system 120, the process 700 may be performed by the authentication server 115 or another system in some embodiments. The process 700 may include receiving a secure tag layout, determining available tag features based on a current tag state, selecting tag feature options using tag data values, and updating the available tag feature options based on the selected tag feature options. In this manner, items of tag data may be iteratively encoded into a secure tag, with each iteration creating tag feature options to be used to encode the next item of tag data.

[0109] After starting, process 700 may proceed to step 701. In step 701, the personal system 120 may receive a safety tag layout. The safety tag layout may be received from a previous step in the process of generating a safety tag (e.g., step 605 of process 600), from memory in the personal system 120, from another component of the system 100, or from another system. The safety tag layout may include a set of potential tag feature options.

[0110] After step 701, process 700 may proceed to step 703. In step 703, the person system 120 may determine available tag features based on the current tag state. For example, a security tag layout may specify that tag features can include dots and connections between dots. The security tag layout may specify an order of potential dot locations, where the position of the potential dot locations within the order corresponds to a bit position in the binary tag data. The security tag layout may specify that the presence of a dot corresponds to a bit value of 1 and the absence of a dot corresponds to a bit value of 0. In this example, the current tag state may include these potential dot locations. The current tag state may also include additional available tag features, such as potential rim breakage or distortion.

[0111] After step 703, process 700 may proceed to step 705. In step 705, the person system 120 may use the tag data value to select a tag feature option from the available tag feature options. To continue with the previous example, the person system 120 may read a bit from the binary tag data and place a dot at the corresponding potential dot location when the bit has a value of 1 (whereas the bit has a value of 0). While described with respect to dots, such a process may be applied to other tag features as well.

[0112] After step 705, process 700 may proceed to step 707. In step 707, the persona system 120 may update the available tag feature options based on the selected tag feature option. Continuing with the previous example, potential dot locations may no longer constitute selectable tag feature options, but dot size, dot color, whether there is a connection between dots, and whether there is a connection between the dot and the rim may still be available. A style sheet may provide rules governing the correspondence between these tag feature options and tag data items. For example, a style sheet may provide rules that associate connections between dots with particular bits of binary tag data.

[0113] The personal system 120 can be configured to continue selecting tag feature options and update the set of available tag feature options until the tag data is completely encoded. For example, the personal system 120 can select a first tag feature option according to the value of the first tag data. The selection of this first tag feature option can create a second tag feature option. The personal system 120 can then select a second tag feature option according to the value of the second tag data. The selection of this second tag feature option can create a third tag feature option. In a non-limiting example, the first tag feature option can include the presence or absence of points, the second tag feature option can include the presence or absence of connections between points according to the value of the first tag data, and the third tag feature option for encoding the third tag data can include the width of connections that exist according to the value of the second tag data.

[0114] 8 shows a flowchart illustrating an example process 800 for tag reading. Process 800 includes steps of tag detection, tag identification and server-side decoding, and optional client-side decoding. In some embodiments, tag detection may be performed by client device 110 using an image received from a scanner of client device 110 (e.g., a mobile device camera or a handheld optical scanner). In various embodiments, tag detection may be performed by client device 110 using an image received from another device. In various embodiments, tag identification and server-side decoding may be performed by authentication server 115, personal system 120, or another system. In various embodiments, optional client-side decoding may be performed by client device 110.

[0115] After starting, process 800 may proceed to step 801. In step 801, client device 110 may receive a raster image including at least a portion of secure tag 105. In some embodiments, tag detection 801 may include converting the raster image to a normalized vector graphic image and providing the vector graphic image to authentication server 115. In various embodiments, tag detection 801 may include converting the raster image to a normalized raster image and providing the normalized raster image to authentication server 115.

[0116] Tag detection 801 may include detecting the security tag 105 in the received image using at least one of geometric feature detection, kernel-based feature detection, template matching, or a convolutional neural network. In some embodiments, detecting the security tag 105 in the received image using geometric feature detection may include thresholding the raster image to generate a binary image. This thresholding may include converting a color image to a grayscale image and thresholding the image based on grayscale values, or converting the color image to a black and white image. In some embodiments, the client device 110 may be configured to perform the image conversion using image processing functions provided by ImageMagic, OpenCV, etc.

[0117] Consistent with disclosed embodiments, the client device 110 may be configured to detect geometric features in the received tag image that match known target parameters. The client device 110 may also be configured to detect reference points for potential secure tags using the geometric features. In some aspects, the client device 110 may be configured to use a geometric feature detection algorithm provided by, for example, OpenCV. In some aspects, the client device 110 may be configured to use target parameter values ​​obtained from a style sheet when detecting geometric features in a binary image. For example, the public portion of the style sheet may include a description of the geometric features present in a class of secure tags. Such geometric features may include the shape of the inner and / or outer tag rims. For example, the style sheet may indicate that the inner and outer tag rims are circles with a predetermined dimensional ratio. The client device 110 may then use the geometric feature detection algorithm to detect concentric ellipses with the appropriate dimensional ratio in the received tag image. In some embodiments, the reference point may be the focus of the concentric ellipses. In some embodiments, the client device 110 may register the reference point as the center of the secure tag 105.

[0118] Consistent with disclosed embodiments, the client device 110 may be configured to detect potential tag locations within an image using kernel-based feature detection. In some aspects, the kernel-based feature detection may be used to identify a security tag 105 or outline tag features within the security tag 105. Consistent with disclosed embodiments, the kernel-based feature detection may be performed using kernel-based feature detection algorithms such as those provided by OpenCV.

[0119] The client device 110 can be configured to use template matching or image stencil detection to detect potential tag locations within an image. In some embodiments, the template or stencil can be included or generated using the public portion of a stylesheet. The template or stencil relates to identifying a portion of the secure tag, such as a central logo or the edge of the tag. For example, the template or stencil can match a central logo. The client device 110 can be configured to perform template matching or image stencil detection using a template matching algorithm provided by, for example, OpenCV.

[0120] The client device 110 can be configured to detect potential tag locations within an image using a convolutional neural network. The convolutional neural network can be implemented using real-time object detection capabilities such as those provided by YOLO. The convolutional neural network can be trained to distinguish safety tags from other features within the image. In some embodiments, the convolutional neural network (or another convolutional neural network) can be configured to distinguish classes of safety tags following identification of the safety tags within the image.

[0121] During tag detection step 801, the client device 110 can be configured to generate a normalized secure tag image using the received image and style sheet. In some embodiments, the client device 110 can be configured to use a public portion of the style sheet. The public portion of the style sheet can specify target parameter values ​​for a class of tags. These target parameter values ​​can include shared characteristics of tags in the class of tags. Such shared characteristics can include the presence, shape, and orientation of tag features, such as a central logo, an inner rim, or an outer rim. The target parameter values ​​can further include ratios that represent relationships between dimensions of tag features. For example, such ratios can include the ratio between the thickness of the inner (or outer) tag rim and the tag diameter, or the ratio between the thickness of the inner (or outer) tag rim and the break width of the tag rim. The target parameter values ​​can also include tag size constraints (e.g., the overall diameter of a circular secure tag). The client device 110 can be configured to determine whether a secure tag identified in the received image satisfies the overall size constraint retrieved from the public portion of the style sheet. The public portion of the stylesheet can also provide rules for decoding public tag data encoded in a secure tag as tag feature options. For example, the public portion of the stylesheet can describe the correspondence between tag feature options discernible from a normalized image and the encoded tag data. A stylesheet that includes the public portion of the stylesheet can also describe the semantics of the encoded data. For example, the public portion of the stylesheet can identify publicly accessible encoded binary data as the address of an authentication server, a product type, a brand name, a stock number, or an error correction code.

[0122] During tag detection step 801, client device 110 may be configured to flatten the received image using an image warp transform. In some embodiments, client device 110 may perform the warp transform using target parameter values ​​retrieved from the public portion of the stylesheet. In some aspects, the image warp transform may map tag features detected in the received image to known locations specified in the public portion of the stylesheet. For example, client device 110 may detect potential safety tag features in the received image and determine a transformation from the detected image locations to the known image locations. Using image warping functionality provided by OpenCV or the like, client device 110 may be configured to transform the entire image to better map the detected features to the feature locations described by the public portion of the stylesheet. In this manner, client device 110 may be configured to correct for at least one of fisheye distortion, barrel distortion, or angular distortion.

[0123] During the tag detection step 801, the client device 110 may be configured to determine the orientation of the tag feature and rotate the image based on the determined orientation of the tag feature. The rotation may be further based on a target parameter value obtained from the public portion of the style sheet. The tag feature may be a central logo of the security tag. The client device 110 may be configured to identify the center of the tag using the template matching system described above. The client device 110 may then be configured to determine an outer oval line that encompasses the entire security tag. The client device 110 may be configured to determine the center of the security tag. After determining the center and the oval line, the client device 110 may be configured to construct multiple right-angled triangles on the security tag image. The right-angled triangles may be positioned so that the center of each right-angled triangle overlaps the center of the security tag, while the two vertices surrounding the hypotenuse intersect the edge of the outer oval. The triangle with the smallest and / or largest hypotenuse may be used in combination with orientation information in the public portion of the style sheet to correct the orientation of the tag. The client device 110 may be configured to determine an appropriate style sheet based on the central logo. If the secure tag does not include a central logo, the client device 110 can be configured to determine the tag style sheet by reading the tag feature options at a default location (e.g., characters from the outer edge spline using spline encoding).

[0124] During tag detection step 801, client device 110 may be configured to detect image gaps. Such image gaps may result from damage, lighting (e.g., ambient light reflecting off the scanner), or surface conditions (e.g., dirt). Client device 110 may be configured to detect tag feature options for potential image gaps and compare the tag feature option values ​​to target parameter values ​​listed in the public portion of the stylesheet. If the potential image gap does not match the target parameter values ​​in the public portion of the stylesheet, client device 110 may be configured to ignore the image gap and extend tag features surrounding the image gap based on the target parameter values ​​in the public portion of the stylesheet. For example, client device 110 may be configured to handle rim gaps determined to be artifacts by ignoring the rim gaps when converting normalized raster images to vector graphics files for transmission to authentication server 115.

[0125] During tag detection step 801, client device 110 can be configured to provide an identification request to the authentication server, the identification request including the normalized secure tag image. While described herein as an “identification request,” the reason or purpose for providing such a request is not limited to identifying the secure tag. For example, providing an identification request can be part of an action related to the secure tag, such as trading ownership of an item labeled with the secure tag, updating rules regarding the secure tag, canceling the secure tag, or the like. As described above, client device 110 can be configured to at least normalize the orientation of the received raster image, flatten the raster image, and correct image gaps. Client device 110 can be configured to generate the normalized secure tag image by converting the raster image to a vector graphics image, such as an SVG, EPS, or PDF image.

[0126] In some embodiments, the client device 110 may be configured to provide instructions to display an image and instructions to highlight potential secure tags on a user interface of the secure tag reader. For example, if the client device 110 is a smartphone camera, the smartphone display may depict the image and include a bounding box or similar indication around the detected secure tag. In some embodiments, the bounding box may indicate whether the tag was successfully identified. For example, the color, shape, line style, etc. of the bounding box may indicate whether the tag was successfully identified. The client device 110 may be configured to perform an action upon selection of the bounding box, such as optically or digitally zooming in on the area of ​​the detected tag.

[0127] After step 801, process 800 may proceed to step 803. In step 803, client device 110 may be configured to provide an identification request to authentication server 115. The identification request may include the normalized image generated in step 801. The normalized image is a vector graphics image. In some embodiments, the raster image received by client device 110 in step 801 may include multiple potential secure tags. In such embodiments, client device 110 may be configured to detect and generate normalized images of the multiple potential secure tags. Client device 110 may be configured to provide the generated normalized image as a stream of vector graphics images corresponding to the multiple potential secure tags. In some embodiments, the identification request may include the public key of the secure tag reader, and at least a portion of the identification request may be encrypted with the private key of client device 110.

[0128] In some embodiments, client device 110 may be configured to receive instructions to generate another image. These instructions may be received from authentication server 115. The instructions may cause client device 110 to automatically generate a second zoomed-in image of the potential safety tag. Alternatively or additionally, the instructions may instruct a user to cause client device 110 to generate a second zoomed-in image of the potential safety tag. Client device 110 may then be configured to generate another normalized image from the second zoomed-in image of the potential safety tag.

[0129] After step 803, process 800 may proceed to step 805. In step 805, client device 110 may receive decoding instructions and / or tag data from authentication server 115. In some embodiments, the decoding instructions may supplement the public portion of the style sheet. For example, the decoding instructions may limit the possibilities exposed by the style sheet to specific mappings between tag feature options and tag data values. In various embodiments, the decoding instructions may describe a specific set of rules for converting tag feature options to tag data values. For example, the decoding instructions may indicate that a particular tag data item has a value that depends on a specified set of tag feature options.

[0130] As described above, in some embodiments, client device 110 can be configured to display an image and instructions highlighting a potential secure tag on a user interface of a secure tag reader. In some embodiments, client device 110 can be configured to receive instructions from a user to select a potential secure tag (e.g., a touch-sensitive display where the instructions are a bounding box surrounding the potential secure tag and the instructions may include a user selecting the bounding box). Client device 110 can be configured to generate a normalized image of a potential secure tag, provide an identification request to authentication server 115, and in response receive tag data and / or decoding instructions from authentication server 115. Client device 110 can be configured to decode the tag data using any decoding instructions received from authentication server 115. Client device 110 can then be configured to provide instructions to display the secure tag data (e.g., the received and / or decoded tag data) on a user interface of client device 110 (or another device).

[0131] 9 shows a flowchart illustrating an example process 900 for tag identification. While described below as being performed by authentication server 115, process 900 may, in some embodiments, be performed by personal system 120, client system 110, or another system. Consistent with disclosed embodiments, process 900 may include receiving a tag identification request, identifying a secure tag based on the tag identification request, generating tag data using the retrieved tag image and decoding rules, and providing the decoded tag data in response to the request.

[0132] After starting, process 900 may proceed to step 901. In step 901, authentication server 115 may receive a tag identification request. The tag identification request may include a tag image (e.g., a photo or video image including an unidentified secure tag). Authentication server 115 may be configured to receive the tag identification request from client device 110. The tag identification request may be received using network 130. In some aspects, the tag identification request may include an authentication key (e.g., an API key for authenticating API calls). In some aspects, the tag identification request may include a session token (e.g., an OAUTH 2.0 bearer token, a Kerberos token, etc.). In some aspects, the tag identification request may include user identification information, such as a username or account information. In some aspects, authentication server 115 may be configured to determine whether the identification request is valid based on the session token and general access rules 210. For example, authentication server 115 may be configured by general access rules 210 to require account information in addition to the session token. Alternatively, the authentication server 115 may be configured with general access rules 210 to allow access without requiring account information.

[0133] After step 901, process 900 may proceed to step 903. At step 903, authentication server 115 may identify the secure tag 105 in the received tag image. Consistent with disclosed embodiments, authentication server 115 may be configured to identify the secure tag 105 using a stored hash of the secure tag image. The stored hash may be a perceptual hash (e.g., pHash, aHash, dHash, etc.). As described above with respect to FIG. 6, the secure tag corresponding to the stored hash may have been generated using a style sheet. In some embodiments, authentication server 115 may be configured to store the hash received from personal system 120. Authentication server 115 may be configured to associate the stored hash with a secure tag identifier. Authentication server 115 may not be configured to store the style sheet or private portions of the style sheet. Thus, if an attacker gains access to authentication server 115, the attacker only gains access to the hash and the secure tag identifier. However, in some embodiments, authentication server 115 may be configured to store public portions of the style sheet.

[0134] In step 903, consistent with disclosed embodiments, authentication server 115 may generate one or more hashes of the received tag image. The one or more generated hashes may be perceptual hashes (e.g., pHash, aHash, dHash, etc.). In some aspects, the received tag image may be a vector graphics image. In various aspects, generating a hash of the received tag image may include converting at least a portion of the received vector graphics image into a raster image. The raster image may have a predetermined number of pixels. In some aspects, the predetermined number of pixels may be 64 pixels or greater. In various aspects, the predetermined number of pixels may be 1,048,576 pixels or less.

[0135] In step 903, consistent with disclosed embodiments, the authentication server 115 may identify a secure tag 105 in the received tag image by comparing one or more generated hashes of the received tag image with stored hashes of images of known secure tags. In some embodiments, this comparison may include determining a difference between the stored hashes and the generated hashes. The authentication server 115 may be configured to identify the secure tag 105 as the secure tag corresponding to the stored hash when the difference between the stored hash and the generated hash meets a threshold criterion. For example, the threshold criterion may require the hashes to match. As an additional example, the threshold criterion may require the hashes to be similar. For example, in some aspects, the difference may be the distance between the stored hash and the generated hash. The authentication server 115 may be configured to similarly identify hashes within a threshold distance. In some embodiments, the distance may be a Hamming distance.

[0136] In some embodiments, the authentication server 115 can be configured to identify damaged or partially obscured tags. For example, the authentication server 115 can be configured to identify a secure tag 105 in an incoming tag image by generating hashes of progressively smaller segments of the incoming tag image. These progressively smaller segments of the incoming tag image can be compared to hashes of corresponding segments of known secure tags. Based on the degree of match between these generated hashes and the corresponding hashes of known secure tags, a damaged or partially obscured tag can be identified even if the hash of the entire image of the damaged or partially obscured tag does not match the stored hash.

[0137] In step 903, consistent with disclosed embodiments, the authentication server 115 can determine the tag identifier of the matching stored hash. The tag identifier can be used to obtain the tag decoding rules.

[0138] After step 903, process 900 may proceed to step 905. In step 905, authentication system 115 may generate tag data using the received tag image and decoding rules. In some aspects, these decoding rules may be specific to the tag generated using a particular stylesheet. For example, these decoding rules may identify the location of tag data within the tag, specify default locations for tag features, specify correspondences between tag feature options and tag data values, provide ratios (e.g., dot diameter as a ratio of overall diameter, width tag feature to identify tag feature options, rim breakage as a ratio of rim thickness, etc.).

[0139] In step 905, the authentication system 115 may receive the decoding rules in response to the decoding request. In some aspects, the decoding request may be provided to the personal system 120 or another system. The decoding request may be provided using the network 130. The decoding request may include an identifier of the secure tag 105. The decoding request may include an authentication key (e.g., an authentication key received from the client device 110). In some aspects, the decoding rules may be obtained from the personal system 120 or another system.

[0140] In some embodiments, the decoding rules may enable decoding of a subset of the secure tag 105. The decoding rules may include or be based on portions of a stylesheet used to generate the secure tag 105. The decoding rules may correspond to an authentication key. For example, the authentication system 115 may receive different decoding rules depending on the authentication key that includes the decoding request. As a further example, different rules may be provided depending on the authentication key associated with the manufacturer and depending on the authentication key associated with the retailer. While the secure tag may contain the same information, differences in the decoding rules mean that different subsets of that information are available to the manufacturer and the retailer.

[0141] In some embodiments, the decoding rules may enable iterative decoding of the secure tag 105. For example, the decoding rules may include a first decoding rule and a second decoding rule. The first decoding rule may enable decoding of at least one of a first portion of the secure tag defined by the style sheet or a first subset of tag features defined by the style sheet. For example, the first decoding rule may enable decoding of first tag data of a reference portion of the secure tag. The second decoding rule may enable decoding of at least one of a second portion of the secure tag or a second subset of tag features. For example, the second decoding rule may enable decoding of second tag data of a portion of the secure tag referenced by the first tag data encoded in the reference portion of the secure tag decoded using the first tag. Without the first tag data encoded in the reference portion, the second tag data cannot be decoded using the second decoding rule. Thus, the first tag data can be generated using a first decoding rule, and the second tag data can be generated using the first tag data and a second decoding rule.

[0142] In some embodiments, the authentication system 115 can receive public decoding rules for decoding public portions of tags generated using a stylesheet. Such rules can specify how to decode commonly significant non-sensitive information such as stock keeping unit numbers (SKUs), brand names, expiration dates, product names, etc.

[0143] After step 905, process 900 may proceed to step 907. In step 907, authentication server 115 may be configured to provide decoded tag data to client system 110 in response to the original tag identification. In some embodiments, authentication system 115 may be configured to provide tag decoding rules in addition to or instead of the tag data, thereby allowing the client device to perform tag decoding on behalf of authentication server 115 or to verify decoding performed by authentication server 115. For example, in some embodiments, authentication server 115 may be configured to provide public decoding rules for the secure tag 105 stored by authentication server 115 or received from personal system 120 to client device 110.

[0144] In some embodiments, the authentication server 115 can be configured to track tag identification requests. For example, the authentication server 115 can be configured to save tracking information including the identification request type, location, IP address, time, client device identification information, user identification information, transaction information, etc. In some embodiments, the authentication server 115 can be configured to store the tracking information in the authentication database 205. In various embodiments, the authentication server 115 can be configured to provide instructions to write this information to the public database 130 (which can be a distributed database such as the Ethereum blockchain). For example, the authentication server 115 can be configured to use an oracle 510 to write the location of the secure tag 105 identification request to the bundle account 520. In some embodiments, the authentication server 115 can be configured to provide at least a portion of the tracking information in response to a request from the client device 110 depending on one or more identities associated with the request or an API key provided in the request. In some embodiments, the authentication server 115 can be configured to provide an address in the public database 130 that the client device 110 can use to retrieve the tracking information.

[0145] 10 shows a flowchart illustrating an example process 1000 for multi-resolution tag identification consistent with disclosed embodiments. While described below as being performed by the authentication server 115, the process 1000 may, in some embodiments, be performed by the personal system 120, the client system 110, or another system. The process 1000 may include generating a hash of an image of the secure tag 105, selecting a first secure tag based on the generated hash, generating a second hash corresponding to a predetermined segment of the secure tag 105, and selecting a secure tag from the first secure tag as a secure tag that matches the secure tag 105. In this manner, the process 1000 may enable the authentication server 115 to identify a secure tag 105 in an image if the hash of the secure tag 105 in the image matches multiple stored hashes.

[0146] After starting, process 1000 may proceed to step 1001. In step 1001, authentication server 115 may generate a hash of the secure tag depicted in the received tag image (e.g., secure tag 105). The hash may be a perceptual hash.

[0147] After step 1001, process 1000 may proceed to step 1003. In step 1003, authentication server 115 may select a first secure tag using the difference between the generated hash and a stored hash of the first secure tag. In some embodiments, the difference may be a distance according to a metric such as Hamming distance. In some aspects, the stored hash of the selected first secure tag may differ from the generated hash of the secure tag depicted in the received tag image by less than a threshold value.

[0148] After step 1003, process 1000 may proceed to step 1005. In step 1005, authentication server 115 may generate a second hash of a predetermined segment of the secure tag 105 depicted in the received tag image. For example, authentication server 115 may be configured to generate a hash of one or more quadrants of the secure tag.

[0149] Consistent with disclosed embodiments, authentication server 115 can be configured to prompt client device 110 for a second image. For example, authentication server 115 can be configured to provide instructions to display a banding box or similar display around a predetermined segment of secure tag 105. In response to this instruction, a user can interact with the client device to obtain a second image representing the predetermined segment of secure tag 105.

[0150] The authentication server 115 may be configured to receive this second image from the client device 110. The first received image may show at least a portion of the security tag 105 as a whole at a first level of detail, while the second received image may show a predetermined segment of the security tag 105 at a second level of detail that is greater than the first level of detail. For example, the first and second images may include the same number of pixels, but the camera of the client device 110 may be closer to the predetermined segment of the security tag 105 when taking the second image than when taking the first image.

[0151] After step 1005, process 1000 may proceed to step 1007. In step 1007, authentication server 115 may be configured to select a specific secure tag from the previously selected first secure tags. Authentication server 115 may be configured to narrow the selection of matching secure tags using a difference between the second hash generated in step 1005 and stored second hashes of a predetermined portion of the image of the first secure tag. For example, the first hash generated in step 1001 may broadly match the stored hash of the first secure tag, but the second hash generated in step 1005 may match only one of the stored second hashes (e.g., the second hash generated in step 1005 may only match one of the stored second hashes below a threshold). If two or more stored second hashes sufficiently match the second hash generated in step 1005, the authentication server 115 may be configured to repeat this comparison process with another predetermined segment of the secure hash 105 (e.g., a sub-segment of the quadrant selected in step 1005, or another quadrant of the secure tag 105).

[0152] FIG. 11 shows a flowchart illustrating an example process 1100 for multi-resolution tag identification with modified tags. While described below as being performed by authentication server 115, process 1100 may, in some embodiments, be performed by personal system 120, client system 110, or another system. Consistent with disclosed embodiments, process 1100 may include comparing a hash of a secure tag depicted in a received tag image with a stored hash of the secure tag image. If the hash of the secure tag depicted in the received tag image does not match any of the stored hashes within a predetermined difference, authentication server 115 compares a hash of a predetermined segment of the secure tag depicted in the received tag image with a stored hash of the corresponding segment of the secure tag. Authentication server 115 may be configured to identify potentially matching secure tags based on this second comparison. Authentication server 115 may be configured to compare a hash of another predetermined segment of the secure tag depicted in the received tag image with a stored hash of the corresponding segment of the identified potentially matching secure tag. If these additional hashes match within a predetermined difference, authentication server 115 can be configured to confirm the identity of the matching secure tag as the secure tag depicted in the received tag image. Thus, according to process 110, authentication server 115 can be configured to search authentication database 205 for hashes that match the portion of the secure tag depicted in the received image. In this manner, authentication server 115 can be configured to match incomplete or damaged secure tags.

[0153] After starting, process 1100 may proceed to step 1101. In step 1101, the authentication server 115 may determine that the difference between an initially generated hash of a secure tag and an initially stored hash does not meet a threshold criterion. The first generated hash may be of a secure tag depicted in a received image (e.g., secure tag 105). The initially stored hash may be of a secure tag in the authentication database 205. The difference is a distance calculated according to a metric (e.g., Hamming distance).

[0154] After step 1101, process 1100 may proceed to step 1103. In step 1103, authentication server 115 may be configured to select one of the security tags in authentication database 205 based on a comparison of the generated second hash of the security tag depicted in the received image (e.g., security tag 105) with a stored second hash. The generated second hash may be a hash of a segment of the security tag depicted in the received image (or another image of the same security tag). The stored second hash may be a hash stored in authentication database 205 of a segment of a potentially matching security tag. The segment of the potentially matching security tag may be the same as the segment of the security tag depicted in the received image.

[0155] After step 1103, process 1100 may proceed to step 1105. In step 1105, authentication server 115 may be configured to generate a hash of a second segment of the secure tag depicted in the initially received image. In some embodiments, authentication server 115 may be configured to prompt client device 110 for another image. For example, authentication server 115 may be configured to provide instructions to display a banding box or similar display around a segment of the secure tag 105. In response to this instruction, the user may interact with client device 110 to obtain a second image showing the desired segment of the secure tag 105.

[0156] In some embodiments, the second segment can be different from the first segment. For example, if the first segment is in the upper right quadrant of the safety tag, the second segment can be in the upper left quadrant of the safety tag. In various embodiments, the second segment can overlap the first segment. For example, the second segment can be completely or partially contained within the first segment. For example, the second segment can be in the lower left quadrant of the first segment.

[0157] After step 1105, process 1100 may proceed to step 1107. In step 1107, authentication server 115 may be configured to verify the potentially matching secure tag identified in step 1103. The authentication server 115 may be configured to verify the potentially matching secure tag using a difference between the generated third hash and the stored third hash. The stored third hash may be a segment of the potentially matching secure tag. The segment may correspond to a segment used to generate the third hash. The authentication server 115 may determine that the difference between the third generated hash and this stored hash meets a threshold criterion. The difference is a distance calculated according to a metric (e.g., Hamming distance).

[0158] Consistent with disclosed embodiments, processes 1000 and 1100 may include (i) using segment distances to determine an overall distance and / or (ii) a count of segment distances meeting a threshold criterion. For example, authentication server 115 may compare multiple hashes of images of segments of secure tag 105 with corresponding stored hashes of the segments of the secure tag. This comparison may include determining a distance between each hash of the images of segments of secure tag 105 and the corresponding stored hash of the segments of the secure tag. The comparison may include determining an overall distance based on these individual distances, such as an average distance. The comparison may also include determining a count of individual distances that meet a threshold criterion (e.g., fall within a certain maximum distance). In some embodiments, authentication server 115 may be configured to determine a confidence value using the number of hashes compared, the count of individual distances that meet the threshold criterion, or at least one of the individual distances or the overall distance.

[0159] FIG. 12 shows a schematic diagram of a logical database structure for performing multi-resolution tag identification. In some embodiments, the authentication database 205 may be configured with the schema shown in FIG. 12. The authentication database 1205 may be configured to store hashes generated using secure tags. These hashes may be generated by the person system 120 during the tag creation process, as described above with respect to FIG. 6. In some aspects, the authentication database 205 may be configured to store hashes for a first secure tag in the data structure 1201. The authentication database 205 may be configured to store hashes corresponding to multiple levels of detail. In some aspects, the tag level 1230 may include hashes calculated over the entire secure tag. At this level of detail, small tag feature options used to encode data may not be discernible (due to scanner resolution or image processing losses). Therefore, a hash calculated on an image representing the entire tag may not match any of the hashes stored in the authentication database, or may match multiple hashes. In various aspects, the tag level 1240 may include hashes calculated over segments of the entire tag (e.g., quadrants of the entire secure tag). At this level of detail, small tag feature options used to encode data are discernible. Furthermore, damage to one segment of a tag may not affect another segment of the tag. Thus, hashes calculated across a damaged tag may not match (e.g., mismatched hashes 1203), while hashes calculated across undamaged segments of the tag may match (e.g., matched hashes 1211). In various aspects, tag level 1250 may include hashes calculated across subsegments of the entire tag (e.g., quadrants of quadrants across the secure tag). Because additional segments of other tags may match (e.g., matching hashes 1213), authentication server 115 can be configured to check additional hashes (e.g., matching hashes 1221, mismatched hashes 1223).By checking these additional hatches, the authentication server 115 can verify that the secure tag corresponding to the hash in the first tag hash structure 1201 is the secure tag depicted in the received image. In some embodiments, the authentication server 115 can be configured to generate a score based on the number of hashes checked, the number of hashes that match according to a similarity criterion, and the degree of match. This score can be used to identify a secure tag that matches the secure tag depicted in the image received from the client device 110. As will be appreciated by those skilled in the art, the illustrated tree structure is not intended to be limiting. Other data structures can be used to store the hashes and associated information, such as an associative array or map keyed to the stored hashes and including the identifiers of the secure tags.

[0160] FIG. 13 illustrates an exemplary user interface for assessing the authenticity of a tag. The reading device can include an app that can display the determined level of authenticity of the tag. Authenticity can be determined using the systems and methods disclosed herein. When a secure tag is scanned, the scanned tag image is sent to an authentication server. The authenticity of the tag can be determined using the hashing methods described in FIGS. 10-12. Once the tag is authenticated, information about the tag, such as the number of scans, reports, etc., is returned. In certain aspects, the authentication server can determine the probability of authenticity based on the hashing process. In other aspects, the authentication server can determine the authenticity of the secure tag based on the tag history stored in the blockchain.

[0161] In some embodiments, the app that determines the level of authenticity of the tag can return an "authentication score." In certain aspects, a perfect score 1301 can be returned. This can occur, for example, if the security tag is in good condition and the reader is able to obtain a proper scan of the security tag. Additionally, a perfect score 1301 can be returned if the authentication server determines that the security tag has not been scanned before or if the tag history in the blockchain indicates that the product is not counterfeit. In other aspects, a low score 1303 can be returned. This can occur if the security tag is in poor condition or if the reader is unable to obtain a proper scan of the security tag. Additionally, a low score 1303 can be returned if the authentication server determines that the same tag has been identified as a possible counterfeit. For example, if a tag has been scanned multiple times in multiple locations, a low score 1303 is returned as the authentication score. In another example, if the tag has been reported as counterfeit, a low score 1303 is returned as the authentication score.

[0162] In some embodiments, a user can report a tag via the exemplary user interface shown in Figure 13. For example, if a low score 1303 is returned, indicating that the tag has been scanned multiple times and is not unique, the user can report the tag so that the tag's owner is aware of the potential counterfeit. In other embodiments, the user can view product information via the app. For example, if a high score 1301 is returned, the user can review the product information.

[0163] FIG. 14 illustrates an exemplary process for decoding tag feature selections. While described below as being performed by the authentication server 115, the process 1400 may, in some embodiments, be performed by the personal system 120, the client system 110, or another system. The process 1400 may include receiving an image, receiving decoding rules and a numeric seed, identifying possible functions using a known style sheet and / or known data values, identifying actual functions based on the received image, reconstructing the data values, and decrypting the data values. In this manner, the authentication server 115 may be configured to decode data stored in a secure tag using information received from both the client device 110 and the personal system 120. In some embodiments, the authentication server 115 does not store the image, the decoding rules, or the numeric seed. In this manner, the arrangement of the system 100's functionality ensures that an attacker who compromises the authentication server 115 cannot decode the contents of secure tags managed by the authentication server 115.

[0164] After starting, process 1400 may proceed to step 1401. In step 1401, the authentication server 115 may be configured to receive an image. The image may be a raster image or a vector graphics image. The image may be received from the client device 110 or another system. If the image is a raster image, the authentication server 115 may be configured to convert the image to a vector graphics image.

[0165] After step 1401, process 1400 may proceed to step 1403. In step 1401, the authentication server 115 may receive a decoding instruction. In some embodiments, the authentication server 115 may be configured to receive the decoding instruction from the personal system 120. The decoding instruction may be received in response to a request from the authentication server 115 to the personal system 120. The request may include an application key, and the received decoding instruction depends on the provided application key.

[0166] In some embodiments, the personal system 120 may be configured to convert the style sheet and numeric seed used to generate the secure tag into decoding instructions that directly describe the correspondence between tag features and tag data values ​​present in the vector graphics image. For example, the decoding instructions may specify a set of tag feature options and a mapping from values ​​of these tag feature options to values ​​of items of tag data. In such embodiments, the personal system 120 may not provide the private portion of the style sheet or the numeric seed to the authentication server 115. In some embodiments, the authentication server 115 may be configured to use at least a portion of the private portion of the style sheet, along with the numeric seed used to generate the secure tag layout of the secure tag, to generate the tag. In such embodiments, the authentication server 115 may be configured to generate the correspondence between tag features and tag data values ​​present in the vector graphics image.

[0167] After step 1403, process 1400 may proceed to step 1405. In step 1405, authentication server 115 may identify possible features using the decode instructions and known tag data values. For example, authentication server 115 may be configured to find tag features listed in the decode instructions. In some cases, identifying a tag feature depends on known tag data values. For example, a secure tag may encode an 8-bit binary number as the size of a dot on the secure tag. The decode instructions may indicate a correspondence between the size of the dot and a particular 8-bit binary value. However, the decode instructions may not specify which portion of the secure tag contains the associated dot. Another portion of the secure tag may include a reference that can be used to identify a portion of the tag that encodes a tag feature (a dot) with a tag feature option (dot size) that encodes a particular value of tag data.

[0168] After step 1405, process 1400 may proceed to step 1407. In step 1407, authentication server 115 may identify actual tag feature option values ​​based on the received image. In some embodiments, if the image file is a vector graphics file, authentication server 115 may read feature option values ​​from the vector graphics file. If necessary, authentication server 115 may initially convert the received image to a vector graphics file. Alternatively, authentication server 115 may determine tag feature option values ​​(e.g., relative dot size, presence or absence of a feature at a certain location) directly from the raster image using functions provided by OpenCV or the like.

[0169] After step 1407, process 1400 may proceed to step 1409. In step 1409, authentication server 115 may reconstruct tag data values ​​based on the actual feature values. For example, having determined the tag feature option values ​​for the associated tag features, authentication server 115 may be configured to convert these tag feature option values ​​into tag data according to decoding rules received from person system 120.

[0170] After step 1409, process 1400 may proceed to optional step 1411. In optional step 1411, authentication server 115 may decrypt the tag data. In some embodiments, authentication server 115 may be configured to decrypt the encrypted tag data using key material encoded in the secure tag.

[0171] 15 illustrates an exemplary authentication process that uses contextual information. While described below as being performed by the personal system 120 and the authentication server 115, process 1500 can, in some embodiments, be performed entirely by the personal system 120 or the authentication server 115, or by the client system 110 or another system. According to process 1500, the personal system 120 can encode contextual data into a secure tag. The authentication server 115 can then enforce contextual conditions on the encoded data when responding to an identification request.

[0172] After starting, process 1500 may proceed to step 1501. In step 1501, the personal system 120 may receive tag data. As previously mentioned, this tag data may be received from another system, from the memory of the personal system 120, or from a user.

[0173] After step 1501, process 1500 may proceed to step 1503, where the personal system 120 may receive contextual information. In some embodiments, this contextual information may include at least one of authentication credentials (e.g., a password, an authentication token, etc.), a biometric identifier (e.g., a fingerprint, a voiceprint, etc.), an audio file, a tag identifier (e.g., a tag identifier of another secure tag), or a perceptual hash of the image. For example, a secure tag may be created to label an item (e.g., a user ID card, a piece of meat, a bottle of wine, an item owned by an individual), and an image may depict a portion of the item (e.g., an ID photo on an ID card, a grain of meat, a label on a bottle of wine, the face of an individual who owns the item).

[0174] After step 1503, process 1500 may proceed to step 1505. In step 1505, the person system 120 may encode the tag data and contextual information into the secure tag. As described in this application, the tag data and contextual information may be encoded into the secure tag as a selection of tag feature options, with the available tag feature options dependent on the numeric seed.

[0175] After step 1505, process 1500 may proceed to step 1507. In step 1505, authentication system 115 may receive an identification request for a secure tag. As described in this application, the authentication server may be configured to identify the tag using one or more hashes of the secure tag. The authentication server 115 may be configured to request decoding instructions from the personal system 120. The authentication server 115 may be configured to use the decoding instructions to decode the stored contextual information.

[0176] After step 1507, process 1500 may proceed to step 1509. At step 1509, authentication system 115 may receive additional contextual information. This additional contextual information may be received from client device 110 or another device. The additional contextual information may be received in response to a request provided by authentication system 115. For example, authentication system 115 may provide instructions to client device 110 for display to a user of client device 110 (e.g., instructions to display the text "Take a photo of owner's face to unlock Lava Tag" on the user interface of client device 110).

[0177] After step 1509, process 1500 may proceed to step 1511. At step 1511, authentication system 115 may authenticate the identification request using the additional contextual information. In some embodiments, authentication system 115 may be configured to determine that the received additional contextual information and the decoded contextual information meet a similarity criterion. For example, authentication system 115 may be configured to compare the decoded contextual information with the received contextual information. If the contextual information is a perceptual hash of the image (e.g., a perceptual hash of another tag, or the owner of the labeled item, or a portion of the labeled item), authentication system 115 may be configured to determine the difference between the received additional contextual information and the decoded contextual information. In some aspects, this distance will be a Hamming distance (or a similar metric).

[0178] After step 1511, process 1500 may proceed to step 1513. At step 1513, authentication system 115 may provide an indication based on the result of the authentication performed at step 1511. If the additional contextual information and the decoded contextual information do not meet the similarity criteria, authentication system 115 may provide an indication of authentication failure to client device 110. If the additional contextual information and the decoded contextual information meet the similarity criteria, authentication system 115 may provide an indication of authentication success to client device 110. In some embodiments, the indication of successful authentication may include at least some of the tag data received at step 1501. In various embodiments, the indication of successful authentication may include decoding instructions for at least some of the tag data received at step 1501. In various embodiments, the indication of successful authentication may include status information retrieved from a distributed database. This status information may be obtained from the distributed database using an oracle (e.g., the distributed database is the Ethereum blockchain).

[0179] FIG. 16A illustrates paired and sequenced safety tags. Safety tags can have relationships with other tags to increase levels of security and reliability. For example, a first safety tag 1601 can be paired with a second safety tag 1603. Both the first safety tag 1601 and the second safety tag 1603 can then be required to be scanned by a user to obtain information about the product or to transfer ownership of the product. For example, a first safety tag 1601 can be generated and placed on one shoe of a pair of shoes, and a second safety tag 1603 can be generated and placed on a second shoe of the same pair. In this example, both tags are unique and identify the specific shoe of the pair, but both tags must be read to authenticate the pair of shoes or transfer ownership.

[0180] In some embodiments, paired tags can be further sequenced to create a sequenced tag 1605. The sequenced tag 1605 is a combination of the first secure tag 1601 and the second secure tag 1603 and provides information about the paired tags. In certain aspects, the sequenced tag 1605 can be the only tag that can be scanned prior to purchase or transfer of ownership. In these aspects, the sequenced tag 1605 can provide product authentication and basic information about the product. The sequenced tag 1605 can also indicate which paired tags must be present. Using the previous example, if a pair of shoes contains paired tags, the tags can be sequenced to create the sequenced tag 1605. The sequenced tag 1605 can be placed on the outside of a shoebox to provide information about the shoes within the box. Once opened, the first secure tag 1601 and the second secure tag 1603 can be scanned to verify that the correct shoes are in the box.

[0181] FIG. 16B illustrates an ID card 1607 using proximity fingerprinting. In addition to having relationships with other secure tags, the secure tag 1611 can have a relationship with an external image, such as a facial fingerprint 1609. The identification card 1607 can have an additional level of authenticity by combining the secure tag 1611 with the facial fingerprint 1609. Proximity fingerprinting uses an object in proximity to the secure tag 1609 to further authenticate the tag. In some embodiments, this can prevent a situation where the secure tag is copied and authenticated elsewhere. For example, if the secure tag 1611 is copied from the ID card 1607, it will not be verified without the facial fingerprint 1609. The result is a combined, protected ID in the form of the ID card 1607. In some embodiments, the secure tag 1611 is paired with the facial fingerprint 1609, meaning that both the secure tag 1611 and the facial fingerprint 1609 must be presented together for authentication.

[0182] In some embodiments, ID card 1607 may be used to provide proof of identity in appropriate circumstances. For example, a police officer may request that a citizen present ID 1607 to verify that the person is who they claim to be at the encounter. In other embodiments, an establishment serving alcohol may require a person to present ID 1607 to ensure that the person is not using a fake driver's license or proof-of-age card.

[0183] Figure 22 illustrates paired tags throughout the supply chain. When a manufacturer produces a product, they can create a first safety tag 2201 and a second safety tag 2203, pair the safety tags, and affix the safety tags to the product. The paired tags can be sequenced and updated on the blockchain throughout the supply chain process. For example, the sequenced tag can contain information about the paired product itself 2205, the specific pallet the paired products were shipped to 2207, the overall shipment the paired products were sent to 2209, and information about the retailer 2211. At each stage in the supply chain process, the blockchain is updated with information about the paired products. When a customer goes to a retailer and purchases the product, ownership verification 2213 of the sequenced tag can be performed.

[0184] In some embodiments, retailer control 2215 and closed consumer loop 2217 may have access to different levels of information. For example, closed consumer loop 2215 may only have access to information about the paired tag itself. This may include information about the product itself and the manufacturer. Closed consumer loop 2215 allows the consumer to verify the authenticity of the paired tag. In this example, retailer control 2215 may include the ability to access information about the entire supply chain process. Retailer control 2215 may include access to individual package information 2205, pallet information 2207, shipping information 2209, and retailer information 2211. Retailer control 2215 typically does not include access to the paired tag itself. Retailer control 2215 allows the retailer to track shipping information and manage logistics.

[0185] FIG. 17 illustrates an exemplary two-part label. The two-part label may include a base tag 1710 and an overlay 1720. The base tag 1710 may include a substrate labeled with a first security tag that encodes first tag data as a selection of a potential first secure data feature option. The overlay 1720 may be removably adhered to the substrate that includes the base tag 1710. The overlay 1720 may include a transparent portion 1721 and an opaque portion 1723. Both the transparent portion 1721 and the opaque portion 1723 may be aligned with the first security tag. The first security tag located on the base tag 1710 may be unaffected by the aligned transparent portion 1721. The aligned opaque portion 1723 and the first security tag located on the base tag 1710 may encode second tag data as a selection of a potential second security tag feature option.

[0186] In some embodiments, the potential first safety tag feature options on base tag 1710 are different from the potential second safety tag feature options created by opaque portion 1723 and base tag 1710. In other embodiments, aligned opaque portion 1723 can obscure a selected first safety tag feature on base tag 1710. In still other embodiments, aligned opaque portion 1723 can select a potential first safety tag feature option on base tag 1710. In still other embodiments, the potential first safety tag feature options on base tag 1710 can include the presence or absence of a tag feature at a location specified by the first safety tag layout. In these embodiments, the potential second safety tag feature options created by aligned opaque portion 1723 can include the presence or absence of a tag feature at a location specified by the second safety tag.

[0187] The two-part label shown in FIG. 17 can be generated by first generating a first safety tag using first tag data, a first numeric seed, and a first style sheet to encode the first tag data as a selection of a potential first safety tag feature option. Next, the method generates a second safety tag using second tag data, a second numeric seed, and a second style sheet to encode the second tag data as a selection of a potential second safety tag feature option. The method then determines a difference image between the first and second safety tags and labels a substrate with the first safety tag to create a base tag 1710. The method then removably attaches an overlay 1720 to the base tag 1710, the overlay 1720 labeled with the difference image and aligned with the first safety tag.

[0188] In some embodiments, overlay 1720 obscures the portion of the first safety tag located on base tag 1710 with opaque portion 1723 that is not present on the second safety tag. In other embodiments, overlay 1720 shows the portion of the second safety tag that is not present on the first safety tag. In yet other embodiments, overlay 1720 transmits the portion of the second safety tag that is present on the first safety tag located on base tag 1710 through transparent portion 1721. In still other embodiments, the first style sheet used to generate the first safety tag may be different from the second style sheet used to generate the second safety tag. In still other embodiments, the substrate to which base tag 1710 is labeled and overlay 1720 is adhered may include a consumer good.

[0189] For example, a two-part label can be used for additional authentication and security of a product. A two-part label can be placed on the outside of the box in which it is sold. This two-part label includes a base tag 1710 and an overlay 1720. The overlay 1720 includes both a transparent portion 1721 and an opaque portion 1723, giving the tag a unique appearance different from the base tag 1710. In this example, a customer or retailer can scan the second tag created by the overlay 1720 to reveal specific information about the product. After the product is purchased and / or ownership is transferred, the overlay 1720 can be removed to reveal the base tag 1710. The current owner can scan the base tag 1710 to reveal information completely different from that provided by the combination of the overlay 1720 and the base tag 1710. The two-part label adds an additional layer of security without the added complexity of the security tag itself.

[0190] FIG. 18 is a flowchart of an example method 1800 for providing a document using a secure tag. Method 1800 begins at step 1801, where the method associates a first secure tag 1813 with a document 1811. The first secure tag 1813 can be generated and paired with the document 1811. Additionally, the first secure tag 1813 has an identifier for the document 1811 encoded using a selection of potential functional options. In some embodiments, the identifier for the document 1811 can include a hash of the document 1811. In other embodiments, the document 1811 is encrypted in a blockchain. The method can receive a request to access the document 1811 from a first device 1821. The first device 1821 can be a mobile device (e.g., a tablet, a smartphone, etc.), a desktop computer, a laptop, a server, a wearable device (e.g., glasses, a watch, etc.), and / or a dedicated hardware device. Following the request for access to the document 1811, method 1800 moves to step 1803.

[0191] At step 1803, the method provides the first secure tag 1811 via the first user device 1821 for display. At step 1805, the method may receive confirmation of the request via the second device 1831 including the secure tag image. The second device 1831 may be a mobile device (e.g., tablet, smartphone, etc.), a desktop computer, a laptop, a server, a wearable device (glasses, watch, etc.), and / or a dedicated hardware device. The method may then compare the first secure tag image 1813 with the secure tag image received from the second device 1831. If the comparison reveals a match between the first secure image 1813 and the secure tag image received from the second device 1831, the method 1800 moves to step 1807.

[0192] In step 1807, the method provides the document 1811 to a first device 1821 for display. In some embodiments, the document 1811 can be watermarked with a security tag to create a watermarked document 1843. The watermarked document 1843 can have a new security tag or can be watermarked with the first security tag 1813. In other embodiments, the first device 1821 can become an authorized user device 1841. In some embodiments, the authorized user device 1841 can access the watermarked document 1843 for a predetermined period of time. Once the predetermined period has expired, the authorized user device 1841 loses permission to view the watermarked document 1843. In other embodiments, the watermarked document 1843 cannot be accessed by any device after it has been marked as read. In yet other embodiments, the watermarked document 1843 can be read by a second authorized user device after the authorized user device 1841 marks the document as read.

[0193] In some embodiments, comparing the first safety tag 1813 with the safety tag image received from the second user device 1831 may include generating a perceptual hash of the first safety tag 1813, generating a perceptual hash of the safety tag image received from the second user device 1831, and determining that a difference between the stored perceptual hash and the generated perceptual hash meets a threshold criterion, which may include a determination. In other embodiments, comparing the first safety tag 1813 with the safety tag image received from the second user device 1831 may include generating a perceptual hash of the safety tag image received from the second user device 1831, selecting the first safety tag using a difference between the generated perceptual hash and a stored perceptual hash of the image of the first safety tag, generating a second perceptual hash of a predetermined segment of the safety tag image received from the second user device 1831, and selecting the first safety tag 1813 from the first safety tags using a difference between the generated second perceptual hash and a stored second perceptual hash of the predetermined portion of the image of the first safety tag.

[0194] In some embodiments, the verification request of step 1805 may include a verification request identifier. In this embodiment, providing the document to the first device 1821 in step 1807 based on the comparison may further include generating a second secure tag paired with the request that encodes the verification request identifier using a selection of the latent tag feature options, and watermarking the document 1811 with the second secure tag. In these embodiments, the watermarked document 1843 does not include the watermark of the first secure tag 1813.

[0195] In some embodiments, the method 1800 may further include determining that receipt of the security tag image satisfies an authentication criterion. In certain aspects, the authentication criterion may relate to some verification request associated with the first security tag 1813. In other aspects, the authentication criterion may relate to the amount of time elapsed since the first security tag 1813 was provided to the first device 1821. In yet other aspects, the authentication criterion may relate to the geographic origin of the verification request. In still other aspects, the verification request may include a verification request identifier, and the authentication criterion may relate to the verification request identifier. In these aspects, the authentication criterion may be satisfied if the access identifier of the access request matches the verification identifier of the verification request.

[0196] Method 1800 can be used when there is an additional level of security required for a document. For example, a bank can use method 1800 to ensure the security of a particular document. The bank can create a tag that is paired with a document related to a customer's account. The customer can request access to the document from their laptop. The bank sends the security tag associated with the document to the customer's laptop. The customer can then scan the tag with their mobile phone and send the scan back to the bank. The images are then compared, and if the image matches the provided security tag, access to the bank's document is granted.

[0197] FIG. 19 illustrates an exemplary variable secure tag. The variable tag can be digitally animated over time by morphing the glyph and tag. For example, initially, the variable tag may be in the form of a series of dots with no tag features added, or an invalid frame 1901. The invalid frame 1901 can change over a period of time to become a valid frame 1903. The valid frame 1903 can be read by an appropriate reading device and return data. In some embodiments, the variable tag can be authenticated by a single frame of the variable tag process. In other embodiments, the variable tag can be authenticated by being authenticated by several frames of the variable tag process. In still other embodiments, authentication can occur only based on the order in which the frames appear in the variable tag process. In other embodiments, the invalid frame 1901 can include a "junk tag," or a type of tag that appears valid but does not return information. The variable tag can be read by any type of reading device, such as a camera.

[0198] In some embodiments, the variable tag process may be triggered by a rollover or click event. In these embodiments, the tag is static before the trigger event and enters the variable tag process after the trigger event. In other embodiments, the tag can be set to enter the variable tag process during a specific time frame. For example, the tag can be set to change between 8:00 PM and 8:00 AM to enhance tag security at night. In still other embodiments, the variable tag includes a valid frame 1903 that is paired with another valid frame. In these embodiments, the user may need to scan both paired frames to authenticate the tag.

[0199] A system for generating a variable safety tag may include at least one processor and at least one non-transitory memory including instructions that, when executed by the at least one processor, cause the system to perform operations that may include generating a first safety tag encoding as a selection of tag feature options responsive to values ​​of the tag data; receiving a request from a scanner of a second device, the request including a sequence of tag images including a first tag image; authenticating the request using the first safety tag and the first tag image; and providing an indication of authentication of the request.

[0200] In some embodiments, the operations may further include providing instructions to display a sequence of tags on a display of the first device, the sequence of tags including the first secure tag shown in the valid frame 1903. In some aspects, the instructions provided for displaying a sequence of tags including the first secure tag shown in the valid frame 1903 may include embedding the sequence of tags in a digital product. In other aspects, the instructions may provide for displaying the sequence of tags on a display of the first device in response to a trigger. The trigger is an event caused by a user or a predefined event. In either aspect, the displayed sequence of tags includes the invalid frame 1901 and the valid frame 1903.

[0201] In some embodiments, authenticating the request may include comparing one or more perceptual hashes of the first secure tag displayed in the validity frame 1903 with one or more corresponding hashes of the first tag image. In other embodiments, authentication may further require matching multiple secure tags to multiple corresponding tag images according to a predetermined order of appearance. In yet other embodiments, the indication of authenticating the request may include at least some of the tag data. In yet other embodiments, the indication of authenticating the request may include decoding instructions for decoding at least some of the first tag data. In yet other embodiments, the indication of authenticating the request may include status information retrieved from a database. In certain aspects, the database may be a distributed database, and Oracle may be used to retrieve the status information from the distributed database.

[0202] FIG. 20 illustrates an exemplary system 2000 for inventory management using a database, consistent with disclosed embodiments. While described below as being executed by client systems associated with different entities in a supply chain, system 2000 can be executed in some embodiments by authentication system 115, person system 120, or another system. In some embodiments, manufacturing system 2001 can be configured to provision a database (e.g., database 130) with status information for security tags. In some aspects, manufacturing system 2001 can be configured to update the status of accounts 2010 in the database with status information about security tags or items labeled with security tags. Manufacturing system 2001 or another system can be configured to provide application keys to carrier system 2003 and retailer system 2005. These application keys enable carrier system 2003 and / or retailer system 2005 to update or change the status of accounts 2010. Alternatively or additionally, the status of accounts 2010 in the database can include rules governing access to the account. In some embodiments, customer system 2007 can lack an application key. Thus, in some embodiments, customer system 2007 may have a default level of access to the database. For example, customer system 2007 may have read-only access to the status information listed in account 2010.

[0203] A client device can scan a secure tag associated with the account 2010. Scanning the secure tag can cause the client device to interact with the authentication server 115 to decode the secure tag. In some embodiments, the client device can be configured to provide authentication information (e.g., an application key or authentication credentials) and update information to the authentication server 115.

[0204] In some embodiments, using the information decoded from the secure tag, authentication server 115 may be configured to update account 2010. In some aspects, authentication server 115 may be configured to provide the address of the account in the update information to Oracle. Oracle may then write the update to account 2010. In some embodiments, authentication server 115 may be configured to provide the information to a personal database. The personal database may be configured to collect the updates and periodically write them to the database.

[0205] In various embodiments, using information decoded from the secure tag (e.g., the address of the account 2010 in database 130), authentication server 115 can be configured to retrieve information from account 2010. In some aspects, authentication server 115 can be configured to provide a request for state information to an oracle. The request can include the address of the account. The oracle can read the state of account 2010 to retrieve the state information. The state information is communicated to the client device (directly or via one or more oracles and authentication servers).

[0206] In some embodiments, authentication server 115 can be configured to provide information for reading or writing to a database. For example, authentication server 115 can be configured to decode the address of account 2010 in database 130 and provide the address to a client device. The client device can contact the oracle to provide updates or read information. In such embodiments, the oracle can be configured to restrict access to account 2010 based on an application key received from the client device or rules stored in account 2010.

[0207] Consistent with disclosed embodiments, a client device associated with manufacturing system 2001 can scan the safety tag. For example, when an item labeled with the safety tag leaves a manufacturing facility associated with manufacturing system 2001, a worker can scan the safety tag using a client device. Manufacturing system 2001 can be configured to use system 2000 to update account 2010 with information regarding the production of the item. In some embodiments, manufacturing system 2001 can subsequently access a portal to read the information stored in account 2010 regarding the safety tag. For example, when manufacturing system 2001 accesses system 2000 using an application key or credentials associated with the manufacturer (via authentication server 215 or Oracle), manufacturing system 2001 can obtain status information including at least one of tracking information, sales information, customer data, usage information, activity information, or location information.

[0208] A client device associated with distribution system 2003 can scan the security tag, consistent with disclosed embodiments. For example, a worker can use a client device to scan the security tag when receiving an item labeled with the security tag for transfer. Based on this scan, distribution system 2003 can be configured to use system 2000 to obtain status information regarding at least one of authentication information, destination information, or manufacturer information. Distribution system 2003 can be configured to use system 2000 to update account 2010 with information regarding the distribution of the item. In some embodiments, distribution system 2003 can subsequently access a portal to read information stored in account 2010 regarding the security tag. For example, if distribution system 2003 accesses system 2000 using an application key or credentials associated with a wholesaler (via authentication server 215 or Oracle), distribution system 2003 can obtain status information regarding at least one of authentication information, destination information, or manufacturer information.

[0209] A client device associated with retailer system 2005 can scan the security tag, consistent with disclosed embodiments. For example, a worker can use a client device to scan an item labeled with the security tag when it is received from a wholesaler. Based on this scan, retailer system 2005 can be configured to use system 2000 to obtain status information regarding at least one of authenticity information, transaction information, product information, or tracking information. Retailer system 2005 can be configured to use system 2000 to update account 2010 with information regarding the receipt or sale of the item. In some embodiments, retailer system 2005 can subsequently access a portal to read the information stored in account 2010 regarding the security tag. For example, if retailer system 2005 accesses system 2000 using an application key or credentials associated with a distributor (via authentication server 215 or Oracle), retailer system 2005 can obtain status information regarding at least one of authenticity information, transaction information, product information, or tracking information.

[0210] Consistent with disclosed embodiments, the client device 2007 can scan a secure tag. In some embodiments, the client device 2007 may lack an application key or authentication certificate. In such embodiments, the system 200 may provide relatively little information about the item labeled with the secure tag 105. For example, the client device 2007 may be able to obtain at least one of authenticity information, product information, or ownership information.

[0211] As described herein, the account state can store status information including tracking information, sales information, customer data, usage information, activity information, location information, authenticity information, destination information, updated manufacturer information, transaction information, product data, or proof of ownership information for secure tags. The particular allocation of access to this information among manufacturers, distributors, retailers, and customers is intended to be exemplary and not limiting.

[0212] FIG. 21 illustrates an exemplary system 2100 for modifying secure tag information in a database, consistent with disclosed embodiments. While described below as being performed by a client system, system 2100 can be performed in some embodiments by authentication system 115, personal system 120, or another system. As discussed above with respect to FIG. 20, the system can access the database during an interaction involving the secure tag or using a portal to read and write information about the state of the secure tag. As shown in FIG. 21, a user with a privileged account (e.g., indicated by a privileged application key or authentication credentials) can access the database to update state information and cancel the tag, potentially invalidating it for future use or transactions. For example, if user 2103 later attempts to perform an action using the tag, authentication server 115 can indicate that the tag has been canceled and refuse to identify the tag, authenticate the tag, or perform the action.

[0213] FIG. 22 illustrates a process for tracking inventory using secure tags. As shown, two shoes can be tied together using paired tags (e.g., tags 2201 and 2203), as described with respect to FIGS. 16A and 16B. Shoes can be paired with the shoebox containing the shoes by labeling the shoebox with tag 2205, which is paired with each of tags 2201 and 2203. Shoebox box tag 2207 can be paired with tag 2205. Shipping container tag 2209 can be paired with shoebox box tag 2207. Retailer tag 2211 can be paired with shipping container tag 2209. Transfer of ownership to a customer can be associated with the generation of tag 2213, as described below with respect to FIG. 23. In some embodiments, tag 2213 can be paired with individual shoe tags 2201 and 2203. Throughout this inventory tracking process, the accounts associated with the described tags can be updated with tracking, location, and other status information as described with respect to Figures 20 and 21. As shown, information in the accounts of retailer-controlled tags (in retailer control loop 2203) is accessible to at least the retailer, while information in the accounts of tags 2201, 2203, and 2213 is accessible to the customer.

[0214] FIG. 23 illustrates the process of transferring ownership of an item using a safety tag. The tag verification process involves pairing a uniquely generated digital safety tag with an original manufacturer's safety tag 2301. In some embodiments, a product is received by a seller with the original manufacturer's safety tag 2301. The manufacturer's safety tag 2301 is recorded in the seller's system and associated with the product online. Potential customers can view the product online. Each potential customer is presented with a uniquely generated tag that includes secondary data that, when scanned, can authenticate the product. Each uniquely generated tag is paired with an original manufacturer's safety tag 2301. For example, a potential purchaser is presented with a unique safety tag 2303. The unique safety tag 2303 resembles the original manufacturer's safety tag 2301 but includes unique secondary data. Furthermore, the unique safety tag 2303 is paired with the original manufacturer's safety tag 2301. Thus, a user can verify the authenticity of the product while maintaining the unique safety tag 2303, which may include information regarding the date and time of viewing the product. In other embodiments, potential user 2 can be presented with unique safety tag 2 (2305), potential user 3 can be presented with unique safety tag 3 (2307), potential user 4 can be presented with unique safety tag 4 (2309), and potential user 5 can be presented with unique safety tag 5 (2311). In each embodiment, the unique safety tag is paired with the original manufacturer's safety tag 2301.

[0215] In some embodiments, when a product is purchased by a buyer, the seller can assign the original manufacturer security tag 2301 to the buyer. In other embodiments, the original manufacturer security tag 2301 can be automatically assigned to the buyer at the time of purchase. In either embodiment, the purchase and subsequent assignment of the original manufacturer tag 2301 is updated on the blockchain. Following the purchase and assignment, additional unique security tags may be generated and paired with the original manufacturer tag 2301. In certain aspects, the purchase can be communicated to a potential customer via the paired unique security tag. For example, the pairing of the original manufacturer security tag 2301 and the unique security tag can be removed. In another example, the unique security tag can communicate the purchase to a potential customer via updated information on the blockchain.

[0216] FIG. 24A illustrates an exemplary secure tag. A secure tag can include various technical components. For example, the technical components include a validation fragment, outer and inner borders, border sections, border blocks, dots, glyphs, connectors and splines, Laava Stage 1 ID, center graphic, center graphic public, key, and additional technical features described in more detail below. Additionally, the technical components can be used to encode data in various formats. The technical components are described in more detail below.

[0217] The central graphic can be a graphic, brand, or other visual, and can be an end-user identifiable element that also contains fingerprinted data. In some embodiments, the central graphic can be used to orient the secure tag. In other embodiments, the central graphic can be a glyph set that can contain data. For example, the central graphic can include a smaller fingerprint signature than larger tags and, if desired, can include 128 characters of information in readable text. In still other embodiments, the central graphic can be used to display branding. In such embodiments, the central graphic can be any shape and can have a color. The central graphic can be further surrounded by a contrasting line to separate it from the rest of the tag. In some embodiments, the line can be required to have a specific thickness.

[0218] The central graphic public key can be a hashed SHA2 version of the central graphic, typically a large generated number. As explained in more detail below, the central graphic public key can be used to unlock other parts of the tag. The Laava Stage 1 ID can be a manufacturer ID and public key, allowing the tag to be identified before data can be read. The glyph is typically a generated individual shape or character within the tag, where most data, keys, IDs, etc. are stored. The outer frame is the outer border of the security tag and defines the shape for scanning. The outer frame also allows for additional functionality and data storage. The inner frame can be an optional border on the inside of the security tag that surrounds the central graphic and can be used to visually separate the glyph from the central graphic. Additionally, the inner frame can be used to fingerprint the central graphic and contain data.

[0219] A validation fragment can be a specific set of image data and can be used for validation, comparison, and data storage. A validation fragment can contain multiple elements, such as a central graphic or other variable elements. A dot can be a point on a security tag where the white space becomes a visible shape or circle. A dot can store multiple data elements to define a tag and is the starting point for forming a glyph. Splines and connectors can be shapes that join or blend two or more dots, allowing for large amounts of data storage and strong encryption or encoding. An outer frame section is an identified portion of the outer frame that can be used to store or repeat data. An outer frame block is a collection of breaks in the outer frame section that can be used to store data.

[0220] Figure 24B shows a portion of a graphics file corresponding to an exemplary security tag. The graphics file represents the exemplary security tag shown in Figure 24A. The graphics file is created during the tag generation process, which is described in more detail below.

[0221] FIG. 25A shows secure tags 2501, 2503, and 2505, each generated using the same style sheet but different data. The style sheet provides a tag template for the first step of secure tag generation. In some embodiments, the style sheet describes the class of the secure tag. Following receipt of the style sheet, the tag generation process receives a numeric seed, generates a secure tag layout, and receives tag data, all of which then generate the final secure tag. The style sheet and numeric seed provide locations where data can be encoded. The data is then encoded as tag feature options. In FIG. 25A, secure tags 2501, 2503, and 2505 were all generated using the same style sheet in the first step of the secure tag generation process, but different data was provided before the final secure tag was generated. During the tag generation process, the tag generation system can select from the same primary and secondary locations based on the style sheets for secure tags 2501, 2503, and 2505, resulting in similarities between the secure tags. After the layout of each exemplary secure tag is created, data is encoded into tag feature options to create a unique design.

[0222] FIG. 25B shows safety tag 2511, safety tag 2513, and safety tag 2515, each generated using a different style sheet but the same tag data. As previously described, style sheets are used in the first step of the tag generation process. Safety tags 2511, 2513, and 2515 each began the tag generation process with different available primary and secondary locations. As with the previous example, data is encoded after the primary and secondary locations are identified and selected. Because data can be encoded into various tag features and the tag generation algorithm generates randomized designs, the same tag data can ultimately result in significantly different safety tag designs. Safety tags 2511, 2513, and 2515 all return the same data when scanned, but each safety tag has its own unique design.

[0223] Figures 26A-26P show details of potential secure tag features, each of which is described in more detail below.

[0224] FIG. 26A illustrates potential features of an exemplary secure tag. Each potential feature can be used to encode data or create a fingerprint. The potential features are: primary interior dot, exterior break, interior break, interior edge blend, exterior horizontal blend, interior frame, owner ID, secondary interior dot, interior horizontal blend, exterior frame, exterior blend, short blend, secondary exterior dot, interior deformation, exterior deformation, knot, and long blend. Each of these potential features can be used to encode information, as described in more detail below. Additional variable assets can be used to embed additional data or encrypt information. For example, variable assets can include indents, indentations, colored shapes, gradients, connecting lines, and embedded symbols.

[0225] In some embodiments, the security tag may include additional features to authenticate the product or store information. For example, a background pattern or texture can be subtly or invisibly placed behind the tag. Similarly, in another example, an adjacent pattern or texture can be used to provide additional authentication or store information. In another example, a Penrose tiling graphic pattern can be used to fingerprint or distinguish a particular set of tags. In yet another example, adjacent information, such as a unique set of words, can be placed near the tag. Such a design is useful when human-readable identity verification is required, for example, for customer support.

[0226] 26B shows an example tag showing a position vector 2601. The position vector 2601 discloses the final positions of the dots and shapes in the example security tag after the layout and any displacements of the dots and shapes have been determined. The position vector 2601 provides information about the location of each shape, dot, and tag feature of the security tag.

[0227] FIG. 26C illustrates an example of offset dot alignment. As disclosed above, the layout of an exemplary security tag may be determined following receipt of a style sheet describing the security tag's class and numeric seed. Layout position 2603 illustrates the location of an exemplary dot after the security tag layout is generated. Upon receipt of tag data, the security tag is generated as a tag feature option. Specific tag feature options include the placement and arrangement of dots and shapes. Displacement position 2605 illustrates the final location of an exemplary dot after the tag data is encoded as a tag feature option. The difference between layout position 2603 and displacement position 2605 may be indistinguishable to the human eye, making such tags difficult to copy. Tag generation systems are designed to make the grid much less predictable than a standard grid. In some embodiments, resolution allows for adjustment of displacement position 2605 from layout position 2603 based on grid offset, line length, angle, etc. In such embodiments, these adjustments may enable additional information to be encoded into the tag.

[0228] 26D illustrates an exemplary security tag showing connect the dots option 2608. The connect the dots option 2608 can extend any distance within the outer perimeter of the security tag to reach other dots. In some embodiments, the connect the dots option 2608 can be established as a line as the dots. The connect the dots option 2608 cannot pass through the central image to reach another dot.

[0229] Figure 26E shows the connect dots function option 2608 after the data has been encoded to create the splines and edge connections. The shapes formed through the splines are called glyphs. As explained above, glyphs can be the individual shapes or characters generated within the tag and can be where most data, keys, IDs, etc. are stored. In some embodiments, spline mathematics can be used to include encrypted or encoded information. For example, elliptic curve cryptography can be used. Edge connections can also be used to store data.

[0230] Figures 26F and 26G show dots and connectors as vectors for the same example tag layout. The security tag is generated in vector format and defined in terms of 2D points, including connecting lines and curves. The vectors in these images show the origin of a variable spline and spline thickness, or connector, that can be used to encode data. Figure 26F shows a first connection width 2607, and Figure 26G shows a second connection width 2609. The first connection width 2607 is shown as being larger than the second connection width 2609. The first connection width 2607 and the second connection width 2609 can be encoded with the same or different data.

[0231] 26H shows an example tag showing edge connection feature option 2610. Edge connections can be formed from potential edge connector feature option 2610. Edge connector feature option 2610 provides the possibility to form an edge connection between an inner frame or an outer frame. Selecting edge connector feature option 2610 to convert to an edge connection allows data to be encoded into the shape. For example, an edge connection can be encoded with data used to represent a manufacturer number.

[0232] Figures 26H and 261 show dots and edge connections as vectors for the same exemplary tag layout. The vectors in these images show the origin and thickness of variable edge connections that can be used to encode data. Figure 261 shows a first edge connection size 2611, and Figure 26H shows a second edge connection size 2613. The first edge connection size 2611 is shown as being larger than the second edge connection size 2613. The first connection size 2611 and the second edge connection size 2613 can be encoded with the same data or different data.

[0233] FIG. 26J illustrates various glyphs and potential spline features for an exemplary security tag. Glyph sets can be generated using multiple splines and placed within a flexible coordinate system. In some embodiments, glyphs can be mathematically generated using a blend curvature algorithm. In other embodiments, glyphs can be generated based on a predetermined shape. For example, a customer may request a glyph with a specific shape based on their product or service. In this example, the glyph set can be clearly identified and specifically designed. The thickness of the glyph splines varies based in part on the starting position of the spline for each dot. In some embodiments, glyphs can be formed between any number of dots. Data can be included around the glyph as a microstructure or within an algorithmic approach that stores data in a path. FIG. 26J illustrates only a limited number of possible glyph and spline features.

[0234] 26K shows a first ring deformation 2615, a second ring deformation 2617, and a third ring deformation 2619, all of which can be used to encode data. The first ring deformation 2615 can include a deformation on the inner edge of the outer frame. The second ring deformation 2617 can include a deformation on the outer edge of the inner frame. The third ring deformation 2619 can include a deformation on the outer edge of the outer frame.

[0235] FIG. 26L shows microdots 2621 and microprinting 2623, both of which can be used to encode data. The microprinting 2623 can include a second binary data set, which can be interpreted in a similar manner to the outer frame and outer frame breakage data. At low resolutions, the microprinting 2623 may appear as noise. At higher resolutions, the microprinting 2623 can include information about the grid location of the fingerprint data. The information can include an X or Y grid number and an offset value. In some embodiments, with enough microprinting 2623, the tag can be encrypted. In other embodiments, the microprinting 2623 can include different colors. In such embodiments, the microprinting 2623 can store additional information in the same physical space. In still other embodiments, the outer frame can include microprinting 2623 both inside and outside the lines. In such embodiments, both the inner and outer microprinting 2623 can be colored. In other embodiments, the microprinting 2623 can store additional binary data by varying the height of the blocked sections. In such embodiments, the binary code can be difficult to copy due to its small physical size. The micro-printing 2623 can be used for advanced data storage and can be accessed by very high resolution cameras.

[0236] Figure 26M shows the same location with three different gradient color fills: no fill 2625, filled with a different color 2627, and filled with the same color 2629. Data can be encoded into the security tag based on the gradient and color of the location.

[0237] FIG. 26N shows an example tag feature 2631 and the data encoded therein. Tag feature 2631 shows two dots connected by a connection, or two bits connected by a third bit, along with a detail region 2633 containing the encoded data. Detail region 2633 may include a spline that wraps around one edge of the dots. Detail region 2633 can be read by moving in a read direction 2637 from a start position 2635. Detail region 2633 may have a first spatial frequency that may encode 3 bits of data (value A) and a second spatial frequency that may encode 18 bits of data. Value A set bit 2639 represents a 1 at the first spatial frequency, and value A unset bit 2641 represents a 0 at the first spatial frequency. Value B unset bit 2645 represents a 0 at the second spatial frequency. There are 3 bits and 18 bits of encoded data followed by 2647 repetitions.

[0238] 27A-27K illustrate the creation of an exemplary secure tag, each of which is described in more detail below.

[0239] Figure 27A shows an exemplary grid used as a base in the process of generating a security tag. The grid comprises potential primary locations 2701 and potential secondary locations 2703, which are the base for glyphs 2705. Formation of the grid is the first stage in generating a security tag, and a specific algorithm is used to create a randomized design. The potential primary locations 2701 and potential secondary locations 2703 determine the final location and shape of the glyphs 2705. The glyphs 2705 can span any number of potential primary locations 2701 and potential secondary locations 2703.

[0240] Figure 27B shows selected primary locations 2707 and unselected primary locations 2709. At this stage in the tag generation process, potential primary locations 2701 are identified and selected. The tag generation algorithm randomly selects a predetermined number of potential primary locations 2701. The selected primary locations 2707 are then used further in the secure tag generation process, while the unselected primary locations 2709 are no longer part of the tag generation process. In Figure 27B, there are 26 selected primary locations 2707 that were randomly selected, resulting in one of 7.2 billion possible combinations.

[0241] Figure 27C shows the identification of potential secondary positions 2711. Potential secondary positions 2711 may include any secondary positions located between selected primary positions 2707. In Figure 27C, 40 potential secondary positions 2711 have been identified, resulting in approximately 1 trillion possible subcombinations.

[0242] 27D shows an unselected secondary location 2713 and a selected secondary location 2715. The selected secondary location 2715 is selected from previously identified potential secondary locations 2711. The selected secondary location 2715 is selected by the system based on a tag generation algorithm and may be used to connect the selected primary location 2707 to a separate selected primary location 2707.

[0243] FIG. 27E shows a secondary grid showing selected primary locations 2707 and selected secondary locations 2715 just before and after processing through a visualization engine in the process of safety tag generation. The secondary grid including selected primary locations 2707 and selected secondary locations 2715, or the final secondary grid, can be passed to the visualization engine for further safety tag generation. Certain selected primary locations 2707 are bridged by selected secondary locations 2715. The selected secondary locations 2715 are used to create connections between selected primary locations 2707, generating glyphs. In some embodiments, the curved shapes on each glyph may contain data. Based on the shape build, additional code variations can be introduced into the structure. Selected primary locations 2707 not bridged by selected secondary locations 2716 can remain as individual dots. In some embodiments, the dots may contain data.

[0244] Figures 27F-27I show different possible glyphs 2717 based on a selected primary location 2719 and a selected secondary location 2721. In each figure, the tag generation algorithm may have identified any of the secondary locations as potential connectors. Each figure shows different possible glyphs 2717 based on a selected secondary location 2721. Figures 27F and 27H both show a glyph 2715 with a selected primary location 2719 connected to at least one but no more than three selected primary locations 2719, while Figure 27H shows selected primary locations 2719 connected in series. Figure 27G shows a glyph 2717 with a selected primary location 2719 connected to all selected primary locations 2719. In this figure, the selected secondary location 2721 causes the selected primary location 2719 to become a large circle or dot. Figure 27J shows a glyph 2717 with only three of the five selected primary locations 2719 connected by the selected secondary locations 2721. In this figure, the final tag includes a glyph 2717 and two individual dots. Each glyph 2717 in Figures 27F-27I can encode data.

[0245] 27J shows an example security tag with orientation information 2723. The orientation information 2723 may be located in the center of the security tag as a center image. The orientation information 2723 may be used in the tag identification process to allow an optical reader to properly identify the correct tag. In some embodiments, the orientation information may include a logo, brand, or other identifier.

[0246] 28A-28N show exemplary security tags, each of which is described in more detail below.

[0247] FIG. 28A illustrates safety tags in various form factors. The outer frame of the safety tag can be any shape. For example, a customer may request a tag designed to match a specific image. In this example, the desired image serves as both the safety tag and the trademark. In some embodiments, the safety tag may not have a central image. In these embodiments, the orientation of the tag can be achieved based on the design of the outer frame of the safety tag. In other embodiments, the central image may be a custom image provided by the customer. FIG. 28A illustrates examples of possible form factors, such as the shape of Australia or the Nike™ Swoosh.

[0248] FIG. 28B shows a series of example tags. Each of these tags has a symmetrical design and a series of dots with no connectors or splines. A typical safety tag generation process is highly unlikely to produce a symmetrical safety tag. However, the safety tag generation process can be controlled to produce aesthetically pleasing tags, such as the examples shown in FIG. 28B. In these examples, a design is selected and data can be encoded into the selected design.

[0249] FIG. 28C shows an example of a security tag integrated with a barcode. In some embodiments, the security tag can be read along with the barcode. In other embodiments, the security tag and barcode can be read separately. Integrating the security tag with the barcode can provide backward compatibility and unique identity for SKU-based barcode readers. The security tag can include matching data related to the barcode. This can prevent fraud or misuse of both the barcode and the security tag.

[0250] 28D shows an exemplary safety tag. In some embodiments, the exemplary safety tag can have a central image overlaid on a colored or black background. In other embodiments, the safety tag may not have an internal frame. In still other embodiments, the safety tag can have an internal frame that is a different shape than the external frame.

[0251] FIG. 28E shows an exemplary security tag with a symmetrical pattern and a Laava central image.

[0252] FIG. 28F shows an exemplary security tag with a symmetrical pattern and a larva center image.

[0253] FIG. 28G shows an exemplary square security tag with a symmetrical pattern and a larva center image.

[0254] FIG. 28H shows an exemplary square security tag with a symmetrical pattern and a larva center image.

[0255] FIG. 28I shows an exemplary security tag without a central image and without connectors between the dots.

[0256] FIG. 28J shows an exemplary square security tag with a Laava center image and no connectors between the dots.

[0257] FIG. 28K shows an exemplary security tag with a Laava center image and a narrow thickness connector.

[0258] FIG. 28L shows the Laava center image and an exemplary square security tag with a narrow thickness connector.

[0259] FIG. 28M shows an exemplary security tag with a symmetrical pattern and a larva center image.

[0260] FIG. 28N shows an exemplary square security tag with a symmetrical pattern and a larva center image.

[0261] FIG. 29A illustrates an exemplary user interface for managing safety tags. In FIG. 29A, a dashboard tab displays safety tag activity over a 24-hour period. In some embodiments, the dashboard of the user interface can provide information including an overview of all safety tags for a single customer, the number of safety tags by location, associated user information, and associated reseller information. The user interface includes various tabs available for user interaction. These tabs include tag management, tag design, tag printing, reports, statistics, account information, API setup, user management, etc.

[0262] Figure 29B shows an example user interface for requesting a safety tag design. The tabbed user interface can provide the user with various options for creating a safety tag. For example, the user has the option to select whether nested safety tags are required and whether the safety tags should be paired. Other potential customizable options include a customer center logo, encrypted IDs, custom DB synchronization, whether the safety tag is user-readable, whether to obfuscate the IDs, offline readability, whether to embed a location, whether to allow resellers access to each included ID, whether to use the Laava blockchain, and whether the safety tag is killable. In Figure 30B, the user has selected four layers of nested tags, with the top layer being paired. Each layer of the safety tag can contain different information. In this example, the user has control over the information each layer can provide and the key required to access each safety tag.

[0263] In some embodiments, system 100 (e.g., authentication server 115 or personal system 120) may be configured to identify one or more security tags as unauthorized copies of authorized security tags. System 100 may be configured to index information about these unauthorized copies and generate reports containing information about the unauthorized copies. For example, system 100 may be configured to generate a heat map displayable by the user interface of FIGS. 29A and 29B that shows where and how frequently unauthorized copies of security tags have been detected.

[0264] Exemplary Use Cases

[0265] Safety tags can be used to assist both customers and retailers in the sale and purchase of products such as alcohol. Before purchase, customers can verify the authenticity of alcohol, such as a wine bottle, and receive information about the wine bottle, such as the previous owner, retailer, manufacturer, production date, ingredients, instructions for use, safety warnings, and other related information. Before the sale, retailers can scan the tag to verify the information. Information can include confirming arrival through logistics, viewing retailer offers from the vineyard, viewing manufacturer and production data, viewing wine bottle inventory, viewing ingredients, viewing customer sales notes, determining store locations, setting return policies, setting per-bottle offers, setting lucky wins that occur with the purchase of a bottle, viewing safety warnings, viewing instructions for use, and other related actions. At checkout, retailers can transfer ownership of the wine bottle to customers, who can use the safety tag to access additional benefits (e.g., reorders, reviews, etc.). In some embodiments, the wine bottle can have a second safety tag location inside the wine bottle cap for additional authenticity after opening the bottle, which can be paired with the safety tag on the exterior of the wine bottle.

[0266] Safety tags can be used to authenticate web pages, emails, or other digital products. For example, a web page can have a unique safety tag on every page that acts as a digital token used to authenticate the web page itself. The safety tag can change after a predetermined period of time. The tag also terminates when it is displayed or times out. A user can authenticate a web page, email, etc. using a browser that scans the safety tag itself, using a secure plug-in, or using an optical reader such as a smartphone. The safety tag can be used to verify the delivery date and time, the website or email provider, security information for the web page or email, or other information specific to the web page or email.

[0267] Multiple forms of membership can be managed within a single secured tag that a customer owns and pairs or shares with authorized businesses. Customers can have various forms of ID and / or memberships, such as health insurance cards, student IDs, fitness memberships, travel memberships, etc., that can be encoded into a single personal physical or digital secure. Like tag. Each business associated with an encoded form of ID or membership can be granted access to check the secure tag for only the specific ID or membership associated with it. Thus, a customer can present the same single secure tag in each situation instead of carrying multiple forms of ID.

[0268] Secure tags can be used to create authenticated, protected personal identities that can be used both online and offline. Users bring their official ID (e.g., credit card, passport) to a relevant institution (e.g., bank, passport office), where the ID is verified and the verified ID supplier is connected to the user's personal ID blockchain. The authenticated, protected personal ID can be read by appropriate authorities and used for elections and voting, bank statement push, secure messaging, secure email, building entry, membership, age proof, and other applications where personal identification is required. The protected ID is owned by the user, but the relationship is paired with the official ID issuer, which can revoke the ID.

[0269] Businesses can use secure tags to create authenticated personal IDs for their customers. For example, a business such as a bank can provide a customer with both a personal ID associated with that user's account and a reading device with specific permissions (e.g., using an app specific to that business). A physical or digital document containing that customer's specific information can include a tag that can only be read by a user with the correct personal ID associated with the document. If a user has the correct personal ID associated with the document, they are granted access corresponding to the level authorized by the personal ID. Furthermore, the authenticated personal ID can be used to verify the customer at an automated teller machine, bank, etc. The business can receive notifications when a user without the correct personal ID scans a document or when the personal ID cannot be used to verify the customer.

[0270] Security tags can be used to authenticate art and other valuable items, potentially allowing artists to capture revenue from ongoing / future sales. A security tag can be affixed to the original artwork and paired with both a second security tag representing ownership and a third security tag retained by the artist. Both the artwork security tag and the second security tag representing ownership can contain information about the art itself, the current owner, the artist, and the art dealer, and both are required for the sale and transfer of ownership. The artist can retain the paired tag and be notified upon transfer of ownership, potentially including a portion of the proceeds from the transfer of ownership. In some embodiments, art can be verified by proximity fingerprinting, for example, using the wood grain pattern on the art frame in proximity to the tag. Because proximity fingerprinting is invisible to the customer, moving the tag may not verify it and therefore may not prove authentic.

[0271] Other valuable products with very specific requirements, such as infant formula, can be authenticated using safety tags. Formula can contain both an external and an internal safety tag. The external tag can contain important information such as: instructions for use, manufacturer ID, market information, safety information, or any other relevant information that can be scanned by any potential customer. Once infant formula is purchased and ownership is transferred, the owner has access to the information contained on the internal safety tag. The internal safety tag is typically paired with an inventory or retailer ID via a pallet or shipment ID, allowing the customer access to complete supply chain information about the specific infant formula they purchased.

[0272] Safety tags can be used to track lost items and return them to their owners. Users can print their own or purchase safety tags in various form factors that contain information about the owner. Safety tags can be paired with a Lost and Found account through the app or another program and attached to an item. The tag owner receives a notification each time the tag is scanned, including information about the scan, such as the time and location. The owner can choose whether to disclose certain information, such as how to contact the owner or how to return the item, if someone else scans the tag.

[0273] Warranty and insurance registration can be handled using the secure tag. A customer can authenticate the vehicle through the blockchain and purchase the vehicle. Title is then transferred to the customer, the customer is registered for warranty, and the vehicle is officially registered to the customer in the appropriate database (e.g., DMV). The customer's insurance company can match the vehicle data with the customer ID of a recently purchased vehicle. Once the customer ID is verified, insurance can be issued.

[0274] Security tags can be used to authenticate casino chips or other gambling chips. Each chip is given a security tag that can be paired with the RFID ID embedded in the chip. The security tag / RFID combination can be managed on the blockchain, allowing casinos to track each chip in various ways. Users can also check the security tag with their own reader to ensure they have a legitimate chip in their hands. Additionally, the unique tag on the chip acts as a visual deterrent to creating spoofed tags.

[0275] Lotteries and other promotions can be managed using secure tags. A company can create a ticket on the blockchain. A customer can then purchase a digital or physical ticket that is associated with the ticket on the blockchain and reveal the ticket's tag. The ticket can then be scanned and the customer can receive information about whether they won or lost, and the results of the win or loss can be updated on the blockchain. In some embodiments, the ticket can be a tag that can be scanned to reveal basic information about the lottery company, retailer, etc. before purchase, or a tag with a portion that can be scratched off to reveal a new tag that the current owner can scan to reveal the win or loss results.

[0276] Secure tags can be used to deliver promotional ads to specific customers. A customer can be served a promotional ad online that includes a specific tag unique to that customer. The customer can then visit a website associated with the ad and print out a coupon with a secure tag that has specific ID and promotional data embedded in it. The customer can then visit a brick-and-mortar store to redeem the coupon, and the sale is associated with the digital cookie associated with the original ad.

[0277] Safety tags can also be used for general promotional activities. For example, a car company can create publicly advertised custom tags used to book vehicle giveaways or test drives. Safety tags are publicly available and can be scanned by anyone. Safety tags can be animated according to a set formula so that every view contains the required location, time, and other data, making each customer scan unique. Each scan is uploaded to the blockchain, allowing the company to set promotional rules for specific scans.

[0278] Physical cryptocurrency can be authenticated using a secure tag. A user can load cryptocurrency, such as "Bitcoin," onto a physical note that has a secure tag printed on it. The secure tag can be tied to a specific owner via an access key or made publicly available offline. The secure tag can be verified at a checkout station, and information about the transaction can be uploaded to the blockchain. In some embodiments, the secure tag can be paired with another form of identification, such as RFID.

[0279] Security tags can be used to control access to sensitive items, such as those used by the military or other private organizations. Private security tags can be created using information stored on a private blockchain. Designated personnel can be given various levels of access to scan and read tagged items. If an item is scanned by an unauthorized reader, data about the location, time, and user who scanned the tag is transmitted back to the private blockchain. If an unauthorized reader scans an item, an alarm or warning may be triggered that is directed to the security tag owner.

[0280] Meat, livestock, or other organic products can be verified using a security tag through proximity fingerprinting. For example, the "texture" of beef near the security tag can be fingerprinted along with the security tag at the point of packaging. The security tag can provide information about the cut of beef, the date of packaging, transportation, and other information important to purchasing perishable goods. To fully authenticate the product to the end user, the security tag and the texture must be scanned together. If the tag is moved, proximity fingerprinting will not verify the product as authentic.

[0281] Safety tags can be used to check and verify safety and inspection reports. When a unit or equipment is installed that requires inspection, the installer can create a safety tag for the entire unit or for individual parts, including information about the installation and manufacturer. Additional users with appropriate access can scan and update tags during inspections and safety assessments. When a new user scans a safety tag, they can receive information about the inspection history, replacement history, who previously scanned the tag, the date and time of the scan, warranty information, information about who provided the part, and any other information deemed relevant. Thus, inspection logs can be stored on the blockchain.

[0282] Security tags can be used to authenticate medications and prescriptions. For example, a doctor could place a unique security tag on every prescription page to prevent prescription theft. The doctor could scan the prescription when writing it out to authorize a specific patient to use it. When a pharmacy is refilling a prescription, they can check the security tag to verify that the doctor has indeed given permission to use the specific prescription page and that the right medication is being prescribed to the right person. In another example, security tags can be printed on medication packaging, blister packs, or even individual tablets themselves. In these examples, medications are matched to patients so that a doctor, nurse, or other authorized healthcare provider can access patient information when scanned. This provides evidence that medications are being taken as prescribed and helps ensure the right medication is provided to the right person.

[0283] Secure tags can be used to track and verify tax and expense reporting. Companies can provide employees with specific readers to scan receipts and invoices. Receipts and invoices can be printed with unique tags that can be scanned with readers designed specifically for this activity. Readers can be designed to give users the ability to scan only specific secure tags on receipts or invoices. Scanned expenses are stored on the blockchain and can be accessed in the future by the company or tax authorities to verify expenses and charges.

[0284] Users can create customized security tags in a variety of configurations. For example, a particular brand may want to have a tag designed with the same shape as their trademark. This allows for different packaging options and different levels of security. In some embodiments, the shape of the security tag can be fixed to a standard shape, but the central logo can be customized.

[0285] Safety tags can be used to eliminate gray products from the supply line. Genuine parts for specific equipment and vehicles can be labeled with a safety tag that contains information about the manufacturer and the type of equipment or vehicle the part is used in. In the future, engineers or technicians inspecting and replacing parts can scan the part to determine whether it is genuine and used in the correct way.

[0286] Safety tags can be used to identify and report counterfeit or fake products. Customers can scan a product's safety tag to see the manufacturer, authorized country of sale, authorized retailer, and more. If any of this information is off, customers can report the item as fake, including information about the location and time of the scan. The report is uploaded to the blockchain and the tag owner is notified. Additionally, because each safety tag is unique, if someone reports the same tag being scanned multiple times in multiple locations, the tag owner is automatically notified of the discrepancy.

[0287] Companies can use security tags to restrict the copying of products such as shoes. In this example, a copier gains access to a single shoe manufactured by a company with a legitimate tag and creates copies of the authentic tag to place on counterfeit shoes. The copier then sells the shoes to numerous buyers, claiming the product is genuine. Only the first scan authenticates the authentic product, and the scan must occur before the shoes are sold. If the tag reveals that this is not the first time the same tag has been scanned, the tag is reported as counterfeit and the customer is spared from purchasing a counterfeit product. If a legitimate customer does not scan the shoes first, the customer can authenticate the product with the company itself.

[0288] The disclosed embodiments may be implemented in a system, method, and / or computer program product, which may include a computer-readable storage medium having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0289] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, encoded devices such as punch cards or ridge structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transitory signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable) or an electrical signal transmitted over a wire).

[0290] The computer-readable program instructions described herein may be downloaded from the computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium within each computing / processing device.

[0291] The computer-readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, on the user's computer as a standalone software package, on a remote computer, or on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or from an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0292] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0293] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that the instructions, when executed by the computer's processor or other programmable data processing device, create means for implementing the functions / acts specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that causes a computer, programmable data processing device, and / or other device to function in a particular manner, such that the computer-readable storage medium includes a product containing instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0294] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0295] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a portion of a software program, segment, or code, including one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently. Or, if functionality is related, the blocks may be executed in the reverse order. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system or a combination of special-purpose hardware and computer instructions that performs the specified functions or acts.

[0296] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0297] During the life of the patent expiring from this application, many related virtualization platforms, virtualization platform environments, trusted cloud platform resources, cloud-based assets, protocols, communication networks, security tokens and authentication credentials will be developed, and the scope of all of these terms is intended to include all such new technologies a priori.

[0298] It will be appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or other described embodiments of the invention, as appropriate. Certain features described in the context of various embodiments should not be considered essential features of those embodiments, unless the embodiments are inoperable without those elements.

[0299] While the present invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims. Some aspects of the invention are described below. [Aspect 1] 1. An authentication server for interacting with a secure tag, comprising: at least one processor; when executed by the at least one processor, receiving a tag identification request including a tag image; identifying a secure tag in the received tag image using a stored hash of the secure tag image generated using the stylesheet; generating tag data using the received tag image and decoding rules for decoding tags generated using the stylesheet; at least one non-transitory memory containing instructions that cause the authentication server to perform operations including: An authentication server comprising: [Aspect 2] identifying the secure tag using the stored hash and the received tag image; generating a hash of the received tag image; determining that a difference between the stored hash and the generated hash meets a threshold criterion; 2. The authentication server of claim 1, [Aspect 3] 3. The authentication server of aspect 2, wherein generating the hash of the received tag image includes converting the received tag image into an image having a predetermined number of pixels. [Aspect 4] 4. The authentication server according to aspect 3, wherein the predetermined number of pixels is equal to or greater than 64 pixels and equal to or less than 1,048,576 pixels. [Aspect 5] 3. The authentication server of claim 2, wherein the hash is a perceptual hash. [Aspect 6] 3. The authentication server of claim 2, wherein the difference is a Hamming distance between the stored hash and the generated hash. [Aspect 7] the received tag image is a vector graphics file; 3. The authentication server of aspect 2, wherein generating the hash of the received tag image includes rasterizing at least a portion of the vector graphics file. [Aspect 8] Identifying the secure tag in the received tag image includes: generating a hash of the received tag image; selecting the first secure tag using a difference between the generated hash and a stored hash of an image of the first secure tag; generating a second hash of a predetermined segment of the received tag image; selecting the secure tag from the first secure tags using a difference between the generated second hash and a stored second hash of the predetermined portion of the image of the first secure tag; 2. The authentication server of claim 1, [Aspect 9] 2. The authentication server of aspect 1, wherein identifying the secure tag in the received tag image includes generating hashes of progressively smaller segments of the received tag image. [Aspect 10] Identifying the secure tag in the received tag image includes: generating a hash of the received tag image; generating a second hash of a first segment of the received tag image corresponding to a first predetermined segment of the secure tag; determining that a difference between the generated hash and a stored hash of an image of the secure tag does not meet a threshold criterion; selecting the secure tag using a difference between the generated second hash and a stored second hash of an image of the first predetermined segment of the secure tag; generating a third hash corresponding to a second predetermined segment of the secure tag; verifying the secure tag using a difference between the generated third hash and a stored third hash of an image of the second predetermined segment of the secure tag; 2. The authentication server of claim 1, [Aspect 11] 11. The authentication server of aspect 10, wherein the third hash is generated over a second segment of the received tag image that corresponds to the second predetermined segment of the secure tag. [Aspect 12] 11. The authentication server of aspect 10, wherein the third hash is generated over a second received tag image corresponding to the second predetermined segment of the secure tag. [Aspect 13] Identifying the secure tag in the received tag image includes: comparing a hash of an image of the predetermined segment of the security tag with hashes of segments of one or more received tag images comprising the received tag image, the segments of the one or more received tag images corresponding to the predetermined segment of the security tag; selecting the security tag based on the comparison; 2. The authentication server of claim 1, [Aspect 14] The comparison is a segment distance between the hash of the image of the given segment of the secure tag and the corresponding hash of a segment of the one or more received tag images; at least one of an overall distance using the segment distances or a count of segment distances that meet a threshold criterion; 14. The authentication server of embodiment 13, comprising: determining: [Aspect 15] 15. The authentication server of claim 14, wherein the operations further include determining a confidence value using the number of hashes of the image of the given segment of the secure tag, a count of segment distances that meet the threshold criteria, and the segment distances. [Aspect 16] the one or more received tag images a first image showing at least some of the tags at a first level of detail; a second image showing at least some of the tags at a second level of detail greater than the first level of detail; 14. The authentication server of claim 13, comprising: [Aspect 17] The operation is receiving the stored hash of the image from a personal system; providing a decode request to the personal system, the decode request including an identifier of the secure tag; further comprising 2. The authentication server of claim 1, wherein the decoding rules are received from the personal system in response to the decoding request. [Aspect 18] the tag identification request includes an authentication key; the decoding request includes an authentication key; the decoding rule corresponds to the authentication key; The authentication server according to aspect 1. [Aspect 19] the tag identification request is received from a client device; The operation is receiving public decoding rules for decoding public portions of tags generated using the stylesheet; providing the public decoding rules to the client device; 2. The authentication server of aspect 1, further comprising: [Aspect 20] 2. The authentication server of aspect 1, wherein the decoding rules enable decoding of a subset of tag features defined by the stylesheet. [Aspect 21] 2. The authentication server of claim 1, wherein the decoding rules enable decoding of a portion of the secure tag defined by the style sheet. [Aspect 22] The decoding rule is: first decoding rules that enable decoding of at least one of a first portion of the secure tag defined by the stylesheet or a first subset of tag features defined by the stylesheet; second decoding rules that enable decoding of at least one of a second portion of the secure tag or a second subset of the tag features; Including, generating tag data using the received tag image and the decoding rules, generating first tag data using a first decoding rule; generating second tag data using the first tag data and a second decoding rule; 2. The authentication server of claim 1, [Aspect 23] 2. The authentication server of aspect 1, wherein the operations further include tracking tag identification requests. [Aspect 24] 2. The authentication server of aspect 1, wherein the operations further include storing tag identification request information. [Aspect 25] 2. The authentication server of aspect 1, wherein the operations further include providing instructions to update a distributed database to reflect the tag data. [Aspect 26] 1. A system for generating security tags, comprising: at least one processor; when executed by the at least one processor, receiving a style sheet describing a class of safety tags; Obtaining a numeric seed; generating a secure tag layout using the numeric seed and a style sheet, the secure tag layout specifying a combination of tag feature options based on the numeric seed and the style sheet; receiving tag data; generating a secure tag that encodes the tag data by selecting the tag feature options according to the value of the tag data; generating a perceptual hash of the secure tag; storing the hash and an identifier of the secure tag in a database; at least one non-transitory memory containing instructions that cause an authentication server to perform operations including: A system comprising: [Aspect 27] 27. The system of aspect 26, wherein the secure tag layout specifies a reference portion that indicates one or more reference locations within the secure tag layout for encoding data. [Aspect 28] 27. The system of aspect 26, wherein the secure tag layout specifies unreferenced portions within the secure tag layout for encoding data. [Aspect 29] 27. The system of aspect 26, wherein the secure tag layout designates junk portions within the secure tag layout for encoding random data. [Aspect 30] 27. The system of aspect 26, wherein the secure tag layout specifies a key portion within the secure tag layout for encoding a cryptographic key. [Aspect 31] 27. The system of aspect 26, wherein the tag feature options include the presence or absence of tag features at locations specified by the security tag layout. [Aspect 32] 27. The system of embodiment 26, wherein the tag feature options include a size, color, or shape of the tag feature. [Aspect 33] 27. The system of claim 26, wherein the tag feature options include deviations from positions specified by the security tag layout. [Aspect 34] 27. The system of claim 26, wherein the tag feature options include a number of tag features present at locations specified by the secure tag layout. [Aspect 35] 27. The system of claim 26, wherein the tag feature options include the presence of a spline encoding on the tag feature. [Aspect 36] 36. The system of embodiment 35, wherein the spline encoding includes tag feature ends that extend at various distances from a reference point or line. [Aspect 37] 37. The system of embodiment 36, wherein the various distances encode one or more spatially multiplexed tag data values. [Aspect 38] 38. The system of embodiment 37, wherein the varying distances encode repetitions of the one or more spatially multiplexed tag data values. [Aspect 39] 27. The system of claim 26, wherein the tag feature options include the presence of microstructures on the tag feature. [Aspect 40] 27. The system of claim 26, wherein the tag feature includes a rim, and the tag feature options for the rim include rim breakage, rim deformation, and rim connection. [Aspect 41] 27. The system of claim 26, wherein the tag feature includes a rim break, and the tag feature options for the rim break include a rim break edge shape. [Aspect 42] 27. The system of embodiment 26, wherein the tag features include connections between tag features of a predetermined type, and tag feature options for the connections include connection width and connection asymmetry. [Aspect 43] 27. The system of claim 26, wherein the tag features include connections between tag features, and the tag feature options for the connections include connection width and connection asymmetry. [Aspect 44] 27. The system of aspect 26, wherein the tag feature includes a central logo and the tag feature options include a displacement of the central logo from a center point of the security tag. [Aspect 45] The system of aspect 26, wherein generating the secure tag encoding tag data by selecting the tag feature option includes selecting a first tag feature option according to a value of first tag data, the selection of the first tag feature option creating a second tag feature option, and selecting the second tag feature option according to a value of second tag data. [Aspect 46] The system of aspect 45, wherein the first tag feature option includes the presence or absence of a point, the second tag feature option includes the presence or absence of a connection between points that exists according to the value of the first tag data, and the third tag feature option encoding the third tag data includes the width of the connection that exists according to the value of the second tag data. [Aspect 47] generating the secure tag encoding the tag data by selecting the tag feature options according to the value of the tag data; encrypting the tag data with an encryption key; selecting the tag feature option according to the value of the encrypted tag data; encoding the encryption key into the secure tag; 27. The system of claim 26, comprising: [Aspect 48] 27. The system of aspect 26, wherein the security tag includes a vector graphics file. [Aspect 49] 27. The system of aspect 26, wherein providing the security tag includes rasterizing the security tag. [Aspect 50] 27. The system of embodiment 26, wherein providing the security tag includes labeling an object with the security tag or incorporating the security tag into a digital product. [Aspect 51] 27. The system of aspect 26, wherein the operations further include checking the generated hash for collisions with hashes of other secure tags before providing the tag data. [Aspect 52] The system of aspect 26, wherein the stylesheet includes a public portion that generates a portion of the secure tag layout for encoding public data and a private portion that generates a portion of the secure tag layout for encoding private data. [Aspect 53] The operation is generating perceptual hashes of different segments of the secure tag at multiple levels of detail; storing the perceptual hashes of the different segments of the secure tag in the database; 27. The system of embodiment 26, further comprising: [Aspect 54] 27. The system of embodiment 26, wherein the tag data includes one or more identifiers related to one or more other security tags. [Aspect 55] 55. The system of aspect 54, wherein a first identifier in the one or more identifiers includes a perceptual hash of a first security tag in the one or more other security tags. [Aspect 56] 27. The system of claim 26, wherein the tag data includes an identifier of a multi-factor identification item. [Aspect 57] 57. The system of embodiment 56, wherein the multi-factor identification item includes an authentication certificate or a perceptual hash of the image. [Aspect 58] 58. The system of claim 57, wherein the image shows a portion of an object labeled with the tag. [Aspect 59] 58. The system of claim 57, wherein the image shows a person associated with the tag. [Aspect 60] 27. The system of embodiment 26, wherein providing the tag includes printing the tag on a substrate, and wherein at least a first portion of the tag is printed with fluorescent ink. [Aspect 61] A security tag reader, comprising: at least one processor; when executed by the at least one processor, Detecting potential security tags in the image; generating a normalized secure tag image using the image and stylesheet; providing an identification request to an authentication server that includes the normalized secure tag image; receiving rules for decoding tag data encoded in the secure tag as tag feature options; at least one non-transitory memory containing instructions that cause the secure tag reader to perform operations including: A safety tag reader comprising: [Aspect 62] 62. The security tag reading device of claim 61, wherein the image is received from a scanner of the security tag reading device. [Aspect 63] 62. The security tag reading device of claim 61, wherein the scanner is a camera. [Aspect 64] 62. The secure tag reading device of claim 61, wherein detecting the potential secure tag in the image includes determining that the size of the potential secure tag satisfies size constraints read from the stylesheet. [Aspect 65] 62. The security tag reading device of embodiment 61, wherein the potential security tags are detected using at least one of geometric feature detection, kernel-based feature detection, template matching, or a convolutional neural network. [Aspect 66] Detecting potential secure tags in the image using geometric feature detection includes: thresholding the image to generate a binary image; detecting geometric features in the binary image using target parameter values ​​retrieved from the stylesheet; determining a reference point for the potential security tag using the geometric features; 66. The security tag reader of embodiment 65, comprising: [Aspect 67] 67. The security tag reader of embodiment 66, wherein the geometric feature comprises concentric ellipses and the reference point comprises a focus of the concentric ellipses. [Aspect 68] 62. The security tag reader of embodiment 61, wherein generating a normalized image of the potential security tag includes converting the image to a black and white or grayscale image. [Aspect 69] A security tag reading device as described in embodiment 61, wherein generating a normalized image of the potential security tag includes flattening the image using an image warp transform and target parameter values ​​retrieved from the style sheet. [Aspect 70] 70. The security tag reading device of embodiment 69, wherein flattening the image using an image warp transform includes correcting at least one of fisheye distortion, barrel distortion, or angular distortion. [Aspect 71] 70. The security tag reading device of embodiment 69, wherein the target parameter value includes an inner or outer tag rim shape. [Aspect 72] A security tag reading device as described in embodiment 61, wherein generating a normalized image of the potential security tag includes detecting image gaps by determining tag feature options for potential image gaps and comparing the tag feature option values ​​with target parameter values. [Aspect 73] 73. The security tag reading device of embodiment 72, wherein the target parameter value comprises a ratio of inner or outer tag rim thickness to diameter, or a ratio of inner or outer tag rim thickness to tag rim break width. [Aspect 74] A security tag reading device as described in embodiment 61, wherein generating a normalized image of the potential security tag includes determining an orientation of a tag feature and rotating the image based on the determined orientation of the tag feature and a target parameter value retrieved from a style sheet. [Aspect 75] 75. The secure tag reader of embodiment 74, wherein the tag feature is a central logo and the target parameter value includes an orientation of the central logo. [Aspect 76] 62. The security tag reader of claim 61, wherein the normalized image of the potential security tag comprises a vector graphics image. [Aspect 77] the image includes a plurality of potential security tags; 62. The security tag reader of claim 61, wherein the identification request includes a stream of vector graphics images corresponding to the plurality of potential security tags. [Aspect 78] the identification request includes the public key of the secure tag reader; 62. The secure tag reader of embodiment 61, wherein at least a portion of the identification request is encrypted with a private key of the secure tag reader. [Aspect 79] generating a normalized secure tag image using the image, providing instructions on a user interface of the security tag reader to display the image and an indication highlighting the potential security tag; receiving an instruction to generate a second zoomed-in image of the potential security tag; generating the normalized image from a second zoomed-in image of the potential security tag; 62. The security tag reader of embodiment 61, comprising: [Aspect 80] The operation is providing instructions on a user interface of the security tag reader to display the image and an indication highlighting the potential security tag; receiving a selection of the potential secure tags; providing a procedure for displaying the secure tag data on a user interface of the secure tag reader; 62. The security tag reader of embodiment 61, further comprising: [Aspect 81] 81. The security tag reading device of embodiment 80, wherein the indication highlighting the potential security tag is a bounding box surrounding the potential security tag in the image. [Aspect 82] 62. The secure tag reading device of embodiment 61, wherein the publicly available portion of the stylesheet provides rules for decoding public tag data encoded in the secure tag as tag feature options. [Aspect 83] 83. The secure tag reader of embodiment 82, wherein the public tag data includes at least one of an authentication server address, a product type, a brand name, an inventory number, or an error correction code. [Aspect 84] 1. A safety tag system, comprising: at least one processor; when executed by the at least one processor, scanning a secure tag to encode tag data as a selection of potential tag feature options; interacting with an authentication server to decode the secure tag; receiving status information of the secure tags stored in a distributed database, the status information indicating a validity status of the tags; at least one non-transitory memory containing instructions that cause the secure tag system to perform operations including: A safety tag system comprising: [Aspect 85] 85. The secure tag system of embodiment 84, wherein interacting with an authentication server to decode the secure tag includes providing an image of the secure tag to the authentication server. [Aspect 86] 85. The secure tag system of embodiment 84, wherein interacting with an authentication server to decode the secure tag includes providing a perceptual hash of the secure tag to the authentication server. [Aspect 87] 85. The secure tag system of embodiment 84, wherein interacting with an authentication server to decode the secure tag includes providing an authentication key to the authentication server. [Aspect 88] 88. The secure tag system of claim 87, wherein the status information is received from the authentication server, and the status information depends on the authentication key. [Aspect 89] Interacting with the authentication server to decode the secure tag comprises: receiving, from the authentication server, decoding instructions indicating the tag feature options encoding the tag data; generating the tag data using the decoding instructions, the tag data including a tag identifier; 85. The safety tag system of embodiment 84, comprising: [Aspect 90] 90. The secure tag system of embodiment 89, wherein receiving the state information of the secure tag from a distributed database includes providing the tag identifier to an oracle. [Aspect 91] receiving the state information of the secure tag from a distributed database further includes providing an authentication key to an oracle; 91. The secure tag system of aspect 90, wherein the received status information depends on the authentication key. [Aspect 92] A security tag system as described in aspect 91, wherein the authentication key corresponds to a manufacturer and the status information includes at least one of tracking information, sales information, customer data, usage information, activity information, or location information. [Aspect 93] 92. The secure tag system of claim 91, wherein the authentication key corresponds to a wholesaler and the status information includes at least one of authenticity information, destination information, or manufacturer information. [Aspect 94] A security tag system as described in aspect 91, wherein the authentication key corresponds to a retailer and the status information includes at least one of authenticity information, transaction information, product information, or tracking information. [Aspect 95] 92. The security tag system of claim 91, wherein the authentication key corresponds to a purchaser and the status information includes at least one of authenticity information, product information, or ownership information. [Aspect 96] 2. The secure tag system of claim 1, wherein the operations further include providing updated state information of the secure tag for storage in the distributed database. [Aspect 97] 97. The secure tag system of embodiment 96, wherein the updated state information of the secure tag is provided to an oracle for writing to the distributed database along with an authentication key. [Aspect 98] 98. The safety tag system of claim 97, wherein the updated status information of the safety tag indicates that the safety tag is invalid. [Aspect 99] 85. The secure tag system of embodiment 84, wherein the updated status information includes updated accessibility options for the status information. [Aspect 100] A safety tag system as described in aspect 84, wherein the status information of the safety tag indicates at least one of tracking information, sales information, customer data, usage information, activity information, location information, reliability information, destination information, updated manufacturer information, transaction information, product data, or proof of ownership information. [Aspect 101] 85. The safety tag system of embodiment 84, wherein the status information of the safety tag indicates pairing between the safety tag and another safety tag. [Aspect 102] 1. A safety tag system, comprising: at least one processor; when executed by the at least one processor, receiving a transaction request for a product associated with a first security tag that encodes first tag data as a selection of potential first security tag feature options; generating a second safety tag for the product encoding second tag identification data as a selection of potential second safety tag feature options, the second tag data including an identifier of the first safety tag and an identifier of a purchaser; receiving an indication of transfer of ownership to said purchaser; at least one non-transitory memory containing instructions that cause the safety tag system to perform operations including: creating an entry for the second safety tag in a database, the created entry indicating the transfer of ownership; A safety tag system comprising: [Aspect 103] The security tag system of embodiment 102, wherein the product comprises a digital product. [Aspect 104] A safety tag system as described in aspect 103, wherein the first safety tag is embedded in the digital product or displayed with the digital product. [Aspect 105] 103. The security tag system of claim 102, wherein the product comprises a physical product. [Aspect 106] 106. The safety tag system of claim 105, wherein the first safety tag labels the physical product. [Aspect 107] 103. The safety tag system of claim 102, wherein the operation further includes updating an entry for the first safety tag in the database. [Aspect 108] A safety tag system as described in aspect 107, wherein the entry is updated to indicate at least one of the transfer of ownership, an identifier of the second tag, transaction information regarding the transfer of ownership, or the validity status of the first safety tag. [Aspect 109] 103. The secure tag system of claim 102, wherein the identifier of the first secure tag includes a hash of at least some of the first tag data. [Aspect 110] 103. The safety tag system of claim 102, wherein generating the second safety tag includes decoding the first safety tag to read the first tag data. [Aspect 111] 103. The secure tag system of claim 102, wherein the second secure tag is generated using a stylesheet associated with the first secure tag. [Aspect 112] 103. The secure tag system of claim 102, wherein the second secure tag is generated using a unique numeric seed. [Aspect 113] The database is a distributed database, The secure tag system of aspect 102, wherein creating the entry for the second secure tag in the database includes providing an authentication key and identifier of the second tag to an oracle for writing to a blockchain. [Aspect 114] 1. A server for interacting with secure tags, comprising: at least one processor; when executed by the at least one processor, receiving a request for a first safety tag encoding first tag data as a selection of potential first safety tag feature options, the first tag data including stored context information; decoding the stored context information; and receiving context information; authenticating the request using the received context information and the stored context information; at least one non-transitory memory containing instructions that cause the server to perform operations including: A server comprising: [Aspect 115] The server of aspect 114, wherein the stored contextual information includes at least one of authentication credentials, a biometric identifier, an audio file, a tag identifier, or a perceptual hash of an image. [Aspect 116] The server of embodiment 115, wherein the biometric identifier includes a fingerprint or a voiceprint. [Aspect 117] The server of aspect 115, wherein the first secure tag labels an item and the image shows a portion of the item. [Aspect 118] the labeled item is an identification card; The server of aspect 117, wherein the portion of the item is an identification photo of an identification card. [Aspect 119] The server of aspect 115, wherein the first safety tag labels an item and the image shows a person associated with the item or a texture of the item. [Aspect 120] The server of aspect 114, wherein authenticating the request includes determining that the received contextual information and the stored contextual information meet a similarity criterion. [Aspect 121] 121. The server of aspect 120, wherein the degree of fulfillment of the similarity criterion depends on a Hamming distance between the received contextual information and the stored contextual information. [Aspect 122] The actions further include requesting the contextual information; The server of aspect 114, wherein the received contextual information is received in response to the request. [Aspect 123] The server of aspect 114, wherein the indication of successful authentication includes at least a portion of the first tag data. [Aspect 124] The server of aspect 114, wherein the indication of successful authentication includes decoding instructions for at least some of the first tag data. [Aspect 125] The server of aspect 114, wherein the indication of successful authentication includes status information retrieved from a distributed database. [Aspect 126] The server of aspect 114, wherein the status information is retrieved from a distributed database using an oracle. [Aspect 127] a substrate labeled with a first safety tag that encodes first tag data as a selection of potential first safety tag feature options; an overlay removably adhered to the substrate, the overlay including a transparent portion and an opaque portion aligned with the first safety tag, the opaque portion aligned with the first safety tag encoding second tag data as a selection of potential second safety tag feature options; A two-part label with [Aspect 128] 128. The two-part label of embodiment 127, wherein the potential first safety tag feature options are different from the potential second safety tag feature options. [Aspect 129] A two-part label as described in embodiment 127, wherein the aligned opaque portion conceals a selected potential first security tag feature option. [Aspect 130] 128. The two-part label of embodiment 127, wherein the aligned opaque portions select a potential first security tag feature option. [Aspect 131] 128. The system of embodiment 127, wherein the potential first safety tag feature options include the presence or absence of a tag feature at a location specified by the first safety tag layout. [Aspect 132] 132. The system of claim 131, wherein the potential second safety tag feature options include the presence or absence of tag features at locations specified by a second safety tag layout that is different from the first safety tag layout. [Aspect 133] generating a first safety tag using the first tag data, the first numeric seed, and the first style sheet, the first safety tag encoding the first tag data as a selection of potential first safety tag feature options; generating a second safety tag using the second tag data, the second numeric seed, and the second style sheet, the second safety tag encoding the second tag data as a selection of potential second safety tag feature options; determining a difference image between the first safety tag and the second safety tag; labeling a substrate with said first security tag; removably adhering an overlay to the substrate, over-labeled with the difference image and aligned with the first security tag; A method for generating two-part labels, including [Aspect 134] 134. The method of claim 133, wherein the overlay hides portions of the first safety tag that are not present in the second safety tag. [Aspect 135] 134. The method of claim 133, wherein the overlay indicates portions of the second safety tag that are not present in the first safety tag. [Aspect 136] 134. The method of claim 133, wherein the overlay transmits a portion of the second security tag that is present in the first security tag. [Aspect 137] The method of embodiment 133, wherein the first style sheet is different from the second style sheet. [Aspect 138] 134. The method of embodiment 133, wherein the substrate comprises a consumer product. [Aspect 139] 139. The method of aspect 138, wherein the first safety tag corresponds to a post-purchase state of the consumer good and the second safety tag corresponds to a pre-purchase state of the consumer good. [Aspect 140] 1. A method of providing a document, comprising: generating a first secure tag paired with the document, the first secure tag encoding an identifier for the document using a selection of latent tag feature options; receiving a request to access the document from a first device; providing the first device with the first security tag; receiving a verification request from a second device, the verification request including a secure tag image; comparing the first security tag to the security tag image; providing the document to the first device based on the comparison; and A method comprising: [Aspect 141] 141. The method of claim 140, wherein the identifier of the document includes a hash of the document. [Aspect 142] Comparing the first security tag to the security tag image includes: generating a perceptual hash of the first secure tag; generating a perceptual hash of the secure tag image; determining that a difference between the stored perceptual hash and the generated perceptual hash meets a threshold criterion; 141. The method of embodiment 140, comprising: [Aspect 143] Comparing the first security tag to the security tag image includes: generating a perceptual hash of the secure tag image; selecting a first secure tag using a difference between the generated perceptual hash and a stored perceptual hash of an image of the first secure tag; generating a second perceptual hash of a predetermined segment of the secure tag image; selecting the first secure tag from a plurality of the first secure tags using a difference between the generated second perceptual hash and a stored second perceptual hash of a predetermined portion of an image of the first secure tag; 141. The method of embodiment 140, comprising: [Aspect 144] the confirmation request includes a confirmation request identifier; providing the document to the first device based on the comparison; generating a second secure tag paired with the request, the second secure tag encoding the verification request identifier using a selection of potential tag feature options; watermarking the document with the second secure tag; 141. The method of embodiment 140, further comprising: [Aspect 145] The method of embodiment 140, wherein the second device is a mobile device. [Aspect 146] 141. The method of embodiment 140, further comprising determining that the receipt of the secure tag image meets an authentication criterion. [Aspect 147] 147. The method of embodiment 146, wherein the authentication criteria relate to some verification requirement associated with the first security tag. [Aspect 148] 147. The method of claim 146, wherein the authentication criteria relates to the amount of time that has elapsed since the provision of the first security tag to the first device. [Aspect 149] 147. The method of claim 146, wherein the authentication criteria relate to the geographic origin of the verification request. [Aspect 150] the confirmation request includes a confirmation request identifier; 147. The method of claim 146, wherein the authentication criteria is related to the confirmation request identifier. [Aspect 151] 151. The method of aspect 150, wherein the authentication criteria is met if an access identifier of the access request matches a confirmation identifier of the confirmation request. [Aspect 152] 1. A system for generating a variable secure tag, comprising: at least one processor; when executed by the at least one processor, generating a first secure tag that encodes the tag data as a selection of tag feature options responsive to values ​​of the tag data; receiving a request from a scanner of a second device, the request including a sequence of tag images including the first tag image; authenticating the request using the first secure tag and the first tag image; at least one non-transitory memory containing instructions that cause the system to perform operations including: A system comprising: [Aspect 153] 153. The system of claim 152, wherein the operations further include providing instructions to display a sequence of tags including the first secure tag on a display of a first device. [Aspect 154] The system of aspect 153, wherein providing instructions to display a sequence of tags including the first secure tag includes embedding the sequence of tags in a digital product. [Aspect 155] 154. The system of claim 153, wherein the instructions provide for displaying a sequence of tags on a display of the first device in response to a trigger. [Aspect 156] The system of embodiment 152, wherein the scanner is a camera. [Aspect 157] The system of aspect 152, wherein authenticating the request includes comparing one or more perceptual hashes of the first secure tag with one or more corresponding hashes of the first tag image. [Aspect 158] The system of aspect 152, wherein authenticating the request includes matching a plurality of safety tags including the first safety tag to a plurality of corresponding tag images including the first tag image. [Aspect 159] 159. The system of claim 158, wherein the authentication further requires matching the plurality of secure tags to the plurality of corresponding tag images according to a predetermined order of appearance. [Aspect 160] The system of embodiment 152, wherein the sequence of tags includes junk tags. [Aspect 161] The system of aspect 152, wherein the trigger is a rollover event or a click event. [Aspect 162] The system of aspect 152, wherein the indication of authentication of the request includes at least some of the tag data. [Aspect 163] The server of aspect 152, wherein the indication of authentication of the request includes decoding instructions for decoding at least some of the first tag data. [Aspect 164] 153. The server of claim 152, wherein the indication of authentication of the request includes status information retrieved from a database. [Aspect 165] the database is a distributed database; The server of aspect 152, wherein the status information is obtained from a distributed database using an oracle. [Aspect 166] A method of tracking a product comprising labeling the product with a computer-readable secure tracking tag that encodes product identification data as a selection of tag feature options based on a combination of a numeric seed and a style sheet. [Aspect 167] A method as described in embodiment 166, wherein the tag feature options include the presence or absence of a tag feature at a location specified by a combination of the numeric seed and the style sheet. [Aspect 168] 167. The method of claim 166, wherein the tag feature options include size, color, or shape of the tag feature. [Aspect 169] 167. The method of claim 166, wherein the tag feature options include deviations from a position specified by a combination of the numeric seed and the style sheet. [Aspect 170] A method as described in aspect 166, wherein the tag feature options include several tag features that are present at a location specified by a combination of the numeric seed and the style sheet. [Aspect 171] The method of embodiment 166, wherein the tag feature options include the presence of spline encoding on the tag feature. [Aspect 172] The method of embodiment 171, wherein the spline encoding includes tag feature ends that extend at various distances from a reference point or line. [Aspect 173] 173. The method of embodiment 172, wherein the various distances encode one or more spatially multiplexed tag data values. [Aspect 174] 174. The method of claim 173, wherein the varying distances encode repetition of the one or more spatially multiplexed tag data values. [Aspect 175] 167. The method of claim 166, wherein the tag feature options include the presence of microstructures on the tag feature. [Aspect 176] The method of embodiment 166, wherein the tag feature includes a rim, and the tag feature options for the rim include rim breakage, rim deformation, and rim connection. [Aspect 177] 167. The method of claim 166, wherein the tag feature includes a rim break, and the tag feature options for the rim break include a rim break end shape. [Aspect 178] 167. The method of embodiment 166, wherein the tag features include connections between tag features of a predetermined type, and tag feature options for the connections include connection width and connection asymmetry. [Aspect 179] The method of embodiment 166, wherein the tag features include connections between tag features, and tag feature options for the connections include connection width and connection asymmetry. [Aspect 180] 167. The method of claim 166, wherein the tag feature includes a central logo and the tag feature option includes a displacement of the central logo from a center point of the security tag. [Aspect 181] The method of embodiment 166, wherein the method further includes generating the computer-readable secure tracking tag. [Aspect 182] The method of aspect 181, wherein generating the computer-readable secure tracking tag includes selecting a first tag feature option according to a first value of the product identification data, wherein selecting the first tag feature option creates a second tag feature option, and selecting the second tag feature option according to a second value of the product identification data. [Aspect 183] The method of aspect 182, wherein the first tag feature option includes the presence or absence of a point, the second tag feature option includes the presence or absence of a connection between the points that exists according to the first value, and a third tag feature option encoding a third value of product identification data includes the width of the connection that exists according to the second value. [Aspect 184] generating the computer readable secure tracking tag; encrypting at least a portion of the product identification data with an encryption key; selecting a first tag feature option according to a value of the encrypted portion of the product identification data; encoding the encryption key on a computer-readable secure tracking tag; 182. The method of embodiment 181, comprising: [Aspect 185] The method of embodiment 166, wherein the computer-readable safety tracking tag comprises a vector graphics file, and labeling the product with the computer-readable safety tracking tag comprises rasterizing the vector graphics file. [Aspect 186] The method of embodiment 166, wherein the method further includes providing identification information of the computer-readable secure tracking tag to an authentication server. [Aspect 187] The method of embodiment 186, wherein the method further includes generating a hash of the computer-readable secure tracking tag and checking the hash for collisions with hashes of other computer-readable secure tracking tags before providing the identification information to the authentication server. [Aspect 188] A label for tracking a product comprising a substrate having printed thereon a computer-readable secure tracking tag that encodes product identification data as a selection of tag feature options based on a combination of a numeric seed and a style sheet. [Aspect 189] A label as described in embodiment 188, wherein the tag feature options include the presence or absence of a tag feature at a position specified by a combination of the numeric seed and the style sheet. [Aspect 190] A label as described in embodiment 188, wherein the tag feature options include size, color, or shape of the tag feature. [Aspect 191] A label as described in aspect 188, wherein the tag feature options include deviations from a position specified by a combination of the numeric seed and the style sheet. [Aspect 192] A label as described in aspect 188, wherein the tag feature options include several tag features that are present at a position specified by a combination of the numeric seed and the style sheet. [Aspect 193] A label as described in embodiment 188, wherein the tag feature options include the presence of a spline encoding on the tag feature. [Aspect 194] A label as described in embodiment 193, wherein the spline encoding includes tag feature ends that extend at various distances from a reference point or reference line. [Aspect 195] The label of embodiment 194, wherein the various distances encode one or more spatially multiplexed tag data values. [Aspect 196] A label as described in embodiment 195, wherein the various distances encode repetition of the one or more spatially multiplexed tag data values. [Aspect 197] A label as described in embodiment 188, wherein the tag feature option includes the presence of a microstructure on the tag feature. [Aspect 198] A label as described in embodiment 188, wherein the tag feature includes a rim, and the tag feature options for the rim include rim breakage, rim deformation, and rim connection. [Aspect 199] The label of embodiment 188, wherein the tag feature includes a rim break and the tag feature options for the rim break include a rim break edge shape. [Aspect 200] A label as described in embodiment 188, wherein the tag features include connections between tag features of a predetermined type, and tag feature options for the connections include connection width and connection asymmetry. [Aspect 201] A label as described in embodiment 188, wherein the tag features include connections between tag features, and tag feature options for the connections include connection width and connection asymmetry. [Aspect 202] A label as described in embodiment 188, wherein the tag feature includes a central logo and the tag feature option includes a displacement of the central logo from a center point of the security tag.

Claims

1. 1. An authentication server for interacting with a secure tag, comprising: at least one processor; When executed by the at least one processor, receiving a tag identification request including at least one tag image; identifying a secure tag in the received at least one tag image that is generated by selecting tag feature options based on a combination of a numeric seed and a style sheet, wherein identifying the secure tag includes: comparing a pair of first and second hashes, the first hash of the pair being based on a predetermined segment of a secure tag and the second hash of the pair being based on a corresponding segment of the received at least one tag image, and selecting a secure tag based at least in part on the comparison; and providing a response indicating the identity of the secure tag. An authentication server comprising:

2. Identifying the secure tag further includes generating the second hash; Selecting a secure tag based at least in part on the comparison further comprises determining that a difference between the first hash and the second hash meets a threshold criterion; The authentication server of claim 1 , comprising:

3. 3. The authentication server of claim 2, wherein generating the second hash of the received at least one tag image comprises converting the received at least one tag image into an image having a predetermined number of pixels.

4. The authentication server of claim 3 , wherein the predetermined number of pixels is equal to or greater than 64 pixels and equal to or less than 1,048,576 pixels.

5. The authentication server of claim 2 , wherein the hash is a perceptual hash.

6. The authentication server of claim 2 , wherein the difference is a Hamming distance between the first hash and the second hash.

7. the received at least one tag image is a vector graphics file; The authentication server of claim 2 , wherein generating the second hash of the received at least one tag image comprises rasterizing at least a portion of the vector graphics file.

8. Comparing the first hash and the second hash includes: selecting the first secure tag using a difference between the second hash and the first hash corresponding to the first secure tag; generating an additional hash of a second segment of the received at least one tag image; selecting the secure tag based at least in part on the comparison includes selecting the secure tag from the first secure tag using a difference between the additional hash and an additional hash of a segment corresponding to the first secure tag; The authentication server of claim 1 , comprising:

9. 2. The authentication server of claim 1, wherein comparing the pair of first and second hashes comprises generating hashes of progressively smaller segments of the received at least one tag image.

10. Comparing the pair of first and second hashes includes: determining that a difference between the second hash and the first hash does not meet a threshold criterion; selecting the secure tag using a difference between a first additional hash of a first additional segment of the received at least one tag image and a first additional hash of a segment corresponding to the secure tag; generating a second additional hash corresponding to a second additional segment of the secure tag; verifying the secure tag using a difference between the second additional hash and a third additional hash of the second additional segment of the secure tag; The authentication server of claim 1 , comprising:

11. 11. The authentication server of claim 10, wherein the received at least one tag image includes a first image and the second additional hash generated using the first image corresponding to the second additional segment of the secure tag.

12. 11. The authentication server of claim 10, wherein the received at least one tag image includes a first image and a second image, the second image corresponding to the second additional segment of the tag, the first additional hash being generated using the first image, and the second additional hash being generated using the second image.

13. The comparison is the segment distance between each pair of hashes of the first hash and the second hash; at least one of an overall distance using the segment distances or a count of segment distances that meet a threshold criterion; The authentication server of claim 1 , further comprising: determining:

14. The authentication server of claim 13 , wherein the operations further include determining a confidence value using the number of first hashes, a count of the segment distances that meet the threshold criterion, and the segment distances.

15. the received at least one tag image; a first image showing at least some of the tags at a first level of detail; a second image showing at least some of the tags at a second level of detail greater than the first level of detail; The authentication server of claim 1 , comprising:

16. The operation is receiving the first hash from a personal system; further comprising The authentication server of claim 1 , wherein the response is provided to the personal system, the response including an identifier of the secure tag.

17. The authentication server of claim 1 , wherein the operations further include tracking tag identification requests.

18. The authentication server of claim 1 , wherein the action further comprises storing tag identification request information.

Images