Security tag

Abstract

Systems and methods are provided for decoding a security tag using an authentication server and a security tag reader. The system may include at least one processor and at least one non-transitory memory. The memory may contain instructions that, when executed by the at least one processor, cause the security tag reader to perform operations. These operations may include detecting potential security tags in an image, and generating a normalized security tag image using the image and a style sheet. The operations may further include providing an identification request to an authentication server, the identification request including the normalized security tag image. The operations may additionally include receiving a rule for decoding tag data encoded into the security tag as a tag feature option, and decoding the tag data using the received rule.

Description

Related Applications

[0001] This application is a divisional application of application number: 201880048518.9, invention name: security tag. This application claims the priority benefit of U.S. Provisional Patent Application No. 62 / 535,201 filed on July 20, 2017, which is incorporated herein by reference in its entirety. Background Art

[0002] Authentication of things currently presents many problems for brands, merchants, and consumers. Existing inventory tracking methods make brands vulnerable to counterfeiting, easy sales through unauthorized channels ("gray market"), difficult to solve supply chain management problems, and problems dealing with end-user contacts (e.g., tracking and verifying sales, managing product recalls, and performing after-sales service). Retailers and distributors deal with similar problems, such as, for example, identifying counterfeit products, accessing information about products, and managing relationships with customers (e.g., managing returns, receipts, customer support, special offers or discounts, and customer relationship management). Consumers may also face problems with existing systems, including difficulties in identifying counterfeit products, receiving accurate information about products, managing warranties, proof of exchange, product registration, and reselling products as authentic.

[0003] Traditional tags such as barcodes and QR codes have various disadvantages. For example, traditional tags are mainly used for stock keeping unit (SKU) identification and are usually read-only. In addition, the stored information as stored binary encoded data can be freely accessed by the reader. Information can only be written to traditional tags using a single method. When reading the tag, the tag must be oriented in a specific direction. In addition, traditional tags usually contain information of a fixed size. These tags can be easily reused and copied. Traditional tags also contain security risks because QR codes have been used in the past for the transmission of viruses / malware. Summary of the invention

[0004] The security tags disclosed in this article solve many of the problems faced by brands, merchants, and consumers around the authentication of various things. These security tags can allow individual objects to be connected to a blockchain or similar database, allowing for individual verification. Each individual product has a unique security tag that will never be repeated, providing the function of individual item identification rather than SKU identification. Since the security tag can be used to verify each individual item, the individual item identification allows for proof of authenticity. This form of unique identification is made possible in part by high-definition resolution smartphones with huge computing power and online connectivity, digital printing, and blockchain and security database technology.

[0005] The unique security tags of the present disclosure offer significant advantages over existing QR codes and barcodes, the only similarity being that they each have a binary base ID layer. Unlike traditional tags, security tags each contain a unique discreet key, have a dynamic and flexible storage area, are integrated with digital ledgers, and include many other advantages. For example, security tags are not limited to one shape or multiple forms - these security tags can exist in a variety of design states to meet customer needs. In addition, security tags can exist across many form factors, such as, for example, digital, printed, engraved, and animated forms. Another advantage of security tags is that these security tags can be read by a variety of optical devices (including smartphones), greatly expanding the number of users who can scan the tags.

[0006] Security tags contain both binary and analog information, which means that these security tags can be read in a variety of ways. The unique design of security tags allows a large amount of binary information to be encoded into the tag, and also allows for visual "fingerprints" that do not return data but can be used to authenticate the security tag using blockchain. Security tags can have additional layers of authenticity, such as by pairing and / or sequencing a security tag with another security tag, or by using information near the security tag (i.e., close-range fingerprinting). Different levels of access rights can be provided to different users throughout the supply chain. For example, customers may be granted access to view certain information about authenticity, security, and proof of warranty, while retailers may be granted access to view certain information about product data, customer data, and product tracking. The ease of use and effectiveness of security tags make these security tags useful in countless situations, helping to reduce authentication issues for things throughout the supply chain.

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

[0008] In some embodiments, using the stored hash value and the received label image to identify the security label may further include: generating a hash value for the received label image, and determining whether the difference between the stored hash value and the generated hash value meets a threshold criterion. Generating the hash value for the received label image may further include converting the received label image into an image having a predetermined number of pixels. The predetermined number of pixels may be greater than or equal to 64 pixels and less than or equal to 1,048,576 pixels. The stored hash value that can be used to identify the security label may be a perceptual hash value, and the difference between the stored hash value and the generated hash value may be a Hamming distance. In addition, the received label image may be a vector graphics file; and generating the hash value for the received image may include rasterizing at least a portion of the vector graphics files.

[0009] In some embodiments, identifying the security tag in the received label image may include: generating a hash value of the received label image; selecting the first security tags using a difference between the generated hash value and stored hash values ​​of images of the first security tags; generating a second hash value of a predetermined segment of the received label image; and selecting the security tag from the first security tags using a difference between the generated second hash value and stored second hash values ​​of predetermined portions of the images of the first security tags. In other embodiments, identifying the security tag in the received label image may include generating hash values ​​of progressively smaller segments of the received label image.

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

[0011] In other embodiments, identifying a security tag in a received label image may include: comparing a hash value of an image of a predetermined segment of the security tag with hash values ​​of segments of one or more received label images including the received label image, the segments of the one or more received label images corresponding to the predetermined segment of the security tag; and selecting the security tag based on the comparison. The comparison may include determining segment distances between the hash value of the image of the predetermined segment of the security tag and corresponding hash values ​​of the segments of the one or more received label images, and at least one of a total distance of 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 hash values ​​of the image of the predetermined segment of the security tag, the count of segment distances that meet the threshold criterion, and the segment distances. Additionally, the one or more received label images may include: a first image that depicts at least some of the tag at a first level of detail; and a second image that depicts at least some of the tag 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 value of the image from a private system; providing a decoding request to the private system, the decoding request including an identifier of the security tag; and wherein the decoding rules may be received from the private system in response to the decoding request.

[0013] In some embodiments, the tag identification request may include an authorization key; the decoding request may include an authorization key; and the decoding rules may correspond to the authorization 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 a tag generated using the style sheet; and providing the public decoding rules to the client device. In still other embodiments, the decoding rules may enable decoding of a subset of tag features defined by the style sheet. In still other embodiments, the decoding rules may enable decoding of a portion of the security tag defined by the style sheet.

[0014] In some embodiments, the decoding rules may include: first decoding rules that enable decoding of at least one of a first portion of a security label defined by the style sheet or a first subset of label features defined by the style sheet; and second decoding rules that enable decoding of a second portion of the security label or at least one of a second subset of label features. Additionally, generating label data using the received label image and the decoding rules may include: generating first label data using the first decoding rules, and generating second label data using the first label data and the second decoding rules.

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

[0016] The disclosed embodiment includes a system for generating a security label. The system for generating a security label may include at least one processor, and at least one non-volatile memory, the at least one non-volatile memory containing instructions, which when executed by the at least one processor cause an authentication server to perform operations, which operations may include: receiving a style sheet describing a class of security labels; obtaining a digital seed; using the digital seed and the style sheet to generate a security label layout, the security label layout specifies a combination of label feature options based on the digital seed and the style sheet; receiving label data; generating a security label encoding the label data by selecting the label feature options according to the value of the label data; generating a perceptual hash value of the security label; storing the hash value and an identifier of the security label in a database; and providing a security label.

[0017] In some embodiments, the security label layout may specify reference portions that indicate one or more referenced locations in the security label layout used to encode data. In other embodiments, the security label layout may specify unreferenced portions of the security label layout used to encode data. In still other embodiments, the security label layout may specify junk portions of the security label layout used to encode random data. In still other embodiments, the security label layout may specify key portions of the security label layout used to encode encryption keys.

[0018] In some embodiments, the label feature options may include the presence or absence of a label feature at a location specified by the security label layout. In other embodiments, the label feature options may include the size, color, or shape of a label feature. In still other embodiments, the label feature options may include a deviation from a location specified by the security label layout. In still other embodiments, the label feature options may include the number of label features present at a location specified by the security label layout.

[0019] In some embodiments, these tag feature options may include the presence of spline coding on the tag feature. The spline coding may include a tag feature edge extending a varying distance from a reference point or reference line. The varying distance may encode one or more spatially multiplexed tag data values. In addition, the varying distance may encode the repetition of the one or more spatially multiplexed tag data values.

[0020] In some embodiments, the label feature options may include the presence of microstructures on the label feature. In other embodiments, the label features may include edges, and the label feature options for the edges include edge breaks, edge deformations, and edge connections. In still other embodiments, the label features may include edge breaks, and the label feature options for the edge breaks include edge break edge shapes. In still other embodiments, the label features may include connections between label features of predetermined types, and the label feature options for the connections include connection width and connection asymmetry. In still other embodiments, the label features may include connections between label features, and the label feature options for the connections include connection width and connection asymmetry.

[0021] In some embodiments, generating a security label encoding the label data by selecting the label feature options may include: selecting the first label feature options according to the value of the first label data, the selection of the first label feature options creating the second label feature options; and selecting the second label feature options according to the value of the second label data. In addition, the first label feature options may include the presence or absence of points, the second label feature options may include the presence or absence of connections between points that exist according to the value of the first label data, and the third label feature options encoding the third label data may include the width of the connection that exists according to the value of the second label data. In other embodiments, generating a security label encoding the label data by selecting the label feature options according to the value of the label data may include: encrypting the label data using an encryption key; selecting the label feature options according to the value of the encrypted label data; and encoding the encryption key into the security label.

[0022] In some embodiments, the security label may include a vector graphics file. In other embodiments, providing the security label may include rasterizing the security label. In still other embodiments, providing the security label may include marking an object with the security label or incorporating the security label into a digital product. In still other embodiments, the operations may further include checking whether the generated hash value conflicts with hash values ​​of other security labels before providing the label data. In still other embodiments, the style sheet may include a public portion for generating a portion of the security label layout for encoding public data and a private portion for generating a portion of the security label layout for encoding private data. In still other embodiments, the operations may further include: generating perceptual hash values ​​for different fragments of the security label at multiple levels of detail; and storing these perceptual hash values ​​for different fragments of the security label in the database.

[0023] In some embodiments, the tag data may include one or more identifiers of one or more other security tags. A first identifier of the one or more identifiers may further include a perceived hash value of a first security tag of 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 an authentication credential or a perceived hash value of an image. In some aspects, the image depicts a portion of an object marked with the tag. In other aspects, the image depicts a person associated with the tag. In other embodiments, providing the tag may include printing the tag on a substrate, at least a first portion of the tag being printed with a fluorescent ink.

[0024] The disclosed embodiments include a security tag reader. The security tag reader may include at least one or more processors, and at least one non-volatile memory, the at least one non-volatile memory containing instructions that, when executed by the at least one processor, cause the security tag reader to perform operations that may include: detecting a potential security tag in an image; using the image and a style sheet to generate a standardized security tag image; providing an identification request to an authentication server, the identification request including the standardized security tag image; receiving rules for decoding tag data encoded into the security tag as a tag feature option; and decoding the tag data using the received rules. In some embodiments, the image may be received from a scanner of the security tag reader. In other embodiments, the scanner may be a camera.

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

[0026] In some embodiments, generating a standardized image of the potential security label may include converting the image to a black and white image or a grayscale image. In other embodiments, generating a standardized image of the potential security label may include flattening the image using an image warping transform and a target parameter value retrieved from the style sheet. Flattening the image using an image warping transform may further include correcting at least one of fisheye distortion, barrel distortion, or angular distortion. In addition, the target parameter values ​​may include an inner or outer label edge shape. In still other embodiments, generating a standardized image of the potential security label may include detecting an image gap by determining label feature options for a potential image gap and comparing the label feature option values ​​to target parameter values. The target parameter values ​​may include a ratio of an inner or outer label edge thickness to a diameter, or a ratio of an inner or outer label edge thickness to a label edge break width. In still other embodiments, generating a standardized image of the potential security label may include determining an orientation of a label feature, and rotating the image based on the determined orientation of the label feature and the target parameter value retrieved from the style sheet. The label feature may be a center mark, and the target parameter value may include a center mark orientation.

[0027] In some embodiments, the standardized image of the potential security tag may include a vector graphics image. In other embodiments, the image includes a plurality of potential security tags, and the identification request may include a stream of vector graphics images corresponding to the plurality of potential security tags. In still 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 using a private key of the security tag reader. In still other embodiments, using the image to generate a standardized security tag image may include: providing instructions to display the image and an indication of highlighting the potential security tag on a user interface of the security tag reader; receiving instructions to generate a second magnified image of the potential security tag; and generating the standardized image based on the second magnified image of the potential security tag.

[0028] In some embodiments, the operations may further include: providing instructions to display the image and an indication highlighting the potential security tag on a user interface of the security tag reader; receiving a selection of the potential security tag; and providing instructions to display the security tag data on the user interface of the security tag reader. The indication highlighting the potential security tag may be a bounding box surrounding the potential security tag in the image.

[0029] In some embodiments, the publicly available portion of the style sheet may provide rules for decoding public label data encoded into the security label as a label feature option. The public label data may further include at least one of an address of an authentication server, a product type, a brand name, a stock number, or an error correction code.

[0030] The disclosed embodiments include a security tag system. The security tag system may include at least one or more processors and at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the security tag system to perform operations that may include: scanning a security tag encoding tag data as a selection of potential tag feature options; interacting with an authentication server to decode the security tag; and receiving status information of the security tag stored in a distributed database, the status information indicating a validity status of the tag.

[0031] In some embodiments, interacting with an authentication server to decode the security tag may include providing an image of the security tag to the authentication server. In other embodiments, interacting with an authentication server to decode the security tag may include providing a perceptual hash value of the security tag to the authentication server. In still other embodiments, interacting with an authentication server to decode the security tag may include providing an authentication key to the authentication server. The state information may be received from the authentication server, the state information depending on the authentication key. In still other embodiments, interacting with the authentication server to decode the security tag may further include: receiving decoding instructions from the authentication server, the decoding instructions indicating the tag feature options encoding the tag data; and using the decoding instructions to generate the tag data, the tag data including a tag identifier. In addition, receiving the state information of the security tag from a distributed database may further include providing an authentication key to an oracle database; and the received state information may depend on the authentication key. In some aspects, the authentication key may correspond to a manufacturer, and the state information may include at least one of tracking information, sales information, customer data, usage information, activation information, or location information. In other aspects, the authentication key may correspond to a distributor, and the status information may include at least one of authenticity information, destination information, or manufacturer information. In other aspects, the authentication key may correspond to a retailer, and the status information may include at least one of authenticity information, transaction information, product information, or tracking information. In other aspects, the authentication key may correspond to a purchaser, and the status information may include at least one of authenticity information, product information, or ownership information.

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

[0033] The disclosed embodiments include a security tag system. The security tag system may include at least one processor and at least one non-volatile memory containing instructions that, when executed by the at least one processor, cause the security tag system to perform operations that may include: 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 security tag for the product that encodes second tag identification data as a selection of potential second security tag feature options, the second tag data including an identifier of the first security tag and an identifier of a purchaser; receiving an indication to transfer ownership to the purchaser; and creating an entry in a database for the second security tag, the created entry indicating the ownership transfer.

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

[0035] In some embodiments, the operations may further include updating an entry of the first security label in the database. The entry may be further updated to indicate at least one of the ownership transfer, an identifier of the second label, transaction information about the ownership transfer, or a validity status of the first security label. In other embodiments, the identifier of the first security label may include a hash value of at least some of the first label data. In still other embodiments, generating the second security label may include decoding the first security label to retrieve the first label data. In still other embodiments, the second security label may be generated using a style sheet associated with the first security label. In still other embodiments, the second security label may be generated using a unique digital seed.

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

[0037] The disclosed embodiments include a server for interacting with security tags. The server for interacting with security tags may include at least one processor, and at least one non-volatile memory, the at least one non-volatile memory containing instructions that, when executed by the at least one processor, cause the server to perform operations that may include: receiving a request for a first security tag encoding first tag data as a selection of potential first security tag feature options, the first tag data including stored context information; decoding the stored context information; receiving the context information; authenticating the request using the received context information and the stored context information; and providing an indication of successful authentication in response to the request.

[0038] In some embodiments, the stored contextual information may include at least one of an authentication credential, a biometric identifier, a sound file, a tag identifier, or a perceptual hash value of an image. The biometric identifier may further include a fingerprint or a voiceprint. In some aspects, the first security tag may mark an item, and the image may depict a portion of the item. Additionally, the marked item may be an identification card; and the portion of the item is an identification photo on the identification card. In other aspects, the first security tag may mark an item, and the image may depict a person associated with the item or a texture of the item.

[0039] In some embodiments, authenticating the request may include determining that the received context information and the stored context information satisfy a similarity criterion. The satisfaction of the similarity criterion may further depend on a Hamming distance between the received context information and the stored context information. In other embodiments, the operations may further include requesting the context information; and the received context 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 still other embodiments, the indication of successful authentication may include state information retrieved from a distributed database. In still other embodiments, an oracle database may be used to retrieve the state information from a distributed database.

[0041] The disclosed embodiments include a two-part marking. The two-part marking may include: a substrate marked with a first security label encoding first label data as a selection of a potential first security label feature option; and a cover removably adhered to the substrate, the cover including a transparent portion and an opaque portion aligned with the first security label, the first security label and the aligned opaque portion encoding second label data as a selection of a potential second security label feature option. In some embodiments, the potential first security label feature option may be different from the potential second security label feature option. In other embodiments, the aligned opaque portion may cover the selected potential first security label feature option. In still other embodiments, the aligned opaque portion may select a potential first security label feature option. In still other embodiments, the potential first security label feature option may include the presence or absence of a label feature at a location specified by a first security label layout. Additionally, the potential second security label feature option may include the presence or absence of a label feature at a location specified by a second security label layout, the second security label layout being different from the first security label layout.

[0042] The disclosed embodiments include a method for generating a two-part tag. The method for generating a two-part tag may include: using first tag data, a first digital seed, and a first style sheet to generate a first security label that encodes the first tag data as a selection of potential first security label feature options; using second tag data, a second digital seed, and a second style sheet to generate a second security label that encodes the second tag data as a selection of potential second security label feature options; determining a difference image between the first security label and the second security label; marking a substrate with the first security label; and removably adhering a cover to the substrate, the cover marked with the difference image and aligned with the first security label.

[0043] In some embodiments, the covering may cover portions of the first security tag that are not present in the second security tag. In other embodiments, the covering may depict portions of the second security tag that are not present in the first security tag. In still other embodiments, the covering may convey portions of the second security tag that are present in the first security tag. In still other embodiments, the substrate may include a consumer product. The first security tag may correspond to a post-purchase state of the consumer product, and the second security tag may correspond to a pre-purchase state of the consumer product.

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

[0045] In some embodiments, comparing the first security label to the security label image may include: generating a perceptual hash value for the first security label; generating a perceptual hash value for the security label image; and determining that a difference between the stored perceptual hash value and the generated perceptual hash value satisfies a threshold criterion. In other embodiments, comparing the first security label to the security label image may include: generating a perceptual hash value for the security label image; selecting the first security labels using a difference between the generated perceptual hash value and a stored perceptual hash value for the image of the first security label; generating a second perceptual hash value for a predetermined segment of the security label image; and selecting the first security label from the first security labels using a difference between the generated second perceptual hash value and a stored second perceptual hash value for a predetermined portion of the images of the first security labels.

[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 security tag paired with the request, the second security tag encoding the confirmation request identifier using a selection of potential tag feature options; and watermarking the document using the second security tag.

[0047] In some embodiments, the method may further include determining that receipt of the security tag image satisfies authentication criteria. In some aspects, the authentication criteria may be related to the number of confirmation requests associated with the first security tag. In other aspects, the authentication criteria may be related to the time that has passed since the first security tag was provided to the first device. In still other aspects, the authentication criteria may be related to the geographic origin of the confirmation request. In still other aspects, the confirmation request may include a confirmation request identifier; and the authentication criteria may be related to the confirmation request identifier. In addition, the authentication criteria may be satisfied when the access identifier of the access request matches the confirmation identifier of the confirmation request.

[0048] The disclosed embodiments include a system for generating a mutable security label. The system for generating a mutable security label may include at least one processor, and at least one non-volatile memory, the at least one non-volatile memory containing instructions that, when executed by the at least one processor, cause the system to perform operations that may include: generating a first security label that encodes the label data to select label feature options based on the value of the label data; receiving a request including a label image sequence from a scanner of a second device, the label image sequence including a first label image; authenticating the request using the first security label and the first label image; and providing an indication of the authentication of the request. In some aspects, the scanner may be a camera. In other aspects, the trigger may be a flip event or a click event.

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

[0050] In some embodiments, authenticating the request may include comparing one or more perceived hash values ​​of the first security tag with one or more corresponding hash values ​​of the first tag image. In other embodiments, authenticating the request may include matching a plurality of security tags including the first security tag with a plurality of corresponding tag images including the first tag image. The authentication may further require matching the plurality of security tags with the plurality of corresponding tag images according to a predetermined order of appearance. In still other embodiments, authenticating the tag sequence may include junk tags.

[0051] In some embodiments, the requested authentication indication may include at least some of the tag data. In other embodiments, the requested authentication indication may include decoding instructions for decoding at least some of the first tag data. In still other embodiments, the requested authentication indication may include state information retrieved from a database. In still other embodiments, the database may be a distributed database; and an oracle database is used to retrieve the state information from the distributed database.

[0052] The disclosed embodiments include a method for tracking a product. The method for tracking a product may include marking the product with a computer-readable secure tracking label that encodes product identification data as a selection of label feature options based on a combination of a digital seed and a style sheet. In some embodiments, the label feature options may include the presence or absence of a label feature at a location specified by the combination of the digital seed and the style sheet. In other embodiments, the label feature options may include a size, color, or shape of a label feature. In still other embodiments, the label feature options may include a deviation from a location specified by the combination of the digital seed and the style sheet. In still other embodiments, the label feature options include a number of label features present at a location specified by the combination of the digital seed and the style sheet.

[0053] In some embodiments, the tag feature options include the presence of spline coding on the tag feature. The spline coding may further include a tag feature edge extending a varying distance from a reference point or reference line. In addition, the varying distance may encode one or more spatially multiplexed tag data values, and the varying distance may encode the repetition of the one or more spatially multiplexed tag data values. In other embodiments, the tag feature options may include the presence of a microstructure on the tag feature. Still in other embodiments, the tag features may include edges, and the tag feature options for these edges include edge breaks, edge deformations, and edge connections. Still in other embodiments, the tag features may include edge breaks, and the tag feature options for these edge breaks include edge break edge shapes. Still in other embodiments, the tag features may include connections between tag features of predetermined types, and the tag feature options for these connections may include connection widths and connection asymmetries. Still in other embodiments, the tag features may include connections between tag features, and the tag feature options for these connections may include connection widths and connection asymmetries. Still in other embodiments, the tag features may include a center mark, and the tag feature options may include the displacement of the center mark relative to the center point of the security tag.

[0054] In some embodiments, the method may further include generating the computer-readable security tracking label. In some aspects, generating the computer-readable security tracking label may further include: selecting first label feature options based on the first value of the product identification data, the selection of these first label feature options creating second label feature options; and selecting these second label feature options based on the second value of the product identification data. The first label feature options may further include the presence or absence of points, the second label feature options may include the presence or absence of connections between points that exist based on the first values, and the third label feature options encoding the third value of the product identification data may include the width of the connections that exist based on the second values. In other aspects, generating the computer-readable security tracking label may further include: encrypting at least a portion of the product identification data using an encryption key; selecting the first label feature options based on the value of the encrypted portion of the product identification data; and encoding the encryption key into the computer-readable security tracking label.

[0055] In some embodiments, the computer-readable security tracking label may include a vector graphics file, and marking the product with the computer-readable security tracking label may include rasterizing the vector graphics file. In other embodiments, the method may further include providing identification information of the computer-readable security tracking label to an authentication server. The method may further include generating a hash value of the computer-readable security tracking label, and checking whether the hash value conflicts with hash values ​​of other computer-readable security tracking labels before providing the identification information to the authentication server.

[0056] The disclosed embodiments include a tag for tracking a product. The tag for tracking a product may include a substrate printed with a computer-readable secure tracking label that encodes product identification data as a selection of tag feature options based on a combination of a digital 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 digital seed and the style sheet. In other embodiments, the tag feature options may include a size, color, or shape of a tag feature. In still other embodiments, the tag feature options may include a deviation from a location specified by the combination of the digital seed and the style sheet. In still other embodiments, the tag feature options may include a number of tag features present at a location specified by the combination of the digital seed and the style sheet.

[0057] In some embodiments, the tag feature options may include the presence of spline coding on the tag feature. The spline coding may further include a tag feature edge extending a varying distance from a reference point or reference line. In addition, the varying distance may encode one or more spatially multiplexed tag data values, and the varying distance may encode the repetition of the one or more spatially multiplexed tag data values. In other embodiments, the tag feature options may include the presence of a microstructure on the tag feature. Still in other embodiments, the tag features may include edges, and the tag feature options for the edges may include edge breaks, edge deformations, and edge connections. Still in other embodiments, the tag features may include edge breaks, and the tag feature options for the edge breaks may include edge break edge shapes. Still in other embodiments, the tag features may include connections between tag features of predetermined types, and the tag feature options for the connections may include connection widths and connection asymmetries. Still in other embodiments, the tag features may include connections between tag features, and the tag feature options for the connections may include connection widths and connection asymmetries. Still in other embodiments, the tag features may include a center mark, and the tag feature options may include the displacement of the center mark relative to the center point of the security 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The drawings are not necessarily drawn to scale or detailed. Instead, emphasis is generally placed on illustrating the principles of the invention described herein. The accompanying 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 present disclosure. In the figure:

[0060] Figure 1 An exemplary system for interacting with a security tag is depicted.

[0061] Figure 2 An exemplary schematic diagram of an authentication server for interacting with a security tag is depicted.

[0062] Figure 3 An exemplary schematic diagram of label data is depicted.

[0063] Figure 4 An exemplary diagram illustrating components of an exemplary computing device generally suitable for implementing the disclosed systems and methods is depicted.

[0064] Figure 5An exemplary schematic diagram of a database for storing tag information is depicted.

[0065] Figure 6 A flow chart showing an exemplary process for tag generation is depicted.

[0066] Figure 7 A flow chart showing an exemplary iterative encoding process is depicted.

[0067] Figure 8 A flow chart showing an exemplary process for tag reading is depicted.

[0068] Fig. 9 A flow chart showing an exemplary process for tag identification is depicted.

[0069] Fig.10 A flow chart showing an exemplary process for multi-resolution tag identification is depicted.

[0070] Fig.11 A flow chart showing an exemplary process for multi-resolution label recognition with changing labels is depicted.

[0071] Fig.12 A flow chart showing an exemplary data structure for performing multi-resolution tag identification is depicted.

[0072] Fig.13 An exemplary user interface depicting tag recognition results is depicted.

[0073] Fig.14 An exemplary process for decoding tag feature selection is depicted.

[0074] Fig.15 An exemplary authentication process using contextual information is depicted.

[0075] Fig.16A Paired security labels and ordered security labels are depicted.

[0076] Fig. 16B Depicted are security labels paired with contextual information.

[0077] Fig.17 An exemplary overlay label is depicted.

[0078] Fig.18 An exemplary process for multi-channel document authentication using security tags is depicted.

[0079] Fig.19 An exemplary security tag sequence for authentication is depicted.

[0080] Fig. 20 An exemplary process for using a database for inventory management is depicted.

[0081] Fig.21 An exemplary process for modifying a tag is depicted.

[0082] Fig. 22 An exemplary process for inventory management using paired tags is depicted.

[0083] Fig.23 An exemplary process for recording a transfer of ownership is depicted.

[0084] Fig.24A An exemplary security tag is depicted.

[0085] Fig. 24B Portions of a graphics file corresponding to an exemplary security label are depicted.

[0086] Fig.25A Depicts security labels generated using the same style sheet but different data.

[0087] Fig.25B Depicts security labels generated using different stylesheets and the same data.

[0088] Fig.26A Depicts security label feature options.

[0089] FIG. 26B to FIG. 26N Depicts details of potential security label options.

[0090] FIG. 27A to FIG. 27J The generation of an exemplary security tag is depicted.

[0091] FIG. 28A to FIG. 28N The generation of an exemplary security tag is depicted.

[0092] Fig.29A and 29B An exemplary user interface is depicted. DETAILED DESCRIPTION

[0093] In the following detailed description, many specific details are set forth in order to provide a comprehensive understanding of the disclosed example embodiments. However, those skilled in the art will appreciate that the principles of these example embodiments can be practiced without each specific detail. Well-known methods, procedures, and components are not described in detail to avoid blurring the principles of these example embodiments. Unless explicitly stated, the example methods and processes described herein are neither limited to a specific order or sequence nor to a specific system configuration. In addition, some of the described embodiments or their elements may occur or be executed simultaneously, at the same time point, or concurrently. Now, reference will be made to the disclosed embodiments in detail, examples of which are shown in the accompanying drawings. Unless explicitly stated, sending and receiving as used herein are understood to have a broad meaning, including sending or receiving in response to a specific request or in the absence of such a specific request. Therefore, these terms cover both active and passive forms of sending and receiving.

[0094] Figure 1 An exemplary system 100 for interacting with a security tag is depicted. This exemplary system may include a security tag 105, a client device 110, an authentication server 115, a private 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 security tag 105 may be decoded using an image, a style sheet, and a digital seed of the security tag. This information may be distributed between the private system 120 and the client device 110 to reduce the likelihood that an attacker who is able to compromise any of these systems can decode the security tag. For example, the private system 120 may be configured to store the style sheet and the digital seed, while the client device 110 may be configured to obtain an image of the security tag 105. In some embodiments, the authentication server 115 may be configured to perform the decoding, obtain the image of the security tag 105 from the client device 110, and obtain the decoding instructions from the private system 120. In this way, the system may distribute the information necessary to decode the security tag 105 while ensuring that the decoding occurs on the security system (authentication server 115).

[0095] The security tag 105 can be a tag configured to mark a product. The product can be a physical product (e.g., a shoe) or a digital product (e.g., a website or a video stream). As described herein, the product can be configured to encode the tag data using a selection of tag feature options. The potential tag feature options for selection can depend on a style sheet and a digital seed. In this way, a style sheet can define a class of similar security tags, while different digital seeds can ensure that each tag remains unique.

[0096] The client device 110 may include a mobile device (including a scanner). For example, the client device 110 may be a mobile phone, such as a smart phone, a tablet computer, or a portable computer. As an additional example, the client device 110 may be an optical scanner, such as a handheld optical scanner (e.g., a SIMATIC or MOTOROLA optical scanner). The client device 110 may be configured to generate images of the security tag 105 and provide these images to the authentication server 115.

[0097] Authentication server 115 may include one or more computing systems, such as servers, general-purpose computers, or mainframe computers. Authentication server 115 may be independent, or it may be part of a subsystem, which may be part of a larger system. For example, authentication server 115 may include a distributed server that is remotely located and communicates 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 include one or more containers or virtual machines hosted on a cloud computing environment (such as Amazon Web Services).

[0098] The authentication server 115 may be configured to identify the security tag based on the image received from the client device 110 and the decoding instructions received from the private system 120 or another system. The authentication server 115 may be configured to interact with the public database 125 to read or write state information about the identified tag. In some embodiments, the authentication server 115 may be configured to interact with the public database 125 indirectly through an oracle database (e.g., when the public database 125 is an Ethereum blockchain). The authentication server 115 may be configured to provide the decoded tag information or certain decoding instructions to the client device 110 in response to the identification request.

[0099] Private system 120 may include one or more computing systems, such as servers, general-purpose computers, or mainframe computers. Private system 120 may be independent, or it may be part of a subsystem that may be part of a larger system. For example, private system 120 may include a distributed server that is remotely located and communicates via a public network (e.g., network 130) or a dedicated private network. In some embodiments, private system 120 may be configured to communicate with components of system 100 via network 130. In some aspects, private system 120 may include one or more containers or virtual machines hosted on a cloud computing environment (such as Amazon Web Services).

[0100] The private system 120 may be configured to generate security labels for use by the system 100. In some embodiments, the private system 120 may be configured to store style sheet information and digital seeds for creating security labels. Consistent with the disclosed embodiments, the private system 120 may be configured to respond to requests from the authentication server 115. These requests may include security label identifiers. The private system 120 may be configured to provide decoding instructions for security labels corresponding to the security label identifiers. In some embodiments, the decoding instructions may include at least some of the style sheet and the digital seed. The decoding instructions may include a specific correspondence between label feature options and label data for the security label.

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

[0102] Figure 2 An exemplary schematic diagram of an authentication server for interacting with a security tag consistent with the disclosed embodiments is depicted. In some aspects, the authentication server 115 can be configured to include an authentication database 205. In various aspects, the authentication database 205 can include a record 220. In some embodiments, the record can associate one or more hash values ​​of a security tag with the tag identification data. In various embodiments, in addition to the authentication database, the authentication server 115 can be configured to include general access rules. The general access rules can include application key requirements, authentication credential requirements, session token requirements, or similar restrictions on access to the authentication server.

[0103] Figure 3An exemplary schematic diagram of tag identification data consistent with the disclosed embodiments is depicted. In some embodiments, the tag identification data may include tag-specific access rules 305. For example, a specific security tag may require a specific application key for decoding. As an additional example, another security tag may not require any specific application key for decoding. Some security tags may include time, geographic location, 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 meet the security tag-specific access rules 305 for the security tag. In some embodiments, the tag identification data may include a tag identifier 310. In some aspects, the tag identifier 310 may be specific to a specific security tag. For example, the tag identifier 310 may be a hash value of information encoded in the security tag. As an additional example, the tag identifier 310 may be a perceptual hash value of the security tag. In such embodiments, the authentication server 115 may be configured to store only the tag identifier 310, rather than storing a hash value 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 security tags that the operator of authentication server 115 wishes to make publicly available, such as tracking data or location data. Private data 320 may include metadata about interactions with security tags that the operator of authentication server 115 wishes to restrict access to, such as manufacturing data or customer data collected by manufacturers, distributors, or retailers. Although public data may be provided in response to any query, authentication server 115 may limit access to private data. For example, authentication server 115 may be configured to provide private data 320 in response to an identification request including an appropriate application key or authentication credential. The amount and type of private data 320 provided may depend on the application key or authentication credential received. In some embodiments, authentication server 115 may be configured to store a link to at least one of tag-specific access rules 305, tag identifier 310, public data 315, or private data 320. For example, at least some of this information may be stored in public database 125 or another database. Whether a link to the actual tag-specific access rules 305, tag identifier 310, public data 315, or private data 320 is stored on the authentication server 115 may depend on performance and security concerns.

[0104] Figure 4An exemplary simplified diagram showing components of an exemplary computing device generally suitable for implementing the disclosed systems and methods is depicted. According to some embodiments, the exemplary device may include a processor 410, a memory 415, (multiple) I / O interfaces 420, and a network adapter 425. These units may communicate with each other via a bus 405 or wirelessly. Figure 4 The components shown in the figure may reside in a single device or in multiple devices.

[0105] Processor 410 may be one or more microprocessors, central processing units, or graphics processing units that perform various methods according to the disclosed embodiments. Memory 415 may include one or more computer hard disks, random access memories, removable storage devices, or remote computer storage devices. 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-computer interface device. Network adapter 425 enables the exemplary device to communicate with the network 130 via the network 130. Figure 1 Components exchange information. In various embodiments, network adapter 425 can be configured to support wireless networks or wired networks. In some aspects, network adapter 425 can be configured with modules for supporting one or more local area networks, personal area networks, or near-field networks. In some aspects, network adapter 425 can be configured with hubs for supporting computer buses. For example, network adapter 425 can be configured with one or more USB hubs.

[0106] Figure 5An exemplary schematic diagram of a database for storing tag information is depicted. In some embodiments, a public database may include a separate account 515 and a bundled account 520. Consistent with the disclosed embodiments, status information for high-priced items (e.g., houses, jewelry, cars, etc.) may be stored in a separate account, while status information for multiple low-priced items (e.g., shoes, clothes, personal electronic products, digital products such as movies, etc.) may be stored in a single bundled account. In some aspects, each transaction involving a security tag for a high-priced item may be written to the public database 125, while a transaction group involving low-priced items may be stored in a private database and periodically written to a corresponding bundled account 520. In some embodiments, when the public database 125 is a distributed database, the requester 501 (e.g., the authentication server 115) must interact with the oracle database 510 to read and write information to the public database. In various aspects, the requester and the oracle database may be combined into a single program (e.g., the authentication server 115 may act as both the requester 501 and the oracle database 510). In some embodiments, users of the system 100 are able to read information directly from the public database 125 without having to contact the authentication server 115. For example, system 100 may include a portal for reading information about security tags contained in public database 125 .

[0107] Figure 6 A flow chart showing an exemplary process 600 for security label generation consistent with the disclosed embodiments is depicted. Although process 600 is described below as being performed by proprietary system 120, in some embodiments, the process may be performed by authentication server 115 or another system. Process 600 may include receiving a digital seed and style sheet necessary to generate a security label, generating a security label layout, generating a security label using the security label layout and label data, registering the security label with authentication server 115, and providing a label of appropriate form for a product to be tracked. In this manner, an identifier unique to a product may be generated that encodes label data as a selection of label feature options.

[0108] After starting, process 600 can proceed to step 601. In step 601, proprietary system 120 can receive a style sheet. The style sheet can describe a class of security labels. In some embodiments, such security labels can be similar in appearance, purpose, or use. For example, a style sheet can describe a class of security labels used by a particular manufacturer (e.g., a shoe manufacturer) to mark a particular product (e.g., a certain model of shoe). In some embodiments, the manufacturer can use the same style sheet to generate security labels for instances of the same product. This can allow the manufacturer to achieve a degree of visual uniformity among the security labels used to mark the products, while ensuring that each individual label remains unique.

[0109] The style sheet can define the label data location, label features, and label feature options that can be used by such security labels. In some aspects, spatial options (e.g., label feature size within a security label, label feature location, etc.) can be defined by standardized values ​​(such as ratios and angles). As a non-limiting example, a style sheet can be configured to define a first diameter option for a point that can be 10% of the distance from the center of the security label to the outer edge of the security label, while a second diameter option for the point can be 15% of the distance from the center of the security label to the outer edge of the security label. As a second non-limiting example, a style sheet can be configured to define potential label feature locations based on a radial coordinate system with an origin at the center of the label. A specific potential label feature location can be 5 degrees clockwise from the calibration line and 50% of the distance from the center point to the label edge. As another example, the break at the label edge can be twice as wide as the label width. The width of the label edge can be defined as a portion of the distance from the center point to the label edge. In this way, a style sheet can be used to define a set of constraints on label features that can be used to authenticate labels regardless of whether the label can be decoded.

[0110] Consistent with the disclosed embodiments, a style sheet may describe a potential mapping of data to a tag feature option. For example, a style sheet may describe a correspondence between a specific tag feature option and a specific bit of a binary number. In some aspects, a style sheet may describe a correspondence between a specific value of a tag feature option and a specific value of a bit of a binary number. For example, when a tag feature option has a specific value (or a specific range of values, or a value selected from a specific potential value set), the value of the corresponding bit of the binary number may be 1. When a tag feature option has a different specific value (or a different range of specific values, or a value selected from a different specific potential value set), the value of the corresponding bit of the binary number may be 0. In various aspects, a style sheet may describe alternative options for a security label layout and a correspondence between a tag feature option and a tag data value. In some aspects, a style sheet may describe the possibility that a tag feature exists or does not exist at a specific location. For example, a style sheet may identify a location where a small dot may exist in a security label, or a location where a break may exist in the edge of a security label. These options may be mutually exclusive. For example, according to a first option, a specific portion of the security tag can be reserved for tag data, according to a second option, this specific portion of the security tag can be reserved for a reference to another portion of the security tag, and according to a third option, this specific portion of the security tag can be populated with random tag features designed to prevent unauthorized tag decoding.

[0111] In some embodiments, a style sheet may be configured with data and / or instructions for selecting between a plurality of security label layout options (e.g., layout options, correspondence options between label data and label feature options, the presence or absence of label features at specific locations, etc.). This selection process may depend on a randomly generated number. For example, a style sheet may be configured to select between a first use of a specific location in a security label (e.g., storing data) and a second use of the specific location in the security label (e.g., storing garbage values) based on the value of the randomly generated number. A style sheet may be configured to use such a vector of randomly generated numbers and specific security label layouts (including, for example, specific layout options, correspondence options between label data and label feature options, the presence or absence of label features at specific locations, etc.). A style sheet may also be configured with a parameter vector. For example, a style sheet may be configured to: when the value of the randomly generated number exceeds the value of the parameter α, select the first correspondence between the label data and the label feature options, and otherwise, select the second correspondence between the label data and the label feature options. Continuing with this example, the style sheet can be configured to: when the value of another randomly generated number exceeds the value of parameter β, select a first position in the security tag for encoding the tag data, and otherwise select a second position in the security tag for encoding the tag data. In this example, α and β are parameters of the style sheet. These parameters can take default values, or can take values ​​received from a user or retrieved from another system or configuration file.

[0112] In some embodiments, the style sheet may be configured to contain parameters for label appearance, minimum values, maximum values, and tolerances for features that are preset, variable, or randomly generated. The style sheet may be configured to generate different security label layouts depending on the intended use of the security label (e.g., the intended size of the security label (because small labels may be more difficult to read using a cell phone camera), the intended resolution of the printed security label, the intended color and surface finish of the security label). In some embodiments, the proprietary system 120 may be configured to provide a configuration tool that enables the generation, export, and storage of style sheets.

[0113] The proprietary system 120 may be configured to generate random numbers for use by the style sheet when creating a security label layout. A pseudo-random number generator may be used to generate the random numbers. In some aspects, the style sheet may specify the pseudo-random number generator (e.g., by referencing a library or web service, by encoding the pseudo-random number generator into the style sheet, etc.). In various aspects, the proprietary system 120 may specify the pseudo-random number generator.

[0114] In some embodiments, the pseudo-random number generator can be configured to generate a random number sequence based on an initial seed. Given the same seed, the pseudo-random number generator can be configured to generate the same pseudo-random number sequence. Thus, consistent with the disclosed embodiments, the security label layout generated by the style sheet can depend on any parameters of the style sheet as well as the seed.

[0115] In various embodiments, a pseudo-random number represented as a binary number can provide a selection sequence through the bits of the binary number. For example, when the binary number is 00110110, the "false" option can be selected for the first two options provided by the style sheet, and the "true" option can be selected for the third option provided by the style sheet. Multiple bits can be used to select between options with more than two choices. For example, two bits can be used to select an option with four possible values.

[0116] In some embodiments, the style sheet may include a public portion. In some aspects, the system 100 may be configured to provide a public portion of the style sheet to a client device. In various aspects, the public portion of the style sheet may be available at a known location (e.g., a known URL, etc.). The public portion of the style sheet may include at least some of the ratios of the constrained tag feature relationships. For example, the public portion may include the ratio of the width of the outer tag edge to the diameter (or major axis or minor axis, etc.) of the tag. This ratio may be used to determine whether the tag is true in some respects without any further processing. The public portion may also indicate where the public tag data is located and how to decode this tag data. As a non-limiting example, the public portion of the style sheet may indicate that a spline extending from the 12 o'clock position along the outer edge of the outer edge continues to the 6 o'clock position to encode a known value of the SKU, the URL of the authentication server, or whether the image of the tag has been correctly processed. Since the style sheet describes a class of tags, this public portion may describe the information that can be accessed in each security tag belonging to this class of tags.

[0117] In some embodiments, the style sheet may include a private portion. The private portion may describe ratios, security label layout information, correspondence between label data and label feature options, etc., which may be used to encode private label data. In some aspects, the private portion of the style sheet may be stored by the private system 120.

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

[0119] After step 601 and step 603, process 600 may proceed to step 605. In step 605, proprietary system 120 may generate a secure label layout using the digital seed and the style sheet. As described above, the style sheet may include multiple ways of encoding data into label feature options. The selection of a particular way of encoding data into label feature options (e.g., a secure label layout) may depend on the digital seed.

[0120] In some embodiments, a random number generator (e.g., an ultra-high entropy pseudo-random number generator such as Gibson Research's) can use a digital seed to generate one or more pseudo-random numbers. These pseudo-random numbers can then be used to select a way to encode data as a tag feature option. For example, when there are 32 binary options, the bit values ​​of two 16-bit binary numbers can be used to select from these 32 binary options to generate a secure label layout. As an additional example, 32 binary options can be selected based on comparing the randomly generated numbers to a threshold parameter. For example, the private system 120 can be configured to: select a first option when the value of the randomly generated number exceeds 0.95, and otherwise, select a second option. As a further option, a random number generator can be used in conjunction with a card shuffling algorithm to generate a binary data sequence (e.g., the presence or absence of 20 tag feature sequences). As a non-limiting example, the proprietary system 120 may be configured to: determine a desired number of tag features, determine a number of potential locations for the tag features, create an array of a size equal to the number of potential locations, fill the array with a desired number of elements with values ​​indicating the presence of the tag features, and then shuffle the array to create a random sequence (e.g., using a Fisher-Yates shuffle algorithm, etc.). In this way, a secure label layout may specify a combination of tag feature options based on a selection of a digital seed and a style sheet.

[0121] In some embodiments, the security label layout may specify at least one of a referenced label portion, a reference portion, an unreferenced label portion, a key portion, or a junk portion. These portions may include one or more locations in the security label that contain label data. For example, the referenced label portion may include one or more locations in the security label that are identified by label data stored elsewhere in the label. The corresponding reference portion of the security label may store the label data necessary to locate the referenced portion of the security label. Therefore, decoding the reference portion of the security label may enable the corresponding referenced portion of the security label to be decoded. In some embodiments, additional information may be required to decode the referenced portion of the label. For example, the data stored in the reference portion may enable the referenced portion to be located, but additional decoding instructions or encryption keys may be required to decode the label data at the referenced portion. As an additional example, the unreferenced portion may include one or more locations in the security label that are not referenced by label data stored elsewhere in the label. In the absence of instructions (e.g., the relevant portion of the style sheet), such unreferenced portions cannot be identified, let alone decoded. As a further example, the key portion may include one or more locations in the security label that store key material. In some aspects, such key material can be used to decode tag data encoded into other portions of the security 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 application keys, etc.). As described above, the key portion can be a referenced portion or an unreferenced portion. In some embodiments, the security tag may include a junk portion that stores no data or stores random data that lacks semantic meaning. Such junk portions ensure that an attacker cannot simply assume that all tag features have some associated meaning, thereby making unauthorized attempts to decode the tag more difficult.

[0122] In some embodiments, the label portion may describe a spatial region of a security label. For example, a physical quadrant of a security label. In various embodiments, the label portion may describe a logical portion of a security label. For example, a security label may be a vector graphics file, and the label portion may be a logical partition within the vector graphics file. For example, the label portion may include an element containing SVG tags that describe the potential locations of dots in the security label in a specific order. The order of the tags in the element may describe a mapping from bits in a number to the presence or absence of dots in a security image without reference to the actual location of the dots in the security label.

[0123] Consistent with the disclosed embodiments, a security label layout may include a variety of different types of label feature options. The label feature options may include the presence or absence of a label feature at a location specified by the security label layout. For example, the security label layout may indicate that a dot may be placed at a particular location within the security label. The presence of a dot at that location may indicate that a corresponding bit of the label data is set.

[0124] The label feature options may include the size, color, or shape of the label feature. For example, the security label layout may indicate that larger dots (or dots of a first color or deformed label features, etc.) correspond to set positions, while smaller dots (or dots of a second color or undeformed label features, etc.) correspond to empty positions.

[0125] The label feature options may include deviations from a position specified by a security label layout. For example, a security layout may specify a relative position for a label feature within a security label. The deviation from a specified position may encode a value of one or more bits by the direction and magnitude of the deviation (e.g., one or more bits in the x-direction and one or more bits in the y-direction).

[0126] The label feature options may include the number of label features present at the location specified by the security label layout. For example, the number of dots present at the specified location may encode the bit. As a further example, the encoding may be by a direct correspondence (e.g., the value of the bit includes the number of dots) or by some indirect correspondence (e.g., the bit is set when there are zero to two dots, and is empty when there are more than two dots).

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

[0128] The tag feature options may include the presence of spline encoding on the tag feature. In some embodiments, the spline encoding may include an extension or change of the edge of the tag feature. This extension or change may extend a distance that varies from a reference point or reference line. For example, the edge of an originally circular dot may extend a varying amount from the center of a dot or the circumference of a dot specified by the tag layout. This varying distance may encode one or more spatially multiplexed tag data values.

[0129] For example, the basic spatial frequency can be multiplexed with the binary representation of the first tag value. Therefore, the basic spatial frequency can contribute to the extension or change of the edge at a position corresponding to the set bit in the first tag value rather than at a position corresponding to the empty bit in the first tag value. Additional basic spatial frequencies can be multiplexed with the binary representation of the additional tag value. These basic spatial frequencies can differ by at least four times (for example, the first basic spatial frequency can have a period of 2^12 microns, the second spatial frequency can have a period of 2^10 microns, the third spatial frequency can have a period of 2^8 microns, etc.). The security tag layout can be configured to further specify the starting point and number of repetitions for decoding the spline. Therefore, the distance of the change can encode the repetition of one or more spatially multiplexed tag data values.

[0130] The label feature may include the edges of the security label, such as the inner edge and the outer edge. The label feature options for the edge may include edge break, edge deformation, and edge connection. When the edge includes edge break as an option, the label feature options for the edge break may include edge break edge shape.

[0131] The label feature may include connections between predetermined types of label features. For example, such connections may include connections between dots and connections between dots and edges (e.g., connections between dots and inner or outer edges). Label feature options for connections may include connection width and connection asymmetry.

[0132] The tag features may include a center mark. The center mark may be used to identify a general class of tags, such as enabling a user to identify a common portion of a style sheet that may be used to decode common data in a tag. A tag feature option for the center mark may include a displacement of the center mark relative to a center point of the security tag. For example, a hash value of a security tag or a public key associated with a security tag may be encoded by the displacement of the center mark relative to a center point of the security tag.

[0133] After starting, process 600 may proceed to step 606. In step 606, private system 120 may be configured to receive tag data. Tag data may be received from a user through a user interface, from an input file, from a memory of private system 120, from another system, etc. Tag data may include data and / or instructions. Data and / or instructions may be represented by one or more numbers. Tag data may include an identifier of a multi-factor identification item. Attempting to read a tag or perform an action using a tag may include decoding the tag and comparing the identifier with other data to determine whether the read attempt or action is authenticated or authorized. For example, the multi-factor identification item may include authentication credentials (e.g., a password; an API key; a token; a hash value of a password, an API key, or a token; etc.). As an additional example, the multi-factor identification item may include contextual information, such as an image or a perceptual hash value of an image, or a voiceprint or a hash value of a sound. For example, an image may depict a portion of a product tagged with a tag. In the case of a perceptual hash value of an image of a portion of a product tagged with a tag, private system 120 may be configured to prevent the tag from being moved to another product or to prevent multiple products from being tagged with copies of the security tag. As an additional example, the image may depict a person associated with the security tag. As a non-limiting example, this person may be the owner of the tagged product. In this way, the security tag may be used to verify ownership.

[0134] As a further example, the tag data may include one or more identifiers of one or more other security tags. For example, a first identifier of the one or more identifiers may include a perceptual hash value of a first security tag of the one or more other security tags. In this way, additional tags may be paired with the current tag. In some embodiments, the authentication server may be configured to request images of the additional tags or perceptual hash values ​​of the additional tags in order to authenticate or authorize a request regarding the current tag.

[0135] After step 606, process 600 may proceed to step 607. In step 607, private system 120 may generate a security label encoding the label data. In some aspects, private system 120 may be configured to generate a security label encoding the label data by selecting a label feature option according to the value of the label data. For example, when the security label layout provides a label feature option (including a plurality of potential locations of small dots or edge breaks) and the label data includes a binary number, the small dots or edge breaks may exist or not exist depending on whether the corresponding bit of the binary number is set or empty. In some embodiments, an encryption key may be used to encrypt at least a portion of the label data. A security label may then be generated by selecting a label feature option according to the value of the encrypted label data. In some embodiments, an encryption key for decrypting the encrypted label data may also be encoded into the security label (e.g., in a referenced key portion or an unreferenced key portion of the security label). In some embodiments, the security label 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.

[0136] After step 607, process 600 may proceed to step 609. In step 609, the private system 120 may generate a perceptual hash value (such as a pHash, etc.) for the security tag. Generating the perceptual hash value may include rasterizing the security tag. For example, when the security tag is stored as a vector graphics file, generating the perceptual hash value may include converting the perceptual hash value to a raster graphics file format. In some embodiments, the private system 120 may be configured to check for hash collisions by comparing the generated pHash with a pHash library of existing security tags. If a hash collision exists, the private system 120 may be configured to recreate the security tag using a new digital seed. In various embodiments, the private system 120 may be configured to generate additional perceptual hash values ​​for different fragments of the security tag at multiple levels of detail.

[0137] After step 609, process 600 may proceed to step 611. In step 611, private system 120 may store the perceived hash value of the security tag in a database (e.g., a database of authentication server 115). In some aspects, when private system 120 is configured to generate additional hash values ​​for different fragments of the security tag, these additional hash values ​​may be stored in the database together with the perceived hash value of the entire security tag. Private system 120 may be configured to store an identifier of the security hash value in the database together with the hash value (s) of the security tag. This identifier may be configured to enable private system 120 to determine which style sheet and which digital seed were used to generate the security tag. For example, private system 120 may be configured to maintain a database for tracking security tags. This database may use a security tag identifier including as a key value, an indication of the style sheet used to generate each security tag, and a digital seed used to generate each security tag. In some embodiments, this database does not include the tag data used to generate the security tag or the image of the security tag. Therefore, an attacker who is able to compromise this secure database will not be able to recreate the tag data based on the stored identifier, style sheet reference, and digital seed.

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

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

[0140] Figure 7A flow chart showing an exemplary iterative encoding process 700 consistent with the disclosed embodiments is depicted. Although the process 700 is described below as being performed by the proprietary system 120, in some embodiments, the process may be performed by the authentication server 115 or another system. The process 700 may include receiving a security label layout, determining available label features based on a current label state, selecting label feature options using label data values, and updating available label feature options based on the selected label feature options. In this manner, label data items may be iteratively encoded into a security label, with each iteration creating label feature options for encoding the next label data item.

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

[0142] After step 701, process 700 can proceed to step 703. In step 703, private system 120 can determine available label features based on the current label state. For example, the security label layout can specify that label features can include dots and connections between dots. The security label layout can specify an ordering of potential dot positions, and the position of the potential dot positions in the ordering corresponds to the bit position in the binary label data. The security label layout can 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 zero. In this example, the current label state can include these potential dot positions. The current label state can also include additional available label features, such as potential edge fractures or potential edge deformations.

[0143] After step 703, process 700 may proceed to step 705. In step 705, proprietary system 120 may use the tag data value to select a tag feature option from the available tag feature options. Continuing with the previous example, proprietary system 120 may read a bit from the binary tag data and place a dot at the corresponding potential dot position when the value of the bit is 1 (and simply jump to the next bit when the value of the bit is 0). Although explained with respect to dots, such a process is similarly applicable to other tag features.

[0144] After step 705, process 700 may proceed to step 707. In step 707, proprietary system 120 may update available label feature options based on the selected label feature options. Continuing with the previous example, potential dot locations may no longer constitute selectable label feature options, but now dot size, dot color, the presence or absence of connections between dots, and the presence or absence of connections between dots and edges may be available. A style sheet may provide rules governing the correspondence between these label feature options and label data items. For example, a style sheet may provide rules for associating connections between dots with specific bits in binary label data.

[0145] The private system 120 may be configured to continue selecting label feature options and updating the set of available label feature options until the label data is fully encoded. For example, the private system 120 may select a first label feature option based on the value of the first label data. This selection of the first label feature option may create a second label feature option. The private system 120 may then select a second label feature option based on the value of the second label data. This selection of the second label feature option may in turn create a third label feature option. In a non-limiting example, the first label feature option may include the presence or absence of a point, the second label feature option may include the presence or absence of a connection between points that exists based on the value of the first label data, and the third label feature option encoding the third label data may include the width of the connection that exists based on the value of the second label data.

[0146] Figure 8 A flow chart showing an exemplary process 800 for tag reading is depicted. Process 800 includes steps of tag detection, tag identification, and server-side decoding, as well as 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 camera of a mobile device 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, private system 120, or another system. In various embodiments, optional client-side decoding may be performed by client device 110.

[0147] 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 security tag 105. In some embodiments, tag detection 801 may include converting the raster image into a standardized vector graphics image and providing the vector graphics image to authentication server 115. In various embodiments, tag detection 801 may include converting the raster image into a standardized raster image and providing the standardized raster image to authentication server 115.

[0148] Tag detection 801 may include detecting security tags 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 security tags 105 in the received image using geometric feature detection may include thresholding a raster image to generate a binarized image. This thresholding may include converting a color image to a grayscale image and then thresholding the image based on grayscale values, or converting a color image to a black and white image. In some embodiments, the client device 110 may be configured to perform image conversion using image processing functions provided by ImageMagic, OpenCV, or the like.

[0149] Consistent with the disclosed embodiments, the client device 110 may be configured to detect geometric features in the received label image that match known target parameters. The client device 110 may also be configured to use geometric features to detect reference points of potential security labels. In some aspects, the client device 110 may be configured to use a geometric feature detection algorithm provided by OpenCV or the like. In some aspects, the client device 110 may be configured to detect geometric features in a binary image using target parameter values ​​retrieved from a style sheet. For example, a common portion of a style sheet may include a description of geometric features present in a class of security labels. Such geometric features may include the shape of inner and / or outer label edges. For example, the style sheet may indicate that the inner label edge and the outer label edge are circles with a predetermined size ratio. The client device 110 may then use a geometric feature detection algorithm to detect concentric ellipses with appropriate size ratios in the received label image. In some embodiments, the reference point may be a focus of the concentric ellipses. In some embodiments, the client device 110 may align the reference point to the center of the security label 105.

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

[0151] The client device 110 may be configured to detect potential tag locations in an image using template matching or image template detection. In some embodiments, the template or stencil may be included in a common portion of a style sheet, or may be generated using a common portion of a style sheet. The template or stencil may involve identifying portions of a security tag, such as a center mark or a tag edge. For example, the template or stencil may match a center mark. The client device 110 may be configured to perform template matching or image template detection using a template matching algorithm provided by OpenCV or the like.

[0152] The client device 110 may be configured to detect potential tag locations in an image using a convolutional neural network. The convolutional neural network may be implemented using real-time object detection capabilities provided by YOLO or the like. The convolutional neural network may be trained to distinguish security tags from other features in an image. In some embodiments, the convolutional neural network (or another convolutional neural network) may be configured to distinguish between multiple classes of security tags after identifying security tags in an image.

[0153] During the tag detection step 801, the client device 110 may be configured to generate a standardized security label image using the received image and style sheet. In some embodiments, the client device 110 may be configured to use the public portion of the style sheet. The public portion of the style sheet may specify target parameter values ​​for a class of tags. These target parameter values ​​may include common tag features in the class of tags. Such common features may include the presence, absence, shape, and orientation of tag features such as center marks, inner edges, and outer edges. The target parameter values ​​may further include ratios describing the relationship between the dimensions of the tag features. For example, such ratios may include the ratio of the inner (or outer) tag edge thickness to the tag diameter or the ratio of the inner (or outer) tag edge thickness to the tag edge break width. The target parameter values ​​may also include size constraints on the tag (e.g., the total diameter of a circular security tag). The client device 110 may be configured to determine whether the security tag identified in the received image satisfies the overall size constraints retrieved from the public portion of the style sheet. The publicly available portion of the style sheet may also provide rules for decoding public tag data encoded into the security tag as a tag feature option. For example, the publicly available portion of the style sheet may describe the correspondence between label feature options that can be identified from the standardized image and the encoded label data. The style sheet (including the publicly available portion of the style sheet) may also describe the semantics of the encoded data. For example, the publicly available portion of the style sheet may identify the 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.

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

[0155] 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 the target parameter value retrieved from the common portion of the style sheet. The tag feature may be a center mark of the security tag. The client device 110 may be configured to use the above-mentioned template matching system to identify the center of the tag. The client device 110 may be configured to then determine the outer oval line that surrounds the entire security tag. The client device 110 may be configured to then determine the center of the security tag. After determining the center and the oval line, the client device 110 may be configured to construct a plurality of right triangles on the security tag image. These right triangles may be placed so that the center of each right triangle overlaps with the center of the security tag, and the two vertices defining the hypotenuse intersect with the outer oval edge. The (multiple) triangles with the smallest hypotenuse and / or the largest hypotenuse may be used in combination with the orientation information in the common portion of the style sheet to correct the orientation of the tag. The client device 110 may be configured to determine the appropriate style sheet based on the center mark. If the security label does not include a center mark, the client device 110 may be configured to determine the label style sheet by reading the label feature options in a default position (eg, characters from an outer spline using spline encoding).

[0156] During the tag detection step 801, the client device 110 can be configured to detect image gaps. Such image gaps can be caused by damage, lighting (e.g., ambient light reflected into the scanner), or surface conditions (e.g., dust). The client device 110 can be configured to detect tag feature options for potential image gaps and compare the tag feature option values ​​with target parameter values ​​listed in the public portion of the style sheet. If the potential image gap does not match the target parameter value in the public portion of the style sheet, the client device 110 can be configured to ignore the image gap, thereby extending the tag features around the image gap through the image gap based on the target parameter value in the public portion of the style sheet. For example, the client device 110 can be configured to handle edge gaps determined to be artifacts by ignoring the edge gaps when converting a standardized raster image to a vector graphics file for transmission to the authentication server 115.

[0157] During the tag detection step 801, the client device 110 may be configured to provide an identification request to the authentication server, the identification request including a standardized security label image. Although described herein as an "identification request," the reason or purpose for providing such a request is not limited to identifying a security label. For example, providing an identification request may be part of an action involving a security label, such as a transaction of ownership of an item marked with a security label, an update of rules regarding security labels, or cancellation of a security label. As described above, the client device 110 may be configured to at least standardize the orientation of the received raster image, flatten the raster image, and correct image gaps. The client device 110 may be configured to then generate a standardized security label image by converting the raster image into a vector graphics image, such as an SVG image, an EPS image, or a PDF image.

[0158] In some embodiments, the client device 110 may be configured to provide instructions to display an image and an indication of a highlighted potential security tag on a user interface of the security tag reader. For example, when the client device 110 is a camera of a smart phone, the display of the smart phone may depict the image and include a bounding box or similar indication around the detected security tag. In some embodiments, the bounding box may indicate whether the tag has been successfully identified. For example, the color, shape, line type, etc. of the bounding box may indicate whether the tag has been successfully identified. The client device 110 may be configured to perform an action upon selection of the bounding box, such as optically or digitally magnifying an area of ​​the detected tag.

[0159] 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 standardized image generated in step 801. The standardized image may be a vector graphics image. In some embodiments, the raster image received by client device 110 in step 801 may include a plurality of potential security tags. In such embodiments, client device 110 may be configured to detect and generate standardized images of a plurality of potential security tags. Client device 110 may be configured to provide the generated standardized image as a stream of vector graphics images corresponding to a plurality of potential security tags. In some embodiments, the identification request may include a public key of the security tag reader, and at least a portion of the identification request may be encrypted using a private key of client device 110.

[0160] In some embodiments, the client device 110 may be configured to receive instructions to generate another image. These instructions may be received from the authentication server 115. These instructions may automatically cause the client device 110 to generate a second magnified image of the potential security tag. Alternatively or additionally, the instructions may instruct the user to cause the client device 110 to generate a second magnified image of the potential security tag. The client device 110 may then be configured to generate another standardized image based on the second magnified image of the potential security tag.

[0161] 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, decoding instructions may supplement the common portion of the style sheet. For example, decoding instructions may limit the possibilities disclosed by the style sheet to a specific mapping between tag feature options and tag data values. In various embodiments, decoding instructions may describe a specific set of rules for converting tag feature options to tag data values. For example, decoding instructions may indicate that a particular tag data item has a value that depends on a specifically identified set of tag feature options.

[0162] As indicated above, in some embodiments, the client device 110 may be configured to provide instructions to display an image and an indication highlighting a potential security tag on a user interface of the security tag reader. In some embodiments, the client device 110 may be configured to receive an indication from a user selecting a potential security tag (e.g., the indication may be a bounding box around the potential security tag, and the indication may include the user selecting the bounding box on a touch-sensitive display). The client device 110 may be configured to: generate a standardized image of the potential security tag, provide an identification request to the authentication server 115, and in response receive tag data and / or decoding instructions from the authentication server 115. The client device 110 may be configured to decode the tag data using any decoding instructions received from the authentication server 115. The client device 110 may then be configured to provide instructions to display the security tag data (e.g., the received and / or decoded tag data) on a user interface of the client device 110 (or another device).

[0163] Fig. 9A flow chart showing an exemplary process 900 for tag identification is depicted. Although process 900 is described below as being performed by authentication server 115, in some embodiments, the process may be performed by private system 120, client system 110, or another system. Consistent with the disclosed embodiments, process 900 may include the steps of receiving a tag identification request, identifying a security tag based on the tag identification request, generating tag data using a retrieved tag image and a decoding rule, and providing decoded tag data in response to the request.

[0164] 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 unrecognized security tag). Authentication server 115 may be configured to receive a tag identification request from client device 110. Network 130 may be used to receive the tag identification request. In some aspects, the tag identification request may include an authorization key (e.g., an API key for authorizing an API call). In some aspects, the tag identification request may include a session token (e.g., an OAUTH2.0 bearer token, a Kerberos token, etc.). In some aspects, the tag identification request may include user identification information, such as a user name 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, authentication server 115 may be configured by general access rules 210 to grant access without account information.

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

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

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

[0168] In some embodiments, the authentication server 115 can be configured to identify damaged or partially obscured labels. For example, the authentication server 115 can be configured to identify the security label 105 in the received label image by generating hash values ​​of gradually smaller segments of the received label image. These gradually smaller segments of the received label image can be compared with hash values ​​of corresponding segments of known security labels. Based on the degree of match between these generated hash values ​​and corresponding hash values ​​of known security labels, a damaged or partially obscured label can be identified even when the hash value of the entire image of the damaged or partially obscured label fails to match any stored hash values.

[0169] In step 903, consistent with the disclosed embodiments, the authentication server 115 may determine a tag identifier of the matching stored hash value. The tag identifier may be used to retrieve a decoding rule for the tag.

[0170] After step 903, process 900 may proceed to step 905. In step 905, the 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 tags generated using a particular style sheet. For example, these decoding rules may identify the location of tag data within a tag, specify a default location for tag features, specify a correspondence between tag feature options and tag data values, and provide ratios for identifying tag features and tag feature options (e.g., the ratio of a small dot diameter to a total diameter, the ratio of an edge break width to an edge thickness, etc.).

[0171] In step 905, the authentication system 115 may receive a decoding rule in response to a decoding request. In some aspects, the decoding request may be provided to the proprietary system 120 or another system. The decoding request may be provided using the network 130. The decoding request may include an identifier of the security tag 105. The decoding request may include an authorization key (e.g., an authorization key received from the client device 110). In some aspects, the decoding rule may be retrieved from the proprietary system 120 or another system.

[0172] In some embodiments, the decoding rules may enable decoding of a subset of the security label 105. The decoding rules may include or be based on portions of a style sheet used to generate the security label 105. The decoding rules may correspond to an authorization key. For example, the authentication system 115 may receive different decoding rules depending on the authorization key included in the decoding request. As an additional example, different rules may be provided in response to an authorization key associated with a manufacturer than in response to an authorization key associated with a retailer. Even though the security label may include the same information, the differences between the decoding rules mean that different subsets of this information may be available to the manufacturer and the retailer.

[0173] In some embodiments, the decoding rules may enable iterative decoding of the security 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 a security tag defined by a style sheet or a first subset of tag features defined by a style sheet. For example, the first decoding rule may enable decoding of first tag data in a reference portion of a security tag. The second decoding rule may enable decoding of a second portion of a security tag or at least one of a second subset of tag features. For example, the second decoding rule may enable decoding of second tag data in a portion of a security tag referenced by the first tag data, the first tag data being encoded in the reference portion of the security tag and decoded using the first tag. In the absence of the first tag data encoded in the reference portion, the second decoding rule cannot be used to decode the second tag data. Therefore, the first tag data may be generated using the first decoding rule, and the second tag data may be generated using the first tag data and the second decoding rule.

[0174] In some embodiments, the authentication system 115 may receive public decoding rules for decoding public portions of tags generated using a style sheet. Such rules may specify how to decode non-sensitive information of general interest, such as stock keeping unit numbers (SKUs), brand names, expiration dates, and product names.

[0175] 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 in lieu of tag data. This may enable a client device to perform tag decoding in lieu of authentication server 115, or in order to verify decoding performed by authentication server 115. For example, in some embodiments, authentication server 115 may be configured to provide client device 110 with any public decoding rules for security tag 105 stored by authentication server 115 or received from private system 120.

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

[0177] Fig.10 A flow chart illustrating an exemplary process 1000 for multi-resolution tag identification consistent with the disclosed embodiments is depicted. Although process 1000 is described below as being performed by authentication server 115, in some embodiments, the process may be performed by proprietary system 120, client system 110, or another system. Process 1000 may include the steps of generating a hash value for an image of security tag 105, selecting a first security tag based on the generated hash value, generating a second hash value corresponding to a predetermined segment of security tag 105, and selecting a security tag from the first security tags as a security tag that matches security tag 105. In this manner, process 1000 may enable authentication server 115 to identify security tag 105 in an image when the hash value of security tag 105 in the image matches a plurality of stored hash values.

[0178] After starting, process 1000 may proceed to step 1001. In step 1001, authentication server 115 may generate a hash value of a security tag (eg, security tag 105) depicted in a received tag image. The hash value may be a perceptual hash value.

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

[0180] After step 1003, process 1000 may proceed to step 1005. In step 1005, authentication server 115 may generate a second hash value for a predetermined segment of security label 105 depicted in the received label image. For example, authentication server 115 may be configured to generate hash values ​​for one or more quadrants of the security label.

[0181] Consistent with the disclosed embodiments, the authentication server 115 can be configured to prompt the client device 110 to provide a second image. For example, the authentication server 115 can be configured to provide instructions to display a box or similar indication surrounding a predetermined segment of the security label 105. In response to this indication, the user can interact with the client device to obtain a second image depicting the predetermined segment of the security label 105.

[0182] Authentication server 115 may be configured to receive this second image from client device 110. The first received image may depict at least some of security tag 105 in its entirety at a first level of detail, while the second received image may depict a predetermined segment of security tag 105 at a second level of detail that is greater than the first level of detail. For example, the first image and the second image may include the same number of pixels, but the camera of client device 110 may be closer to the predetermined segment of security tag 105 when capturing the second image than when capturing the first image.

[0183] After step 1005, process 1000 may proceed to step 1007. In step 1007, authentication server 115 may be configured to select a particular security tag from the previously selected first security tags. Authentication server 115 may be configured to refine the selection of a matching security tag using a difference between the second hash value generated in step 1005 and a stored second hash value of a predetermined portion of the image of the first security tag. For example, while the first hash value generated in step 1001 may broadly match the stored hash value of the first security tag, the second hash value generated in step 1005 may only match one of the stored second hash values ​​(e.g., only the second hash value generated in step 1005 and one of the stored second hash values ​​may differ by less than a threshold amount). If more than one of the stored second hash values ​​sufficiently matches the second hash value generated in step 1005, the authentication server 115 can be configured to repeat this comparison process for another predetermined segment of the security hash value 105 (e.g., a sub-segment of the quadrant selected in step 1005 or another quadrant of the security tag 105).

[0184] Fig.11 A flow chart illustrating an exemplary process 1100 for multi-resolution tag recognition utilizing a changing tag is depicted. Although process 1100 is described below as being performed by authentication server 115, in some embodiments, the process may be performed by proprietary system 120, client system 110, or another system. Consistent with the disclosed embodiments, process 1100 may include comparing a hash value of a security tag depicted in a received tag image with a stored hash value of the security tag image. When the hash value of the security tag depicted in the received tag image fails to match any of the stored hash values ​​within a predetermined degree of difference, authentication server 115 may be configured to compare a hash value of a predetermined segment of the security tag depicted in the received tag image with a stored hash value of a corresponding segment of the security tag. Authentication server 115 may be configured to identify a potentially matching security tag based on this second comparison. Authentication server 115 may be configured to compare a hash value of another predetermined segment of the security tag depicted in the received tag image with a stored hash value of a corresponding segment of the identified potentially matching security tag. If these additional hash values ​​match within a predetermined degree of difference, then the authentication server 115 may be configured to confirm the identification of the matching security tag as the security tag depicted in the received tag image. Thus, according to process 110, the authentication server 115 may be configured to search the authentication database 205 for a hash value matching portion of the security tag depicted in the received image. In this way, the authentication server 115 may be configured to match incomplete or damaged security tags.

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

[0186] 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 between the generated second hash value and the stored second hash value of the security tag (e.g., security tag 105) depicted in the received image. The generated second hash value may be a hash value of a segment of the security tag depicted in the received image (or another image of the same security tag). The stored second hash value may be a hash value of a segment of a potentially matching security tag stored in authentication database 205. The segment of the potentially matching security tag may be the same as the segment of the security tag depicted in the received image.

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

[0188] In some embodiments, the second segment can be different from the first segment. For example, when the first segment is the upper right quadrant of the security label, the second segment can be the upper left quadrant of the security label. In various embodiments, the second segment can overlap with the first segment. For example, the second segment can fall entirely or partially within the first segment. For example, the second segment can be the lower left quadrant of the first segment.

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

[0190] Consistent with the disclosed embodiments, process 1000 and process 1100 may include determining (i) a total distance using segment distances, and / or (ii) a count of segment distances that meet a threshold criterion. For example, authentication server 115 may compare multiple hash values ​​of an image of a segment of security tag 105 to corresponding stored hash values ​​of the segment of security tag. The comparison may include determining a distance between each hash value of an image of a segment of security tag 105 and a corresponding stored hash value of the segment of security tag. The comparison may include determining a total distance (such as an average distance) based on these individual distances. 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 at least one of the number of hash values ​​compared, the count of individual distances that meet the threshold criterion, or the individual distances or the overall distance.

[0191] Fig.12 A schematic diagram of a logical database structure for performing multi-resolution tag recognition is depicted. In some embodiments, the authentication database 205 may be configured with Fig.12 The authentication database 1205 may be configured to store hash values ​​generated using security tags. Figure 6As described, these hash values ​​can be generated by the private system 120 during the label creation process. In some aspects, the authentication database 205 can be configured to store hash values ​​about the first security label in the data structure 1201. The authentication database 205 can be configured to store hash values ​​corresponding to multiple levels of detail. In some aspects, the label level 1230 may include hash values ​​calculated on the entire security label. At this level of detail, small label feature options for encoding data may not be identified (due to the resolution of the scanner or image processing loss). Therefore, the hash value calculated on the image depicting the entire label may not match any one hash value stored in the authentication database, or may match multiple hash values. In various aspects, the label level 1240 may include hash values ​​calculated on fragments of the entire label (e.g., quadrants of the entire security label). At this level of detail, small label feature options for encoding data can be identified. In addition, damage to one fragment of the label may not affect another fragment of the label. Thus, although the hash values ​​calculated on the entire damaged tag may not match (e.g., unmatched hash value 1203), the hash values ​​calculated on the undamaged segments of the tag may still match (e.g., matched hash value 1211). In various aspects, the tag level 1250 may include hash values ​​calculated on sub-segments of the entire tag (e.g., quadrants of quadrants of the entire security tag). Because additional segments of other tags may match (e.g., matched hash value 1213), the authentication server 115 may be configured to check additional hash values ​​(e.g., matched hash value 1221, unmatched hash value 1223). By checking these additional hatches, the authentication server 115 can confirm that the security tag corresponding to the hash value of the first tag hash value structure 1201 is the security 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 hash values ​​checked, the number of hash values ​​that match according to the similarity criteria, and the degree of match. This score can be used to identify a security tag that matches the security tag depicted in the image received from the client device 110. As will be appreciated by those skilled in the art, the depicted tree structure is not intended to be limiting.Other data structures may be used to store hash values ​​and related information, such as an associative array or map for stored hash values ​​and including identifiers of security tags.

[0192] Fig.13 An exemplary user interface for evaluating the authenticity of a tag is depicted. The reading device may have an application capable of displaying the determined authenticity level of the tag. Authenticity may be determined using the systems and methods disclosed herein. After scanning a security tag, the scanned tag image is sent to an authentication server. Figures 10 to 12The authenticity of the tag is determined by the hashing method described in . When the tag is authenticated, information about the tag is returned, including the number of scans, any reports, etc. In some 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 security tag based on the tag history stored in the blockchain.

[0193] In some embodiments, the app for determining the authenticity level of the tag can return an "authentication score". In some aspects, a full score 1301 can be returned. For example, this can happen when the security tag is in good condition and the reading device is able to scan the security tag well. In addition, when 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 a counterfeit, a full score 1301 can be returned. In other aspects, a low score 1303 can be returned. This can happen when the security tag is in a poor state or the reader is unable to scan the security tag well. In addition, when the authentication server determines that the same tag has been identified as possibly counterfeit, a low score 1303 can be returned. For example, if the tag has been scanned multiple times in multiple locations, a low score 1303 will be returned as the authentication score. In another example, if the tag has been reported as counterfeit, a low score 1303 will be returned as the authentication score.

[0194] In some embodiments, the user can Fig.13 1304. The exemplary user interface shown in FIG. 1305 shows an example of a user reporting a tag. For example, when a low score 1303 is returned indicating that the tag has been scanned on multiple occasions and is not unique, the user can report the tag to make the owner of the tag aware of possible counterfeiting. In other embodiments, the user can view product information through the app. For example, when a high score 1301 is returned, the user can then review the product information.

[0195] Fig.14An exemplary process for decoding a tag feature selection is depicted. Although process 1400 is described below as being performed by authentication server 115, in some embodiments, the process may be performed by private system 120, client system 110, or another system. Process 1400 may include the steps of receiving an image, receiving decoding rules and a digital seed, identifying possible features using a known style sheet and / or known data values, identifying actual features based on the received image, reconstructing the data values, and decrypting the data values. In this way, authentication server 115 may be configured to decode data stored in a security tag using information received from both client device 110 and private system 120. In some embodiments, authentication server 115 does not store images, decoding rules, digital seeds. In this way, the functional arrangement of system 100 ensures that an attacker who compromises authentication server 115 will not be able to decode the contents of the security tag managed by authentication server 115.

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

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

[0198] In some embodiments, the private system 120 may be configured to convert a style sheet and a digital seed for generating a security label into decoding instructions that directly describe the correspondence between label features and label data values ​​present in a vector graphics image. For example, the decoding instructions may specify a set of label feature options and a mapping from the values ​​of these label feature options to the values ​​of the label data items. In such embodiments, the private system 120 may not provide the private portion of the style sheet or the digital seed to the authentication server 115. In some embodiments, the authentication server 115 may be configured to receive at least some of the private portion of the style sheet, which is used to generate a label together with a digital seed for generating a security label layout for a security label. In such embodiments, the authentication server 115 may be configured to generate a correspondence between label features and label data values ​​present in a vector graphics image.

[0199] After step 1403, process 1400 may proceed to step 1405. In step 1405, authentication server 115 may use the decoding instructions and known tag data values ​​to identify possible features. For example, authentication server 115 may be configured to locate tag features described in the decoding instructions. In some instances, locating tag features may depend on known tag data values. For example, a security tag may encode an 8-bit binary number as the size of a dot in a security tag. The decoding instructions may indicate a correspondence between the size of the dot and the value of a specific 8-bit binary number. However, the decoding instructions may not specify which portion of the security tag contains the relevant dot. Another portion of the security tag may include a reference that can be used to identify portions of the tag that encode tag features (dots) that have tag feature options (dot sizes) that encode specific values ​​of tag data.

[0200] 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, when 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 first convert the received image into a vector graphics file. Alternatively, authentication server 115 may use functions provided by OpenCV or the like to determine tag feature option values ​​(e.g., relative dot size, presence or absence of a feature somewhere) directly from a raster image.

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

[0202] 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 into the secure tag.

[0203] Fig.15 An exemplary authentication process using context information is depicted. Although process 1500 is described below as being performed by private system 120 and authentication server 115, in some embodiments, the process can be performed entirely by private system 120 or authentication server 115 or client system 110 or another system. According to process 1500, private system 120 can encode context data into a security tag. Authentication server 115 can then enforce context conditions on the encoded data in response to an identification request.

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

[0205] After step 1501, process 1500 may proceed to step 1503, where private system 120 may receive context information. In some embodiments, this context information may include at least one of an authentication credential (e.g., a password, an authentication token, etc.), a biometric identifier (e.g., a fingerprint, a voiceprint, etc.), a sound file, a tag identifier (e.g., a tag identifier of another security tag), or a perceptual hash value of an image. For example, a security tag may be generated to mark an item (e.g., a user identification card, a piece of meat, a bottle of wine, an item owned by an individual), and the image may depict a portion of the item (e.g., an identifying photo on the identification card, the texture of the meat, the markings on the bottle of wine, the face of the individual who owns the item).

[0206] After step 1503, process 1500 may proceed to step 1505. In step 1505, private system 120 may encode tag data and context information into a security tag. As described herein, tag data and context information may be encoded into a security tag as a selection of tag feature options, where the available tag feature options depend on a digital seed.

[0207] After step 1505, process 1500 may proceed to step 1507. In step 1505, authentication system 115 may receive an identification request regarding a security tag. As described herein, authentication server 115 may be configured to identify the tag using one or more hash values ​​of the security tag. Authentication server 115 may be configured to request a decoding instruction from private system 120. Authentication server 115 may be configured to decode the stored context information using the decoding instruction.

[0208] After step 1507, process 1500 may proceed to step 1509. In step 1509, authentication system 115 may receive additional context information. This additional context information may be received from client device 110 or another device. The additional context 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 to display to a user of client device 110 (e.g., instructions to display text "To unlock the Laava tag, take a picture of the owner's face" on a user interface of client device 110).

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

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

[0211] Fig.16A Paired security tags and ordered security tags are depicted. Security tags can have relationships with other tags to increase the level of security and authenticity. For example, a first security tag 1601 and a second security tag 1603 can be paired. Then, both the first security tag 1601 and the second security tag 1603 can be required to be scanned in order for a user to obtain information about a product or transfer ownership of a product. For example, a first security tag 1601 can be generated and placed on one shoe in a pair of shoes, and a second security tag 1603 can be generated and placed on a second shoe in the same pair of shoes. In this example, both tags are unique and identify a specific shoe in the pair of shoes, however both tags need to be read to authenticate the pair of shoes and / or transfer ownership.

[0212] In some embodiments, the paired tags can be further sorted to create sorted tags 1605. Sorted tags 1605 are a combination of the first security tag 1601 and the second security tag 1603, and provide information about the paired tags. In some aspects, the sorted tags 1605 can be the only tags available for scanning before purchase or transfer of ownership. In these aspects, the sorted tags 1605 can provide authentication of the product and basic information about the product. The sorted tags 1605 can also indicate which paired tags should be present. By way of the previous example, when a pair of shoes contains paired tags, the tags can be sorted to create sorted tags 1605. The sorted tags 1605 can be placed on the outside of a shoe box to provide information about the shoes inside the box. Once the box is opened, the first security tag 1601 and the second security tag 1603 can be scanned to check whether the correct shoes are in the box.

[0213] Fig. 16B An identification card 1607 using proximity fingerprint recognition is depicted. In addition to having a relationship with other security tags, the security tag 1611 can also have a relationship with an external image (such as a facial fingerprint 1609). By combining the security tag 1611 with the facial fingerprint 1609, the identification card 1607 can have an additional level of authenticity. The proximity fingerprint recognition works by using an object 1609 near the security tag to further authenticate the tag. In some embodiments, this can prevent the situation where a duplicate security tag is authenticated elsewhere. For example, if the security tag 1611 is copied from the identification card 1607, the security tag will still not be able to be verified without the facial fingerprint 1609. The result is a combined security ID in the form of the identification card 1607. In some embodiments, the security tag 1611 is paired with the facial fingerprint 1609, which means that both the security tag 1611 and the facial fingerprint 1609 must be presented together for authentication.

[0214] In some embodiments, identification card 1607 may be used to provide proof of identification where appropriate. For example, a police officer may ask a citizen to show identification card 1607 to ensure that the person is who they claim to be. In other embodiments, a liquor store may ask a person to show identification card 1607 to ensure that the person is not using a fake driver's license or a fake proof of age card.

[0215] Fig. 22 Paired tags throughout the supply chain are depicted. When a manufacturer makes a product, it can create a first security tag 2201 and a second security tag 2203, pair these security tags, and attach these security tags to the product. The paired tags can then be sorted and updated in the blockchain throughout the supply chain process. For example, the sorted tags can contain information about the paired products themselves 2205, information about the specific pallet on which the paired products were shipped 2207, information about the overall shipment in which the paired products were sent 2209, and information about the retailer 2211. At each stage of the supply chain process, the blockchain is updated with information about the paired products. When a customer goes to a retailer to purchase a product, they can perform ownership verification 2213 of the sorted tags.

[0216] In some embodiments, retailer control 2215 and closed consumer loop 2217 may access different levels of information. For example, closed consumer loop 2217 may only access information about the paired tag itself. This may include information about the product itself and the manufacturer. Closed consumer loop 2217 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 packaging information 2205, pallet information 2207, shipping information 2209, and retailer information 2211. Retailer control 2215 will typically not include access to the paired tag itself. Retailer control 2215 allows the retailer to track shipping information and manage logistics.

[0217] Fig.17 An exemplary two-part tag is depicted. The two-part tag may include a base tag 1710 and a cover 1720. The base tag 1710 may include a substrate that is labeled with a first security tag that encodes first tag data as a selection of potential first security data feature options. The cover 1720 may be removably adhered to the substrate containing the base tag 1710. The cover 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 not be affected by the aligned transparent portion 1721. The aligned opaque portion 1723 and the first security tag located on the base tag 1710 may encode the second tag data as a selection of potential second security tag feature options.

[0218] In some embodiments, the potential first security label feature options on the substrate label 1710 are different from the potential second security label feature options created by the opaque portion 1723 and the substrate label 1710. In other embodiments, the aligned opaque portion 1723 can cover the selected first security label feature on the substrate label 1710. In still other embodiments, the aligned opaque portion 1723 can select the potential first security label feature options on the substrate label 1710. In still other embodiments, the potential first security label feature options on the substrate label 1710 can include the presence or absence of label features at locations specified by the first security label layout. In these embodiments, the potential second security label feature options created by the aligned opaque portion 1723 can include the presence or absence of label features at locations specified by the second security label.

[0219] The first security label may be generated by first using the first label data, the first digital seed, and the first style sheet to generate a first security label encoding the first label data as a selection of potential first security label feature options. Fig.17 17. Next, the method generates a second security label that encodes the second label data as a selection of potential second security label feature options using the second label data, the second digital seed, and the second style sheet. The method then determines a difference image between the first security label and the second security label, and marks the substrate with the first security label to create a base label 1710. The method then removably adheres a cover 1720 to the base label 1710, the cover 1720 being marked with the difference image and aligned with the first security label.

[0220] In some embodiments, cover 1720 obscures portions of the first security label located on base label 1710 through opaque portions 1723 that are not present in the second security label. In other embodiments, cover 1720 depicts portions of the second security label that are not present in the first security label. In still other embodiments, cover 1720 transmits portions of the second security label that are present in the first security label located on base label 1710 through transparent portions 1721. In still other embodiments, the first style sheet used to generate the first security label can be different from the second style sheet used to generate the second security label. In still other embodiments, the substrate on which base label 1710 is marked and to which cover 1720 is attached can include a consumer product.

[0221] For example, a two-part tag can be used for additional authentication and security of a product. A two-part tag can be placed on the outside of a box being sold, the two-part tag comprising a base label 1710 and a cover 1720. The cover 1720 comprises both a transparent portion 1721 and an opaque portion 1723, so that the label has a unique appearance different from the base label 1710. In this example, a customer or retailer can scan a second label created by the cover 1720 to reveal certain information about the product. After the product is purchased and / or ownership is transferred, the cover 1720 can be removed to reveal the base label 1710. The current owner can scan the base label 1710 to reveal information completely different from the information provided by the combination of the cover 1720 and the base label 1710. The two-part tag adds an additional layer of security without increasing the complexity of the security tag itself.

[0222] Fig.181 is a flow chart of an exemplary method 1800 for providing a document using a security tag. The method 1800 begins at step 1801, in which the method associates a first security tag 1813 with a document 1811. The first security tag 1813 can be generated and paired with the document 1811. In addition, the first security tag 1813 has an identifier of the document 1811 encoded into the first security tag using a selection of a potential feature option. In some embodiments, the identifier of the document 1811 can include a hash value of the document 1811. In other embodiments, the document 1811 is encrypted to 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 computer, a smart phone, etc.), a desktop computer, a laptop computer, a server, a wearable device (glasses, a watch, etc.), and / or a device-specific hardware device. After the request to access the document 1811, the method 1800 proceeds to step 1803.

[0223] At step 1803, the method provides the first security label 1813 for display via the first user device 1821. At step 1805, the method may receive a confirmation of the request via the second device 1831, the confirmation of the request including the security label image. The second device 1831 may be a mobile device (e.g., a tablet computer, a smart phone, etc.), a desktop computer, a laptop computer, a server, a wearable device (glasses, a watch, etc.), and / or a device-specific hardware device. The method may then compare the first security label image 1813 with the security label image received from the second device 1831. If the comparison reveals a match between the first security image 1813 and the security label image received from the second device 1831, the method 1800 will proceed to step 1807.

[0224] At step 1807, the method provides the document 1811 to the first device 1821 for display. In some embodiments, the document 1811 may be watermarked with a security tag to create a watermarked document 1843. The watermarked document 1843 may have a new security tag, or may be watermarked with the first security tag 1813. In other embodiments, the first device 1821 may become an authorized user device 1841. In some embodiments, the authorized user device 1841 may access the watermarked document 1843 for a predetermined period of time. When the predetermined period of time ends, the authorized user device 1841 loses its authorization 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 still other embodiments, a second authorized user device may read the watermarked document 1843 after the authorized user device 1841 has marked the document as read.

[0225] In some embodiments, comparing the first security tag 1813 with the security tag image received from the second user device 1831 may include generating a perceptual hash value for the first security tag 1813, generating a perceptual hash value for the security tag image received from the second user device 1831, and determining whether a difference between a stored perceptual hash value and the generated perceptual hash value satisfies a threshold criterion. In other embodiments, comparing the first security tag 1813 with the security tag image received from the second user device 1831 may include generating a perceptual hash value for the security tag image received from the second user device 1831, selecting the first security tag using a difference between the generated perceptual hash value and a stored perceptual hash value for the image of the first security tag, generating a second perceptual hash value for a predetermined segment of the security tag image received from the second user device 1831, and selecting the first security tag 1813 from the first security tags using a difference between the generated second perceptual hash value and a stored second perceptual hash value for a predetermined portion of the image of the first security tag.

[0226] In some embodiments, the confirmation request at step 1805 may include a confirmation request identifier. In this embodiment, providing the document to the first device 1821 at step 1807 based on the comparison may further include: generating a second security tag paired with the request, the second security tag encoding the confirmation request identifier using a selection of potential tag feature options, and watermarking the document 1811 with the second security tag. In these embodiments, the watermarked document 1843 does not include the watermark of the first security tag 1813.

[0227] In some embodiments, method 1800 may further include determining that receipt of the security tag image satisfies authentication criteria. In some aspects, the authentication criteria may be related to the number of confirmation requests associated with the first security tag 1813. In other aspects, the authentication criteria may be related to the time that has passed since the first security tag 1813 was provided to the first device 1821. In still other aspects, the authentication criteria may be related to the geographic origin of the confirmation request. In still other aspects, the confirmation request may include a confirmation request identifier, and the authentication criteria may be related to the confirmation request identifier. In these aspects, the authentication criteria may be satisfied when the access identifier of the access request matches the confirmation identifier of the confirmation request.

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

[0229] Fig.19 An exemplary variable security label is depicted. The variable label can be digitally animated over time by morphing between a glyph and a label. For example, at a first time, the label (which can be a variable label) can be in the form of a series of small dots without additional label features, or in the form of an invalid frame 1901. The invalid frame 1901 can change within a predetermined time period to become a valid frame 1903. The valid frame 1903 can be read by an appropriate reading device and can return data. In some embodiments, the variable label can be authenticated by a single frame in the variable label process. In other embodiments, the variable label can be authenticated by several frames in the variable label process. In still other embodiments, authentication can be performed only based on the order of appearance of the frames in the variable label process. In still other embodiments, the invalid frame 1901 can include a "junk label" or a type of label that may appear valid but does not return information. The variable label can be read by any form of readable device (such as, for example, a camera).

[0230] In some embodiments, the variable tag process can be triggered by a flip event or a click event. In these embodiments, the tag is static before the triggering event and enters the variable tag process after the triggering event. In other embodiments, the tag can be set to enter the variable tag process during a certain time frame. For example, the tag can be set to change between 8 pm and 8 am to achieve additional tag security throughout the night. In still other embodiments, the variable tag contains a valid frame 1903 paired with another valid frame. In these embodiments, the user may be required to scan the two paired frames to authenticate the tag.

[0231] A system for generating a mutable security label may include at least one processor and at least one non-volatile memory, the at least one non-volatile memory containing instructions that, when executed by the at least one processor, cause the system to perform operations that may include: generating a first security label that encodes label data to select label feature options based on the value of the label data; receiving a request including a label image sequence from a scanner of a second device, the label image sequence including a first label image; authenticating the request using the first security label and the first label image; and providing an indication of the authentication of the request.

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

[0233] In some embodiments, the authentication request may include comparing one or more perceived hash values ​​of the first security label displayed in the valid frame 1903 with one or more corresponding hash values ​​of the first label image. In other embodiments, the authentication may further require matching the multiple security labels with the multiple corresponding label images according to a predetermined order of appearance. In still other embodiments, the indication of the requested authentication may include at least some of the label data. In still other embodiments, the indication of the requested authentication may include decoding instructions for decoding at least some of the first label data. In still other embodiments, the indication of the requested authentication may include state information retrieved from a database. In some aspects, the database may be a distributed database, and the state information may be retrieved from the distributed database using an oracle database.

[0234] Fig. 20An exemplary system 2000 for inventory management using a database consistent with the disclosed embodiments is depicted. Although the system 2000 is described below as being performed by a client system associated with different entities in the supply chain, in some embodiments, the system can be performed by the authentication system 115, the proprietary system 120, or another system. In some embodiments, the manufacturing system 2001 can be configured to provide a database (e.g., database 125) with status information of a security tag. In some aspects, the manufacturing system 2001 can be configured to update the status of an account 2010 of the database with status information about a security tag or an item marked with a security tag. The manufacturing system 2001 or another system can be configured to provide application keys to the distribution system 2003 and the retailer system 2005. These application keys can allow the distribution system 2003 and / or the retailer system 2005 to update or modify the status of the account 2010. Alternatively or additionally, the status of the account 2010 of the database can include rules governing access rights to the account. In some embodiments, the client system 2007 can lack an application key. Therefore, in some embodiments, the client system 2007 may have a default access level to the database. For example, the client system 2007 may have read-only access to the state information described in the account 2010.

[0235] The client device may scan a security tag associated with account 2010. Scanning the security tag may cause the client device to interact with authentication server 115 to decode the security tag. In some embodiments, the client device may be configured to provide authentication information (e.g., application keys or authentication credentials) to authentication server 115 and update information.

[0236] In some embodiments, using the information decoded from the security tag, the authentication server 115 can be configured to update the account 2010. In some aspects, the authentication server 115 can be configured to provide the update information and the address of the account to an oracle database. The oracle database can then write the update to the account 2010. In some embodiments, the authentication server 115 can be configured to provide the information to a private database. The private database can be configured to collect updates, which can be periodically written to the database.

[0237] In various embodiments, using the information decoded from the security tag (e.g., the address of account 2010 in database 125), 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 database. The request can include the address of the account. The oracle database can then read the state of account 2010 to retrieve the state information, which is then transmitted to the client device (either directly or through one or more of the oracle database and the authentication server).

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

[0239] Consistent with the disclosed embodiments, a client device associated with the manufacturing system 2001 can scan a security tag. For example, a worker can use a client device to scan a security tag when an item tagged by a security tag is leaving a manufacturing facility associated with the manufacturing system 2001. The manufacturing system 2001 can be configured to use the system 2000 to update the account 2010 with information about the manufacturing of the item. In some embodiments, the manufacturing system 2001 can then access the portal to read the information about the security tag stored in the account 2010. For example, when the manufacturing system 2001 uses an application key or credential associated with the manufacturer (via the authentication server 215 or an oracle database) to access the system 2000, the manufacturing system 2001 can retrieve status information including at least one of tracking information, sales information, customer data, usage information, activation information, or location information.

[0240] Consistent with the disclosed embodiments, a client device associated with the distribution system 2003 can scan the security tag. For example, when receiving an item marked by a security tag for transport, a worker can use a client device to scan the security tag. Based on this scan, the distribution system 2003 can be configured to use the system 2000 to retrieve status information about at least one of authenticity information, destination information, or manufacturer information. The distribution system 2003 can be configured to use the system 2000 to update the account 2010 with information about the distribution of the item. In some embodiments, the distribution system 2003 can then access the portal to read the information about the security tag stored in the account 2010. For example, when the distribution system 2003 uses an application key or credential associated with the distributor (through the authentication server 215 or an oracle database) to access the system 2000, the distribution system 2003 can retrieve status information about at least one of authenticity information, destination information, or manufacturer information.

[0241] Consistent with the disclosed embodiments, a client device associated with the retailer system 2005 can scan a security tag. For example, when receiving an item marked by a security tag from a distributor, a worker can use a client device to scan the security tag. Based on this scan, the retailer system 2005 can be configured to use the system 2000 to retrieve status information about at least one of authenticity information, transaction information, product information, or tracking information. The retailer system 2005 can be configured to use the system 2000 to update the account 2010 with information about the receipt or sale of the item. In some embodiments, the retailer system 2005 can then access the portal to read the information about the security tag stored in the account 2010. For example, when the retailer system 2005 uses an application key or credential associated with the distributor (via the authentication server 215 or an oracle database) to access the system 2000, the retailer system 2005 can retrieve status information about at least one of authenticity information, transaction information, product information, or tracking information.

[0242] Consistent with the disclosed embodiments, the client device 2007 may scan the security tag. In some embodiments, the client device 2007 may lack an application key or authentication credentials. In such embodiments, the system 200 may provide relatively little information about the item tagged with the security tag 105. For example, the client device 2007 may be able to retrieve at least one of authenticity information, product information, or proof of ownership information.

[0243] As described herein, the state of the account may store state information including state information of a security tag indicating at least one of tracking information, sales information, customer data, usage information, activation information, location information, authenticity information, destination information, updated manufacturer information, transaction information, product data, or proof of ownership information. The specific allocation of access rights to this information between manufacturers, distributors, retailers, and customers is intended to be exemplary and not limiting.

[0244] Fig.21 An exemplary system 2100 for modifying security tag information in a database consistent with the disclosed embodiments is depicted. Although the system 2100 is described below as being executed by a client system, in some embodiments, the system may be executed by the authentication system 115, the private system 120, or another system. Fig. 20 As described, the system may access the database during an interaction involving a security tag or using the portal to read or write information about the state of the security tag. Fig.21 As shown, a user with a privileged account (e.g., as shown by a privileged application key or privileged authentication credentials) can access the database to update the status information to cancel the tag. This can invalidate the tag for subsequent use or transactions. For example, if user 2103 later attempts to use the tag to perform an action, authentication server 115 can indicate that the tag is canceled and refuse to recognize the tag, authenticate the tag, or perform the action.

[0245] Fig. 22 Depicted is a process for tracking inventory using security tags. As shown, paired tags (e.g., tags 2201 and 2203) can be used to bind two shoes together, as described with respect to Fig.16A and Fig. 16B Shoes may be paired with the shoe boxes containing them by marking the shoe boxes with tags 2205 that are paired with each of tags 2201 and 2203. Tags 2207 of the shoe box box may be paired with tags 2205. Tags 2209 of the shipping container may be paired with tags 2207 of the shoe box box. Retailer tags 2211 may be paired with tags 2209 of the shipping container. Transfer of ownership to the customer may be associated with the generation of tags 2213, as described below with respect to Fig.23 In some embodiments, tag 2213 may be paired with individual shoe tags 2201 and 2203. Throughout this inventory tracking process, the account associated with the described tag may be updated with tracking information, location information, and other status information, such as information about Fig. 20 and Fig.21As shown, at least the retailer can access information for these tags in an account under the retailer's control (within the retailer control loop 2215), while the customer can access information for tags 2201, 2203, and 2213 in the account.

[0246] Fig.23 Depicted is a process of transferring ownership of an item using a security tag. The tag verification process may involve pairing a uniquely generated digital security tag with an original manufacturer security tag 2301. In some embodiments, a product with an original manufacturer security tag 2301 is received by a seller. The original manufacturer security tag 2301 is recorded in the seller's system and associated with the product online. Then, potential customers can view the product online. Each potential customer will see a uniquely generated tag that contains auxiliary data that can authenticate the product when scanned. Each uniquely generated tag is paired with the original manufacturer security tag 2301. For example, a unique security tag 2303 will be shown to a potential buyer. The unique security tag 2303 is similar to the original manufacturer security tag 2301, but contains unique auxiliary data. In addition, the unique security tag 2303 is paired with the original manufacturer security tag 2301. Therefore, the user can confirm the authenticity of the product while maintaining the unique security tag 2303, which can contain information about the time and date of viewing the product. In other embodiments, potential user two may be presented with unique security tag two 2305, potential user three may be presented with unique security tag three 2307, potential user four may be presented with unique security tag four 2309, and potential user five may be presented with unique security tag five 2311. In each embodiment, the unique security tag is paired with the original manufacturer security tag 2301.

[0247] In some embodiments, when a buyer purchases a product, the seller may assign the original manufacturer security tag 2301 to the buyer. In other embodiments, the original manufacturer security tag 2301 may 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 in the blockchain. After the purchase and assignment, it will not be possible to generate an additional unique security tag and pair it with the original manufacturer tag 2301. In some aspects, a potential customer may be notified of the purchase via a paired unique security tag. For example, the pairing between the original manufacturer security tag 2301 and the unique security tag may be terminated. In another example, the unique security tag may notify a potential customer of the purchase via updated information on the blockchain.

[0248] Fig.24AAn exemplary security label is depicted. The security label may include various technical components. For example, these technical components may include: verification fragments, outer and inner frames, outer frame segments, outer frame blocks, dots, glyphs, lines and splines, Laava stage-ID, center graphics, center graphics public keys, and additional technical features as described in more detail below. These technical components may further be used to encode data in various forms. These technical components are described in more detail below.

[0249] The central graphic can be a graphic, brand, or other visual, and can be an end-user recognizable element that also contains fingerprint data. In some embodiments, the central graphic can be used for orientation of the security label. In other embodiments, the central graphic can be a set of glyphs that can contain data. For example, the central graphic can contain a fingerprint signature that is smaller than the larger label and can contain 128 characters of information in readable text if desired. In still other embodiments, the central graphic can be used to display the brand. In such embodiments, the central graphic can be any shape and can have a color. The central graphic can be further surrounded by a line with a contrast difference to separate the central graphic from the rest of the label. In some embodiments, the line may be required to have a certain thickness.

[0250] The central graphic public key can be a hashed SHA2 version of the central graphic, typically a larger generated number. The central graphic public key can be used to unlock other parts of the tag, as described in further detail below. The Laava Phase One ID can be a manufacturer ID and public key, and can allow the tag to be identified before any data is read. The glyphs can typically be individual shapes or characters generated within the tag, and can be where most data, keys, IDs, etc. are stored. The outer frame is the border of the outside of the security tag and defines the scan shape. The outer frame can also allow additional functionality and data storage. The inner frame can be an optional border around the central graphic inside the security tag, and can be used to visually separate the glyphs from the central graphic. In addition, the inner frame can be used to assist in fingerprinting of the central graphic and can contain data.

[0251] A verification fragment may be a specific image data set and may be used for verification, comparison, and data storage. A verification fragment may include a variety of elements, such as a central graphic and other variable elements. A dot may be a point on a security label at which a blank space becomes a visible shape or circle. A dot may store a variety of data elements and define a label, and may be a starting point for forming a glyph. Splines and lines may be shapes that join or fuse two or more dots together, and may allow for storage of larger amounts of data and stronger encryption or encoding. An outer frame segment is an identifying portion of an outer frame and may be used to store or repeat data. An outer frame block may be a collection of breaks in an outer frame segment and may be used to store data.

[0252] Fig. 24B A portion of a graphics file corresponding to an exemplary security label is depicted. The graphics file represents Fig.24A . This graphics file is created during the label generation process, which will be discussed in more detail below.

[0253] Fig.25A Depicted are security label 2501, security label 2503, and security label 2505, each of which is generated using the same style sheet but using different data. The style sheet provides a label template for the first step of security label generation. In some embodiments, the style sheet describes a class of security labels. After receiving the style sheet, the label generation process will receive a digital seed, generate a security label layout, and receive label data before generating the final security label. The style sheet and digital seed provide a location where data can be encoded. The data is then encoded into label feature options. In Fig.25A In the example, security labels 2501, 2503, and 2505 are all generated using the same style sheet in the first step of the security label generation process, but different data is provided before the final security label is generated. During the label generation process, the label generation system can select from the same primary and secondary positions based on the style sheet of security labels 2501, 2503, and 2505, thereby generating certain similarities between the security labels. After the layout of each exemplary security label is generated, the data is encoded into the label feature options to generate a unique design.

[0254] Fig.25B Describe security label 2511, security label 2513 and security label 2515, they are each generated using different style sheets but using the same label data. As discussed above, the style sheet is used in the first step of the label generation process. Security labels 2511, 2513 and 2515 each start the label generation process with different available primary and secondary positions. As with the previous example, the data is encoded after the primary and secondary positions are identified and selected. Since data can be encoded into various label features, and the label generation algorithm can produce a randomized design, the same label data may produce significantly different final security label designs. Security labels 2511, 2513 and 2515 will all return the same data when scanned, but each security label has a unique design.

[0255] FIG. 26A to FIG. 26N Details of potential security tag features are depicted. Each figure is described in more detail below.

[0256] Fig.26AThe potential features of an exemplary security tag are depicted. Each of the potential features can be used to encode data or for fingerprint recognition. These potential features include: major inner dots, outer breaks, inner breaks, inner edge fusions, outer horizontal fusions, inner frames, owner IDs, minor inner dots, inner horizontal fusions, outer frames, outer edge fusions, short fusions, minor outer dots, inner deformations, outer deformations, nodules, and long fusions. As discussed in more detail below, each of these potential features can be used to encode information. Additional variable useful resources (assets) can be used to embed additional data or encrypt information. For example, variable useful resources can include indentations, depressions, colored shapes, gradients, connecting lines, and embedded symbols.

[0257] In some embodiments, the security tag may include additional features to authenticate the product or store information. For example, a background pattern or texture may be placed behind the tag subtly or invisibly. Similarly, in another example, an adjacent pattern or texture may be used to provide additional authentication or storage information. In another example, a Penrose Tile graphic pattern may be used for fingerprinting or to distinguish a particular set of tags. Still in another example, adjacent information (such as a unique word set) may be placed near the tag. This design may be useful when human-readable ID confirmation is required (such as, for example, in customer support instances).

[0258] Fig.26B An exemplary label is depicted showing position vectors 2601. After the placement of the dots and shapes and any displacements are determined, position vectors 2601 disclose the final positions of the dots and shapes in the exemplary security label. Position vectors 2601 provide information about the position of each shape, dot, and label feature in the security label.

[0259] Fig.26C An example of offset dot alignment is depicted. As disclosed above, the layout of an exemplary security label can be determined after receiving a style sheet describing a class of security labels and a digital seed. Layout position 2603 depicts the position of an exemplary dot after generating a security label layout. After receiving the label data, a security label is generated as a label feature option. Some label feature options involve alignment and positioning of dots and shapes. Displacement position 2605 depicts the final position of an exemplary dot after the label data is encoded as a label feature option. The difference between layout position 2603 and displacement position 2605 may be indistinguishable to the human eye, making it difficult to copy such a label. The label generation system is designed to make the grid more unpredictable than a standard grid. In some embodiments, the resolution may allow the displacement position 2605 to be adjusted from layout position 2603 based on grid offset, line length, angle, etc. In such embodiments, these adjustments may allow additional information to be encoded into the label.

[0260] Fig.26D An exemplary security label showing a dot connect feature option 2608 is depicted. The dot connect feature option 2608 can span any distance within the outer frame of the security label to reach other dots. In some embodiments, the dot connect feature option 2608 can be established as a straight line between dots. The dot connect feature option 2608 cannot pass through the center image to reach another dot.

[0261] Fig.26E The dot join feature option 2608 is depicted after the data has been encoded to create splines and edge joins. The shapes formed by the splines are called glyphs. As discussed above, glyphs can be individual shapes or characters generated within a label and can be where most data, keys, IDs, etc. are stored. In some embodiments, spline mathematics can be used to contain encrypted or encoded information. For example, elliptic curve cryptography can be used. Edge joins can also be used to store data.

[0262] Fig.26F and Figure 26G Small dots and lines are depicted as vectors for the same exemplary label layout. Security labels are generated in vector format and are defined from 2D points using connecting lines and curves. The vectors in these images show the variable spline origin and the thickness of the spline or line that can be used to encode data. Fig.26F A first connection width 2607 is depicted, and Figure 26G A second connection width 2609 is depicted. The first connection width 2607 is depicted as being greater than the second connection width 2609. The first connection width 2607 and the second connection width 2609 may be encoded using the same or different data.

[0263] Fig.26H An exemplary label showing an edge connection feature option 2610 is depicted. An edge connection can be formed from any potential edge connection feature option 2610. The edge connection feature option 2610 provides the possibility of forming an edge connection between an inner frame or an outer frame. Once an edge connection feature option 2610 is selected to convert it into an edge connection, data can be encoded into the shape. For example, the edge connection can be encoded with data representing a manufacturer number.

[0264] Fig.26H and Fig.26I Small dots and edge connections are depicted as vectors for the same exemplary label layout. The vectors in these images show variable edge junction origins and thicknesses that can be used to encode data. Fig.26I depicts a first edge connection size of 2611, and Fig.26HA second edge connection size 2613 is depicted. The first edge connection size 2611 is depicted as being larger than the second edge connection size 2613. The first edge connection size 2611 and the second edge connection size 2613 may be encoded using the same or different data.

[0265] Fig.26J Various glyphs and potential spline features of an exemplary security label are depicted. A glyph set can be generated using a large number of splines and placed in a flexible coordinate system. In some embodiments, the glyphs can be mathematically generated using a blend curvature algorithm. In other embodiments, the glyphs can be generated based on predetermined shapes. For example, a customer can set the glyph to a specific shape based on the customer's product or service request. In this example, the glyph set can be clearly identified and specially designed. The thickness of the splines of the glyphs can vary based in part on the starting position of the splines on each dot. In some embodiments, the glyphs can be formed between any number of dots. Data can be contained around the glyphs as a microstructure, or data can be contained within an algorithmic method that stores data in a path. Fig.26J Only a limited number of possible glyphs and spline features are depicted.

[0266] Figure 26K Depicted are 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.

[0267] Figure 26LDepicted are microdots 2621 and microprinting 2623, both of which can be used to encode data. Microprinting 2623 can include a second binary data set that can be interpreted in a similar manner to the outer frame and outer frame break data. At lower resolutions, microprinting 2623 can appear as noise. At higher resolutions, microprinting 2623 can include information about the grid position of the fingerprint data. This information can include X or Y grid numbers and offset values. In some embodiments, as long as there are enough microprinting 2623, the tag can be encrypted. In other embodiments, microprinting 2623 can include different colors. In such embodiments, microprinting 2623 can store additional information in the same physical space. Still in other embodiments, the outer frame can include microprinting 2623 on both the inside and outside of the line. In such embodiments, microprinting 2623 on both the inside and outside can be colored. In other embodiments, microprinting 2623 can store additional binary data by changing the height of its blocked segment. In such embodiments, due to the small physical size of the binary code, it may be difficult to copy the binary code. Microprinting 2623 can be used for advanced data storage and can be accessed by very high resolution cameras.

[0268] Figure 26M The same location is depicted using three different color fill gradients: unfilled 2625, filled with different colors 2627, and filled with the same color 2629. Data can be encoded into the security label based on the gradient and the color of the location.

[0269] Fig.26N An exemplary tag feature 2631 and data encoded into the tag feature 2631 are depicted. The tag feature 2631 depicts two dots connected by a connection, or two bits connected by a third bit, wherein a detail region 2633 contains the encoded data. The detail region 2633 may include a spline wrapped around the edge of one of the dots. The detail region 2633 may be read by starting at a starting position 2635 and moving along a read direction 2637. The detail region 2633 may have a first spatial frequency and a second spatial frequency, the first spatial frequency having the potential to encode 3-bit data (value A), and the second spatial frequency having the potential to encode 18-bit data. The value A set bit 2639 represents a 1 at the first spatial frequency, and the value A unset bit 2641 represents a 0 at the first spatial frequency. The value B unset B represents a 0 at the second spatial frequency, and the value set bit 2645 represents a 1 at the second spatial frequency. After the 3-bit encoded data and the 18-bit encoded data, there is a repetition 2647.

[0270] FIG. 27A to FIG. 27J Depicted is the generation of an exemplary security tag. Each of the figures is described in more detail below.

[0271] Fig.27A An exemplary grid used as a substrate in the security label generation process is depicted. The grid includes potential primary positions 2701 and potential secondary positions 2703, which are the basis for glyphs 2705. The formation of the grid is the first stage of security label generation and is completed using a specific algorithm to create a randomized design. Potential primary positions 2701 and potential secondary positions 2703 determine the final position and shape of glyphs 2705. Glyphs 2705 can span any number of potential primary positions 2701 and potential secondary positions 2703.

[0272] Fig.27B Depicted are selected primary locations 2707 and unselected primary locations 2709. At this stage of the label generation process, potential primary locations 2701 are identified and selected. The label generation algorithm randomly selects a predetermined number of potential primary locations 2701. The selected primary locations 2707 will then be used further in the secure label generation process, while the unselected primary locations 2709 are no longer part of the label generation process. Fig.27B There are 26 selected primary positions 2707 that are randomly selected, resulting in one of 72 trillion possible combinations.

[0273] Fig.27C Depicted are identifications of potential secondary locations 2711. Potential secondary locations 2711 may include any secondary locations located between the selected primary locations 2707. Fig.27C In , 40 potential secondary positions 2711 are identified, resulting in approximately 1 trillion sub-combination possibilities.

[0274] Fig.27D Depicted are unselected secondary locations 2713 and selected secondary locations 2715. Selected secondary locations 2715 are selected from previously identified potential secondary locations 2711. Selected secondary locations 2715 may be selected by the system based on a tag generation algorithm and may be used to connect selected primary locations 2707 to separate selected primary locations 2707.

[0275] Fig.27EA secondary grid is depicted showing selected primary positions 2707 and selected secondary positions 2715 immediately before and after processing by a visualization engine during security label generation. A secondary grid including selected primary positions 2707 and selected secondary positions 2715, or a final secondary grid, can be passed to a visualization engine for further security label generation. Certain selected primary positions 2707 are bridged by selected secondary positions 2715. Selected secondary positions 2715 are used to create connections between selected primary positions 2707, thereby generating glyphs. In some embodiments, the shape of the curve on each glyph can contain data. Additional code variants can be introduced into the structure based on shape construction. Selected primary positions 2707 that are not bridged by selected secondary positions 2716 can remain as separate dots. In some embodiments, dots can contain data.

[0276] FIG. 27F to FIG. 27I Different possible glyphs 2717 based on a selected primary position 2719 and a selected secondary position 2721 are depicted. In each figure, the tag generation algorithm may have identified any secondary position as a potential link. Each figure depicts a different possible glyph 2717 based on a selected secondary position 2721. Fig.27F and Fig.27H Each depicts a glyph 2715 in which a selected primary position 2719 is connected to at least one but not more than three selected primary positions 2719, however, Fig.27H Selected primary positions 2719 connected in series are depicted. Figure 27G A glyph 2717 is depicted where a selected primary position 2719 is connected to each selected primary position 2719. In this figure, a selected secondary position 2721 may cause the selected primary position 2719 to form a larger circle or a small dot. Fig.27J Glyph 2717 is depicted where only three of the five selected primary positions 2719 are connected via selected secondary positions 2721. In this figure, the final label would include glyph 2717 and two separate dots. FIG. 27F to FIG. 27I Each glyph in 2717 can have data encoded into it.

[0277] Fig.27J An exemplary security tag with orientation information 2723 is depicted. Orientation information 2723 can be placed in the center of the security tag as a center image. Orientation information 2723 can be used in the tag recognition process to allow an optical reader to correctly identify the correct tag. In some embodiments, the orientation information can include a logo, brand, or any other identifier.

[0278] FIG. 28A to FIG. 28NDepicted are exemplary security tags. Each tag is described in more detail below.

[0279] Fig.28A Security labels of various form factors are depicted. The outer frame of the security label can be any shape. For example, a customer may request that the label be designed to match a specific image. In this example, the desired image may serve as both a security label and a trademark. In some embodiments, the security label may not have a central image. In these embodiments, label orientation may be achieved based on the design of the outer frame of the security label. In other embodiments, the central image may be a custom image provided by the customer. Fig.28A Examples of possible form factors are depicted, such as the shape of Australia and Nike TM Swoosh.

[0280] Fig.28B A series of exemplary labels are depicted. Each of these labels has a symmetrical design and a series of small dots with no connecting lines or splines. In the normal security label generation process, the possibility of creating a symmetrical security label is very low. However, the security label generation process can also be controlled to create aesthetically pleasing labels, such as Fig.28B In these examples, a design is chosen and the data can be encoded into the chosen design.

[0281] Fig.28C An example of a security tag integrated with a barcode is depicted. In some embodiments, the security tag can be read together 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 for SKU-based barcode readers and provide unique identification. The security tag can contain matching data related to the barcode. This can prevent fraudulent use or abuse of both the barcode and the security tag.

[0282] Fig.28D An exemplary security label is depicted. In some embodiments, an exemplary security label may have a central image overlaid on a color or black background. In other embodiments, the security label may not have an inner frame. In still other embodiments, the security label may have an inner frame that is a different shape than the outer frame.

[0283] Fig.28E An exemplary security tag with a symmetrical pattern and a central image of Laava is depicted.

[0284] Fig.28F An exemplary security tag with a symmetrical pattern and a central image of Laava is depicted.

[0285] Figure 28GAn exemplary square security label with a symmetrical pattern and a central image of Laava is depicted.

[0286] Fig.28H An exemplary square security label with a symmetrical pattern and a central image of Laava is depicted.

[0287] Fig.28I An exemplary security label is depicted without a central image and without connecting lines between the dots.

[0288] Fig.28J An exemplary square security label is depicted with a Laava center image and no connecting lines between the dots.

[0289] Figure 28K An exemplary security label with a Laava center image and a narrow thickness line is depicted.

[0290] Figure 28L An exemplary square security label with a Laava center image and a narrow thickness connecting line is depicted.

[0291] Figure 28M An exemplary security tag with a symmetrical pattern and a central image of Laava is depicted.

[0292] Fig.28N An exemplary square security label with a symmetrical pattern and a central image of Laava is depicted.

[0293] Fig.29A An exemplary user interface for managing security tags is depicted. Fig.29A In the dashboard tab, the security label activity within a 24-hour period is displayed. In some embodiments, the dashboard of the user interface can provide information including an overview of all security labels for a single customer, the number of security labels by location, associated user information, and associated dealer information. The user interface has various tabs that can be used for user interaction, and these tabs can include: label management, label design, label printing, reports, statistics, account information, API settings, user management, etc.

[0294] Fig.29B An exemplary user interface for requesting a security label design is depicted. The tab design user interface may provide a user with various options for creating a security label. For example, a user has the option to select whether they want to nest security labels and whether they want to pair security labels. Other potentially customizable options include: customer center badge, encrypted ID, custom DB synchronization, whether the security label is user readable, whether to obfuscate (multiple) IDs, offline readability, whether to have an embed location, dealer access rights per ID, whether to use the Laava blockchain, and whether the security label is terminable. Fig.29B In the example, the user has selected 4 layers of nested tags, where the top layer is paired. Each layer of security tags can contain different information. In this example, the user has the ability to control what information each layer can provide and what keys are required to access each security tag.

[0295] In some embodiments, system 100 (e.g., authentication server 115 or proprietary 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 a report containing information about the unauthorized copies. For example, system 100 may be configured to generate a report that can be viewed through Fig.29A and Fig.29B The user interface of the security tag displays a heat map showing where and how often unauthorized copies of security tags are detected.

[0296] Example use cases

[0297] Security tags can be used to assist customers and retailers in buying and selling products such as alcohol. Before buying, customers can verify the authenticity of alcohol (such as, for example, a wine bottle) and receive information about the wine bottle, including: previous owner, retailer, manufacturer, date of manufacture, ingredients, instructions for use, safety warnings, and any other relevant information. Before selling, retailers can scan tags to review information, which can include: using logistics to confirm arrival, viewing retailer quotes for vineyards, viewing manufacturers and manufacturing data, viewing inventory of wine bottles, viewing ingredients, viewing customer sales records, determining store locations, setting return policies, setting "per bottle" quotes, setting up a chance to win prizes if you buy a bottle of wine, viewing safety warnings, viewing instructions for use, and performing any other relevant actions. At checkout, retailers can transfer ownership of the wine bottle to customers, and customers can use security tags to take advantage of additional benefits (e.g., reordering, reviewing, etc.). In some embodiments, the wine bottle can have a second security tag placed on the inner side of the wine bottle cap to provide additional authenticity after opening the bottle, which can be paired with the security tag on the outer side of the wine bottle.

[0298] Security tags can be used to authenticate web pages, emails, or other digital products. For example, a website may have a unique security tag for each page that serves as a digital token for authenticating the web page itself. Security tags can be changed after a predetermined period of time, and tags can also be terminated once displayed or timed out. Users can authenticate web pages, emails, etc. using a browser that uses a security plug-in or by scanning the security tag itself using an optical reading device (such as a smart phone). Security tags can be used to verify service date and time, website or email provider, web page or email security information, or any other information unique to the web page or email.

[0299] Multiple forms of membership can be managed within a single security tag that is owned by the customer and paired with or shared by permitted businesses. A customer may have various forms of ID and / or memberships, such as, for example, health insurance cards, student IDs, gym memberships, travel memberships, etc., encoded into a single personal physical or digital security tag. Each business associated with an encoded form of ID and / or membership can be given access rights to only check the security tag for the specific ID and / or membership associated with that business. Thus, the customer can present the same single security tag in each instance without having to carry around multiple forms of ID.

[0300] The security tag can be used to create a certified protected personal ID for online and offline use. The user can take their official ID (credit card, passport, etc.) to the relevant institution (bank, passport office, etc.) to verify the ID, and the confirmed ID provider is connected to the user's personal ID blockchain. The certified protected personal ID can be read by the appropriate institution and can be used in situations such as: elections and voting, push bank statements, secure messaging, secure email, building entrance, membership, proof of age card or any other application that requires personal identification. The protected identity is owned by the user, but the relationship is paired with the official ID issuer, which means that the official ID issuer can revoke the ID.

[0301] Businesses can use security tags to create authenticated personal IDs for customers. Businesses such as banks can provide customers with personal IDs associated with the user's account and also provide specific access rights to readers (e.g., through an app specific to the business). A physical or digital document with specific information for the customer can contain a tag that can only be read by a user with the correct personal ID associated with the document. If the user has the correct personal ID associated with the document, access rights corresponding to the level allowed by the personal ID will be granted. In addition, authenticated personal IDs can be used to verify customers at, for example, an ATM or bank. Businesses can receive notifications whenever a user scans a document without the correct personal ID or when a personal ID cannot be used to verify a customer.

[0302] Security tags can be used to authenticate artworks and other valuable commodities, and allow artists to potentially earn revenue from ongoing / future sales. A security tag can be attached to an original work of art and paired with a second security tag indicating ownership and a third security tag retained by the artist. Both the security tag on the artwork and the second security tag indicating ownership can contain information about the artwork itself, the current owner, the artist, and the art dealer, and both security tags may be required for the sale and transfer of ownership. The artist can retain his or her paired tags and can receive a notification when ownership is transferred, which can potentially include a percentage of the revenue from the transfer of ownership. In some embodiments, the artwork can be authenticated using close-range fingerprint recognition using, for example, a wood grain pattern near the tag on the artwork frame. The close-range fingerprint is invisible to the customer, and if the tag is moved, it may not be authenticated and authenticity may not be proven.

[0303] Other valuable products with very specific requirements, such as infant formula, can be authenticated using security labels. Infant formula can have both external and internal security labels. The external label can contain important information, such as instructions for use, manufacturer ID, market information, safety information, or any other relevant information, and all potential customers can scan the external label. Once the infant formula is purchased and ownership is transferred, the current owner can access the information contained on the internal security label. The internal security label will usually be paired with the inventory ID or retailer ID by the pallet ID or shipment ID, thereby giving the customer access to the complete supply chain information about the specific infant formula purchased.

[0304] Security tags can be used to track lost items and return those items to their owners. Users can print their own security tags or purchase security tags in various form factors that contain information about the owner. Security tags can be paired with a Lost and Found account via an app or other program and attached to an item. Whenever a tag is scanned, a notification is sent to the tag owner with information about the scan, such as the time and location. The owner can choose whether to disclose certain information if someone else scans the tag, including information about how to contact the owner or return the item.

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

[0306] Security tags can be used to authenticate gaming tokens or other gaming coins. Each token or coin is given a security tag that can be paired with an embedded RFID ID in the token or coin. The combination of security tags and RFID can be managed in a blockchain, allowing gaming rooms to track each token or coin in a variety of ways. Users can also check security tags with a reading device they own to ensure they have a legitimate token or coin in their hands. Additionally, the unique tag on the token or coin can be used as a visual deterrent to the creation of counterfeit tags.

[0307] Sweepstakes and other promotions can be managed through the use of secure tags. Companies can create tickets on the blockchain. Customers can then purchase digital or physical tickets associated with the ticket on the blockchain and display the tag on the ticket. The ticket can then be scanned and the customer can receive information about whether they have won or not, and the results of the win or not can be updated in the blockchain. In some embodiments, the ticket can be a tag that can be scanned before purchase to reveal basic information about the sweepstakes company, retailer, etc., and has a portion that can be scratched off to reveal a new tag that can be scanned by the current owner to reveal the results of the win or not.

[0308] The secure tag can be used to serve promotional ads to specific customers. A promotional ad can be served to a customer online that contains a specific tag unique to that customer. The customer can then visit a website associated with the ad and print a coupon with the secure tag that has the specific ID and promotional data embedded into it. The customer can then visit a physical store and redeem the coupon, and the physical sale will then be tied to the digital theme icon associated with the original ad.

[0309] Security tags can also be used for general promotions. For example, a car company could create a custom tag to be publicly advertised for vehicle giveaways or to book a test drive. Security tags can be made available to the public and scanned by anyone. Security tags can be animated based on a set formula so that they contain the location, time, and other data required for each view, making each customer scan unique. Each scan will be uploaded to the blockchain, and the company can set up suitable promotional rules to reward certain scans.

[0310] Physical cryptocurrency can be authenticated using security tags. Users can load cryptocurrency onto physical tickets printed with security tags. Security tags can be tied to a specific owner through an access key or can be open to the public for anyone to use offline. Security tags can be verified at the checkout counter and information about the transaction can be uploaded to the blockchain. In some embodiments, security tags can be paired with another form of identification, such as RFID.

[0311] Security tags can be used to control access to confidential items, such as those used by the military or other non-public organizations. Private security tags can be created where information is stored on a private blockchain. Designated personnel can be granted different levels of access rights to scan and read tagged items. If an item is scanned by an unauthorized reader, data about where, when, and who scanned the tag is sent back to the private blockchain. In the event that an item is scanned by an unauthorized reader, an alarm or warning may be triggered for the owner of the security tag.

[0312] Meat and livestock or other organic products can be authenticated through proximity fingerprinting using security tags. For example, the "grain" of beef near a security tag can be fingerprinted along with the security tag at the time of packaging. The security tag can provide information about the cut of beef, the date it was packed, the shipping, and any other information that is important for purchasing perishable goods. The security tag and the grain must be scanned together to fully authenticate the product to the end user, and if the tag has been removed, proximity fingerprinting will not be able to authenticate the product as authentic.

[0313] Security tags can be used to confirm and verify safety and inspection reports. When a unit or equipment that needs to be inspected is being installed, the installer can create a security tag for the entire unit or individual parts that contains information about the installation and the manufacturer. Tags can be scanned and updated during inspections and safety assessments by additional users with appropriate access rights. When a new user scans a security tag, that user can receive information about the inspection history, replacement history, users who have previously scanned the tag and the date / time they scanned it, warranty information, information about the parts supplier, and any other information deemed relevant. Thus, the inspection log can be saved on the blockchain.

[0314] Security labels can be used to authenticate drugs and prescriptions. For example, a doctor can have a unique security label on each prescription page to prevent prescriptions from being stolen. The doctor can scan the prescription when writing it down, and can give permission for a specific patient to use the prescription. When the pharmacy fills the prescription, it can check the security label to determine whether the doctor has actually given someone permission to use a specific prescription page, and whether the right medicine has been prescribed to the right person. In another example, the security label can be printed on the drug packaging, on the blister packaging, or even on the individual pills themselves. In these examples, the drug is matched with the patient, thereby providing access to the patient's information to the doctor, nurse, or other approved medical provider when scanned. This can provide evidence that the drug is being taken as prescribed, and helps ensure that the right medicine is provided to the right person.

[0315] Tax reports and expense reports can be tracked and verified through the use of secure tags. Companies can provide specific readers to their employees to scan receipts and invoices. Receipts and invoices can be printed with unique tags that can then be scanned by readers designed specifically for this activity. Readers can be designed to give users the ability to only scan certain secure tags on receipts or invoices. The scanned expenses are then stored in the blockchain and can be accessed in the future by the company or tax authorities to verify expenses and costs.

[0316] Users can create customized security labels in a variety of configurations. For example, some brands may want to design the label to be the same shape as their logo. This can enable different packaging options and different levels of security. In some embodiments, the center logo can be customized while keeping the shape of the security label fixed to a standard shape.

[0317] Gray products can be removed from the supply line through the use of security tags. Authentic parts for specific equipment and vehicles can be provided with security tags that contain information about the manufacturer and about what type of equipment or vehicle the part is supposed to be used for. Engineers or technicians who inspect and replace parts in the future can scan the part to determine if it is authentic and is being used in the correct manner.

[0318] Security tags can be used to identify and report counterfeit or fake products. Customers can scan security tags on products to check the manufacturer, countries of sale, approved retailers, etc. If any of this information is not available, the customer can report the item as fake, including information about the location and time of the scan. The report will be uploaded to the blockchain, and the owner of the tag will be notified. Additionally, since each security tag is unique, if the same tag report is scanned multiple times in multiple locations, the owner of the tag will automatically be notified of the discrepancy.

[0319] Companies can use security tags to limit the duplication of products, such as, for example, shoes. In this example, a copier has gained access to a single shoe produced by the company with a legitimate tag, and has placed a copy of the legitimate tag on a fake shoe. The copier then sells the shoe to numerous buyers, claiming that the products are genuine. Only the first scan will result in the authenticity being authenticated, and the scan must be performed before the shoe is sold. If the tag shows that this is not the first time the same tag has been scanned, the tag will be reported as a counterfeit and the customer is prevented from purchasing a counterfeit product. In the event that the legitimate customer is not the first to scan the shoe, the customer can authenticate the product to the company itself.

[0320] The disclosed embodiments may be implemented in systems, methods, and / or computer program products. The computer program product may include (multiple) computer-readable storage media having computer-readable program instructions thereon for causing a processor to perform various aspects of the present invention.

[0321] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but 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 above storage devices. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device (such as a punch card or a structure protruding in a groove (on which instructions are recorded)), and any suitable combination of the above storage media. As used herein, a computer-readable storage medium should not be understood as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0322] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or can be downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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 to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0323] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related 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 conventional program programming languages ​​such as "C" programming language or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer by any type of network including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit system including, for example, a programmable logic circuit system, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be executed by utilizing the state information of the computer-readable program instructions to implement the personalization of the electronic circuit system, so as to perform various aspects of the present invention.

[0324] Various aspects of the present invention are described herein with reference to the flow chart and / or block diagram of the method, device (system) and computer program product according to an embodiment of the present invention. It will be understood that each frame of the flow chart and / or block diagram and the combination of frames in the flow chart and / or block diagram can be implemented by computer-readable program instructions.

[0325] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed via the processor of the computer or other programmable data processing device create a means for implementing the functions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct a computer, a programmable data processing device, and / or other equipment to function in a special manner, so that the computer-readable storage medium having instructions stored therein includes a manufactured article including instructions, which implement various aspects of the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0326] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0327] The flowcharts and block diagrams in the accompanying drawings show the architecture, functions and operations of possible implementations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a part of a software program, a fragment or a code including one or more executable instructions for implementing (multiple) specific logical functions. It should also be noted that in some alternative embodiments, the functions indicated in the box may not occur in the order marked in the figure. For example, depending on the functions involved, the two boxes shown in the order can actually be executed substantially simultaneously, or sometimes these boxes can be executed in the opposite order. It will also be noted that each box of the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can be implemented by a combination of a dedicated hardware-based system or dedicated hardware and computer instructions that perform specific functions or actions.

[0328] The description of the various embodiments of the present invention is presented for the purpose of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications of technologies found in the market or technical improvements, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

[0329] It is expected that during the life of the patent from the expiration of this application, many related virtualization platforms, virtualization platform environments, trusted cloud platform resources, cloud-based useful resources, protocols, communication networks, security tokens and authentication credentials will be developed, and the scope of these terms is intended to include all such derivative new technologies.

[0330] It should be understood that certain features of the invention described in the context of separate embodiments for clarity may also be provided in combination in a single embodiment. Conversely, different features of the invention described in the context of a single embodiment for simplicity may also be provided in any other described embodiment of the invention, either alone or in any suitable sub-combination or where appropriate. Certain features described in the context of different embodiments are not considered essential features of those embodiments, unless the embodiment is ineffective without those elements.

[0331] Although the present invention has been described in conjunction with its specific embodiments, it is apparent that many alternatives, modifications and variations will be apparent to those skilled in the art. Therefore, it is intended to encompass all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

Claims

1. A security label system, comprising: at least one processor; as well as at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the security tag system to perform operations including: receiving a request for a digital product from a first user; generating a first security tag associated with the digital product and the first user, the generating comprising a selection of first tag features included in the security tag and a selection of second tag features, the second tag feature being the presence of a connection between the first tag features; providing the first security tag to the first user; as well as The digital product is provided.

2. The system of claim 1, wherein: The first label feature includes at least one of an edge, an edge deformation, or a point.

3. The system of claim 1, wherein: Generating the security tag further includes selecting a connection width of the connection between the first tag features.

4. The system of claim 1, wherein: The operations further include: receiving a second security tag from the first user; and comparing the second security tag to the first security tag; and Wherein the digital product is provided to the first user based on the comparison.

5. The system of claim 4, wherein: Wherein comparing the first security tag and the second security tag comprises comparing a perceptual hash value of the first security tag and a perceptual hash value of the second security tag.

6. The system of claim 1, wherein: The second security tag is a variable tag.

7. The system of claim 1, wherein: The first security tag is embedded in the digital product or displayed together with the digital product.

8. The system of claim 1, wherein: The operations further include: receiving a transaction request from the first user; generating a second security tag associated with the digital product and a second user, the second security tag being paired with the first security tag; and The second security tag is provided to the second user.

9. A security labeling method, comprising: receiving a request for a digital product from a first user; generating a first security tag associated with the digital product and the first user, the generating comprising a selection of a first tag feature included in the security tag and a selection of a second tag feature, the second tag feature being the presence of a connection between the first tag features; providing the first security tag to the first user; as well as The digital product is provided.

10. The method of claim 9, wherein: The first label feature includes at least one of an edge, an edge deformation, or a point.

11. The method of claim 9, wherein: Generating the security tag further includes selecting a connection width of the connection between the first tag features.

12. The method of claim 9, wherein: The method further comprises: receiving a second security tag from the first user; and comparing the second security tag to the first security tag; and Wherein the digital product is provided to the first user based on the comparison.

13. The method of claim 12, wherein: Wherein comparing the first security tag and the second security tag comprises comparing a perceptual hash value of the first security tag and a perceptual hash value of the second security tag.

14. The method of claim 9, wherein: The second security tag is a variable tag.

15. The method of claim 9, wherein: The first security tag is embedded in the digital product or displayed together with the digital product.

16. The method of claim 9, wherein: The method further comprises: receiving a transaction request from the first user; generating a second security tag associated with the digital product and a second user, the second security tag being paired with the first security tag; and The second security tag is provided to the second user.

17. A non-transitory computer readable medium comprising instructions that, when executed by at least one processor of a system, cause the system to perform operations comprising: receiving a request for a digital product from a first user; Generating a first security tag associated with the digital product and the first user, the generating comprising: selecting a first label feature included in the security label, the first label feature comprising at least one of an edge, an edge deformation, or a point; and selecting a second tag feature included in the security tag, the second tag feature being the presence of a connection between the first tag features; providing the first security tag to the first user; receiving a second security tag from the first user; comparing the second security tag to the first security tag; and Based on the comparison, the digital product is provided to the first user.

18. The non-transitory computer readable medium of claim 17, wherein: Generating the security tag further includes selecting a connection width of the connection between the first tag features.

19. The non-transitory computer readable medium of claim 17, wherein: Wherein comparing the first security tag and the second security tag comprises comparing a perceptual hash value of the first security tag and a perceptual hash value of the second security tag.

20. The non-transitory computer readable medium of claim 17, wherein: presenting the first security tag to a first device of the first user; and The second security tag is received from a second device of the first user.

21. A system for generating a security label, the system comprising: at least one processor; and at least one non-transitory memory, the at least one non-transitory memory containing instructions that, when executed by the at least one processor, cause the authentication server to perform operations comprising: receiving a style sheet describing a class of security tags; Get a digital seed; generating a security label layout using the digital seed and the style sheet, the security label layout specifying a combination of label feature options based on the digital seed and the style sheet; Receive tag data; Generating a security tag encoding the tag data by selecting the tag feature options according to the value of the tag data; generating a perceptual hash value of the security tag; storing the hash value and the identifier of the security tag in a database; and Provide this safety label.

22. The system of claim 21, wherein: The security label layout specifies reference portions that indicate one or more referenced locations in the security label layout for encoding data.

23. The system of claim 21, wherein: The security label layout specifies an unreferenced portion of the security label layout for encoding data.

24. The system of claim 21, wherein: The security label layout specifies a junk portion of the security label layout used to encode random data.

25. The system of claim 21, wherein: The security label layout specifies a key portion of the security label layout that is used to encode an encryption key.

26. The system of claim 21, wherein: The label feature options include the presence or absence of label features at the locations specified by the security label layout.

27. The system of claim 21, wherein: These label feature options include the size, color, or shape of the label feature.

28. The system of claim 21, wherein: The label feature options include deviations from the positions specified by the security label layout.

29. The system of claim 21, wherein: The label feature options include the number of label features that are present at the locations specified by the security label layout.

30. The system of claim 21, wherein: These label feature options include the presence of a spline encoding on the label feature.

31. The system of claim 30, wherein: The spline encoding includes a label feature edge extending varying distances from a reference point or reference line.

32. The system of claim 31, wherein: The varying distance encodes one or more spatially multiplexed tag data values.

33. The system of claim 32, wherein: The varying distance encodes the repetition of the one or more spatially multiplexed tag data values.

34. The system of claim 21, wherein: These tag feature options include the presence of microstructures on the tag feature.

35. The system of claim 21, wherein: The label features include edges, and label feature options for the edges include edge break, edge deform, and edge connect.

36. The system of claim 21, wherein: The label features include edge breaks, and the label feature options for the edge breaks include edge break edge shapes.

37. The system of claim 21, wherein: The tag features include connections between tag features of predetermined types, and tag feature options for the connections include connection width and connection asymmetry.

38. The system of claim 21, wherein: The label features include connections between the label features, and label feature options for the connections include connection width and connection asymmetry.

39. The system of claim 21, wherein: The label features include a center mark, and the label feature options include a displacement of the center mark relative to a center point of the security label.

40. The system of claim 21, wherein: Generating a security label encoding the label data by selecting the label feature options includes: selecting first label feature options according to the value of the first label data, the selection of the first label feature options creating second label feature options; and selecting the second label feature options according to the value of the second label data.

41. The system of claim 40, wherein: These first label feature options include the presence or absence of points, these second label feature options include the presence or absence of connections between points that exist according to the value of the first label data, and the third label feature options encoding the third label data include the width of the connection that exists according to the value of the second label data.

42. The system of claim 21, wherein: Generating a security label encoding the label data by selecting the label feature options according to the value of the label data includes: encrypting the tag data using an encryption key; selecting the tag feature options based on the value of the encrypted tag data; and encoding the encryption key into the security tag.

43. The system of claim 21, wherein: The security label includes a vector graphics file.

44. The system of claim 21, wherein: Providing the security label includes rasterizing the security label.

45. The system of claim 21, wherein: Providing the security tag includes marking an object with the security tag or incorporating the security tag into a digital product.

46. ​​The system of claim 21, wherein: The operations further include checking whether the generated hash value collides with hash values ​​of other security tags before providing the tag data.

47. The system of claim 21, wherein: The style sheet includes a public portion for generating a portion of the security label layout for encoding public data and a private portion for generating a portion of the security label layout for encoding private data.

48. The system of claim 21, wherein: These operations further include: generating perceptual hash values ​​of different segments of the security tag at multiple levels of detail; and The perceptual hash values ​​for different segments of the security tag are stored in the database.

49. The system of claim 21, wherein: The tag data includes one or more identifiers of one or more other security tags.

50. The system of claim 49, wherein: A first identifier of the one or more identifiers includes a perceptual hash value of the first security tag of the one or more other security tags.

51. The system of claim 21, wherein: The tag data includes an identifier of the multi-factor identification item.

52. The system of claim 51, wherein: The multi-factor identification item includes an authentication credential or a perceptual hash value of the image.

53. The system of claim 52, wherein: The image depicts a portion of an object tagged with the label.

54. The system of claim 52, wherein: The image depicts the person associated with the tag.

55. The system of claim 21, wherein: Providing the label includes printing the label on a substrate, at least a first portion of the label being printed with a fluorescent ink.

56. A method for tracking a product, the method comprising marking the product with a computer-readable secure tracking label encoding product identification data as a selection of label feature options based on a combination of a digital seed and a style sheet.

57. The method of claim 56, wherein: The tag feature options include the presence or absence of tag features at the locations specified by the combination of the digital seed and the style sheet.

58. The method of claim 56, wherein: These label feature options include the size, color, or shape of the label feature.

59. The method of claim 56, wherein: The tag feature options include deviations from the positions specified by the combination of the digital seed and the style sheet.

60. The method of claim 56, wherein: The tag feature options include the number of tag features that are present at the location specified by the combination of the numeric seed and the style sheet.

61. The method of claim 56, wherein: These label feature options include the presence of a spline encoding on the label feature.

62. The method of claim 61, wherein: The spline encoding includes a label feature edge extending varying distances from a reference point or reference line.

63. The method of claim 62, wherein: The varying distance encodes one or more spatially multiplexed tag data values.

64. The method of claim 63, wherein: The varying distance encodes the repetition of the one or more spatially multiplexed tag data values.

65. The method of claim 56, wherein: These tag feature options include the presence of microstructures on the tag feature.

66. The method of claim 56, wherein: The label features include edges, and label feature options for the edges include edge break, edge deform, and edge connect.

67. The method of claim 56, wherein: The label features include edge breaks, and the label feature options for the edge breaks include edge break edge shapes.

68. The method of claim 56, wherein: The tag features include connections between tag features of predetermined types, and tag feature options for the connections include connection width and connection asymmetry.

69. The method of claim 56, wherein: The label features include connections between the label features, and label feature options for the connections include connection width and connection asymmetry.

70. The method of claim 56, wherein: The label features include a center mark, and the label feature options include a displacement of the center mark relative to a center point of the security label.

71. The method of claim 56, wherein: The method further includes generating the computer readable security tracking tag.

72. The method of claim 71, wherein: Generating the computer-readable security tracking label includes selecting first label feature options based on the first value of the product identification data, the selection of the first label feature options creating second label feature options; and selecting the second label feature options based on the second value of the product identification data.

73. The method of claim 72, wherein: The first label feature options include the presence or absence of dots, the second label feature options include the presence or absence of connections between dots that exist based on the first values, and the third label feature options encoding the third value of the product identification data include the width of the connections that exist based on the second values.

74. The method of claim 56, wherein: The computer-readable security tracking label includes a vector graphics file, and marking the product with the computer-readable security tracking label includes rasterizing the vector graphics file.

75. The method of claim 56, wherein: The method further includes providing identification information of the computer-readable security tracking tag to an authentication server.

76. The method of claim 75, wherein: The method further includes generating a hash value of the computer-readable security tracking tag and checking whether the hash value collides with hash values ​​of other computer-readable security tracking tags before providing the identification information to the authentication server.

Images