Patent Application
20220343328
The present invention relates generally to methods and systems that use tags for engaging with a non-fungible token (NFT). The present invention also relates generally to methods and systems that use tags to enable the creation of an NFT, purchase of an NFT and electronic delivery of an NFT created by accessing or scanning an encoded tag located in, on, or near a point of interest.
The advent of distributed ledger systems has led to the creation and collection of Non-Fungible Tokens (NFTs), which are unique tokens related to certain subject matter whether it is physical or digital. For example, NFTs have been created for physical artwork, digital images of artwork, digital artwork, video, imager or other subject matter data. In certain instances, NFTs are created to signify and relate to ownership of the subject matter created by or sold by an individual or an entity. In other instances, the NFT itself is merely a unique digital asset. Thus, the NFT is a single, unique token that may or may not be related to certain subject matter, and in many cases can be utilized to signify ownership of, or other rights in, the same.
NFTs however, have not found use in all mediums and there are new and useful ways in which an NFT can be utilized to capture of a moment of time, or of ownership subject matter related to a particular location at a given moment in time. Herein, are described an elegant solution of systems and methods related to the acquisition and/or the use of NFTs in response to scanning a tag associated with a point of interest to enable the creation and/or purchase of, or interaction with, NFTs.
The embodiments herein are directed to various systems and methods, specifically to interact with and afford the opportunity to create, purchase, or bid on Non-Fungible Tokens (NFT) by scanning a tag within the system. The NFT may then identify a point of interest, whether that be the actual location, an issue happening at that location, or some other information pertaining to that point of interest, an event, a moment in time related to an event, a program, a storage of digital media, a ticket, or a memorabilia related to a particular point of interest or event.
In a preferred embodiment, a system for verifying a user device and obtaining a right to purchase an NFT comprising: (a) a server system comprising at least one server, at least one database, and at least one user device; (b) populated on said server system are a plurality of operable rules, wherein said operable rules are met by actions performed by scanning, by the user device, one or more tags positioned within a geofence within a venue; (c) defining at least a first rule, wherein said user device confirms ownership of a ticket corresponding to a first tag, said first tag comprising a tag ID defining a specific seat within the venue; wherein the user device confirms ownership by the system after receiving a scan of the first tag by the user device and sends a request to the user device to identify a digital record matching the tag ID; (d) upon meeting the first rule, verifying a location by determining whether the scan by the user device of the first tag was within a geofence corresponding to the venue; and (e) upon verifying the location, redirecting from a server a URL or a Web app to the user device to a page selling or offering for sale the NFT.
In a further embodiment, the system wherein a further rule is required to receive the redirection in step (e), wherein the rule requires that the digital record confirms purchase of a season ticket to the seat.
In a further embodiment, the system wherein a further rule is required to receive the redirection in step (e), wherein the rule defines that the redirection is only available within the first x minutes after an event-related occurrence. In a further embodiment, the system wherein x minutes is between 1 minute and 60 minutes. In a further embodiment, the system wherein the event-related occurrence is selected from the group consisting of: a point scored, a game related event, the start of a game, the finish of a game, an occurrence by a given player within a game, scanning by a predetermined number of users of at least one tag within the venue, scanning by a predetermined number of users of at least one tag within the venue wherein the predetermined number of users are active on the system at a given time point, scanning of at least two tags by the user device, scanning of at least two tags wherein each of said two tags are positioned within a different geofence, purchase of an item through the system, placement of a wager on the system, and combinations thereof.
In a further embodiment, the system further comprising a graphical user interface (GUI), said GUI defining at least two tags positioned on a visual map on said GUI, wherein the rule requires a user to scan the at least two tags defined on said GUI to receive the redirection.
In a further embodiment, the system wherein the NFT comprises a digital image, wherein the digital image within the NFT comprises an operable tag comprising a machine-readable code.
In a further embodiment, the system wherein ownership of the NFT affords a benefit to a user owning the NFT, said benefit selected from the group consisting of: free beverages or food, special rights or entry, specific seat upgrades, backstage access, discounts to tickets, merchandise, other materials at the venue, wagering discount, and other tangible benefits that may be given by a proprietor at a given venue.
In a preferred embodiment, a method for authorizing purchase of an NFT comprising: (a) scanning, via a user device (14a), a tag (16a) comprising a machine-readable code (MRC) (17a); (b) verifying a unique ID (22a) on said user device (14a) or generating a unique ID (22a) if one is not present; and (c) directing the user device (14a) to a target URL for purchase of an NFT.
In a further embodiment, the method wherein the tag (16a) comprises a unique tag ID that identifies a seat within a venue. In a further embodiment, the method further comprising a verification step selected from the group consisting of: verifying ownership of a ticket corresponding to the tag (16a), a time verification, a geolocation verification, a predetermined threshold defined by an administrator, and combinations thereof.
In a further embodiment, the method further comprising a verification step, wherein upon scanning the tag (16a) in step (a), a server confirms the presence of a digital record corresponding to ownership of a ticket corresponding to the unique tag ID. In a further embodiment, the method wherein the verification step comprises wherein a server performs an API call to a third party to obtain a digital record confirming ownership of a ticket matching seat information for said tag ID, wherein the digital record is selected from the group consisting of: a digital ticket, a phone number, a credit card, an address, a name, a birthday, another personally identifiable information, and combinations thereof. In a further embodiment, the method further comprising matching a unique tag ID with a physical ticket.
In a preferred embodiment, a method for purchasing an NFT from a tag (16a) comprising: (a) scanning, via a user device (14a), a tag (16a) comprising a tag ID, said tag (16a) positioned on a seat and comprising a tag ID identifying said seat; (b) verifying a unique ID (22a) on said user device (14a) by requesting from a server a matching unique ID within a database or generating a unique ID (22a) if one is not present; (c) verifying ownership of a ticket on said user device (14a), said ticket matching the seat defined by said tag ID; and (d) directing the user device (14a) to a target URL for purchase of an NFT.
In a further embodiment, the method further comprising a verification step selected from the group consisting of: a time verification, a geolocation verification, a predetermined threshold defined by an administrator, and combinations thereof.
In a further embodiment, the method wherein the step of verifying ownership of a ticket on said user device is performed wherein upon scanning the tag (16a) in step (a), a server confirms the presence of a digital record corresponding to ownership of a ticket by a digital record stored on said user device corresponding to the seat and the tag ID.
In a further embodiment, the method wherein the step of verifying ownership of a ticket on said user device is performed by utilizing an API call to match a digital record on the user device (14a) to an authorization for the ticket at the given tag (16a), wherein the digital record is selected from the group consisting of: a digital ticket, a phone number, a credit card, an address, a name, a birthday, another personally identifiable information, and combinations thereof.
In a further embodiment, the method further comprising: (c2) determining that the user device is within a predetermined geofence. In a further embodiment, the method further comprising: (c2) confirming the presence of a first scan of a tag corresponding to a tag ID and performing a second scan of the same tag on a different day than the first scan.
In a preferred embodiment, a method for authorizing minting of an NFT by scanning a tag (16a) comprising: (a) performing a user scan by scanning, via a user device (14a), a first tag (16a) comprising a tag ID; (b) verifying, via a server and a database, a record for a unique ID (22a) having a corresponding matching unique ID on said user device (14a) or generating a unique ID (22a) if one is not present; (c) verifying that the user device (14a) comprises ownership of a ticket corresponding to the tag ID; (d) determining that the first tag (16a) is present at a venue wherein an event is being held at the time of the user scan; (e) determining, from a counting mechanism, whether at least x number of additional user devices have scanned a second tag at the venue within a predetermined amount of time before or after the user scan; (f) redirecting at least one user device having scanned the first or second tag at the venue to a target URL to award a right to mint an NFT; and (g) minting an NFT by creating a record within a distributed ledger.
In a further embodiment, the method wherein the step of verifying ownership of a ticket on said user device is performed wherein upon scanning the tag (16a) in step (a), a server confirms the presence of a digital record corresponding to ownership of a ticket by a digital record stored on said user device corresponding to a seat and the tag ID.
In a further embodiment, the method wherein the step of verifying ownership of a ticket on said user device is performed by utilizing an API call to match a digital record on the user device (14a) to an authorization for the ticket at the given tag (16a), wherein the digital record is selected from the group consisting of: a digital ticket, a phone number, a credit card, an address, a name, a birthday, another personally identifiable information, and combinations thereof.
In a preferred embodiment, a method for verifying a right to purchase an NFT by confirmation of attendance at an event based upon location comprising: (a) receiving a request from a user device for purchasing an NFT, the request received in response to scanning a machine-readable code with the user device, the machine-readable code corresponding to a tag disposed on a surface at an event, said tag having a tag ID; (b) in response to receiving the request and based on the tag ID, determining if the tag that was scanned by the user device has a matching digital record within the user device confirming the right to that tag ID; (c) in response to a confirmation that the matching digital record exists, confirming a location within a geofence corresponding the event; and (d) based on the determining and confirming of location steps, redirecting the user device to a portal offering the NFT for sale.
In a further embodiment, the method further comprising: (c2) wherein the NFT is only available upon an event-related occurrence; and redirecting the user device to the portal offering the NFT for sale only in response to the event-related occurrence.
In a preferred embodiment, a method for determining ownership of a seat for obtaining a right to bid on or purchase an NFT comprising: (a) scanning, via a user device (14a), a tag (16a) positioned on a seat, said tag comprising a tag ID identifying the seat; (b) verifying a unique ID (22a) on said user device (14a) by confirming the presence of a database entry containing the unique ID; (c) requesting to a server to confirm the presence of a digital record providing ownership information corresponding to said tag ID by searching a digital wallet (24a) for the presence or absence of the digital record; and (d) comparing the digital record to the tag ID and confirming ownership where said digital record and said tag ID confirm a matching record wherein, if no matching record is located, a subsequent search for ownership is performed.
In a preferred embodiment, a method for determining ownership of a seat for purchase of an NFT comprising: (a) scanning, via a user device (14a), a tag (16a) comprising a tag ID, said tag ID comprising seat information; (b) verifying a unique ID (22a) on said user device (14a) or generating a unique ID (22a) if one is not present; (c) performing a search to confirm a record providing ownership corresponding to the tag ID selected from the group consisting of: (i) directing the user device (14a) to a server to confirm the presence of a digital record providing ownership information corresponding to said tag ID by searching a digital wallet (24a) for the presence or absence of a digital record and comparing a digital record to the tag ID and confirming ownership where said digital record and said tag ID confirm a matching record; (ii) searching a paper ticket for a record corresponding to said tag ID; and (iii) performing an API call to a provider of said paper ticket and confirming at least one piece of personally identifiable information selected from the group consisting of: name, date, birthdate, credit card number, address, phone number, other personally identifiable information, and combinations thereof; and (d) upon location of a record providing ownership, authorizing the purchase of an NFT.
In a further embodiment, the method further comprising a verification step selected from the group consisting of: a geofence, a time, a predetermined limitation, and combinations thereof.
In a further embodiment, the method wherein the purchase is related to an NFT from a sporting event.
In a further embodiment, the method wherein the purchase is related to an NFT from a venue.
In a further embodiment, the method wherein the purchase is related to an NFT from a music event.
In a further embodiment, the method wherein the NFT provides unique access; said unique access selected from the group consisting of: free beverages or food, special rights or entry, specific seat upgrades, backstage access, discounts to tickets, merchandise, other materials at the venue, special discounts related to wagering, and other tangible benefits that may be given by a proprietor at a given venue.
In a further embodiment, the method wherein the NFT comprises rights to a unique digital image, and wherein the unique digital image comprises a tag, said tag comprising a unique tag ID; wherein scanning of the unique tag ID redirects a user to Web page that provides a tangible benefit.
In a further embodiment, the method wherein the right to purchase the NFT is provided based upon scanning a predetermined number of tags, wherein the predetermined number of tags are identified by a plurality of clues in a scavenger hunt.
In a further embodiment, the method wherein a counting mechanism is required to determine if x number of people are online at a given moment, and upon a given number of people being online at the moment, generating a lottery to select a winner of the NFT from the people online at the moment.
In a further embodiment, the method wherein a map of required tags is provided on a GUI, wherein each tag must be scanned by a user device having the same unique ID, wherein upon scanning of a required tag, a database is updated to confirm the scan of a given tag, and wherein the GUI identifies the scanning of the scanned tag; wherein upon scanning of all of the tags within a treasure hunt, redirecting the user to a page to bid on an NFT. In a further embodiment, the method wherein the treasure hunt is located in a zoo, and wherein a plurality of tags corresponds to individual animals; upon scanning all of the tags, providing an auction page to bid on an NFT; wherein winning the NFT authorizes a winner to name a baby animal; and wherein the NFT comprises a digital image of the baby animal.
In a further embodiment, the method comprising a rule wherein the rule requires x number of scans at a given event within a geofence; and upon meeting the threshold, making an auction available to all users who scanned a tag.
In a further embodiment, the method wherein x number of users have to purchase the NFT, wherein the purchase is held in escrow until x number of users have purchased the NFT.
In a further embodiment, the method wherein sequential NFTs are awarded, wherein a price is dynamic. In a further embodiment, the method wherein the NFTs are sold when x number of users agree to buy the NFT, and wherein the price of the NFT drops every 10 minutes.
In a further embodiment, the method wherein the purchase is related to an NFT from an arts event.
In a further embodiment, the method wherein the purchase is related to the occurrence of an event occurring at a venue.
In a further embodiment, the method wherein the right to purchase is further defined by a lottery, wherein winning of said lottery enables the authorization to purchase the NFT.
In a further embodiment, the method further comprising a rule requiring a predetermined number of tags to be scanned by said user device; wherein each of said tags comprises a unique tag ID.
In a further embodiment, the method wherein the predetermined number of tags comprises at least three tags. In a further embodiment, the method wherein each of the at least three tags are positioned in the same or a different geofence.
In a further embodiment, the method wherein the tag is provided on a video broadcast of an event. In a further embodiment, the method wherein the tag is provided on a social media platform.
In a preferred embodiment, a method of authorizing a right to purchase an NFT comprising: (a) scanning, via a user device, a tag, said tag comprising a tag ID; (b) defining, within both the user device and a database, a unique ID wherein said database populates information related to said user device; and (c) determining a rule and upon meeting the rule making available the right to purchase said NFT.
In a further embodiment, the method further comprising verifying a seat; wherein said tag ID comprises a known location; and verifying the presence of a record confirming rights to sit in the known location. In a further embodiment, the method further comprising verifying a geolocation wherein upon scanning the tag ID by the user device, determining whether the user device is present within the geolocation. In a further embodiment, the method further comprising counting, via a counting mechanism, the total number of users online at a time t, wherein the rule determines that when x number of users are online at the time t, the right to purchase the NFT is authorized for all users.
In a further embodiment, the method wherein the rule requires the user device to scan at least x number of tags having unique tag IDs.
Various embodiments are described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the innovations may be practiced. The embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the embodiments to those skilled in the art. Among other things, the various embodiments may be methods, systems, media, devices, or any similar or equivalent arrangements known to those skilled in the art. Accordingly, the various embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
As used herein, the below terms will have the following meanings as may be supplemented elsewhere in this specification:
As used in this application, the words “a,” “an,” and “one” are defined to include one or more of the referenced items unless specifically stated otherwise. The terms “approximately” and “about” are defined to mean ±10%, unless otherwise stated. Also, the terms “have,” “include,” “contain,” and similar terms are defined to mean “comprising” unless specifically stated otherwise. Furthermore, the terminology used in the specification provided above is hereby defined to include similar and/or equivalent terms, and/or alternative embodiments that would be considered obvious to one skilled in the art given the teachings of the present patent application.
A
A
A
A
A
API C
B
B
C
C
C
D
D
D
D
D
D
D
E
F
I
G
GUI
J
L
M
M
M
N
NFT M
P
P
R
R
R
R
R
R
S
T
T
T
T
T
T
T
T
T
T
U
U
U
V
W
Historically, proof of purchase, the conveyance of other rights, and similar transactions were recorded on paper. For instance, if you attended a sporting event, a music concert, an artistic performance, or literally anywhere with a controlled entrance, you purchased a ticket, which was printed on paper and either handed to you or mailed to you. After using the ticket to gain entry to the event, you retained a stub portion of the ticket. The stub was your evidence of the limited ownership of your seat or your right to be in attendance in a particular area of a stadium or other venue. After the event, performance, or the like, the ticket stub served as evidence that you attended the event, where you sat at the event, if you had a VIP ticket, and similar information.
Modern ticketing, however, has changed, almost exclusively, to digital transactions. Indeed, most digital tickets have a bar code, some other readable matrix, or even an embedded digital code, and are delivered to a smart phone, or other handheld computing device, so that the digital ticket can be scanned for entry into an event. This digital ticket is then stored or wasted within a user's device, never to again be seen.
Ticket stubs and memorabilia from events, however, can be highly collectible. In some cases, ticket stubs, as one example, have obtained significant historical and collectible value because of the event that occurred such as Woodstock, championship games, games where a world or national record was set or a historical statistic was reached, and similar types of noteworthy events. In the sporting world, championship games include, but are not limited to, a playoff or world series game in baseball, a playoff or Super Bowl in football, a world cup or league match in soccer. Collectables, however, are not limited to significant events; many people collect tickets and other memorabilia from their favorite teams, favorite players, bands, and other similar examples.
Paper tickets are easily tradeable and can be authenticated by numerous third parties to confirm authenticity of the paper ticket, especially for events with valuable tickets or ticket stubs, which could easily be forged. Modern digital tickets, however, have virtually no way to be transferred, sold, or captured within the collectible industry, thus losing a valuable asset for notable events. One of the hallmarks of the present disclosure is that it details how embodiments may confirm or authenticate attendance at an event that took place at a particular time, place, or both, which, in turn, confirms/authenticates the digital ticket, or other type of similar asset associated therewith. Such confirmation/authentication has implications for numerous different use cases.
Embodiments of the present invention described herein enable the ability to acquire a non-fungible token (NFT) through the scan of a tag at the event and/or venue. An NFT, by its nature is a unique, i.e., non-fungible, record that is stored in a distributed ledger commonly referred to as a blockchain. There are numerous blockchain providers that store NFTs, including but not limited to, Etherium, Binance Smart Chain, Polkadot, Flow by Dapper Labs, EOS, Tron, Tezos, WAX, Theta, and more. An NFT does not typically possess inherent value. The value of the NFT, in fact, comes from the subject matter associated with the NFT and rights, if any, granted with respect to that subject matter. For example, NFTs have been associated with artwork, both physical and digital artwork. Digital artwork is created digitally (e.g., on a computer, with a digital camera, etc.,) and saved as a data file, often a jpeg or another type of file. To be associated with an NFT, physical artwork is represented by a data file such as a digital photo of the physical artwork. The data file of the artwork may then be stored in a central server, an interplanetary file system (IPFS), or other storage as is commonly associated with storage of the subject matter associated with NFTs. Thus, the value in owning an NFT is typically gained by its associated subject matter, the appeal and sacristy of that subject matter, and the rights provided by the NFT contract, among other variables.
To associate subject matter with an NFT, creators typically go through a process commonly referred to as minting. Minting generally refers to the actual recording or adding of the NFT to the blockchain, which may occur at the time of subject matter association (e.g., NFT creation) or when the NFT is first sold after creation (e.g., “lazy minting”). To create one or more NFTs for certain subject matter, the creator uses a digital wallet such as a cryptocurrency wallet, which may be a noncustodial wallet, and selects a marketplace, a blockchain provider, or a project (e.g., Web site for subject matter/NFT collections). The cryptocurrency wallet enables payment (e.g., with appropriate crypto/digital currency) for the minting process, listing fees, other fees, and/or NFT purchase after minting. The cryptocurrency used should be accepted by the platform of choice (i.e., marketplace, blockchain provider, project). NFT marketplaces include, without limitation, Open Sea, Mintable, and Rarible. Many platforms enable one-click style minting, wherein the NFT is created by simply uploading subject matter data to the platform, designating a storage option for the data and contract (e.g., IPFS), determining the desired number of NFTs for the subject matter, and clicking the appropriate button. Of course, all the necessary fees must also be paid. In return, the creator/owner may get some sort of proof of NFT ownership (i.e., “proof of ownership”) delivered to one or more digital wallets, such as the cryptocurrency wallet. Thereafter, the creator/owner of the NFT may do what he/she wishes with the NFT, but the rights associated with the subject matter are provided in the NFT contract, which may sometimes be referred to as the “metadata,” and/or smart contract. Rights in subject matter may include sole ownership of the original subject matter that is not-to-be-duplicated, ownership of a copy of the subject matter, or ownership of the NFT itself with no ownership interest in the subject matter, as a few non-limiting examples. The creator of the subject matter and/or NFT may determine what rights (i.e., the NFT contract) in the subject matter, if any, come with NFT ownership at the time the NFT is minted. As detailed herein, an NFT is a digital asset, and more particularly a digital asset for subject matter related to an event, venue, or the like. The NFT may be acquired via scanning the encoded tag while the user is at the event (e.g., tag is on the seatback in front of the user), remotely watching the event (e.g., tag is in/on a television broadcast), or the like. The systems and methods described herein provide an easy, convenient, and accurate way for users to acquire such NFTs and receive confirmation of NFT ownership simply by scanning an encoded tag with a device such as, without limitation, a smartphone. The following paragraphs provide details about various nonlimiting embodiments of the present invention.
Proprietors that house or run venues and/or events, sell tickets, or otherwise provide content may utilize embodiments of the present invention to create NFTs for subject matter relating to the events, venues, and the like. For example, if a user purchased a ticket for seat 1, row 1, section 100 to attend a baseball game, and the baseball game turns out to be a special game because player Smith hits a homerun to win the game, the user may want to memorialize his or her attendance at the game and the seat in which the user was sitting at the time the homerun occurred. Embodiments may enable a user to do so by scanning an encoded tag to acquire an NFT. Proof of NFT ownership may be secured in the user's digital wallet. As another example, a user attends the last concert performed by a rock band's original members. The user desires to acquire an NFT to commemorate the user's presence at the concert. The user may mint (i.e., create) the NFT by scanning an encoded tag at the venue, which may be specifically related to the ticket (e.g., on or with the ticket) or generally related to the ticket as the tag is physically located at the venue. In other embodiments, the proprietor, whether the owner of a venue (e.g., stadium) or a team, or a manager of a group of artists or the artists themselves may mint certain NFTs to be released during the event. The NFTs may be released globally (e.g., to all users) or selectively (e.g., a designated group of users), or upon meeting some threshold or defined limitation that is set by the proprietor. These and other embodiments are explored in greater detail below.
A high-level overview of an exemplary system (10) is shown in
A proprietor may use a network of encoded tags (16a, 16b) to identify points of interest (e.g., locations, objects, people, etc.). The number of tags (16a, 16b) in the network and placement of tags on, in, or near points of interest is at the discretion of the proprietor to fit its particular assets and needs. Further, a proprietor may add to or subtract from the number of tags (16a, 16b) in the network at will. Thus, the number of tags (16a, 16b) in a proprietor's network may be dynamic, either more or less than an original network of tags. Each tag (16a, 16b) in the network of tags has a unique identifier (tag ID), which may be used to identify a particular point of interest. For example, a tag (16a, 16b) may be situated on or near a seat in a stadium, and the user who purchased a ticket to sit in that seat is the “limited owner” or renter of that seat for a particular event. In certain embodiments, it may be possible to have multiple copies of the same tag, each with the same tag ID, in locations where multiple scans would be desirable at the same time by multiple users. Thus, at the entrance to a stadium, a plurality of tags could be located at different entrance points, each having the same tag ID.
As is implied in
The proprietor may also access platform (20), albeit via the administrator device (12) and one or more networks (18). The administrative device may be located at the venue, or it may be at a location remote from the venue. Generally, the proprietor may access a proprietor portal (
In addition to hosting the proprietor portal, platform (20) may host a variety of other services including, without limitation, event user and remote user access to content associated with the event, venue, proprietor, and the like. As such, platform (20) may include, or may include access to, one or more servers, databases, application programming interfaces (APIs), artificial intelligence/machine learning algorithms, other algorithms, code, blockchains, blockchain platforms, geofences, third-party integrations, times stamp, and more, which is detailed below, with reference to accompanying figures.
In the example of
As was mentioned with respect to
In-venue tags (16a) may be physical (e.g., tangible), digital (e.g., virtual/intangible), or combinations of both forms. Physical tags may be constructed from diverse types of materials. In the case of tags having one or more graphical/matrix type codes such as QR codes, barcodes, and the like, the code may be printed, etched, fabricated, or the like on materials such as paper, glass, plastic, metal, fabric, and the like, as a few nonlimiting examples. In the case of NFC/RFID enabled tags, chips/antennae may be adhered to, attached to, embedded in, or fabricated on (or combinations thereof) a natural or manufactured material such as metal (e.g., aluminum, stainless steel), semiconductor, wood, polymer (e.g., plastic), film, glass, and combinations thereof, without limitation. The material may be incorporated into or affixed (e.g., adhesive, or other form of attachment) where desired. Digital tags may be displayed on a screen or communicated via radio waves. In the case of QR codes, barcodes, and the like, the graphical code may be displayed on a display screen such as the jumbo screen (204) or a display screen associated with the event user's seat (208), other locations/point of interest, or combinations thereof. Thus, the in-venue tag (16a) may be a video display, such as LCD, LED, e-ink, or other visual display and/or text accompanying the MRC (17a). In fact, most, if not all, remote tags (16b) will be a display screen such as on a television screen, computer screen, appliance screen, and the like, having the MRC (e.g., 17b) displayed thereon, or text on the display screen identifying the MRC (17b), although embodiments are not limited thereto.
Information encoded on or in each tag in the system (10) may include an address to direct a request (e.g., for a Web page) from the user device (14a, 14b) to a server or the like on the network (18) such as a server on platform (20). The address may be in the form of a uniform resource identifier (URI) such as a uniform resource locator (URL), according to a non-limiting embodiment. In this way, when the user scans the tag (16a, 16b) with the user device (14a, 14b), the user device (14a, 14b) sends a request to the appropriate network (18) location. In the example shown in
In a typical embodiment, each tag (16a, 16b) in the plurality has a unique tag identification number (i.e., “tag ID”), which may be appended to the URI/URL, although embodiments are not so limited. The tag ID may be used by the platform (20) for several reasons, one of which is to identify a point of interest/location associated with the tag (14a, 14b) via a tag ID lookup. For example, when a request comes from the event user device (14a), the platform (20) knows that the request came from within the venue (202) and is associated with the seat (208) in which the event user is sitting. And when the request comes from the remote user device (14b), the platform (20) knows that the request is in response to scanning a tag (e.g., 16b/MRC 17b) in transmission, on a Web page, or the like, and the platform (20) knows which transmission/Web page is associated with the scanned tag (16b). In an embodiment, the tag ID may be appended to the URL (or URI) such as by one or more parameters, pattern matching techniques, or other such mechanism for encoding information in a URI, URL and/or browser request.
Referring to
In an embodiment, the redirect/identification server (302) may pass information needed to further method (400). For example, the tag ID may be passed to the interface server (306) for a tag ID lookup (step 412), such as in database (308), the administration server (310) and/or any other suitable database or server. In this instance, the redirect/identification server (302) obtained the tag ID from the request made by the event user device (14a). In an embodiment, the tag ID is appended to the URL, and thus the entire URL, or a portion thereof, may be passed to the interface server (306) for use in looking up the tag ID. Looking up the tag ID provides information about the venue (202) and/or event. To clarify, when a particular venue (202) installs tags (16a) and/or uses tags (16b), the tag IDs for the installed/used tags (16a, 16b) are associated with the point/location of interest and the particular venue (202). Thus, if a tag is installed proximate seat 1, row A, section 100, database (308) information associates the installed tag's (16a) tag ID and that particular seat (208), which is in that particular venue (202). Since the tag ID is known to belong to a particular venue (202), the interface server (306), the administration server (310) via the interface server (306), any other suitable server, or combinations thereof makes a series of determinations using the tag ID, which was received in response to a request from a user device (14a, 14b) prompted by scanning the tag (16a, 16b). One determination is if the venue (202) is actively implementing platform (20) services (step 414). For example, the venue (202) may have tags (16a) installed but it is no longer using the tags (16a), or it is not using the tags for a particular event. If not, the event user device (14a) is redirected to a global default target (step 416) that may inform the event user that the services are no longer available, are temporarily out of service, or the like. If the venue (202) is actively implementing platform (20) services, the method (400) may make another determination. At step (418), the method (400) may determine if a particular event is currently (or soon to be) in progress, or recently ended. In an embodiment, an event may be determined to be in progress based on the time that the event is scheduled to begin. Since many venues (202) open before the actual event begins, and close after the actual event ends, the window set for an event to be in progress may encompass a given amount of time before and after the actual activity begins/ends. In an embodiment, the time that the “event in progress” determination is made (step 418) may be recorded to serve as a timestamp to approximate the time that the event user device (14a) scanned the tag (16a). In other words, the unique ID, tag ID, and time determination may be recorded for later use, in certain embodiments. If the event is not in progress, the event user device (14a) may be redirected to a venue default target (step 420) such as a Web page for the venue, or another Web page such as a page to identify that an incident has occurred at the venue (202) at the location/point of interest in which the tag (16a) was scanned. Incidents may encompass any sort of incident such as a need for something to be cleaned up to calling emergency services.
If the event is in progress, the method (400) may also determine if the tag ID belongs to a grouping of tag IDs (step 422). Tags (16a, 16b) may be grouped for many reasons and in many different ways. Tags (16a, 16b) may also belong to more than one group. As one non-limiting example, in the stadium of
Method (400) may simultaneously process other data such as looking up one or more records associated with the unique ID (step 428). In embodiments, the platform (20) may gather information relating to user activities via the user device and unique ID. For example, the platform (20) may gather data relating to tags that the user has scanned in the past (across a variety of different events, venues, or the like) and activities associated with those tag scans (e.g., purchases made, content looked at, coupons downloaded), although embodiments are not limited thereto. This data may be stored in association with the unique ID assigned to the event user device (14a). Thereafter, a controller may associate the unique ID, its record, its record location or the like with the tag ID, target ID, a URL, any other determined information, or combinations thereof (step 430). The event user device (14a) may then be redirected to the appropriate target that has been determined for the event user device (14a).
When a request comes from a remote user device (14b), the method (400) starts out essentially the same as with the event user device (14a). That is, the redirect/identification server (302) receives the request (step 402), checks for a manifest containing a unique ID (step 404), assigns a manifest with a unique ID if one has not yet been assigned (step 406), and sends it to the remote user device (14b, step 408) for secure storage thereon. If the remote user device (14b) has a manifest, then the redirect/identification server (302) obtains it (and other information such as a unique ID) from the remote user device (14b). Either way, the redirect/identification server (302) has the information that it needs such as unique ID, URL, tag ID, and the like, and forwards the information to the interface server (306) to continue the method (400). The interface server (306) may then look up, or cause to look up, the record associated with the unique ID (step 428) assigned to the remote user device (14b). At the same time, the interface server (306) may cause a determination to be as to whether the venue exists (step 414). In this case the interface server (306), or other server, may look at the data associated with the tag ID to determine from where the tag (16b) that was scanned originated.
For example, the MRC (17b) may have originated from a particular signal, transmission, etc., (e.g., network, regional network, etc.), Web site (e.g., for the venue, a streaming service, etc.) or the like. If the method (400) determines that the venue does not exist, for example, if the tag is to an unrelated element, then the remote user device (14b) is redirected to that unrelated element or to a global default target (step 416), for example if the tag is related. Assuming that the venue in this case does exist, the interface server (306)/method (400), then determines whether the event is in progress (step 418). If the signal, transmission, Web page, or the like is transmitting an event as it is occurring in real time then the event is in progress. Such can also be determined by a time stamp or time record set within the system. Either way, in an embodiment, the time the determination is made may be recorded by the platform (20). If the event is not occurring in real time (e.g., the user is watching a recording after the fact), then the remote user device (14b) will be redirected to an appropriate target such as a Web page relating to the event (step 420). However, the proprietor can set any time parameter to define “real time”. For example, a proprietor may desire to allow recordings watched within N number of days of a live event to constitute real time. The interface server (306) may then determine if the tag (16b), via the tag ID belongs to a group (step 422). For instance, different tags (16b) may be associated with different signals, transmissions, Web sites, or the like. Some of these tags (16b) may form groups based on predetermined criteria. Thus, if the tag (16b) belongs to a group, the remote user device (14a) will be redirected to the target for the appropriate group, and if not, the remote user device (14a) will be redirected to the default target. The default target for remote users may or may not be the same default for event users. Either way, the information relating to the determined redirection target is obtained (steps 424, 426). At step (430), a controller may associate the unique ID, the record for the unique ID, a pointer to the record for the unique ID, the tag ID, and target information such as a URL, target ID, or both. Thereafter, the remote user device (14b) is redirected to the appropriate target (step 432), as was described with respect to the event user. In certain embodiments, the step of (428) may be provided in parallel to or concurrent with the lookup of the tag ID (step 412), where the unique ID is necessary for determining any of the other elements. Furthermore, the unique ID may be stored, for example in local memory or cache, which is readily accessible or known to the system after step (410).
In an embodiment, the user device (14a, 14b) may receive a redirect URL from the redirect/identification server (302) at the end of method (400) to redirect the user device (14a, 14b) to the appropriate target. For instance, the method (400) may return a target ID to identify the particular target. The target ID, tag ID, unique ID (and/or information associated therewith), or combinations thereof may be appended to the redirect URL for the target, which is sent to the requesting user device (14a, 14b). The requesting user device (14a, 14b) then uses the redirect URL to send a new request, this time for the target, which is received by the redirect/identification server (302) and is forwarded to the interface server (306) for processing. Alternatively, the target ID, tag ID, and unique ID may be used by the platform (20) without sending a redirect URL to the requesting device at the end of method (400). Regardless of the forgoing, the requesting user device (14a and/or 14b) receives the target of the redirection whatever that target may be. For example, a target may be a static Web page, a dynamic Web page, an application delivered by way of one or more Web pages, files, data, information, or combinations thereof. As one non-limiting example, the fan portal (218) may have been the target identified by the target ID, and it may include application code “wrapped” or embedded in in an HTML document, and wherein such fan portal (218) may be used to access and purchase NFT. Application code includes, but is not limited to, Web application code, progressive Web application code, cloud-based application code, native application code, native mobile application code, other such code, or combinations thereof. The HTML document (and cascading style sheet, etc.) generally determines the format/layout of what the user sees as is known in the art.
Furthermore, targets are not necessarily static. In fact, the same tag (e.g., 16a) may cause a user device (e.g., 14a) to be redirected to distinct targets depending upon when the particular tag (16a) is scanned. For example, a venue (202) hosts many events over the course of a season, year, decade, etc. Each event may have its own target as the individual events are distinct. For example, the fan portal (218) may be the target of a game in progress, such as the football game shown in
A proprietor may also change a target during the course of a particular event. For example, referring again to the fan portal (218) shown in
There may be instances where the content delivered via the target may need to be changed, updated, altered, released, opened, or other such stipulations based on a rule and/or other conditions. Rules may be defined to force a modification of content already delivered, deliver additional content, information, data, release content, and/or make other such changes as would be appreciated by one skilled in the art. In this non-limiting example, the target delivered at (432)
The method detailed in
Using fan portal (218) as a non-limiting example while referring to
Examples of rules that are detailed with respect to
A more complex event rule may include more than one trigger/metric. For example, the rule may be that if team “A” scores a touchdown, push a digital offer for a free beer to all event users over the age of 21 that have used their user device (14a) to scan a tag (16a) in the venue (202). The first metric/trigger of whether a touchdown has been scored may be monitored as described above. The second metric/trigger may be monitored (at 518, 524) in the same or similar manner if the metric/trigger warrants, or it may be determined before or after the first trigger/metric has been satisfied. For example, since in this example the second metric/trigger relates to age, a query may be sent to one or more data sources (at 512) to find all users who are over the age of 21. Records stored on database (308), for example, may be consulted to look for age data in connection with unique ID data to determine if the person who has loaded the fan portal (218) on his/her device (14a) is of legal drinking age. As an alternative source of data or for any other reason, the interface server (at 510) may cause another data source (at 512) to be consulted to determine user age. For example, one or more third-party integrations (320) may have age information; thus, an API call or other query may be made to the third-party integrations (320) to obtain age data. As with the first example, if the first metric/trigger (step 520, no) is not met (i.e., touchdown), then the platform (20) continues to monitor the metric/trigger (step 522). If the metric/trigger (step 520, yes) has been met the platform (20) determines if the second metric/trigger (518) has also been met (step 524). Where the second trigger/metric has not been met (step 524, no) then the target on the user device (14a) is not updated (step 528), such as with the digital offer. Depending upon the rule, the second metric/trigger may continue to be monitored or not. For example, if the digital offer was to be sent only one time, then the rule is satisfied, and no additional monitoring is needed. If, however, the rule is to send the same digital offer (e.g., for a beer) every time team “A” scores a touchdown, the second metric/trigger would not have to be redetermined since even if the user turned 21 that day, the user's age would not change. Of course, if the event went past midnight, the rule could be structured to recheck ages after midnight. This does not mean that for a given rule a second (or third, or fourth, etc.,) trigger/metric would never need to be monitored. Should an additional metric/trigger be defined by a rule that needs additional monitoring, the method (500) will be allowed to do so. Going back to step (524), if the determination is yes, the digital offer may be pushed (526), such as via the controller (at 514, 506) to those users who have scanned a tag (16a) and who are at least 21 years old. Pushed content may update an element, such as a dynamic element, on a Web page, cause a popup to show on the user device (14a, 14b), send content to a digital wallet (24a, 24b), or any other way to push content as is known in the art. Such complex rules may be specifically desirable for providing access to or purchasing NFTs as a mechanism to limit even the opportunity to participate in these non-fungible elements.
Local rules, as an example, may be associated with one or more targets being utilized for a given event. Referring again to
Referring back to
In some implementations, a counter may be needed. For example, a counter may be enabled to maintain the countdown shown in
Thus, while a target is displayed on a particular device (14a, 14b), dynamic content may be seamlessly and dynamically updated/changed per coding/interactions between the user device (14a, 14b) and the platform (20). Certain dynamic changes occur through push and pull techniques such as those detailed by
As is also indicated in
Data related to user devices (14a, 14b) may also be obtained from third party sources. As one example, when a query, request, or the like sent to a third party, the platform (20) may provide certain information with that query, request, etc., such as the unique ID, tag ID/target information, or combinations thereof. Thus, data returned by the third parties may also be stored (e.g., temporarily, or persistently) in association with unique IDs, tag IDs, target information, or combinations thereof. As one non-limiting example, service providers such as mobile/cellular providers may be queried to obtain information about user devices (14a, 14b). The unique ID identifying a particular user device may be sent to the service provider to obtain information about the particular device, or the service provider may provide information that may be later associated with a particular device. Either way, the platform (20) may collect and store information about users via the unique ID assigned to each user device (14a, 14b). As another non-limiting example, information associated with unique IDs assigned to user devices (14a, 14b) may be collected from various third-party integrations (320) such as in-venue/event metrics, integrated third-party metrics, ticket brokerage, and other tools, without limitation to the forgoing. In-venue/event metrics may include data collected relating to the venue, event, or both. For example, information relating to user purchases at the venue and/or during an event such as tickets, food, merchandise, and upgrades and the like may all be gathered and stored in association with the unique ID. Similarly, ticket brokerage integrations (e.g., 320) may be used to gather information from ticket brokers who sell tickets for the venue (202), event, or both, and may include a wide range of marketing data, not only about ticket purchases made, but also related information about the user. Thus, third-parties, including third party metrics integrations (320) may enable collecting information about users, user devices (14a, 14b), or both from third-parties including those who participate in a shared program or who sell or otherwise provide marketing information, demographics, and other data about the user.
In addition to collecting and storing data associated with unique ID, the platform (20) may analyze such data, which may or may not be recorded in association with unique IDs. Data analysis may occur while it is being collected, after it is collected and before it is stored, after storage, or combinations of the forgoing. Data, raw, analyzed, or both, may be stored in database (308) or another data store (at 512) such as blockchain (314), without limitation. The analytics server (312) may communicate with various aspects of the platform (20), to ensure data received from various sources is appropriately captured for decision making, analytics, and the like. That is, analytics server (312) may communicate with (either directly or via the interface server [306]), user devices (14a, 14b), third parties, third party integrations (320), time/timestamp (318), geofence (316), blockchain (314), database (308), even proprietor portal (322), or combinations thereof, so that data is captured as needed for desired analytics, decision making, and the like. For example, data may be subject to artificial intelligence analysis include machine learning/pattern recognition/deep learning as is now known or will be known in the art. Collected and/or analyzed data may be coupled with other information relating to the user/user device (14a, 14b), such as the unique ID associated with the user device (14a, 14b) for a variety of reasons, including content selection as one non-limiting example.
Content for display on user devices (14a, 14b) may be customized in numerous ways as has been detailed with respect to methods (400 and/or 500). Content may also be customized where data/data analysis shows that a user has, or group of users have particular preferences. These preferences may be utilized to modify content, such as advertisements that are delivered to that user/group of users. Furthermore, data analysis may allow the proprietor to generate rules specific to a user/group of users, send custom e-mails, push socket notifications or other messaging based upon the user's interactions/group of users' interactions with the platform (20), other such similar examples, or combinations thereof. Indeed, this provides for multiple opportunities for interaction and communication between the proprietor and the user to continue building relationships that can then be mined for longer-term relationships. As yet another implementation, the platform (20) may utilize unique IDs together with known information associated therewith to deliver unique advertising to users via third-party advertising services. For example, where available, the platform (20) has the ability to interface with advertising platforms to deliver a customized experience based on the user's search history or user information as a whole. Taking the forgoing together, it should be apparent that content provided to a particular user or group of users may be customized or modified as was described above with respect to
Analytics may also determine which feature, elements, or the like provided by a target such as the fan portal (218) a user or group of users interact with the most or spend the most time viewing. Thus, advertising on high-usage pages, features, elements, etc. may come at a higher cost. In other words, proprietors may charge a premium to advertisers wishing to purchase the ability to place content, such as advertisements or digital offers on the pages or features of the fan portal (218) or other target that receive the most traffic.
The forgoing has been described largely with reference to a sports environment where event users can scan tags (16a) located proximate each seat (208)/other point of interest or remote users can scan MRCs (17b) that appear on a screen such as a television or computer display. Other environments may utilize the same sort of tag (16a) placement strategy, such as an artistic performance where tags (16a) may be placed proximate a seat. However, many artistic performances are not televised or otherwise visually distributed while the performance is taking place. Thus, these proprietors may enable an option for patrons at a specific donation level, or season ticket holders to remotely access the performance as the performance is taking place such as via an account on a Web site where the user can scan an MRC (17b). Alternatively, certain remote users may receive a digital communication such as an e-mail or physical communication such as a card or badge that is similar to a credit card having information encoded thereon so that the remote user can scan the MRC (17b) on the badge to access the target that is associated with the scanned MRC (17b). In this way, remote users that are unable to attend a particular live performance may still be able to enjoy the performance or features thereof via platform (20). And since the target for remote users may have distinctive features enabled (e.g., replays, filters) during a performance that are not available to an event user (so as to not distract the performers) the remote user may be able to watch the entire performance on the remote user device (14b) and access other target features during the live performance.
Concerts and concert/festivals (collectively “concerts”) may utilize the tags (16a) already in place at the venue (202) in which the concert is being held if the proprietor so allows; alternatively, concert proprietors may utilize a system that is not attached to the venue (202), or they may use both. As an example, concert proprietors may include tags (16a) separate from or integral with concert tickets, passes, credentials, or the like so users can scan (or click on if digital) the MRC (17a) to access the desired target. In an embodiment, the ticket, pass, credentials, or the like may be a badge or badge-like so that it can be attached to a lanyard, put in a wallet, etc. Lanyards may be distributed with the ticket, pass, credentials, etc., or they may be purchased. As an incentive to purchase a lanyard, the lanyard may be associated with its own tag (16a) and associated target (e.g., a digital offer). In an embodiment, remote users who are unable to actually attend the concert may still be able to enjoy certain aspects of the concert via the tag (16b) associated with a ticket, pass, credentials, etc. In an embodiment, remote users may opt to purchase just a tag (16b) so that they may enjoy certain aspects of the concert without being there. As one non-limiting example, the tag (16b) may enable the remote user to access live or recorded video of the concert, which would not otherwise be available without concert attendance.
In the case of schools and the like, tags (16b) may be linked to particular students and distributed to students and parents alike. For example, the student's tag (16b)/MRC (17b) may be on the student's school-issued ID or student-related identifier, and the parent's tag (16b)/MRC (17b), which may be the same as or different from the student's MRC (17b), may be distributed to parents on a magnet, badge, card, or the like so that the student/parent can simply scan their respective tag/MRC (17b) (with respective user device [14b]) to access a target (e.g., a Web page) with information relating to the particular student such as grades, classes, upcoming activities, as a few non-limiting examples. In fact, with respect to graduation, concerts, sports events and the like, a secondary target may be accessed via a link in the “primary” target, although embodiments are not so limited. That is, parents, teachers (with their own tag/MRC (16b/17b) to connect to the desired target), other employees and the like may access targets (e.g., a Web page or the like) for events relating to the school in more than one way. One way may be via the tag/MRC (16b/17b) that may be used on a regular basis as described above, or via tags (16b) permanently or temporarily placed at the school gym, auditorium, or the like, which will enable access to the event-specific target/target content.
Historic sites, museums, zoos, and the like may use any of the forgoing strategies and other unique strategies to enhance visitor experiences via one or more targets of a tag (16a, 16b). As one non-limiting example, tags (16a) may be located at or near entrances for users to scan with their devices (14a) to obtain the target. Additional tags (16a) may be located at, near, within, etc., various exhibits to provide supplementary content. In this way, the target of the tag (16a) may be streamlined and supplemented at-will. In an embodiment, users may buy merchandise/concessions via in-venue tags (16a) much like the stadium example. By making a purchase, the user may use a tag (16a) associated with the purchase to connect to yet another target for that particular tag (16a) such as a coupon, discounted entry tickets, and free entry tickets as a few non-limiting examples. In fact, with any of the forgoing examples tags (16a, 16b) may be placed on or with merchandise of all sorts to be able to access targets such as coupons and/or other incentives.
Several of the following figures detail specific uses cases and embodiments that flow from the diagram. In particular, the embodiments relate to the acquisition of NFTs, implemented through the system. A significant benefit of the elegance of the embodiments herein is the ability to implement certain rules, and even complex rules related to NFT purchases. Another benefit is the ability to verify both the right to be in attendance and actual attendance at a given event, meaning that a user has both a ticket and was actually using the ticket at the venue or event related to that ticket. These and other elements are explored in the several embodiments, which thus allow a user to use some or all of the steps, in any order, which can be used alone or together to scan a tag from a user device and to obtain an NFT.
In response to the received request, the platform (20) may engage (step 604) an embodiment of a confirmation feature (605). Generally, the confirmation feature (605) confirms the place (606), time (608), seat (610), other conditions, limitations, requirements, metrics, or similar such standards (612), or combinations thereof. The degree to which confirmation is required may vary from embodiment to embodiment, which will become apparent from the examples provided herein. In an embodiment, the confirmation feature (605) is invoked upon an initial scan of the tag (16a) as described with respect to
In an embodiment where confirmation has been received by simply scanning the tag (16a, 16b) regardless of whether or not the tag (16a, 16b) is physically/digitally in the venue (202), the user may gain access (step 614) to an NFT acquisition module (615). The NFT acquisition module (615) may enable a user to acquire an NFT via paying a set purchase price (616), via an auction (618), via minting the NFT (620), or by accepting an offer for an NFT that was free or won (622). In an embodiment, the acquisition module (615) may be enabled by appearing on the user device (16a, 16b) in response to confirmation. As one example, the acquisition module (615) may be the initial target to which the user device (14a, 14b) is redirected upon scanning the tag (16a). Thus, if approved by the confirmation feature (605), the URL for acquisition module (615) may be sent to the user device (14a, 14b). See, e.g., method (400) at step (432). As another example, the acquisition module (615) may be represented as a selectable option (220), within the fan portal (218). The selectable option (220) may appear automatically or automatically unlocked upon additional confirmation by the confirmation feature (605) running in the background. Alternatively, a selectable option (220) may be “greyed out” or the like until enabled upon subsequent confirmation initiated by an attempt to select the “greyed out” version or a selectable “confirmation” option (220) or the like. Upon selecting the NFT purchase option, a landing page or the like may be displayed to guide the user through the appropriate acquisition process. Embodiments, however, are not limited to these examples.
In the instance where the desired NFT is being offered at a set purchase price (616), the simple act of supplying funds to buy at the set price results in the purchase of the NFT. In the instance where the desired NFT is being auctioned, those of ordinary skill in the art will recognize the auction (618) format, whether it is live or online bidding, and will also recognize how to win such an auction (618). Minting (620) in an embodiment, may occur in the situation where confirmation enables a user to upload an image (326a, 326b) from user device (14a, 14b) before proceeded with minting (620), or providing some other digital file to be minted. Depending on the minting services, the fees paid for minting may also purchase the NFT. Alternatively, purchasing the NFT may require an additional fee, which would be managed like a straight purchase (616). Similarly, the user may receive confirmation to acquire a free NFT or an NFT that the user has won (622), where instead of incurring fees, proof of purchase/ownership (626) can be provided upon the user's approval, such as via selecting an appropriate icon, button, or the like. In each of the forgoing examples, where appropriate, proof of purchase/ownership (624) may be sent via a crypto wallet (624), which may be or may not be linked to the digital wallet (24a, 24b). Furthermore, in an embodiment, NFT acquisition module (615) may be linked to one or more third-party NFT transaction providers that manage NFT related transactions including the sale (616), auction (618), minting (620), and other acquisition (622), of NFTs. The NFT acquisition module (615) may link to the third-party NFT transaction provider via a third-party integration (320), which may use one or more API calls to the third party NFT transaction provider as is known in the art, although embodiments are not so limited.
NFTs, however, by their nature are unique tokens. And, thus, there may be certain reasons why a particular user device (14a, 14b) may or may not be able to acquire an NFT, or where certain conditions must be met by the user device (14a, 14b) before being afforded the option to even bid at an auction or purchase an NFT outright. In one non-limiting example, the purchase of an NFT may be simply the conversion of a ticket, as owned by the user for that particular game, into an NFT. Here, the user would purchase the NFT, and such action would then mint the NFT, and would then serve as a verified token of the ticket for that game. In view of further embodiments detailed herein, several limitations may be put on the ability to make the purchase of the NFT for the ticket, including a given time (i.e., within a preset period, as a non-limiting example), at a particular location (i.e., within the venue), at the occurrence of an event (i.e., a particular team won, or some other metric occurred, as non-limiting examples), or that a user won a lottery or some other pre-determined metric for providing the right to acquire the NFT.
In embodiments where additional location information is needed before a user device (14a, 14b) is approved by the confirmation feature (605) the platform (20) may utilize a geofence (316). A geofence (316) may be thought of as a defined geographical zone that can be of virtually any size, or meet a particular limitation as needed for a particular embodiment. The limitations of how the geofence (316) may be used is, in some instances, dependent upon the limitations of the geofence itself (316). Thus, a geofence (316) may be created by any means known to those of ordinary skill in the art for defining the meets and bounds of an area.
In certain applications, the geofence (316) is the same as the venue (202) where the event is taking place. In other embodiments, the geofence (316) may be a section, portion, or other type of dividing scheme within the venue (202). In certain other embodiments, the geofence (316) is utilized for a much larger area, such as a state or a region. Generally, a geofence (316) works by receiving data from user device (14a, 14b), which is checked against the area defined by the geofence (316). The user device (14a, 14b) location is either within or outside of the geofence (316). Data receive by user device (14a, 14b) includes without limitation, coordinates for longitude and latitude, GPS coordinates, RFID data, WiFi data, or data from a mobile network, and other such examples. As is shown in
In some cases, the geofence (316) is used to try to prevent fraud. For example, some people may try to “beat the system” by taking a photograph of a tag (16a) in one location, such as a VIP area of a venue (202), to try to acquire benefits that may be awarded to that location, such as free drinks with the purchase of an NFT, or other benefit afforded from the tag (16a). If the geofence (316) defines only the VIP area, and the user device (14a) is not within the geofence (316), then confirmation is denied, and the user device (14a) is not enabled to acquire the NFT or the benefit of the NFT. In other cases, the geofence (316) may be used to open or limit opportunities to acquire an NFT, which is made clear in the examples. As one simple example, however, the geofence (316) may be used to give away an NFT to those user devices (14a, 14b) within the geofence (316). Thus, an NFT acquisition module (615) may be enabled on select user devices (14a, 14b) within the geofence (316). The geofence (316), however, may be used for any other reason that a user device (14a, 14b) location may need to be confirmed and is not limited to examples herein or NFTs in general.
Again, taking the example shown in
At step (802), the platform (20) may receive a request for the NFT from many user devices at the same time due to the MRC displayed on the jumbo screen (204). The tag ID for the tag (16a)/MRC (17a) on the jumbo screen (204) would indicate that the venue exists, and the event is in progress per method (400). Since the jumbo screen (204) may be shown on a national broadcast of the game, or a user at the stadium has recorded the unique offer (214) and posted it on social media or other such situation, the location (step 804) of the requesting user devices (14a, 14b) may be checked to determine if it is within the geofence (316). In this example, the time (608) of the request (step 806) may also be checked to ensure that the requesting user device (14a, 14b) is within the geofence (316) at the time (608) the request has been made (step 808). As a non-limiting example, the time (608) may be checked (step 806) by consulting the recorded time data that was associated with the unique ID and tag ID when the request was made or via a time check (318), as is generally known in the art. If the user device (14a) is within the geofence (316, step [810]), then the user device (14a) is approved or confirmed (812) by the confirmation feature (605) and the NFT acquisition module is available to the user device (14a). If the user device (14b) is not within the geofence (316, step [814]), the user device (14b) is not approved by the confirmation feature (605) and the user device (14a) is unable to acquire the NFT (step 816). To finish the example, after the first 1000 in-venue users have acquired (216) the offered sequentially numbered NFT, the unique offer (214) is disabled and any further attempts to acquire the offered NFT are redirected as appropriate, such as a page indicating that the offer has expired, or redirected to a home page, or venue page as determined by the proprietor. Thus, if the user device (14a, 14b) is inside the prescribed geofence (316) at the given moment the determination (step 808) is made, then the user device (14a, 14b) may be approved by the confirmation feature (605), or it may have to undergo additional confirmation as is described with respect to
As one nonlimiting example, seat 1, row A, section 100, may have a special meaning or value associated therewith for a given event, or may grant the owner of the seat some benefit. In this example, the venue (202), had an NFT lottery and the winner is granted the ability to acquire the NFT whether it is free, part of an auction, straight purchase at a given purchase price, or the ability to mint a digital file uploaded by the user. Seat 1, row A, section 100 is the winning seat of the lottery. Thus, confirmation feature (605) may seek to ensure that the user device (14a) requesting the ability to acquire the NFT is associated with the user that purchased the ticket for the winning seat and not from someone else. There are many examples of someone not being in the right seat, due to user error, or simply someone picking a different seat than one in which they hold a ticket. In other, more sinister instances, a tag (16a) could be imitated, such as a photo or recreation of the tag (16a), for someone seeking to obtain the rights and privileges to that tag (16a), without actually having the rights to that tag at the given moment or event, i.e., you must actually have owned that ticket for that seat.
Thus, the ability to identify and confirm the right to sit in a particular seat, i.e., the user actually has the ticket for the seat in question, may have value to both the venue (202) and the user who holds the ticket for the particular seat. In the past, holding a paper ticket/ticket stub for a given seat, confirmed that that the user was at the game and sat at a particular seat. Today, many users opt for digital tickets, which may require an alternative to confirming that the user of the device (14a) also holds the ticket for the winning seat.
For the present example, the right to be in the particular seat and to have the right to scan that tag (16a) for that seat is limited to the person holding the ticket to that seat. What is not known is whether the person scanning that tag (16a) has the right to be in that seat. As such, the confirmation module (605) may utilize some or all of a seat verification method, such as method (900). Method (900), in this example, is being used to verify that a user holds the ticket for seat 1, row A, section 100 so the user can claim his/her NFT. It should be noted that method (900), may be called in response to scanning a tag (16a) on the seatback (208) in front of the user or in response to selecting an option (220) from the fan portal (218). Thus, some or all of the method (900) may be incorporated into method (400) when the confirmation module (605) confirms place, time, and grouping (
In certain embodiments, the NFT confirms ownership of an original, digital file. The digital file, in certain embodiments includes a tag, such that, by accessing the NFT by the owner, and scanning a tag, which is the subject of the NFT, that scan of that tag within the storage system of the NFT is what confers the benefit. Thus, as each tag is uniquely coded, the specific tag in the NFT would be tied to the owner or unique ID, so as to be validated for the particular benefit being afforded.
Referring to
If, however, a digital ticket was not found on user device (14a) (step 902, no) or the digital ticket data does not match with tag ID data, (step 904, no) then the confirmation feature (605) may look elsewhere to try to verify that the correct user is sitting in the correct seat. As one non-limiting example, the confirmation feature (605) may use a third-party integration (320) to make an API call to a third-party ticket seller, in-venue ticket seller, or the like, to try to verify that the user device (14a) used to scan the tag (16a) associated with seat 1, row A, section 100, is the seat in which the person using the device (14a) is entitled to sit. For example, the ticket seller may obtain certain personal identifying information when a ticket is bought. Such information may include, but is not limited to name, address, phone number, credit card information, or another set of data that may be used to determine if the user device (14a) that scanned the tag (16a) has the particular right to the given seat during the event in progress. Thus, the API (or other) call may provide other digital data (910) that may or may not match (step 912) the tag ID data and/or unique ID data. An example where seats may not match at step (904), but data may match at (912) is where the user of the device (14a) purchased several seats at the same time, such as where a family purchased five tickets for the game. In reality, the same user may have purchased all of the tickets, but the ticket on user device (14a) is for the next seat over, or that particular device (14a) does not have any digital ticket stored thereon. Either way, data from the ticket seller may confirm (step 912, yes) that user holding user device (14a), is indeed entitled to make a request to acquire the offered NFT (step 906). Alternatively, digital data may be obtained from user information, such as an email, credit card, phone number, address, or other data related to the purchase of that seat. Nevertheless, if such data is absent or proves deficient (step 912, no), then a determination may be made to see if a paper ticket (step 914) is available to allow seat verification via the confirmation feature (605).
If a paper ticket is produced (914) and the seat on the paper ticket matches the seat associated with the tag ID (i.e., seat 1, row A, section 100) (step 916, yes) then the confirmation feature (605) may verify the seat (step 906). For example, paper tickets frequently have a code or other information printed thereon that can be scanned to verify the information on the ticket for this purpose. If no (step 916, no), then seat verification is denied (step 908).
Returning back to step (914), if the user does not have a paper ticket (step 914, no) then the user may request verification via an alternative validation source, such as an entity, other than previously consulted, that may have provided the ticket (step 918). Such an example may be that the user bought the ticket from a friend and did not transfer the electronic file related to the ticket. A simple text or email to the friend may allow the user to get the necessary information to validate (step 918) and, if upon re-running the process the requisite data matches (step 918, yes) the seat is verified (step 906). Otherwise, seat verification is denied (step 908).
In each of the processes that may be utilized by the confirmation feature (605), user device (14a) approval with respect to a particular tag (16a), hence the seat, is an initial, gatekeeper function, which may be simple or complex depending upon the certainty desired under the circumstances. Confirmation may be heighted when granting rights enabling user minting of an NFT. That is, a user may mint an NFT for a digital file (326a, 326b) such as a photo, video, digital ticket, etc., that the user created at the event without specifically being granted the right by the proprietor. Like many unique items, however, the story behind the subject matter may influence the subject matter's value. Thus, an NFT that is minted after approval from the confirmation feature (605) may add to the desirability (i.e., value) of the NFT. This is especially true where confirmation feature (605) approval is due to some limitation or special circumstance making that particular NFT very scarce, hence increasing its value. For example, the venue (202)/event may hold a lottery where a given seat at the venue (202) is revealed as the winner. The NFT from this win may be the only official NFT one provided for the subject matter therefore increasing its value. In other non-limiting examples, a contest winner, a purchase made, a prize awarded, or any other reason may limit the right to acquire an NFT via scanning a given tag (16a, 16b). As such, the confirmation feature (605) may require multiple levels of confirmation to be satisfied.
Referring to
If user device (14a) passes the seat verification step (1002, yes), then any time requirements (1006) may be confirmed. Generally, the confirmation feature (605) may determine if the NFT is available at the moment when it checks the time requirements. For example, the NFT may only be available during a set window such as 10 minutes after the first touchdown of the game, as one non-limiting example. To make such determination, the time (318) from an official time keeping element, as is known in the art, may be consulted, and compared to the time set for NFT availability. If the time is confirmed, i.e., the request for the NFT was made while window is open (step 1006, yes), the method (1000) may progress to a geolocation check. If not (step 1006, no) then the user device (14a, 14b) is denied (step 1008) the opportunity to acquire the NFT.
In an embodiment, geolocation determination is made via consulting the geofence (316), as was described with respect to method (800). That is, some or all of the steps associated with method (800) may be utilized by the confirmation module (605) to verify geolocation. If user device is outside the prescribed geofence/geolocation (step 1010, no), then the user device (14a) is denied (step 1012) the ability to acquire the NFT. If, however, the user device (14a) is within the geofence/geolocation (step 1010, yes), then the user device (14a) is approved by the confirmation feature (605) and the NFT acquisition module is enabled (1016). Thus,
Notably, each of the steps regarding seat verification (1002), time confirmation (1006), and geolocation verification (1010), can be used independently or together, based upon the given rules for the NFT release. Indeed, step (1020) simply determines after any one or all of the prior confirmation features if any other rules are in place, and if any such rules are not fulfilled the acquisition is denied (step 1018). As defined in
Minting (step 1124), purchasing (step 1110), and other ownership rights (e.g., steps 1116, yes, and 1104) in an NFT may be through one or more exchanges/marketplaces that mint, list, and/or sell NFTs. In an embodiment an exchange/marketplace may be available via a third-party integration (320), which may use one or more API calls to complete a transaction. In other embodiments, the user may be provided with options to go to the user's exchange/marketplace of choice (e.g., outside of platform [20]) where the transaction may take place. Thus, minting (step 1124), as with the other acquisition options, is not limited to utilizing a third-party integration (320). Nevertheless, when the desired transaction is completed, interface server (306) or other suitable server may communicate directly with a blockchain (314), indirectly through a third-party integration (320), or both, to record the transaction (e.g., ownership/change of ownership). As one non-limiting example, the interface server (306) may access the digital wallet (24a) and/or another crypto wallet (not shown), to provide funds for the transaction, whether it be winning an auction, purchasing, or minting. Upon minting (step 1124), “lazy minting”/purchase (step 1110), or other acquisition method, the interface server (306) may be utilized to record the NFT on the blockchain (314) and provide proof of the transaction to the appropriate parties' digital wallets (24a, 24b) or another necessary crypto wallet (not shown) (step 1106 or 1126). Of course, the user has the option to exit the NFT acquisition module (615) without acquiring an NFT (step 1120, no, to step 1128).
E
Referring to figures described herein, the user device (14a) may be used to scan a tag (16a) on the seatback (210) in front of the user. The platform (20) will check to see if the event is occurring at the place acknowledged to be hosting the event. See, e.g., method (400). If so, the user device (14a) will be redirected to either the fan portal (218), where the user may select an option (220) to try to obtain the NFT or may be subject to additional approval by the confirmation feature (605) as is determined by the event or venue (202) proprietor, or some other authority. If additional approval is required, then under both scenarios the confirmation feature (605) may utilize one or more of a seat verification method (e.g.,
Thus, at step (1002), additional approval by the confirmation feature (605) would look to a seat verification method such as some or all of the method (900) detailed in
The confirmation feature (605) may then call upon the geofence (316) to determine if user device (14a) is at the venue since the offer is only available to in-venue users who are the physically present at the venue (202) hosting the championship game. Thus, a geofence (316) would be provided around the venue (202). If the user device (14a) is within the geofence (316), as determined by a method that is the same as or similar to method (800) then the confirmation feature (605) finally approves (step 1014) the request for the NFT and the platform (20) enables the NFT acquisition module (step 1016). If however, the user device (14a) is not within the geofence (316), then the user device (14a) is denied access to the acquisition module (step 1012). After being enabled, the NFT acquisition module (615) allows the user to acquire the commemorative NFT, such as by a method that is the same as or similar to method (1100), as one non-limiting example. Accordingly, one can see the simple elegance of multiple steps to confirm the right to seek purchase of an NFT and the implementation of certain rules.
E
E
E
As the user continues her visit at the museum, she continues to scan tags (16a) with her user device, the platform (20) updates her user record each time the device (14a) associated with the unique ID scans a tag (16a). In this way, the record associated with the unique ID also notes which tags have been scanned. Once the tag IDs stored on the user record match the variables determined by the system administrator, the acquisition module (615) is launched as detailed above in
E
In the example of the new baby animal at the zoo, the administrator determines the parameters that must be met by a user in order for that user to be granted the right to mint, purchase, bid-on or otherwise acquire the NFT. For example, the user may be required to scan the tag located near the animal's habitat during certain time parameters set by the administrator. Or the user may be required to scan a certain number of tags within a geofenced location as described in
In the various embodiments herein, the NFT may confer certain unique rights to the owner, as determined by the administrator or proprietor. Thus, the purchase of said NFT may not only give the intrinsic value of the NFT, but also those supplemental rights. Within a venue, such NFT rights could include, but are not limited to: free beverages or food, special rights or entry, specific seat upgrades, backstage access, discounts to tickets, merchandise, or other materials at the venue, special discounts related to wagering, or other tangible benefits that may be given by a proprietor at a given venue. Thus, the ownership of said NFT may have value to the user beyond its intrinsic value.
In either event, users at the respective venue scan tags (16a) with their user device (14a) to initiate a method that is the same or similar to method (400). The confirmation feature (605) may use the data in the record associated with the unique ID to determine if parameters set by the administrator have been met by the user device (14a) such as place and time. That is, the tag (16a) scanned by user device (14a) transmits its tag ID to the platform (20). From this, the method (400) can determine that the particular tag is at the venue and is associated with the particular location such as the habitat or the like. The confirmation feature (605) may also use the tag ID to ensure that an event is in progress per method (400), step 418. The confirmation feature (605) may also use the geofence (316), time (318) or both as has been detailed with respect to
E
The administrator may set any number of parameters required to make the NFT available to the user, for example, the tag must be scanned within one hour of the venue opening on the day the rollercoaster debuts, or the tag must be scanned within one week of the day the rollercoaster debuts. Likewise, the administrator can set additional parameters such as the user has N number of minutes from the time the tag was scanned to mint, purchase or acquire the NFT or the NFT is no longer available to the user.
When the user device (14a) scans the tag (16a), the system follows the steps previously detailed above available to the confirmation feature (605) including time determinations using platform resources such as time (318), data stored in database (308) or other data storage, third-party integrations (320) or the like to meet the specific parameters required for confirmation. Once approved by the confirmation module (605), the acquisition module (615) is enabled and the user is able to mint, purchase or otherwise acquire an NFT commemorating that he rode the rollercoaster on the day it debuted (or other time parameters as established by the administrator or the proprietor) in the front row (or specific location of his scan) per one or more steps detailed in
E
In an embodiment of the present invention, a tag (16b) or “tag less” MRC (17b) may be provided in a video feed of the event, which upon approval by the confirmation feature (605) enables the user to acquire an NFT. Such MRCs (17b) may be provided in or as an overlay on a live video feed for an event being broadcast over the Internet, network, cable television, or the like. For example, a network broadcast of the Superbowl, may contain a tag (16b)/MRC (17b) in the lower righthand corner of the video feed. This tag could be the same tag for every viewer or different tags could be visible to different geographic regions as determined by the administrator, owner of the tag, or entity with the broadcasting rights.
The NFTs made available for acquisition, may include any number of NFTs for a particular event. The NFT offered via the video feed may be the same as or different from the NFT offered to in-venue users. Furthermore, multiple different NFTs may be provided and offered for acquisition based upon geographic location. Thus, the NFT offered to a remote user watching the live video in Philadelphia may be different from the NFT offered to a remote user watching in Dallas.
Additionally, the administrator has the ability to set an infinite number of variable parameters that must be met before the confirmation module (605) give approval. For example, if one tag (16b)/MRC (17b) is displayed to a large geographical area, the administrator my use the GPS location of the user device to determine which NFT the user is eligible to purchase. Likewise, the administrator may create a geofence of any area and only offer a particular NFT within that geofenced location, as has been detailed with respect to
E
In this example, platform (20) queries events record e.g., stored in database (308) or other suitable storage to identify the event that has now become significant. For example, after Rolling Stones' drummer Charlie Watts passed away in 2021, the Aug. 30, 2019, at the Hard Rock Stadium in Miami became historically significant as his last concert. The platform (20) then queries the tag ID for each seat located at the particular venue. Next, the platform (20) queries the database (308) or other data store, to identify the unique ID of all user devices (14a) that scanned a tag (16a) while the event was in progress, which in this example, was Aug. 30, 2019, between 7:00 pm and 11:00 pm. Next, the platform (20) may query the user record associated with unique ID and cross references other verification datapoints and API calls such as whether a digital ticket was stored in the digital wallet (24a) of the user device. Once all of the confirmation features established by the platform (20) or an administrator have been met, the user is permitted to mint, purchase, bid-on or otherwise acquire an NFT as described herein, to the extent that one is offered or is made available.
Example 9. In certain embodiments, the right to acquire an NFT may require some element or actions by the user such as those designated by a particular event/venue sponsor. As such, the event, venue, proprietor, or the like may provide engagement opportunities such as via the portal such as the fan portal (218), one or more Web pages, push notifications, or the like. For example, a hotel may enable engagement opportunities such as checking out of the hotel, ordering room service, purchasing merchandise, and the like, whereas a campus may include engagement opportunities such as buying tickets to a game or an event, registering for free events, taking polls, creating study groups, and the like. And a stadium or concert may detail purchase of food or novelties, placing a wager, or engaging with other features in a pushed Web page. As expected, engagement opportunities may vary widely between industries and sponsor types. Nonetheless, the user, via user device (14a, 14b) may have to satisfy the elements/actions before being approved by the confirmation module (605). As one non-limiting example, only those users who have purchased food, or a novelty, placed a wager, or purchased some item will be approved to acquire an NFT via the acquisition module (615)/method 1100.
Example 10. Certain embodiments may tie the acquisition of an NFT to a benefit such as an upgrade to a better seat, lounge access, unlimited food and drinks, or other such benefit as the proprietor, venue, or event prescribes. For example, purchasing an NFT, winning an NFT auction, or approving a winning NFT may come with access to a VIP lounge, even if the user's original seat was not in a VIP section. In each case, the confirmation feature (605) would be configured to ensure that the user was entitled to the NFT, hence the benefit. For example, in addition to the preliminary place and time performed during method (400), the configuration feature may also ensure that the user was entitled to sit in the seat tied to the benefit thereby calling on a seat verification method such as one that is the same as or similar to method (900). Of course, the confirmation may also call on a method such as method (800), to ensure the user device (14a) is within a predetermined geofence (316).
Example 11. The subject matter of the NFT may include a tag (16b) with a functional MRC (17b) so that the user who acquires the NFT will also acquire the target to which the NFT tag is tied. As one non-limiting example, the subject matter of the NFT may include a tag that, when scanned by the user device (14a, 14b) links the user device to a commemorative digital event program having unique content such as video clips, images, and interviews of key people all related to the event that the user attended, watched on a video feed, or the like. Since the subject matter and/or the digital event program may have significant collectable value, the confirmation feature (605) may be configured to approve the acquisition of the NFT only upon heightened approval such as the user device (14a) by being within a geofence (316) per a method such as method (800) and/or a seat verification method such as method (900). Furthermore, an administrator may attach one or more conditions to confirmation feature (605) approval such as the NFT is only available to user device (14a) that have fulfilled a task such as attending three separate events hosted by the proprietor, as one non-limiting example. Indeed, preferred embodiments often require a complex set of rules or obligations to be met, in order to qualify for the right to purchase an NFT that yields some supplemental benefit. Proprietors will recognize that events that engage with fans and force them to participate in or find certain elements to win a prize, are the most loyal fans. Thus, such events can both incentivize participate and also engage fans with content.
Example 12. Certain NFTs, in an embodiment, may be dynamically priced, which in turn may affect the value of the NFT. For example, if a given number of approved users (e.g., via their user device [14a, 14b]), purchase an NFT, the price of the NFT may increase or decrease. In the instance of a price increase, the NFT may become more valuable as more approved users purchase the NFT, which here can be a partial ownership or sequential NFT, wherein the NFT are sequentially numbered to remain distinct. The first approved users to acquire the NFT get the NFT at a lower price and the users who acquire the NFT later pay a premium on the NFT, similar to the rise in popular stock. In this way, the approved users who purchased the NFT at a lower price may receive a better return on their investment. Since time may be of the essence in such an acquisition, the confirmation feature (605) may be configured to utilize a more sophisticated time confirmation technique than the determination at method (400), that the event is in progress. Furthermore, the NFT acquisition module may be configured to enable a price increase as provided by the administrator such as for every ten NFTs purchased raise the price by X number of dollars, or any other pricing increase scheme.
Example 14. In certain instances, purchasing an NFT for a work of art may be equally or more valuable than the original work of art. In this example, a gallery has artwork on display for purchase. Near each work of art is a tag (16a) which has been assigned a tag ID uniquely coded to that piece. When a user scans the tag (16a) with his user device, the user is redirected to a Web page with purchasing information for the NFT for that particular piece. The number of NFTs available for purchase is determined by the administrator or the proprietor. For example, there may only be one NFT available. Likewise, the purchase price, or alternatively, an auction, is set by the administrator or proprietor, together with any other conditions (i.e., rules) that must be met for the purchase of the NFT. If the user meets rules that are in place, if any, the user is permitted to purchase the NFT.
In the instance of a price decrease, the confirmation feature (605) may be configured to wait to see if N number of devices (14a, 14b) are approved before enabling the acquisition module (615) to offer the NFTs at a lower price. If the N number of devices (14a, 14b), however, are not approved within a given amount of time, then the acquisition module (615) may release the NFTs at a higher price.
Example 13. Similar to Example 12, Example 13 may utilize an escrow-type of pricing where approved user funds are held, but the NFT is only released if the stipulated conditions are met. As one non-limiting example, if 100 users at a Superbowl game sitting in a certain section of the venue commit to purchasing an NFT related to the game by transferring funds for the purchase, then the NFT will be released and the funds deducted from the user's wallet (e.g., 24a or the like). If, however 100 users do not commit to purchasing the NFT, then the held funds may be returned to the user's wallet (24a) or held as a down payment on a future NFT purchase price, auction bid or the like.
Referring back to
Administrator device (12), which is shown in
The administrator device (12), user devices (14a, 14b), and servers (e.g., 302, 306, 310, 312, 320, 322, and 324) may each be a general-purpose computer. Thus, each computer includes the appropriate hardware, firmware, and software to enable the computer to function as intended and as needed to implement features detailed herein. For example, a general-purpose computer may include, without limitation, a chipset, processor, memory, storage, graphics subsystem, and applications. The chipset may provide communication among the processor, memory, storage, graphics subsystem, and applications. The processor may be any processing unit, processor, or instruction set computers or processors as is known in the art. For example, the processor may be an instruction set based computer or processor (e.g., x86 instruction set compatible processor), dual/multicore processors, dual/multicore mobile processors, or any other microprocessing or central processing unit (CPU). Likewise, the memory may be any suitable memory device such as Random Access Memory (RAM), Dynamic Random-Access memory (DRAM), or Static RAM (SRAM), without limitation. The processor together with at least the memory may implement system and application software including instructions, including methods, disclosed herein. Examples of suitable storage includes magnetic disk drives, optical disk drives, tape drives, an internal storage device, an attached storage device, flash memory, hard drives, and/or solid-state drives (SSD), although embodiments are not so limited.
In an embodiment, servers (e.g., 302, 306, 310, 312, 320, 322, an/or 324) may include database server functionality to manage database (308) or another database. Although not shown, infrastructure variations may allow for database (308) to have a dedicated database server machine. Database (308) and any other database may be any suitable database such as hierarchical, network, relational, object-oriented, multimodal, nonrelational, self-driving, intelligent, and/or cloud based to name a few examples. Although a single database (308) is shown in
It will be appreciated that the embodiments and illustrations described herein are provided by way of example, and that the present invention is not limited to what has been particularly disclosed. Rather, the scope of the present invention includes both combinations and sub combinations of the various features described above, as well as variations and modifications thereof that would occur to persons skilled in the art upon reading the forgoing description and that are not disclosed in the prior art. Therefore, the various systems and methods may include one or all of the limitations of an embodiment, be performed in any order, or may combine limitations from different embodiments, as would be understood by those implementing the various methods and systems detailed herein.
This application claims the benefit of U.S. Provisional Patent Application No. 63/269,015 filed on Mar. 8, 2022, U.S. Provisional Patent Application No. 63/201,373 filed on Apr. 27, 2021, and US Provisional Patent Application No. 63/201,376 filed on Apr. 27, 2021, all with the United States Patent and Trademark Office, the contents of which are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63269015 | Mar 2022 | US | |
| 63201373 | Apr 2021 | US | |
| 63201376 | Apr 2021 | US |
