WO2023212113A1 - Data aggregation - Google Patents

Data aggregation Download PDF

Info

Publication number
WO2023212113A1
WO2023212113A1 PCT/US2023/020064 US2023020064W WO2023212113A1 WO 2023212113 A1 WO2023212113 A1 WO 2023212113A1 US 2023020064 W US2023020064 W US 2023020064W WO 2023212113 A1 WO2023212113 A1 WO 2023212113A1
Authority
WO
WIPO (PCT)
Prior art keywords
tag
event
user device
unique
user
Prior art date
Application number
PCT/US2023/020064
Other languages
French (fr)
Inventor
Cameron Fowler
Matthew Sullivan
Original Assignee
Digital Seat Media, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digital Seat Media, Inc. filed Critical Digital Seat Media, Inc.
Publication of WO2023212113A1 publication Critical patent/WO2023212113A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/955Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9554Retrieval from the web using information identifiers, e.g. uniform resource locators [URL] by using bar codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/4104Peripherals receiving signals from specially adapted client devices
    • H04N21/4126The peripheral being portable, e.g. PDAs or mobile phones
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/422Input-only peripherals, i.e. input devices connected to specially adapted client devices, e.g. global positioning system [GPS]
    • H04N21/4223Cameras
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44008Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/47815Electronic shopping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6581Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835Generation of protective data, e.g. certificates
    • H04N21/8358Generation of protective data, e.g. certificates involving watermark
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/858Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/021Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/068Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/69Identity-dependent
    • H04W12/77Graphical identity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H04W4/23Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel for mobile advertising

Definitions

  • the invention is related to systems and methods for delivering content to users through a system comprising machine readable codes defined on a tag; and wherein users engage with the system with a user device, wherein the system aggregates data from the user device to populate dynamic content to the user.
  • Applicant has detailed an elegant solution using a system and methods to aggregate data and push content through a user device, based upon a system of tags comprising a tag ID and matching a scan of a tag to a user device compnsing a unique ID; wherein actions by the user device are stored in a database and can be mined to determine content that is of interest to a user/group of users; to generate/evaluate tag groupings, campaigns, or the like; to define rules or other devices to push data to user devices, or combinations thereof.
  • the present invention is a system for delivering content to users only when a predetermined threshold has been met by users on the system. Upon the occurrence of that predetermined threshold, the system knows that there are enough users on the system so that the content will have maximum impact.
  • the embodiments detailed herein specifically detail systems and methods for generating content by accessing a machine-readable code (“MRC”).
  • MRC machine-readable code
  • preferred embodiments generate unique content, and wherein the system utilizes a unique ID to identify a user device within the system.
  • the present embodiments are directed to a method and system for aggregating data from a plurality of user devices, wherein the user data is utilized to define a tag grouping corresponding to a similarly situated user device; said tag grouping defining a set of content to be received by all user devices within said tag grouping.
  • a method for delivering dynamic content to a user device via a machine-readable code comprising: in response to scanning a tag comprising the machine-readable code, receiving a request from a user device and detecting the presence of a manifest packet or locally stored data file comprising a unique ID, wherein if no unique ID is present, creating a unique ID and associating a record with the unique ID within a database; detecting from the tag a tag ID and determining: whether a venue corresponding to the tag ID has been defined; and whether an event is in progress corresponding to the tag ID; redirecting to a default target if no venue exists or no event is in progress, and determining if a tag ID is grouped where the venue exists and an event is in progress; counting, via a counting mechanism, the total number of user devices identified by unique IDs that have scanned a tag while the event is in progress and determining, via the counting mechanism, whether a threshold number of user devices have scanned a tag; upon meeting the threshold number, in response to the detecting from
  • the method further comprising: providing a first supplemental content to the user device when the threshold number is unmet and a second supplemental content upon meeting the threshold number.
  • the threshold number is selected from the group consisting of: a total number of unique users on a system at a time t, the total number of unique users accessing a system after a time t, x number of scans corresponding to a unique ID and x number of tags, and combinations thereof.
  • the method wherein the total number of unique users on the system at a time t is greater than 1,000.
  • the method wherein the total number of unique users on the system after a time t is greater than 1,000.
  • the machine-readable code is selected from the group consisting of: a barcode, a quick response (QR) code, a near-field communication (NFC) code, a radio-frequency identification (RFID) code, and combinations thereof.
  • the method wherein the target is stored within a database and is automatically provided upon the occurrence of the event.
  • a system for displaying unique content to users at a venue via at least one user device comprising: a server system having a computer processor and computer memory; a plurality of machine-readable codes, each of the machine-readable codes encoding an address controlled by the server system, each of the machine- readable codes being operatively mounted within the venue for access by all user devices in the venue; a counting mechanism operably connected to said server system; and wherein the computer memory of the server system stores executable code, wherein when executed the executable code enables the server system to perform a process comprising the following steps: receiving a request from one user device, the request generated by scanning one of the machine-readable codes with said user device; determining whether a unique ID is associated with said user device or generating a new unique ID to the user device that scanned the machine-readable code and associating said unique ID to a database record; collecting user data associated with the
  • the threshold is selected from the group consisting of: a total number of unique users on the system at a time t, a total number of users accessing the system after a time t, and combinations thereof.
  • the system wherein the unique content is a digital offer or an advertisement.
  • the system wherein the digital offer is modified by a provider of said digital offer.
  • a digital offer is provided based upon meeting the threshold and wherein said digital offer may be modified based upon meeting a subsequent threshold.
  • the threshold is selected from the group consisting of: an action in a game, a score in a game, a charitable donation, a purchase, a predetermined time, inventory, and combinations thereof.
  • the system wherein the machine-readable code is printed on a surface.
  • the system wherein the machine-readable code is embedded within a surface.
  • the system wherein the machine-readable code identifies a specific location via a known location of the machine-readable code, GPS, or both.
  • the system wherein the user data is selected from the group consisting of: a date, a time, a GPS location of the machine-readable code, a type of communication device used to scan the machine-readable code, an orientation of a communication device when the machine-readable code was scanned, a type of operating system on a communication device that scanned an interactive code, and combinations thereof.
  • the system wherein the unique content directs the user device to a Web page, and wherein analytical data from the Web page is collected and consists of data selected from the group consisting of: time spent on a Web page, purchases made, IP address, personal information input by a user, products viewed, cookies, pixels, and combinations thereof.
  • the system wherein the user device further receives in-venue metrics via an in-venue metrics API and wherein said in-venue metrics are utilized as data or to modify the unique content.
  • the system wherein the user device further receives third party metrics via a third party metrics API, and wherein said third party metrics are utilized as data or to modify the unique content.
  • the system wherein the machine-readable code is displayed upon a video board located within the venue.
  • a trigger is related to an action performed by at least one fan in attendance of an event.
  • a system for generating unique content to at least one user device upon meeting a threshold of users to the system comprising: a server system having at least one server, at least one computer processor, and a computer memory; a plurality of machine-readable codes, each of the machine-readable codes encoding an address controlled by the server system, each of the machine-readable codes being operatively mounted within a venue for access by all user devices in the venue; and wherein the computer memory of the server system stores executable code, wherein when executed the executable code enables the server system to perform a process comprising the following steps: receiving a request from one user device, the request generated by scanning one of the machine-readable codes with said user device; directing the user device to a URL that is uniquely encoded to the machine-readable code; receiving the request at an identification server, determining a result of whether the at least one user device is new or returning, and informing an interface server of the result; generating an unused unique ID for a new user which is stored in a database; receiving an instruction at the interface server
  • a method for distributing different versions of an interactive digital event program corresponding to an event to a plurality of user devices comprising: receiving a request for an interactive digital event program from a first user device, the request received in response to scanning a first tag having a machine readable code with the first user device; determining that the first tag belongs to a first group of tags to which a first version of the interactive digital event program is to be distributed; providing the first user device with the first version of the interactive digital event program, the first version of the interactive digital event program to include at least one dynamic content element that is capable of being updated through a third party integration while the event is in progress; and updating the at least one dynamic content element in the first version of the interactive digital event program in response to detecting an occurrence of a predefined trigger.
  • the method wherein updating the at least one dynamic content element includes updating dynamic content selected from the group consisting of: a map, a video replay, augmented reality, a fan camera, a fan filter, live statistics, a non-fungible token, wagering, an audience participation activity, upcoming events, merchandise, concessions, a digital offer, or a ticket.
  • the method wherein the digital offer is unlocked in response to using an in-venue map.
  • the method wherein additional tags are distributed around a venue and the location of the additional tags is marked on the map.
  • the method wherein the additional tags are used to facilitate an event wide scavenger hunt.
  • the method wherein the dynamic content element is for a digital offer, which is downloaded to the first user device. [0039] The method wherein the dynamic content element is streamed live action taking place at the event. [0040] The method wherein the dynamic content element is recorded action taking place at the event. [0041] The method wherein the dynamic content element has an augmented reality object overlayed or embedded thereon. [0042] The method wherein the dynamic content element is for a digital offer, the digital offer linked to the dynamic content element after the event has started. [0043] The method wherein the dynamic content element is dynamically positioned within the interactive digital program to have the maximum exposure to a plurality of users.
  • the dynamic content element is for a digital offer that is synced to advertising shown on a jumbo screen, a televised broadcast of the event, or both.
  • the method wherein the dynamic content element is for statistics that are updated in real time as the event is taking place, a dynamic image element proximate the dynamic content element to dynamically display an image corresponding to the statistics, or both.
  • the method wherein the dynamic content element is an offer for a non- fungible token for the first version of the interactive digital program.
  • the method wherein the dynamic content element is a listing of upcoming events that is customized for the user device based on past event history, primary geographical position, current geographical position, or combinations thereof.
  • the method wherein the digital offer is a dynamic digital offer based on inventory levels on merchandise available at the event. [0049] The method wherein the digital offer is customized based on version of the interactive DEP and demographic associated with users of user devices receiving the first version of the interactive digital event program. [0050] The method further including updating the interactive digital event program after the event is over. [0051] The method further including updating the interactive digital event program over the course of a season to document a season of events. [0052] The method further including basing the interactive digital event program on a template, the at least one dynamic content element dragged and dropped into a desired position within the template, and wherein the dynamic content element can be modified by an administrator within the template.
  • the method further including repositioning the at least one dynamic content element in the template while the event is in progress.
  • the method further including, receiving a second request for an interactive digital program from a second user device, the second request received in response to scanning a second tag having a machine readable code with a second user device; determining that the second tag belongs to a second group to which a second version of the interactive digital event program is to be distributed; and providing the second user device with the second version of the interactive digital event program the second version to include a dynamic content element to be populated throughout the event using the third party integration.
  • the method where in the first tag is at a venue in which the event is being held and the second tag is on or in a televised video stream.
  • a method of distributing different versions of an interactive digital event program for a particular event to user devices comprising: designing a template for each of at least two versions of the interactive digital program by dragging and dropping a plurality of dynamic content elements into each template to complete a desired layout; associating each dynamic content element in the plurality with a distinct data source to dynamically update content within the dynamic content element while the event is in progress; assigning each version of the at least two versions of the interactive digital program to separate groups of tags, each tag in each separate group having a unique tag identifier; in response to receiving a request for the interactive digital program from the user device that has scanned a particular tag, determining to which group the particular tag belongs based on the unique tag identifier for the particular tag; sending the version of the interactive digital event program assigned to the group of tags in which the particular tag belongs to user device that sent the request; and causing the distinct data sources to populate the associated dynamic content elements in the template for the sent version of the interactive digital event program and at the content of least one of the associated dynamic content elements
  • a system for providing an interactive digital event program comprising: a plurality of tags, each tag in the plurality having a machine readable code and a unique tag identifier; a server having a computer processor and a computer memory; a database operatively connected to the server, the database including information relating to each tag in the plurality of tags, the information relating to each tag including: the unique tag identifier; a group identifier to identify a group to which the tag belongs; and a template for an interactive digital event program to be distributed to the group in which the tag belongs; and wherein the computer memory of the server stores executable code, which when executed enables the server to perform a process comprising: in response to receiving a request from a user device, using the unique tag identifier to identify the group to which the scanned tag belongs; populating the template for the interactive digital event program to be distributed to the group in which the tag belongs with one or more dynamic content elements; sending the populated interactive DEP to the user device that sent the request; and updating the content of at least one
  • the system wherein updating the content of the at least one dynamic content element includes pushing updated content from a third party data source to the at least one dynamic content element in response to detecting the predefined trigger.
  • the system wherein the predefined trigger is a pause in the activity and updating the content of at least one dynamic content element includes pushing updated content from the third party data source in response to detecting a pause in the activity.
  • the system wherein updating the content of at least one dynamic content element includes unlocking content in response to detecting the predefined trigger.
  • the system wherein the predefined trigger is a threshold number and dynamically updating includes detecting that the threshold number has been reached unlocking the content in response to reaching the threshold.
  • the system wherein the content of the at least one dynamic content element is subject matter associated with a non-fungible token (NFT) and updating the content of at least one dynamic content element in response to detecting a predefined trigger includes unlocking the subject matter in response to detecting predefined trigger to enable acquisition of the NFT.
  • NFT non-fungible token
  • the system of claim 51, wherein the at least one dynamic content defines an augmented reality video.
  • the system wherein the MRC is located within a video stream; wherein the unique tag identifier is utilized to determine which DEP to display to said user device.
  • the system further comprising a geolocation determining, wherein the location of the user device is defined within a rule within a tag group to alter the DEP directed to said user device.
  • the venue is selected from the group consisting of: a school, a cultural event location, a zoo, a music venue, and combinations thereof.
  • the system wherein the dynamic content element is connected to a third party API, and wherein the third party API disseminates the dynamic content upon the occurrence of a trigger.
  • the system wherein the tag grouping defines a version of the DEP displayed to said user device.
  • the system further comprising wherein a camera defined on a user device captures video, wherein the captured video is uploaded into a the DEP and the captured video is released as the dynamic content element.
  • the dynamic content element displays a portion of video, said portion of video being a replay, highlight or augmented reality.
  • the system wherein the dynamic content is an advertisement.
  • the unique ID defines an entry within a database, and wherein the entry comprises information regarding the actions of the unique ID; aggregating the data regarding the unique ID from said database; creating a tag grouping based upon the aggregated data on the unique ID and modifying the dynamic content on said DEP.
  • the system collects and aggregates analytical user data corresponding to said unique ID, when said user device is interacting with the DEP.
  • the dynamic content is a real time polling question; and wherein a result from the real time polling question is displayed.
  • the system wherein the tag grouping is defined within a section of said venue; and wherein the tag grouping is awarded a prize which is pushed into the user device within the dynamic content within the DEP.
  • the system wherein the dynamic content is related to fantasy sports or wagering.
  • a method of charging and automating an electronic vehicle comprising: Positioning the electronic vehicle within a parking spot and adjacent to a charging field; Scanning, with a user device or a camera incorporated in the electronic vehicle, a scannable tag, said user device and said camera comprising a unique ID, and said scannable tag comprising a tag ID; Linking the unique ID to the tag ID; and Pushing to said user device or display integral with the electronic vehicle a dynamic content comprising a payment module and a timing module corresponding to payment for charging the electronic vehicle and a duration of the charging.
  • the method further comprising, in response to scanning the scannable tag, automatically charging the electronic vehicle utilizing a wireless charging system, gathering data in relation to the unique ID, tag ID, or both, and recording the gathered data to a data file, data record or both.
  • a method of using a network of encoded tags to gather data relating to an event comprising: (a) in response to receiving a request from a user device that has scanned an encoded tag linked to the event, identifying a tag identifier to determine where the encoded tag is physically or digitally installed and identifying a device identifier to determine if the user device has previously scanned any tag in the network of tags, wherein if the user device has not previously scanned any tag in the network of tags assigning a device identifier to identify the user device upon a subsequent scan of any tag in the network, and sending the device identifier to the user device; (b) determining, using the tag identifier, an event for which data is to be gathered, the event identified by an event identifier; (c) determining a target to which the user device is to be redirected, the determined target identified by a target identifier, wherein the target is a default target if the event is not in progress and the target is a
  • the method wherein receiving the request from the user device comprises receiving the tag identifier in conjunction with the request.
  • the method wherein identifying the device identifier comprises receiving the device identifier in conjunction with the request or in response to a request for the device identifier from the user device.
  • the method wherein determining if the user device has previously scanned any tag in the network of tags comprises making the determination where the network of tags that belongs to more than one proprietor, the network of tags that belongs to more than one venue, or both.
  • the method further comprising physically installing one or more tags in the network of tags on or near a point of interest, integral with the point of interest, digitally installing one or more tags in the network of tags on a display screen, or both, wherein the display screen is selected from a group consisting of a computer screen, a television screen, a handheld device screen, a screen integrated into a piece of furniture, a screen integrated into an internet of things device.
  • the method wherein determining the event for which data is to be gathered comprises determining if the event is in progress at a time the user device scanned the tag.
  • the method wherein the event is perpetually in progress is a recurring event, or is a single event scheduled to occur during a predetermined window of time.
  • the method wherein recording data comprises recording data, storing data, or both as long as the event is in progress, or the determined target is opened on the user device.
  • redirecting to a web-based application comprises redirecting to a progressive web application, cloud-based application, browser-based application, or an active server page.
  • the method further comprising counting and recording the number of tags in the network of tags that have been scanned while the event is in progress, a counted number retrievable in real time, after the event ends, or both and optionally graphically displayed on an administrator device.
  • the method further comprising, transferring some or all of the data recorded while the event is in progress to a third party customer relationship management service, data management software, or both, the transferred data including at least one identifier that enables the third party to identify a user of the user device.
  • the method further comprising, using the tag identifier to determine the venue in which the scanned tag is installed, the determined venue having a venue identifier assigned thereto, or using the tag identifier to determine a point of interest that the scanned tag points to, or both.
  • redirecting to the web-based application comprises redirecting the user device to a web-based application comprising a module identified by a module identifier and recording each use-related action attributed to the module in association with the module identifier.
  • the method further comprising, digitally installing the encoded tag for display in a television broadcast, a cable broadcast, content that is streamed, or a feed and the tag identifier points to the television broadcast, the cable broadcast, the content that is streamed, or the feed in which the tag was digitally installed.
  • the method further comprising defining a rule relating to the web-based application that causes the web-based application to release tickets to a subsequent event in response to determining that the event in progress is about to end, the web-based application releasing said tickets by unlocking a module within the application, pushing content to the user device, redirecting the user device to an external website that sells the tickets, or updating a dynamic element within a module of the web-based application.
  • the method wherein defining the rule comprises defining the rule to release tickets in response to determining that a home team has won a game-based event.
  • the method further comprising defining a rule relating to the web-based application that causes the web-based application to release an offer to preorder an item in response to determining that a threshold number of user devices have scanned a tag in the network of tags, scan an encoded tag, the web-based application releasing said offer by unlocking a module within the web-based application, pushing the offer to the user device, redirecting the user device to an external website that is promoting the offer, or updating a dynamic element within a module of the web-based application.
  • the method wherein the offer to preorder an item comprises an offer to preorder merchandise at a discounted price or an experience-related item.
  • a system for aggregating data in response to detecting that a user device has scanned an encoded tag comprising: (a) a server system having a computer processor, a computer memory, and one or more web applications, versions of web applications, or both installed thereon; (b) one or more databases operatively connected to the server system and storing a venue ID assigned to a venue, an event ID assigned to an event linked to the venue; a target ID assigned to a web application built for the event, a tag ID assigned to a tag installed within the confines of the venue and that points to a particular point of interest associated with the venue, event, or both, a unique ID assigned to a user device, and recorded data linked to one or more of the unique ID, venue ID, event ID, target ID, or tag ID; and (c) wherein the computer memory of the server system stores executable code that, when executed the executable code enables the server system to: (i) receive a request from the user device, the request made in response to using the
  • each web application installed on the server system has a target ID assigned thereto and at least one module contained therein, each module having a module ID assigned thereto, wherein recording each user action further comprising identifying the module ID for the module in which the user action was taken and recording the user action in association with the module ID.
  • the system wherein the at least one module is selected from the group consisting of a merchandise module, a concessions module, an enter to win module, an audience participation module, an incident reporting module, a wagering module, an augmented reality module, a digital program module, an NFT acquisition module, a map module, a replay module, a roster module, a live statistics module, a fan filter module, and an upcoming events module.
  • the system wherein the executable code enables the system to search the recorded data, filter the recorded data, or both to obtain metrics relating to one or more of a number of tags scanned during the event, a number of modules engaged with during the event, a number of particular user actions performed during the event, a number of tags scanned by venue location, or a number and type of modules engaged with by venue location.
  • the system wherein the executable code enables the system to turn the web application built for the event to turn on at a predetermined time before the event begins and turn off at a predetermined time after the event ends, wherein data relating to the event is recorded as long as the web application built for the event is turned on.
  • actions recorded with respect to the enter to win module include recording opening the enter to win module and recording enter to win submissions and compare the number of enter to win modules opened to the number of enter to win submissions.
  • the system further comprising, recording identifying information obtained from the enter to win submission, identifying information selected from the group consisting of: name, email address, telephone number, age, gender, or combinations thereof, in a data file related to the unique ID, the tag ID, the target ID, the module Id, or combinations thereof.
  • system further comprising identifying via unique IDs associated with enter to win submissions, the users that also requested to receive more information relating to future events at the venue and saving the identified requests to a data file associated with the unique IDs.
  • system further comprising analyze recorded actions to provide customized content to the user device based on one or more past actions.
  • a system for appraising a value of a user based on data obtained as a result of scanning an encoded tag with a user device comprising: (a) a server system comprising a computer processor and a computer memory; (b) at least one database operatively connected to the server system, the at least one database storing data files relating to a plurality of venues, each venue in the plurality identified by a corresponding venue ID; a plurality of events, each event in the plurality identified by a corresponding event ID, tied to a particular venue in the plurality of venues, and in progress during a predetermined time window; a plurality of web-based applications, each web-based application in the plurality identified by a corresponding target ID and tied to a particular event in the plurality of events, wherein each web-based application is only active during a predetermined time window based on, and corresponding to when the tied event is in progress; a plurality of encoded tags, each encoded tag identified by a corresponding tag
  • the system further comprising, wherein assigning a valuation to a particular user further comprises assigning a number, a dollar amount, or both to identify the likelihood that the particular user will take an identified action based on aggregated user data relating to the identified action. [0110] In a further embodiment, the system further comprising assigning the number, the dollar amount, or both to each unique ID in the plurality of unique IDs. [0111] In a further embodiment, the system wherein the number, the dollar amount, or both assigned to each unique ID in the plurality of unique IDs is updated in real time.
  • FIG.1 depicts an embodiment of a system for user device generated interactions with a system and platform for accessing and viewing targets, such as content and digital offers.
  • FIG.2 depicts a stadium comprising a plurality of video cameras and a user device that is accessing a user portal including access to content such as video, augmented video playback, and digital offers.
  • FIG.3 depicts an embodiment of a system for accessing target information from a user device from within a venue or outside of a venue and various back-end platforms for implementing certain target information or for delivering content to the user device.
  • FIG.4 depicts an embodiment of a system for identifying and using information particular to a user device and/or to a tag for directing the user device to an appropriate target.
  • FIG.5 depicts an embodiment of a system wherein the system is enabled to push or pull data or information or due to triggering events or rules to modify or augment a target delivered to a user device.
  • FIG.6 is a diagram of one embodiment of a system that enables delivery of the customized content.
  • FIG.7 is a flowchart illustrating the operation of the system of FIG.6.
  • FIG.8 is a diagram illustrating a further embodiment of the system.
  • FIG.9 is a diagram illustrating a variation of an embodiment of the system.
  • FIG.10 is a flowchart illustrating the operations of the system of FIG.9.
  • FIG 11 depicts an area comprising a plurality of tags positioned at multiple locations.
  • FIG.12 details a flow diagram of various tags, applications and report and related tasks and information for implementing the system of the present embodiments.
  • FIG.13 depicts a flow diagram for use of an embodiment of the system from an admin user. DETAILED DESCRIPTION OF THE INVENTION [0125] Historically macro offers were made to an entire stadium such as if the home team wins you get a free taco at the taco store. Embodiments enable micro offers to be made to select users/groups of users.
  • Aggregating data gathered during one or more events enables envisioning trends for a user or a group of users based on factors such as purchasing habits, seat section, as nonlimiting examples. This follows the marketing trend of obtaining more data, which enables targeted marketing towards individual users. Such targeted marketing provides better leads and a lower cost of acquisition for new users. Furthermore, this data allows for new marketing and targeted approaches towards users who are not seeing advertisements or offers that would drive their engagement.
  • the system and methods detailed herein provide for an improved mechanism to identify user interests and to provide content to the user or groups of similarly situated users that will drive engagement.
  • embodiments are not limited to the specified order and number of steps in a given process or the like. The number and order of steps may be altered to achieve a desired end. The following detailed description is, therefore, not to be taken in a limiting sense.
  • the embodiments detailed herein and as depicted in the drawing figures illustrate several embodiments of the invention, which is directed to a method and system for generating unique content to a one or a plurality of users based upon data collected within the system. Typically, these include forming rules or meeting a metric, whether done by a plurality of users and user devices or a single user device.
  • the unique content provided to the users can then be further tracked, the engagement with the content can be tracked, and the content modified to increase engagement with the content.
  • ADDRESS Code used to direct a user device, browser, Web app, progressive Web app, administrator device, server, database, API, tool, software, etc., to a resource within the system or a network.
  • addresses include a uniform resource identifier (URI) or a uniform resource locator (URL).
  • ADMINISTRATOR The individual or group of individuals with the ability to control and set rules and parameters within the system. This could be a third-party administrator, the proprietor, the venue, the owner of the tags, the team or performer participating in the event, a designated employee of any of the foregoing, etc.
  • ADMINISTRATOR DEVICE Any type of mobile or non-mobile processing device such as a desktop computer, handheld computer (e.g., phone, smartphone, tablet, personal digital assistant), wearable computer (e.g., smart watch, smart glasses), portable computers (e.g., laptop, netbooks, Chromebook), or wearable or implantable device, and the like using wireless communication, a camera or other connectivity element that is accessible only to an administrator or proprietor or an employee designated by the administrator or proprietor.
  • ANALYTICS OR ANALYTICAL DATA Data collected by the system or retrieved by the system via an API call to an external server or database as a nonlimiting example.
  • Nonlimiting examples of analytical data include date, time, GPS location, personal identifying information, etc.
  • API An application programing interface or programming code that enables data transmission within the system, between the system’s server and an external server or between one software product and another.
  • API connections to the system may be third-party vendor databases such as ticketing sales platforms, e-commerce sites such as merchandise sales, social media sites, or any other third-party software product that makes their API available for use by others.
  • API CALL – Code used by the system software to access data, server software or other applications within the system or external to the system, acting as an intermediary between any two devices or servers that want to connect with each other for a specified task.
  • API can mean (i) representational state transfer or Rest (RESTful) API; (ii) Simple Object Access Protocol (“SOAP”) API; (iii) extensible markup language – Remote Procedure Calls (“XML-RPC”); (iv) JSON Remote Procedure Calls (“JSON-RPC), (v) open API; (vi) partner API; (vii) internal or private API; (viii) composite API; or (ix) any other API that is generally known, or will be come to be known in the art.
  • SOAP Simple Object Access Protocol
  • XML-RPC extensible markup language – Remote Procedure Calls
  • JSON-RPC JSON Remote Procedure Calls
  • BLOCKCHAIN Any digitally distributed, decentralized, public or private ledger that exists across a network such as those offered by the providers including but not limited to Ethereum, Binance Smart Chain, Polkadot, Flow by Dapper Labs, EOS, Tron, Tezos, WAX, Theta, etc.
  • BROWSER APPLICATION An application that runs within the Web browser of a user device or computer. The instructions or executable code, typically written in a combination of HTML and JavaScript, are embedded within the Web page that is downloaded from a Web site.
  • COMPUTER May be any type of computer such as a laptop computer, desktop computer, tablet, and the like, and includes the appropriate hardware, firmware, and software to enable the computer to function as intended.
  • CONTENT Any type of information, images, videos, etc.
  • Nonlimiting examples of content can be a video file, an image file, text, executable code, a digital offer, a digital coupon, a digital wallet offer, an AR, VR or mixed reality filter, a game, a poll, an app, an NFT, etc.
  • Content can be specifically formatted for optimal viewing on a user device.
  • CRYPTO CURRENCY Any digital currency in which transactions are verified and records maintained on a distributed ledger such as blockchain, for example, Bitcoin, Ethereum, Cardano, Binance Coin, Tether, Solana, XRP, Dodgecoin, etc.
  • DATABASE MANAGEMENT SYSTEM A software package designed to define, manipulate, retrieve and manage data in a database, or any other generally accepted definition known to those skilled in the art.
  • DIGITAL OFFER Any incentive or reward, for example an incentive to purchase at a discounted price or a free giveaway, offered by a proprietor and delivered to users from a server to a user device through a variety of channels.
  • a digital offer can be code stored in the user’s digital wallet, an MRC displayed in Web browser and presented to a proprietor for redemption, an e-mail with a unique redemption code, a text message, SMS/MMS, push notification or socket notification with a unique redemption code.
  • Digital offers can be stored anywhere on a user device or can be downloaded or turned into physical offers by printing. Digital offers can be limited to a particular user, or a user may share the digital offer with other users. If a digital offer is shared, the same offer can be shared to multiple other users, or the digital offer can be modified by the system when it is shared. Digital offers can also be associated with a unique code that is stored in a database on a server internal or external to the system.
  • DIGITAL WALLET A software-based system that securely stores users’ information such as payment information, passwords, digital certificates, digital coupons, crypto currency, tokens, NFTs, digital ID such as a digital driver’s license or passport, etc.
  • a digital wallet can be a blockchain or crypto currency wallet.
  • a digital wallet can be stored locally on any user device or can be cloud based and accessed by a user device.
  • Digital wallet can also mean digital storage in general on any user device or computer.
  • Digital wallet can also be referred to as a mobile wallet.
  • DISTRIBUTED DATABASE SYSTEM Any database that consists of two or more files located in different sites either on the same network or on entirely different networks.
  • DISTRIBUTED LEDGER Any database that is consensually shared and synchronized across multiple sites, institutions, or geographies, accessible by multiple people.
  • DATA SERVER OR SERVER Any form of electronic device or plurality of devices having at least one computer processor, e.g., a central processing unit (CPU), and some form of computer memory having a capability to store data, as is well known in the art.
  • the server may comprise hardware, software, and firmware for receiving, storing, and/or processing data as described below.
  • the hardware may be in a single unit, or operably connected via a network.
  • a computer or server may comprise any of a wide range of digital electronic devices, including, but not limited to, a server, a desktop computer, a laptop, a smart phone, a tablet, a smart watch, smart glasses, a wearable device or an implantable device or any form of electronic device capable of functioning as described herein.
  • DYNAMIC ELEMENT An element that is updated, altered, customized, etc., in response to a change in the status of a metric, trigger, or any other datapoint as determined by the system.
  • a nonlimiting example of a dynamic element is the score of a game. If a goal is completed, then the score is updated to reflect this change.
  • EVENT Nonlimiting examples of an event include a professional, amateur or intermural sporting events (i.e., football, baseball, hockey, basketball, soccer, rugby or cricket game, tennis or golf match, track and field or figure skating event or automobile race), a theatrical performance (play, musical or opera), a musical concert, elementary school, middle school, high school, college or university event, a service or ceremony (i.e., religious or worship), a tradeshow or conference, guided or self-guided tours (museums, galleries and historical site), time spent in a venue such as a visit to a zoo or amusement park, etc.
  • An event may be for a limited time, extended time, or perpetual.
  • FAN PORTAL A web application, progressive web application, cloud-based application or the like with a visual layout displayed on a user device via a web browser that provides links or access to other pages or interactive modules via buttons or other means of selecting options from a menu of choices.
  • the fan portal can also be used for viewing content and receiving digital offers.
  • INTERFACE SERVER Within the system, a program, executable code or API stored on a physical server, cloud storage system or in a serverless environment such as Amazon Web Services, which is capable of communicating with other servers, databases and API’s internal or external to the system.
  • the interface server is able to make and receive calls, request and receive data, or execute other functions within systems.
  • the interface server is also capable of running AI and/or utilizing machine learning.
  • GEOFENCE A virtual perimeter for a real-world geographic area or an area in or around a venue.
  • GUI OR GRAPHICAL USER INTERFACE An interface with graphics to enable interactions between a user and the user’s device, such as but not limited to a visual interface fa the Web app.
  • JUMBO SCREEN Any display within a venue visible to users attending an event at a venue.
  • the jumbo screen can be one display or multiple displays within the venue that can be controlled by the venue. Jumbo screen may also be known as a jumbotron.
  • LOCATION An area whose perimeter or parameters are defined in an abstract way without boundaries that are clearly visible to users or proprietors.
  • MACHINE-READABLE CODE A barcode, a quick response (QR) code, near-field communication (NFC) code, radio-frequency identification (RFID) code, universal product code (UPC), machine readable graphics (e.g., having a pattern, matrix, or the like) coding, instructions coded on a chip, or combinations thereof.
  • a MRC may be may be included into (i) a tag that is mounted to a surface, (ii) identification badges such as, for example, student identification badges, employment identification badges, concert badges, and the like, (iii) merchandise such as t-shirts, sweatshirts, hats, mugs, glasses, posters, CD’s, and the like, (iv) a piece of paper, cardstock, or plastic that is handed to users, (v) a video stream viewed over the internet or network television channel, (vi) an LCD/LED/e ink display device embedded, attached or affixed to a surface.
  • identification badges such as, for example, student identification badges, employment identification badges, concert badges, and the like
  • merchandise such as t-shirts, sweatshirts, hats, mugs, glasses, posters, CD’s, and the like
  • a piece of paper, cardstock, or plastic that is handed to users
  • a video stream viewed over the internet or network television channel
  • NFT NON-FUNGIBLE TOKEN
  • Nonlimiting examples of the smart contracts that could govern a NFT include (i) 1/1 NFTs - known as ERC-721 tokens on Ethereum and Polygon, KIP17 on the Klatyn blockchain; (ii) Semi-fungible NFTs - known as ERC-1155 tokens on Ethereum and Polygon, KIP37 on Klatyn.
  • NFT MARKETPLACE A platform where NFTs can be stored, displayed, bought, sold, traded, auctioned and in some cases minted.
  • PROPRIETOR Any person or entity who purchases, subscribes to, or otherwise uses the system and/or platform and who is not a user. A Proprietor may or may not have administrative privileges to the system.
  • proprietors include, venue owners, event promotors, teams, performers, theatre quartets, religious organizations, educational institutions (i.e., elementary school, middle school, high school, college, university), restaurants, bars, retail establishments, amusement parks, museums, art galleries, advertisers, media outlets (i.e., network television, cable television, radio, internet broadcasts), hospitals and health care systems, ticketing platforms, airlines, ride share services, organizations, etc.
  • PROPRIETOR PORTAL An access point for a proprietor to enter the system and/or platform typically displayed in a browser.
  • RECORD The act of capturing and storing delayed data that is stored in an electronic or other intangible medium without limitations on how the data is structured.
  • REDIRECT/IDENTIFICATION SERVER The server within the system that makes a determination on if a user and/or user device that has entered the system is unique, by locating the manifest stored on a user device and if a manifest exists, associating the unique ID stored in the manifest on the user device with the database of known unique ID’s stored on the redirect/identification server, or for confirming other data based on one or more requests to the redirect/identification server.
  • REDIRECT URL An address generated by a server, such as the redirect/identification server or the interface server, in response to an incoming request that points the browser on a user device to a different target.
  • REQUEST A message sent by one device to another (e.g., phone to server, server to server, computer to server, server to database, etc.) using an address to send the request. For example, upon selecting from the options available in the Web browser, the selection is coded into a request that the Web browser sends to the server via an address. The request typically provides instructions to the server. Nonlimiting examples of a request can be – GET, POST, PUT, DELETE, CONNECT, OPTIONS.
  • RULE A set of conditional statements that tells the system how to react to a particular situation. Rules can be preprogrammed into the system or can be set or changed by an administrator or proprietor.
  • SYSTEM The network, tags, digital seat platform, etc.
  • TAG A physical (e.g., tangible) form, a digital (e.g., virtual/intangible) form, or maybe combinations of both forms that contains an MRC.
  • Physical versions of tags may be constructed from diverse types of materials.
  • the MRC may be printed, etched, or fabricated onto the tag materials such as paper, glass, plastic, metal, fabric, and the like as a few nonlimiting examples.
  • tags that contain MRC’s that are NFC or RFID may be adhered to, attached to, embedded in, or fabricated on (or combinations thereof) a natural or manmade material such as metal (e.g., aluminum, stainless steel), wood, polymer (e.g., plastic), film, glass, and combinations thereof. The material may then be incorporated into or affixed (e.g., adhesive or other form of attachment) to an object or location.
  • a tag may be printed on a single or multiple use badge or ticket or the tag itself may be a video display such as LCD, LED, or e-ink.
  • Digital tags may include LED/LCD screens, television screens, computer screens, appliance screens, and the like, or a designated location within a video stream in which the MRC is located.
  • TAG ID A unique identifier for the MRC affixed to the tag.
  • the unique identifier can be any combination of letters, numbers, and symbols.
  • the tag ID is stored in a database on a server and is coded with information specific to the location of the tag. For example, the tag ID might generally identify the geographic location of the tag (i.e., the United States, Pennsylvania and/or Philadelphia), the general venue location of the tag (i.e., Fenway Park, Madison Square Garden, Carnegie Hall, The Natural History Museum), the specific location of the tag within the venue (i.e., Section A, Row 1, Seat 10, next to Van Gogh’s “Starry Night”), or any combination of information.
  • TAG URL A unique address assigned to the MRC on each tag that may optionally include the tag ID.
  • TARGET A Web page, file, address, GUI, Web app, progressive Web app, portal, content or digital offer delivered to a user device. Those skilled in the art may also refer to a target as an endpoint.
  • TARGET ID A unique identifier for the target. The unique identifier can be any combination of letters, numbers and/or symbols that can be stored in a database, on a server, and/or both. The target ID allows the platform to distinguish one target from another.
  • TICKETING PLATFORM Both the primary ticketing platform and the secondary ticketing platform.
  • TRIGGER The magnitude or condition that must be reached for a certain result to materialize. Triggers can be determined either by the system, an administrator or a proprietor. Nonlimiting examples of a trigger can be the start or end of an event, something of significance that occurs during the event (i.e., the 10 th goal scored, the first expand by a musical act), a single user completing a certain task, or N-number of users completing a task.
  • TOKEN A digital asset that is stored securely on the blockchain, representing a tradeable asset.
  • TOOLS Cookies, pixels, widgets, plug-ins, etc.
  • UNIQUE ID A unique identifier for the user device.
  • the unique identifier can be any combination of letters, numbers and/or symbols, cookies, digital credentials or it can be a digital certificate such as TLS, SSL, code signing certificate, client certificate, etc...
  • the unique ID can be stored on the user device in any location on the user device such as the manifest, local storage or digital wallet, in a database on a server, and/or both, and is used to associate the user device with the unique user record stored in a database on a server in the system.
  • UNIQUE IDENTIFYING INFORMATION Personal information and demographics collected about a particular user’s such as name, address, phone number, e-mail address, credit card information, gender, marital status, academic affiliation (student, faculty, alumni), driver’s license number, age, username, password, pin number, social security number, bank account number, salary, etc.
  • USER DEVICE Any type of mobile processing device such as a handheld computer (e.g., phone, smartphone, tablet, personal digital assistant), wearable computer (e.g., smart watch, smart glasses), portable computers (e.g., laptop, netbooks, Chromebook), or wearable or implantable device, and the like using wireless communication, a camera or other connectivity element.
  • USER/DEVICE ID RECORD A record stored within a database on a server that contains the unique ID and unique identifying information associated with that unique ID for each user that accesses the system.
  • the user/device record can contain an unlimited amount of information about the user device and presumably the user who owns the user device such as, but not limited to a history of events attended, digital offers used, gambling wagers made, NFTs minted or purchased, venues or locations visited, concession or merchandise purchases, donations made, incident reports, tags scanned, other actions taken, etc. This may further include certain information related to demographics, event attendance history, purchasing history) as well as information about the user device (type of device, GPS location of the device when is scans an MRC).
  • VENUE A physical location with defined perimeters and parameters such as a stadium, arena, court, track, concert hall, theatre, course, museum, restaurant, place of worship (church, synagogue, temple, mosque, etc.), historical site, cultural site, amusement park, zoo, aquarium, conference center or any other place where events are held, or users gather.
  • Venues can also be hotel rooms, cruise ships, trains, airplanes, schools (elementary, middle or high school) or a college campus or dorm.
  • a venue may also be defined by a non-physical boundary or containment area such as a geographical area.
  • WEB APP Executable code that is stored on a remote server and delivered via the system or a network to a browser interface on a user device.
  • the Web app may facilitate communication between the user device and one or more servers such as the redirect/identification server or the interface server.
  • Web app includes different types of Web apps such as progressive Web apps, cloud-based apps, browser based apps, active server pages, etc.
  • the embodiments herein are directed toward a system and methods for aggregating data obtained via user devices in response to scanning encoded tags and using that data to enhance user enjoyment while participating in an event. This and other elements can be performed on the system as detailed in the following embodiments.
  • a high- level overview of an exemplary system (10) is shown in FIG.1 with respect to a single proprietor for ease of understanding. Embodiments are not limited to a single proprietor. Additional proprietors have the same or similar system components as the proprietor described herein.
  • the system (10) may include an administrator device (12), a platform (20), a user device (14a) associated with an event user (e.g., physically at the event/in the venue), a user device (14b) associated with a remote user (e.g., not necessarily at the event/in the venue), a plurality of tags (16a, 16b) and one or more networks (18).
  • each user device (14a, 14b) may be used to scan, read, or otherwise detect (collectively “scan”) machine-readable code (“MRC”) (17a, 17b) associated with a respective tag (16a, 16b).
  • MRC machine-readable code
  • the act of scanning a tag (16a, 16b)/MRC (17a, 17b) initiates communications between the user device (14a, 14b) that scanned the tag (16a, 16b) and the platform (20), which may result in the rendering of a Web page, Web app or the like (e.g., related to the event) by a Web browser and/or other application running on the user device (14a, 14b).
  • Communications between user devices (14a, 14b) and platform (20) is typically via one or more networks (18), which may include, without limitation, the Internet, mobile networks, cloud-based platforms, or combinations thereof.
  • the platform (20) may provide one or more services to a proprietor to enhance user experiences in association with the proprietor.
  • 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.
  • 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 is encoded with a unique identifier (tag ID), which may be used by the platform to identify a particular point of interest.
  • tag ID unique identifier
  • 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.
  • a plurality of tags could be located at different entrance points, each having the same tag ID.
  • tags (16a) may be present at the venue (“in-venue tag”), and additional one or more tags (16b) may be remote from the venue (“remote tag”) where the MRC (17b) is digitally displayed in/on a video transmission, signal, or the like, or on a Web page associated with the event, venue, and/or television network, as a few nonlimiting examples.
  • a digitally displayed MRC/tag is visually displayed to the user regardless of whether the MRC/code is transmitted in a digital format.
  • a user at the event/in the venue scans the remote tag (16b) with his/her user device (14a).
  • Each user device (14a, 14b) may also include, or may eventually include, a unique identifier (22a, 22b) to uniquely identify the user device (14a, 14b) to the platform (20) and a digital wallet (24a, 24b) to securely store sensitive information such as a driver’s licenses, account information (e.g., banks, crypto currencies, credit cards), titles, tokens, tickets, vouchers, coupons, other digital file (301a, 301b), and the like.
  • 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.
  • the proprietor may access a proprietor portal (FIG.3 at [322]) hosted by platform (20) to perform administrative and/or other activities such as determining what content (or other) will be sent to the user device (14a, 14b) in response to scanning a tag (16a, 16b). Since more than one proprietor may access the platform, each proprietor is assigned a proprietor ID to identify the particular proprietor to the platform (20). Furthermore, a given proprietor may be linked to one or more venues and each venue is assigned a venue ID to associate the venue with the proper proprietor and to identify the particular venue to the platform (20). In turn, venues host multiple events and perhaps multiple teams.
  • a proprietor portal hosted by platform (20) to perform administrative and/or other activities such as determining what content (or other) will be sent to the user device (14a, 14b) in response to scanning a tag (16a, 16b). Since more than one proprietor may access the platform, each proprietor is assigned a proprietor ID to identify the particular proprietor to the platform (20). Furthermore, a given proprietor may be linked to one or more venues and each venue is assigned
  • each event e.g., Event ID
  • each team e.g., Team ID
  • collected/recorded data may be linked to one or more of a given proprietor, venue, event, team, tag, or user device as a result of a tag (16a, 16b) scan by a user device (14a, 14b).
  • 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.
  • 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, external websites, Web applications and more, which is detailed below, with reference to accompanying figures.
  • APIs application programming interfaces
  • features of the present invention and embodiments thereof are designed to allow easy installation for proprietors, easy use for end users, increased flexibility for proprietors to provide end users with a wide variety of content, engagement opportunity, etc., while collecting/recoding a vast amount of data all without downloading a native type application to the end users device to be enabled to engage with the system (20).
  • proprietor required to purchase expensive equipment in order to implement service provided via the platform (20).
  • FIG.2 shows an exemplary venue (202), which includes a portion of system (10) shown in FIG.1.
  • the venue (202) is a football stadium including a jumbo screen (204), recording devices (206a, 206b, 206c, 206d), seats (208), and a plurality of encoded tags such as tag (16a).
  • the venue (202) can be any venue: small, large, indoor, outdoor, permanent, temporary, one structure, several structures, a geolocation such as a city, and variations thereof.
  • a venue (202) can be any area or space occupied by or intended for something in which tags (16a, 16b) are contained and events may take place, each venue (202) having a venue ID and linked to the proprietor controlling the venue (202). As such, associated amenities and accoutrements may drastically vary from venue to venue.
  • the stadium has jumbo screen (204), which may display a wide variety of video content as is customary for a football game, though such display screen is not necessary for functionality of the system.
  • the stadium also includes optional recording devices (206a, 206b, 206c, 206d) such as video cameras for recording the football game and other activity, which is also customary for this type of venue (202).
  • an event may be any event including sporting events, artistic performances, trade shows, conferences, ceremonies, services, self-guided tours (e.g., at cities, museums, historic sites), zoos, promotions, campaigns and the like as a few nonlimiting examples.
  • each seat (208) has a seatback (210) with a tag (e.g., 16a) disposed thereon.
  • a tag e.g., 16a
  • event users can easily see a tag (e.g., 16a) directly in front of them while they are sitting in their seats (208).
  • the tag e.g., 16a
  • the tag that the event user sees is associated/linked with the seat (208) in which the user is sitting.
  • Linking/associating each encoded tag (16a, 16b) to a particular POI enables the platform (20) to use the encoded tag ID to link data obtained as a result of a tag scan by the user device to the POI.
  • a proprietor can analyze/use the recorded data from the perspective of the POI.
  • a user can have food or merchandise delivered directly to the seat (208), since the platform (20) can determine the user’s location via the tag ID.
  • In-venue tags e.g., 16a
  • in-venue tags (16a) are associated with particular seats (208), they may be placed in any other location on or near the associated seat (208) such as an arm rest, a cup holder, on the seat (208) next to the event user’s leg, on the ground, or on a structure near the seat (208) such as a wall, a pillar, or the like. It should be noted that in-venue tags (16a) may be associated with other locations/points of interest, and thus may be placed at or near the locations/points of interest such as entrances, levels, sections, isles, loge seats, individual people (e.g., with a tagged badge, tagged ticket, or the like), restrooms, various additional possibilities, or combinations thereof.
  • in-venue tag (16a) placement should be broadly construed to include any placement suitable for use as described herein.
  • Tags (16a) may be associated with one or more groupings, for example, by a section, (222, 224, or 226), wherein grouping of tags (16a) may provide certain benefits in the various embodiments detailed herein.
  • Alternative tag placement schemes may be devised as desired by the proprietor and consistent with the teachings of the present invention, should be considered within the scope of the present disclosure.
  • In-venue tags in certain embodiments, may be installed in a movable venue and/or event, for example a vehicle, a bike, a boat, train, airplane, etc.
  • a tag installed on such movable venue and/or event may be linked to a particular vehicle, POI within the vehicle, or both to be able to identify the venue, event, etc. linked to the scannable tag. If exact GPS coordinates or the like are needed or desired, the coordinates may be obtained from one or more of the user devices that scanned the tag, the vehicle, a third party, or another reliable source. As such, a movable tag can be accessed several times in a series of time (e.g., minutes or seconds) and generate a different GPS location each time a user device scans the tag (or queries a server) and allows the system to identify the movement of the user device, vehicle, POI in the vehicle or combination thereof.
  • a series of time e.g., minutes or seconds
  • each tag (16a, 16b) in the system (10) has a machine-readable code (17a, 17b) encoded thereon.
  • the term machine-readable code (“MRC”) as used herein should be broadly construed to include “graphics” type codes such as quick response (QR) codes, universal product code (UPC), snap codes, and/or any other type of machine-readable graphics (e.g., having a pattern, matrix, or the like) coding known in the art or later developed.
  • machine-readable code/MRC should also be construed to include “chip” technologies that store data on a chip such as, without limitation, nearfield communication (NFC) and radio-frequency identification (RFID) technologies, as is known in the art or is later developed.
  • Embodiments may also include one or more types of MRC such as a QR code and NFC chip, as one nonlimiting example.
  • MRC can be read, scanned, detected or otherwise decoded (collectively, “scanned”) by an appropriately enabled (e.g., camera, QR scanner, and/or NFC reader [212]) user device (14a, 14b).
  • 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.
  • 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).
  • 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 file, Web page, Web application, etc.) 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 nonlimiting embodiment.
  • URI uniform resource identifier
  • URL uniform resource locator
  • the event user device (14a) when the event user uses his/her user device (14a) to scan tag (16a), the event user device (14a) obtains an address from the MRC (17a) and linked to the scanned tag (16a) and sends a request via the network (18) to the address destination.
  • the address is a URL that causes the event user device (14a) to send a request to a redirect/identification server (302), on platform (20), which receives the request.
  • a redirect/identification server (302) on platform (20)
  • a similar URL is obtained which causes the request from the remote user device (14b) to be sent to the redirect/identification server (302), which receives the request.
  • 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/determine the point of interest/location that is linked to the tag (14a, 14b).
  • the platform (20)/server on the platform (20) may look up the tag ID to determine the linked POI upon receipt of the tag ID from the user device or at any other time when information about the linked POI is requested/needed.
  • the tag ID may also be used to determine the event, venue, proprietor, or any other information linked to the tag ID.
  • the platform (20) knows that the request came from the particular venue (202) and was made in response to scanning the tag linked to the seat (208) in which the event user is sitting.
  • 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 tied to the scanned tag (16b).
  • 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.
  • FIG.3 details an exemplary infrastructure that may be used by platform (20) although infrastructures are not limited thereto.
  • This infrastructure may include the redirect/identification server (302), an interface server (306), a database (308), an administration server (310), an analytics server (312), a blockchain, access to a blockchain, or both (314), a geofence (316) a timestamp (318), one or more third party integrations (320), the proprietor portal (322), and a socket server (324).
  • user device (14a, 14b) communicates with the platform (20) via redirect/identification server (302) as was previously described.
  • Redirect/identification server (302) accept requests from user devices (14a, 14b), sends responses to user devices (14a, 14b), and performs various other methods as described herein.
  • the redirect/identification server (302) may forward information (e.g., URLs, parameters, etc.,) from user device (14a, 14b) requests/queries, etc. to the interface server (306).
  • the interface server (306) manages most, if not all the tasks involved with processing requests, such as handing off/directing tasks, functions, calls, queries and the like where needed.
  • the interface server (306) may also return request/query responses to the redirect/identification server (302). If a request came from a user device (14a or 14b), then the redirect/identification server (302) forwards the response to the requesting user device (14a or 14b).
  • Examples of tasks, functions, calls, and the like that the interface server (306) may hand off include, without limitation, database (308)/blockchain data recordation retrieval storage, lookups, etc., administrative and back-end tasks/functions to the administration server (310), analytical tasks/functions to the analytics server (312), geolocation tasks/functions (316), time/timestamps (318), API calls to third-party servers for third party integrations (320), linking to third party resources via URLs and establishing socket connections via socket server (324).
  • a method (400) may begin with the redirect/identification server (302) receiving the request (step 402) from the event user device (14a) and in response using the device to scan an encoded tag.
  • the redirect/identification server (302) may check to see if the event user device (14a) has a unique ID assigned by the platform (20), loaded thereon (step 404).
  • the redirect/identification server (302) may generate/assign a unique ID for the event user device (14a, step 406) so that the user device (14a) can be identified by the platform (20) every time the user device (14a) linked to the assigned unique ID scans a tag (16) belonging to any proprietor using platform (20) services.
  • the redirect/identification server (302) will also cause the unique ID for the event user device (14a) to be stored in a database such as database (308), as is appropriate for the database management system (step 406).
  • the term “record” refers to information that is stored in an electronic or other intangible medium without limitations on how the data is structured. A record may include and/or point to related/linked data.
  • a record for a unique ID may include/point to the unique ID and/or any other data tied thereto, which may be stored in database (308) or other appropriate data storage.
  • the term “record” may also refer to the act of storing, requesting, etc. data in a reproduceable/retrievable form. Thus, the term “record” may be a noun or a verb.
  • the platform (20) via the redirect/identification server (302) may then send the unique ID to the event user device (14a, step 408).
  • the unique ID may be tied to a manifest packet, locally stored data file, in a digital wallet, other secure repository, or combinations thereof maintained on the event user device (14a).
  • the manifest packet, locally stored data file, or the like, including the unique ID may be obtained from the user device (14) for use by the platform (20) to identify the user device assigned to the unique ID, although embodiments are not limited thereto.
  • the unique ID is recorded for further use in the method (400), other methods described herein, or both.
  • the date and time that the unique ID is recorded (in response to a tag scan/responsive to a tag scan) may also be recorded to “timestamp” the tag scan by the user device.
  • the platform (20) may add the tag scan by the user device to one or more counts such as a count of the total number of tags scanned in the venue for a given time, as one non limiting example.
  • the redirect/identification server (302) obtains and records the unique ID (step 410).
  • the redirect/identification server (302) and/or other platform server may also obtain data such as current time, date, location, etc. from the event user device (14a) the platform (20), the venue (202), a third party provider, or other reliable source, or combinations thereof at step (410) or thereafter.
  • date and time information may be obtained from a timer/time source (318) on or linked to the platform such as a system clock, CPU clock or other such clock.
  • the redirect/identification server (302) may pass information needed to further method (400).
  • 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.
  • the redirect/identification server (302) obtained the tag ID from the request made by the event user device (14a) that scanned the tag (16a).
  • 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.
  • the tag ID may be used by the platform (20) to make one or more determinations.
  • the redirect/identification server (302) and/or interface server (306) may use the tag ID from a request to determine one or more of a linked POI, venue, event, proprietor, or any other information tied in some way to the tag via the tag ID.
  • a particular venue (202), proprietor, organization or the like installs tags (16a) and/or uses tags (16b) as desired.
  • Each tag refers to/is linked to a particular point of interest such as a seat, a person, a transmission, etc.
  • a proprietor and/or platform personnel can see, via the proprietor portal (322) or administrator device (310), respectively, a listing and/or digital representation of the tag’s MRC and assign a POI thereto.
  • each MRC in the list can point to a particular seat, row and section.
  • an MRC on a badge, lanyard, or the like can point to a particular person together with other identifying information such as security level, department, permissions, supervisor, or any other identification scheme desired by the proprietor.
  • an MRC displayed on a screen such as a monitor, TV or other display screen may point to information identifying the particular distribution parameters in which the MRC was provided such as channel, broadcast, geolocation, distribution method, network streaming services, etc. as is most appropriate for the particular implementation.
  • the proprietor may be a city or other organization that does not have a physical venue per se.
  • tags may be installed within a geographical area or containment area, which is tantamount to a venue.
  • MRCs may be tied to various points of interest within the containment area and identified as appropriate such as geographical coordinate (latitude, longitude), historical site, artistic installment, bus stop, street address and any other information that can identify where the tag/MRC is installed. Since each tag belongs to a particular proprietor, and the proprietor can install its tags in a venue, the tag ID may be used to determine the venue in which it is installed (416) and/or the proprietor that owns the tag as tags are tied to both the proprietor and the particular venue via a proprietor ID and a venue ID respectively.
  • the platform (20) can determine who owns the tag (proprietor), the venue in which the tag is installed (416) and the POI to which the tag/MRC is tied, all via the tag ID. These determinations may be made by the redirect/identification server (302), , the interface server (306), the administration server (310), any other suitable server, or combinations thereof using data from the request, database (308), the user device, or any other data repository. [0198] At step (418), the method (400) may determine if a particular event is “in progress”. An event may be in progress from a first date/time to a second date/time.
  • the event may be in progress from a time before the event begins (first date/time) to a time after the event ends (second date/time).
  • first date/time a time before the event begins
  • second date/time a time after the event ends
  • the event may always be in progress, be in progress during hours of operation or some other such definition.
  • the proprietor is a city and the venue is “downtown” and the tags are tied to art installations throughout the downtown area
  • the event e.g., viewing art installations
  • event “in progress” determination is made (step 418) using the tag ID, proprietor ID, venue ID or combinations thereof. If a venue hosts more than one team, organization, or the like, the team, organization, etc. is assigned a team ID or equivalent thereof. Since the team ID is tied to the tag ID, proprietor ID and/or venue ID, it too may be used to determine if the event is in progress. Generally, each event is assigned an event ID to identify a particular event to the platform (20). Thus, to determine if an event is in progress, the platform (20) tag ID may be used to determine the venue, and the venue ID may be used to determine which event has an “in progress” time corresponding to the time that the tag was scanned by the user device or time close thereto.
  • the event ID for the event in progress may be tied to the unique ID, tag ID or both, or any other relevant identifier.
  • the unique ID, tag ID, and/or event ID may have one or more time stamp, counter, or both recorded therewith to approximate the time that the event user device (14a) scanned the tag (16a) while the event is in progress.
  • the unique ID, tag ID, and time event in progress determination may be recorded for later use, in certain embodiments.
  • the event user device (14a) may be redirected to a default or fallback target (step 422) such as a Web page for the venue, proprietor, team, etc., 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. [0199] If the event is in progress, the method (400) may also determine if the tag/tag ID belongs to a group (step 420). 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.
  • the tags (16a) may be grouped by seating type or section (e.g., FIG.2, 222, 224, or 226), e.g., VIP seats may belong to one group, loge seats to another group, and discount/student seats may belong to yet another group. If data linked to the tag ID indicates that the tag belongs to a group, the event user device (14a) may be redirected to a target for the particular group.
  • tag groups may be turned on or turned off.
  • a tag group that may be relevant for one type of event may not be relevant to another type of event taking place at the same venue, such as a game played by a men’s team and a game played by a women’s team.
  • Each event may have different tag groupings.
  • a particular tag group may be created, turned on, and/or turned off, as desired or as is determined to be relevant for a particular event.
  • the method (400) obtains the information it needs to determine the appropriate target to which the tag ID points or refers to while the event is in progress.
  • the method (400) uses some or all of a target determination process (424) to determine the content or target a user device that scanned the tag should be redirected whether it be a default/fallback target or a particular version of a Web app or the like signed for one or more groupings of tags.
  • a target determination process 414 to determine the content or target a user device that scanned the tag should be redirected whether it be a default/fallback target or a particular version of a Web app or the like signed for one or more groupings of tags.
  • a college campus may create a version of a Web app for a football game for each of the students/a student section of seats, parents/a parent section of seats, users who bought season tickets, parents who have made donations to the athletic department, and so on, each version including offerings determined to appeal to those users/tag groupings.
  • Each version may be routed to the appropriate user, tag grouping, or the like using one or more of the unique ID, the tag ID, the venue ID, the event ID, the team ID, etc.
  • the method (400) obtains the information it needs to enable the redirection (step 422) to the determined target for the user, seat, tag group, etc.
  • the information needed for redirection may include a URL for the target with parameters, values, patterns, or the like appended thereto such as a target ID to identify the target and the tag ID.
  • Method (400) may simultaneously process other data, such as looking up information associated with the unique ID to determine the appropriate target for redirection, as is suggested by the example above.
  • the platform may gather information relating to user activities via the unique ID, the tag ID, the event ID, and combinations thereof.
  • each action that the user makes with respect to the target is recorded.
  • the tag scan, the unique ID, the time and date of tag scanning, the venue ID, the event ID, and the target ID, or combinations thereof may all be recorded in association with the tag scan and/or the event ID. Any action that the user takes while using the target on the user device is recorded and stored in a database.
  • User actions include without limitation, include selections, data input, voting, submissions, purchases, enter to win, wagering, viewing rosters, concession purchases, content viewed, coupons downloaded and other such actions and/or sub actions that the user may make while the user is interacting with the target during the identified event. Recording may stop when the user closes out of the target, the target is no longer available for use, when the event has ended, or combinations thereof.
  • a target may offer an enter to win module.
  • the enter to win module may be identified by a module identifier. When the user selects the enter to win module, this action may be recorded together with the module identifier.
  • the number of users that selected the enter to win module while the event was in progress can be determined either by a continuous tally, or a count at the time the determination is requested.
  • users that fill in fields for personal identification such as name, e-mail address, phone number, without limitation, and submit that information to the platform may also be tallied, or a number determined when a request for such information is made.
  • the platform can determine the number of users who opened the enter to win module to the number of users that submitted an enter to win entry.
  • the platform can record and save the personal information inputted in the fillable fields. This information may be tied to the event ID, the tag ID, the unique ID, the target ID, the module ID, or combinations thereof.
  • the method (400) is essentially the same when a request is received from a remote user device.
  • the target determination process may determine that the venue is not an arena, stadium, or the like. Rather the venue may be a different tag containment designation/definition such as the stream, transmission, broadcast, or other similar content distribution mechanism in which the tag is installed or where the tag/MRC originated. Nonetheless, the venue ID is determined as is the event ID in an analogous manner. As some distributed content may be recorded, the platform (20) may determine if an event is in progress based on a timestamp or similar indicated tied to the recording. In such a situation, the determined target may be a different version than the one that was built for use while the event is live. Likewise, the determined target for remote users may also be a different version than that available to event users.
  • the target determination process may be as easy as one target for the event, with customization per the unique ID regardless of the POI the tag points to, or several different targets/versions of a target to be distributed/customized based on the POI to which the tag points (seats, sections, rows, levels, etc.), a common characteristic tied to unique IDs (e.g., parent, booster club member, sponsor, season ticket holder, etc.), or both.
  • 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 determined target.
  • the method (400) may return a target ID to identify the particular target/version of the 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) 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.
  • 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 determined target of the redirection whatever that target may be.
  • 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.
  • the target is a web app such as a progressive web application.
  • the target is a fan portal (218).
  • the fan portal (218) or version thereof are each identified by its own target ID.
  • the fan portal (218) may include application code wrapped or embedded in an HTML document.
  • Application code includes, but is not limited to, web application code, progressive web application code, cloud based application code, 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.
  • targets are not necessarily static.
  • the same tag e.g., (16A) may cause a user device e.g., (14A) to be redirected to distinct targets depending upon the circumstances under which a particular tag (16A) is scanned.
  • venue (202) hosts many events over the course of a season, year, decade, etc... Each event may have its own target with its own target ID as the individual events are distinct and identified by their own distinct event ID’s.
  • the fan portal (218) may be the target of a game in progress, such as the football game shown in FIG.2.
  • the game in progress is between team A and team B.
  • the next game, or other event, hosted by the venue (202) may be a soccer game; thus, the fan portal (218) for the soccer game is different from the fan portal (218) for the football game.
  • the two fan portals (218) are distinct targets for redirection.
  • information related to each distinct target and its corresponding event, team, or the like, are tied/linked via respective identifiers.
  • the tag that is scanned by the user device is linked to the venue in which the tag is installed and the event that is determined to be in progress, which is either the football game or the soccer game.
  • the target is the fan portal (or a version thereof) for the football game
  • the soccer game is determined to be in progress
  • the target is the fan portal (or a version thereof) for the soccer game.
  • a given tag may be used by a proprietor to redirect a user device to any desired target.
  • a target such as the fan portal or another web application based target may be turned on and turned off.
  • a fan portal/versions of the fan portal may be built for the football game between home team A and away team B. The teams only play each other once a season. The date, time, and venue in which the game is to be played can be determined before the season starts. Thus, the date and time when the game will be in progress is known.
  • the fan portal/versions of the fan portal may be built (in whole or in part) in advance of the game.
  • Scheduling software may be used to turn on and off targets linked to a particular event, venue, team, proprietor, or combinations thereof. If an event is a perpetual event, occurs daily between daylight hours, business hours or the like, one or more interactive targets built for the event may be turned on and/or off at scheduled times or they may be kept on without being turned off, at least until a given build is retired or replaced. As such, user actions related to a particular target (e.g., Web app) can be recorded as long as the target is turned on or opened on the user device.
  • targets are linked/tied to a particular event, venue, proprietor, team, etc. data may be recorded so that it may be recalled/retrieved as a function of the event, venue, proprietor, team, sport, etc.
  • each user action with respect to each module, action within module, or other engagement action in association with the target/web application, among others may be recorded in conjunction with the particular event, such as was previously described with respect to an enter to win module.
  • data relating to user action within a particular target may be retrieved and graphically displayed at various levels of granularity while an event is in progress, after the target is turned off, or both.
  • data related to unique IDs, or any other identifiers may be searched, filtered, or both to identify various commonalities, trends, habits, etc.
  • proprietors may analyze collected/recorded data to determine what content, modules, offers, coupons, food choices, merchandise choices, etc. are the most frequent with respect to a particular unique ID, tag ID, tag ID grouping, unique ID grouping, demographic, venue, seating section, etc., which may affect future module offerings, discounts, tag groupings, unique ID grouping, target versions, rules, etc. made in the future.
  • a tag scan may be related to dynamic content.
  • the jumbo screen (204) may display a hidden “unique offer” (214) that is only available to the first 1,000 (or other number) users who respond to the “unique offer” (214) after it is displayed on the jumbo screen (204) by scanning a tag (16a) or the like.
  • a countdown (216) on the jumbo screen (204) shows the number of event user devices (14a) that have claimed the “unique offer” (214).
  • the threshold number e.g., 1,000
  • the unique offer may be revealed and is no longer available to any other users. This countdown and the limited nature then become a type of dynamic content.
  • a user may be able to respond to the “unique offer” (214) is by a pop-up window (e.g., in/over the fan portal [218]) or the like, which may be pushed to some or all user devices currently engaging with a target via the socket server (324) in a nonlimiting embodiment.
  • a pop-up window e.g., in/over the fan portal [218]
  • the term “target” should be broadly construed although it may be described herein with respect to obtaining a fan portal (218) or other specific examples.
  • a target of redirection as described herein may be a multitude of different targets with various purposes, designs, capabilities, and the like.
  • the target to which a particular tag (16a, 16b) is assigned may be changed by simply changing the target identifier (“target ID”) associated therewith.
  • target ID target identifier
  • 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.
  • the target delivered as a result of the target determination process (at 424) detailed in FIG.4 may include a Web application, such as a progressive Web application (PWA), that has a pull function, which may be rule-based.
  • PWA progressive Web application
  • the pull function may be time based, requesting information to be pulled from the platform (20) via the interface server (306) every 10 seconds, minutes, N seconds, N minutes or the like.
  • the pull function has the ability to have data updated on a rolling basis. In the sporting world, this is common when updates are provided to the score of a game, the time left in a game, or both as nonlimiting examples.
  • the platform (20) may push rolling data to a user device (14a, 14b) instead of having it pulled from the platform. Pushed data may be sent to user devices (e.g., 14a, 14b) without being requested.
  • Data may be pushed to a user device (14a, 14b) for any number of reasons, a few of which are detailed herein.
  • information, data, etc. may be pushed to a user device (14a, 14b), pulled for a user device (14a, 14b,) or both.
  • a Web application or the like may be based on a template having dynamic elements embedded therein. The contents of such dynamic elements may be altered via push techniques, pull techniques, or both.
  • Content, data, information, and the like may be pushed and/or pulled via a socket connect utilizing a socket server (324) or any other socket connection, communication connection, protocol, or combinations thereof as is available to the platform (20) under a set of given circumstances.
  • the method detailed in FIG.5 may be invoked while the target of redirection (e.g., fan portal [218]) is loading on the requesting user device (e.g., 14a and/or 14b), after the target is already loaded on the requesting user device (14a and/or 14b), or both.
  • steps in the method (500) may be used in whole or in part, in the order shown or a different order, be executed on one device or more than one device, be used in combination with some/all of the other methods described herein or as is known in the art, or combinations thereof.
  • the interface server at (510) may be the same interface server shown in FIG.3 (306), just at the data sources at (512) may be the same data sources shown in FIG.3 such as database (308), administrator server (310), analytics server (312), blockchain (314), geofence (316), time (318), third party integrations (320), and proprietor portal (322), without limitation.
  • interface server at (510) may facilitate utilization of the forgoing, in the same manner or similar manner as described with respect to FIG.3.
  • user device (14a or 14b), communication connection (504), interface server (510), and data sources (512) are shown in FIG.5 just to help the reader visualize interactions detailed in FIG.5.
  • Examples of rules that are detailed with respect to FIG.5 include event rules and local rules, although embodiments are not so limited.
  • an event rule is monitored by the platform (20) and if satisfied causes data to be pushed to one or more user devices (14a, 14b) and a local rule, when invoked, causes a user device (14a, 14b) to request data (i.e., pulls data) from the platform (20).
  • An illustrative example of an event rule is if team “A” scores a touchdown, push a digital offer to all user devices (14a, 14b) that have scanned tags (16a, 16b).
  • the metric or trigger of the rule can be monitored (step 516) such as by directly sending a request or query to a data source (at 512) via the interface server (at 510), receiving data from the data source (at 512) on a regular basis such as every 5 seconds, 5 minutes, or the like (via the interface sever [at 510]), or combinations of both.
  • the platform (20) may monitor for the metric/trigger e.g., a touchdown (steps 515/520) and continue to do so (step 522) until a metric/trigger e.g., a touchdown has occurred (step 520, yes).
  • a more complex event rule may include more than one trigger/metric.
  • 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.
  • 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.
  • 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.
  • 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.
  • each section of seats (222, 224, 226) may represent a grouping of tags (16a) such as student/discount seats, loge seats and all other seats.
  • tags (16a) such as student/discount seats, loge seats and all other seats.
  • the device (14a) may be redirected to first version of fan portal (218)
  • the user device (14a) may be redirected to a second version of a fan portal (218)
  • a tag (16a) in section (226) is scanned the user device (14a) it may be redirected to a third version for a fan portal (218).
  • each fan portal (218) may be a different version, each version having its own target ID.
  • a proprietor may deliver customized content to users in different sections based on the version of the target application to which the user device (14a) was redirected.
  • Local rules, other elements, or both may be written into each version to further customize content, which in some instances may be on an individualized level. That is, elements of application code may written as rules built into the system to provide the content delivery determined by the system by the target determination process and/or rules, which can be an additional feature of the target determination process.
  • rules may be applied during the target determination process using data tied to a unique ID, tag ID (e.g., tag group), or both to redirect to a determined target pointed to the pre the required rule.
  • the interface server (306, at 510) may determine, or cause to be determined, if there are any rules associated with a given version of a target (e.g. for fan portal [218]) or another target.
  • the rule may be designed as an event-type rule where content may be pushed to a device (14a).
  • the rule may only be provided in a given version of a target (e.g., for users sitting in loge seats).
  • a given version may also have local rules written therein.
  • a rule associated with a fan portal (218) version to be distributed to loge seats may be: if the user has season tickets, then include a digital offer for discounted season tickets for the following year.
  • the local rule may desire to pull/acquire (at 508) season ticket information before, during, or after the version of the target determined/identified for the loge seats is loaded on the event user device (14a).
  • the database may be queried (at 512), via the interface server (at 510), using the unique ID to check data records for the requested information (e.g., purchased season tickets).
  • data associated with the unique ID may be gathered (e.g., from a database, a third-party integration such as a ticketing service, or the like) and analyzed when the event user device (14a) makes the request.
  • the data may be pre-analyzed and verified/checked for changes upon the event user device (14a) request.
  • the interface server (306) may take all of the variables from the version of the target application code, rules, and the like and send requests/queries to the appropriate data sources or links (e.g., via, API, URI for file transfer, standard mail transfer protocol, etc.) to the data sources (at 512).
  • a counter may count the number of tags (16a) scanned in a venue (202) during a particular event; count the number of tags (16a, 16b) scanned by a particular user device (14a, 14b) in a predetermined time window; count the tags (16a) scanned by a particular user during a particular event; count the number of times a user has interacted with the target/target modules delivered to that user device; aggregate counts from various events, venues, proprietors, teams; segregate counts by seat, section, row, level; or other such nonlimiting illustrations.
  • 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 FIG.5.
  • dynamic updates/changes may further take place through the use of various third-party application programming interfaces (APIs) and their respective functionality.
  • the interface server (306) may connect, or may cause the third party integration server (320) to connect, to third-party hardware/software (e.g., server) via one or more third-party APIs/API calls to access the respective third-party integration/functionality as is known or will be known in the art.
  • third-party integrations/functionality may push or pull information through analytics server (312), retrieve it from database (308) or another data store, or combinations thereof, for real time/live streaming, updating, changing, and the like as is called for by rules/ instructions associated with the target pointed to by the tag ID or other controlling factor.
  • embodiments allow for the use of interactive, two-way communications between user devices (14a, 14b) and the platform (20) such as via the socket server (324) and/or a socket API, or the like as is known in the art.
  • dynamic content may result via a URL or other link to an external source, which may change in its own right, aside from the target being displayed.
  • methods such as methods (400, 500, or both) may be configured to collect and aggregate data.
  • every action that the user makes via the user’s device (14) with respect to the platform (20) event, determined target for the event, modules/module activity within the determined target is recorded/stored and tied to one or more of the forgoing via their respective ID and the unique ID assigned to the particular device, tag ID assigned to the tag (16) scanned by the particular device.
  • tools such as cookies, widgets, plug-ins, and similar tools may also be used to obtain data from user devices (14a, 14b).
  • This, and other, information may be stored in a data source (at 512) such as database (308) or other data storage and in association with the unique ID, tag ID for scanned tag, event ID, target ID, module ID, etc., so that related data may be searched, filtered, counted and other manipulations in a wide variety of different ways.
  • Data acquired using the aforementioned tools and other tools/techniques may relate to user engagement with a target such as a fan portal (218) as one nonlimiting example.
  • Such data may relate to digital offers presented to the user, digital offers downloaded by the user, products viewed by the user, purchases made by the user, to name a few examples.
  • Such tools/techniques may also gather data relating to other user engagements such as total screen time, Internet browsing (times, sites/pages accessed, software used), updates to Web pages, other Web sites visited, the Internet, and the like.
  • the user may also directly provide information via the user device (14a, 14b) such as by inputting personally identifiable information to obtain opportunities or offers such as unique information relating to user interests, user responses to questions, generic information about age or sex, or any other type of personally identifiable information.
  • Such data is of high value to, for example, advertisers, proprietors, and the like, as it provides a large insight into consumer purchasing and Web browsing habits.
  • the data selected for transfer may include one or more identifiers understood by the third party to identify platform (20) users to the third party such as an email address, phone number, or other such personal information.
  • the third party may use a person’s personal data to determine if the third party already has a file corresponding to the person identified by the personal data and add the transferred data relating to that person to the file. If a file cannot be found, the third party may create a new file for a new person and add related data thereto. Transfer may occur via an API or simple mail transfer protocol (SMPT). Adding data acquired via the platform (20) to a third party system may help build a more robust picture of an individual user, total fan behavior, or both.
  • SMPT simple mail transfer protocol
  • Having a broader picture of individual and/or total fan behavior may be used to provide heightened marketing, offers, content, and the like to individuals, groups, and/or an entire fan base via the platform (20).
  • a heightened marketing campaign may be incorporated into one or more versions of a web-based application for an event in progress or a future event.
  • aggregated data may be available to the proprietor, the venue, a team, or the like directly or via a third party system so that past user actions may influence future user experiences. For instance, gathered transactional data, browsing data, and the like may be analyzed to enable the platform to use the unique ID received in response to a tag scan to determine that the user has ordered only hotdogs at the last three events attended at the venue.
  • 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 their respective identifiers, target identifier, event identifier, tag ID, the unique ID and combinations thereof.
  • ticket brokerage integrations 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.
  • 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 and record that information so that it relates to a unique ID, other relevant identifier or combinations of identifiers.
  • the platform (20) may analyze such data, the analysis of which may or may not be recorded in association with unique IDs and/or other identifiers. 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, metrics, decision making, and the like.
  • 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 nonlimiting example or any other identifier as is appropriate for the situation.
  • the platform may determine how many tags were scanned, how many enter to win offers were opened/submitted and graphically display the data, couple the data to corresponding identifiers and/or new identifiers and more.
  • 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).
  • the socket connection (at 504) may be used to deliver pulled content, push content, notifications, and the like, and/or dynamically update content while the event is in progress.
  • socket connection may be particularly useful where a plurality of users are online at one moment and the total creates an occurrence of a trigger which provides some dynamic content to be released, for example, through a push of that target to the then active user devices that have met the limitation to receive that target.
  • 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, e.g., such as by tracking engagements with a module, other target uses, etc..
  • 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.
  • 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.
  • USER VALUATION In an embodiment, the value of a user to a proprietor, a group of proprietors, a third party (e.g., advertiser, CRM system, ticket broker, etc.), and the like may be appraised. The value of the user is based on data relating to the user and acquired by the platform in ways that have been previously described.
  • data may be acquired by the platform via a web-based application, or version thereof that is built for a particular event taking place at a particular venue.
  • the web-based application may be a fan portal built for a football game taking place at Lincoln Financial Field, home of the Philadelphia Eagles.
  • Users may use their own devices (e.g., smartphone) to scan a tag that is associated with the seat in which they are sitting.
  • Each user device has platform- assigned unique ID assigned thereto or that will be assigned thereto upon first engagement with a tag installed at/for any venue.
  • Each tag at all venues has a tag ID, which is transmitted to the platform by the user device and in response to scanning the tag.
  • the platform receives the tag ID for the scanned tag and the unique ID for the user device from the user device, if the user device already has an identifying unique ID assigned thereto.
  • the platform may use the tag ID to identify one or more of the venue that it is tied to (e.g., Lincoln Financial) , the event that the user is attending (e.g. Eagles v. Dallas), or the seat in which the user is sitting (e.g., level 1, section 500, row 10, seat 2).
  • the platform may also identify data tied to the unique ID.
  • the platform can use the tag ID, the unique ID, the event ID, the venue ID, or combinations thereof to determine the web-based application or version thereof (e.g. fan portal for Eagles v. Dallas) to which the user device is redirected.
  • Each web-based application built using the platform has a target ID assigned thereto.
  • Each target ID may point to the event that it was built for, the venue in which the event is or will be taking place, the tags installed with/for the venue, the teams playing the game, the owner/organization that is the customer for the venue, the type of sport being played, etc., each identified by its own respective identifier, and each of the forgoing may point to/be tied to one or more of the other.
  • Data gathered via the web-based application is collected for each user engaged with the application (and versions thereof) and is recorded based on the event, user, tag, venue, etc. individually or in combination. All user actions relating to the platform and web-based applications are recorded as data so that multiple metrics at multiple levels of granularity may be discerned by the customer proprietor, third party, platform personnel, for a venue, event, user, plurality of users, web-based application use, and much more. For example the number of users that have scanned a tag while at the football game may be counted, analyzed, displayed, etc.
  • the number of users that opened a module such as an enter to win module may also be counted, analyzed, displayed, etc.
  • the number of users that submitted identifying information such as name, phone number, address, email address, etc. in order to enter to win may be counted, analyzed, displayed, etc.
  • Such actions are recorded for each user engaging with each redirected target at each event at each venue supported by the platform.
  • a plethora of data can be collected, stored, analyzed, searched, filtered, etc. to identify a wide variety of user habits, groups of user habits, trends, etc. based on data aggregated by the platform.
  • Data collected/aggregated by the platform can be parsed, digested, grouped, compiled, etc.
  • a score may be expressed as a dollar amount.
  • a dollar amount score may indicate how much the user has spent across merchandise, food and beverages, ticket sales, etc.
  • a dollar amount score can be placed in Jimmy’s file to indicate the likely value of how much he will spend in each monetizable category for the current season, future season, lifetime, etc.
  • the collected/aggregated data can be a data that is collected via the platform alone or in combination with third party data. [0225] Aggregated data can also be parsed, digested, grouped, compiled, etc.
  • a proprietor may ask the platform to show it the likelihood that attendees sitting in lower level seats will purchase a hotdog at all country-music concerts held in its venue.
  • scored data may be transferred to a third party such as a customer relationship management (CRM) system, data management software and the like as described above.
  • CRM customer relationship management
  • 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.
  • 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).
  • 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).
  • Concerts and concert/festivals 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 tag installment system that is not attached to the venue (202), or they may use both.
  • 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 determined target.
  • 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.
  • the lanyard may be associated with its own tag (16a) and associated target (e.g., a digital offer).
  • tags (16b) may be linked to particular students and distributed to students and parents alike.
  • the student’s tag (16b)/MRC (17b) may be on the student’s school-issued ID or student-related identifier
  • the parent’s tag (16b)/MRC (17b) which may be the same as or different from the student’s MRC (17b)
  • tags (16a) may be located at or near entrances for users to scan with their devices (14a) to obtain the determined target for those tags (16). 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.
  • users may buy merchandise/concessions via in-venue tags (16a) much like the stadium example.
  • the platform (20) can also implement machine learning algorithms which, when coupled with a combination of some or all of the data provided from the analytics (312) and database (308), can provide real-time content that is predicted to be favorable to the end user.
  • the fan portal can be in various forms from browser-based Web pages, cloud-based Web apps, progressive Web apps, downloadable apps, etc.
  • the platform (20) could provide multiple options to the fan portal such as ordering food, purchasing merchandise to be delivered to a seat location, viewing replay footage, and/or placing wagers inside of the stadium.
  • the platform (20) would provide the ability to offer all users engaged with the platform (20)/event target determined by the platform (20) the same interactive content options, or to offer different content to users based on predetermined data sets or based on variables and data within the system.
  • a unique feature of one embodiment of the methods and systems detailed herein is the generation of unique content upon the aggregation of a total number of users within a particular event, multiple concurrent/overlapping events, in which the group as a whole is responsible for meeting a threshold to access content, digital offers, or combinations thereof.
  • Home Team has announced that they are providing a unique digital offer to all fans in the stadium if x number of fans are all on the system at a given moment.
  • Home Team has a total of 10,000 fans in attendance and the unique digital offer is being triggered upon meeting a threshold of 1,000 fans all being engaged with the platform (20) at a given moment.
  • a unique digital offer is provided. This would be operable, as detailed in FIG.6.
  • a first user, and a plurality of users would use a user device (14a) to scan a tag (16a) having an MRC (17a) therein, for example on a seatback (210). Scanning by the user device (14a) engages the redirect/identification server (302), and to the interface server (306) as described with respect to FIG.4.
  • the target determination process (644) includes a rule that is defined by requiring a counting of a total of 1,000 user devices being active on the platform (20) at a given moment. Accordingly, a counting module (602), receives and manage the number of user devices active on the system at a given moment from the interface server (306).
  • the threshold being the 1,000 active users, provides that the database is storing a particular target, which is the release of a special coupon for a free hotdog to all active users.
  • the counting module (602) receives and tracks the number of active users as it increases or decreases. For example, the counting module (602) may count the number of tags scanned as they are scanned by the user device.
  • the counter (602) may export the current scan number to a routine that subtracts the number of users that closed out of the target from the current number of tag scans to determine a current number of active platform (20) users. Alternatively, the counter may simply determine the number of active target users on an ongoing basis as part of monitoring the rule criteria, or similar set up.
  • the counting module (602) may also populate or display the total number of users, either on the user device (14a) within the fan portal, on the jumbo screen, on a video display, or combos thereof.
  • the target determination process receives confirmation from the interface server to retrieve the target, being the free hotdog, and then pushes that information form the database to the interface server (306), through the redirect/identification server (302) to the user device (14a).
  • the pushed target may be a target determined via the target determination process or a component thereof (e.g.
  • module, popup, etc. for users who are in the process of initial target determination or it may be a “rule target” that is added to a dynamic element of a target application, overlayed over the target in use on the user device, a popup, a new module, a redirect from the target in use, or the like.
  • the rule target may be sent to the user device apart from an active target/target in use such as via SMS, MMS, email, etc.
  • the venue can then set this particular rule, wherein additional users, who later access the system may also receive the offer, or only users within x number of minutes receive the offer, or any other rule as determined by the proprietor. The user can then use the free hotdog offer.
  • RULE-BASED OFFERS In an embodiment, a rule may be defined to cause an offer to be presented to users engaged with a web-based application such as a fan portal while an event is in progress.
  • FIG.7 details this in a flow diagram (700), with the first step (702) being to scan the tag.
  • the user is authenticated, verified (704), as detailed in FIGS 4 and 5.
  • a request is received at the target determination process which is recapped in part at step 704, is modified to incorporate a rule into the process.
  • the rule indicates that when 1,000 users are online, a free hotdog will be provided to those 1,000 users.
  • the target determination process (706) occurs as was described in FIG.4 as the set rule has not been triggered (706). Meanwhile, the interface server then looks for the tag ID/unique ID to count the active user (708). However, upon the meeting of an occurrence of a trigger or threshold (710), and as further detailed by FIG.7, the target determination process determines that the rule of 1,000 users online is met (712) and triggers the release of the pre-loaded content (e.g., free hotdog offer). Thus, the target determination process identifies the target rule from the database (714), and whatever target material was predetermined. The interface server then instructs the redirect/identification server or other server how to release the content to the qualifying user devices.
  • the target determination process identifies the target rule from the database (714), and whatever target material was predetermined.
  • a user device may be redirected to a URL end point, pushed data/socket pushed data (e.g., overlay, popup, dynamic content), a module/feature of a module that opens/turns on/updates when the rule is triggered, or otherwise provided through a Web app (718), which here is the digital offer for the free hotdog.
  • pushed data/socket pushed data e.g., overlay, popup, dynamic content
  • a module/feature of a module that opens/turns on/updates when the rule is triggered, or otherwise provided through a Web app (718), which here is the digital offer for the free hotdog.
  • a single user may need to meet some threshold, for example, scanning a tag at ten venues within the city, as shown in FIG.11.
  • Joe user scans one tag each day for ten days (i.e., the tag at location [1101], the tag at location [1102] and the tag at location [1103]), and on the tenth day, upon meeting the requirement threshold, the unique content or digital offer is delivered.
  • the special digital offer is the first 500 users to complete 10 scans receive a special viewing of the movie.
  • Joe User completes the task and is one of the first 500 users and thus receives the special digital offer.
  • the movie trailer will be released if 500,000 unique user IDs are online and active within the system at any point during time period t.
  • the system can track and identify both counting numbers and upon meeting one of the thresholds, release the full movie trailer.
  • the full release movie trailer may be only provided to those users who are engaged in the system or can be released publicly at that point.
  • the method here relates to communal interest in unlocking content.
  • the proprietor in this example, the movie company, may provide further digital offers to those users who participated, and, such digital offers can be modified based on the behavior and characteristics of the unique digital offer as it relates to the unique ID (i.e., the unique digital offer is shared on a social media and viewed 1 time as compared to a social media that is viewed 1,000,000 times). Such shares have significantly different value and thus the digital offer can be modified accordingly.
  • These data points, of who engaged with the offer, who shared the offer, and the like, are tracked to the Unique ID. Such information may then be utilized within CRM solutions to further provide unique content to users based upon their particular actions and data within their Unique IDs.
  • FIG.8 is a block diagram illustrating a further embodiment of the system (800).
  • the unique ID is determined to be a returning user, for the purpose of claiming the digital offer, then that user is denied access to the digital offer to prevent the user from redeeming multiple digital offers. If the user is new and does not have a unique ID on his user device, the process of FIG.4 is followed to generate the same. Otherwise, if the unique ID is not new, but has not claimed the digital offer, the new user and returning, but unclaimed user, now claim the digital offer.
  • the target determination process (844) determines what content to display based upon data received from the redirect/identification server (302), and the target determination process (844) communicates with the analytics portal (46), and the analytics database (66), in view of the unique ID (22a) to return a target (807) (FIG.6) through the interface server and redirect/identification server to the user device (14a). Notably, all of this information is stored in a database corresponding to the unique ID, so as to create a profile and information related to the user. [0246] By including a check for the unique ID, two aspects occur. One, there is a confirmation that a single device is not scanning multiple tags to unlock special content multiple times.
  • FIG.9 provides a first step (902) where a user device (14a) scans a tag (16a) on a seat (208). Following a scan of the tag (16a) with the user device (14a), the user is redirected to a tag URL that is uniquely encoded to the specific tag (16a) through step (904).
  • the redirect/identification server (302) receives the tag URL request, checks for a manifest with a unique ID on the user device and informs the interface server (306) and determines the status (new or not new) of the user device (14a) to the system (900). By checking for a manifest and a unique ID on the user device and correlating it with the unique ID stored in the database a confirmation can be made of a new (34) or returning user (36). If the user is new, a new unique ID is generated (906) by the system and stored in the database and on the user device.
  • the interface server (306) includes a database (308) of URLs containing unique certificates used to issue digital wallet passes.
  • the interface server confirms that the unique ID located on the user device matches the unique ID in the database. If the user is a new (34) user, the system obtains a manifest with a unique ID and sends it to the user device (steps [406] and [408] from FIG.4) and records the same within the database. At this point, the user is confirmed with an existing unique ID (22a) or possesses a new unique ID, in either case, the certificate used to issue a digital wallet pass being specific to that user device (14a).
  • the target determination process (844) determines what content to display based upon data received from the redirect/identification server (302) in step (908), and the target determination process (844) is told what to show the end user (910).
  • the interface server and the target determination process (844) further check for dynamic rules and directs back to the server (912).
  • the redirect/identification server sends the end user to the redirect URL directed by the interface server (914).
  • a trigger then occurs (918).
  • the occurrence of a trigger as defined in the several examples herein, then generates a new target. Accordingly, the interface server determines the new target to display based upon the trigger occurrence (920).
  • a step (916) may include that the user is prompted to input unique identifying information (54) (FIG.6) into the system (10), which allows for better analytic information on the user device (14a).
  • the provided information could be stored in an analytics database (66) of the analytics portal (46) or in a primary database (308) among a variety of storage options.
  • a target that was previously provided can actually be modified by the occurrence of a trigger. For example, the digital coupon (32), based upon a live trigger, or based upon the actions taken by a user.
  • the trigger/outcome occurs (68), may be that a home team wins a game.
  • the target or offer which was prepopulated within the database, a coupon can be modified.
  • the digital offer/target (32) first provided for a free drink with an order of a slice of pizza can be changed through the target determination process (844) upon any rule being met, but specifically here upon a trigger event.
  • the digital offer (32) now provides a free drink and salad with the order of a slice of pizza.
  • the incentivized offer increases.
  • the system uses the unique ID stored in a manifest on the user device and in a database on the server; therefore, this digital offer is now unique to the user device on which the manifest with the unique ID is stored and must be in order to track the sharing of the digital offer. If the individual transfers the digital offer from his/her user device to, for example, five other communication devices within a fixed time period such as, for example, a week, the digital offer automatically upgrades from 10% to 20% off at the local retail store. This capability offers further incentive for individuals to transfer their digital offers to family and friends so that they will receive greater discounts.
  • BW Films is releasing a new motion picture trailer. BW Films wants the initial trailer to be viewed by at least 10,000 viewers on the initial launch and is marketing the film to college students. ZY University is hosting a football game at the campus stadium.
  • each seat in the stadium has a tag (16a) installed on the armrest and each tag contains an MRC that is uniquely coded to the system via a tag ID.
  • each fan who wants to interact with the system scans the tag on his or her armrest. Once scanned, method (400) is executed.
  • the redirect/identification server can be programed with certain rules. For example, a rule could be if a user device does not rescan the tag within thirty minutes, or if the user does not interact with any of the redirect URLs the interface server sends to the user device within a thirty-minute time period, that user device may be categorized as inactive and removed from the count of total number of user devices currently active on the system.
  • a counting mechanism (FIG.6, 602) can be utilized with any of the embodiments to track and account for any rule or metric that requires some form of tabulation of users, whether a total or active, as nonlimiting examples of counting.
  • the redirect/identification server Once the redirect/identification server has verified that there are 10,000 unique and active user devices on the system, it directs the interface server to deliver a unique redirect URL to each user device that will allow the user to view the motion picture trailer.
  • BW Films wishes to reach a larger market to launch a new motion picture trailer. BW Films would like a total of 500,000 viewers with a minimum of 5,000 viewers in each of ten venues. BW Films knows that Saturday is traditionally game day for college football.
  • the interface server can tally the number of unique user devices currently on the system rather than the tally being completed by the redirect/identification server.
  • tags are installed in hotel rooms throughout the country. WS Airlines would like to offer a flash sale on air travel and sets the parameter that there must be 10,000 unique users on the system at one time in order for the digital discount offer to launch.
  • the redirect/identification server scans the tag with the tag that is installed in the user’s hotel room and method (400) is executed.
  • the redirect/identification server directs the interface server to deliver a target, i.e., a digital offer for the flash sale.
  • the tag ID can also be part of a tag grouping.
  • the counting mechanisms described in FIG.4, FIG.5, and FIG.6 not only counts user is new or existing, but the count also tracks the university campus on which the MRC is located because each tag ID is part of a tag grouping for a specific campus.
  • the redirect/identification server tallies the number of unique and active users at each college campus location.
  • the redirect/identification server directs the interface server to deliver a unique redirect URL to the user device which allows the user to watch the video advertisement on his user device and the interface server also delivers a digital offer for a free candy bar.
  • the digital offer can be in the form of unique discount code for each user, a single discount code for all users, a unique digital or mobile wallet offer that can be added to the user’s device or the same digital or mobile wallet offer that can be added to all user devices.
  • the users at ZY University may meet the minimum threshold set by N & N Candy within one hour of the launch of the marketing campaign and thus be given access to the video content and free candy bar offer within one hour.
  • a musical group would like to provide their fans with an opportunity to download the group’s latest single.
  • the group is performing in a venue that has a tag installed on the armrest of each seat and each tag contains an MRC that is uniquely coded to the system via a tag ID.
  • the group is also live streaming the event over the internet and the online production of the performance will display a QR or similar MRC in the bottom corner of the video feed.
  • tags are placed throughout one location or in multiple locations (i.e., a bus bench [1101], a coffee shop [1102], or a billboard [1103]).
  • this configuration could also work for a museum with tags at multiple exhibits, a shopping mall with tags at multiple stores, multiple tags placed throughout a particular town or city at certain establishments in that town or city or multiple tags placed at particular locations throughout a larger geographical area.
  • the tags have been placed at restaurants throughout Fort Worth, Texas.
  • Stockyards Rodeo wishes to launch a marketing campaign where they provide a mobile or digital offer of buy-one, get-one-free tickets to users if the user has frequented a certain number of restaurants in the Fort Worth area.
  • Stockyards has set the parameter (i.e., rule) that users must visit four restaurants in order to unlock the digital offer.
  • Rule the parameter that users must visit four restaurants in order to unlock the digital offer.
  • a user arrives at the restaurant, he uses his user device to scan the tag that may be mounted next to the door or the restaurant, in the lobby of the restaurant, or at a particular table in the restaurant, which executes method (400). If the user is new, the identification server notes the device, location, date, and time of the scan and creates a new user/device ID record for this campaign.
  • the server retrieves the user’s existing user/device ID record for this campaign, notes the location, date and time of the scan and updates the user/device ID record to reflect the total number of scans. This process is repeated each time the user scans a tag at a restaurant in Fort Worth until the user meets the parameter set by Stockyards to unlock the digital offer, in this instance, the user must visit four restaurants.
  • the redirect/identification ID server directs the interface server to deliver a unique redirect URL or digital offer to the user device for buy-one get-one-free tickets at Stockyards.
  • the system may be utilized in conjunction with a digital wallet or wagering wallet for wagering.
  • a wagering component users would be able to scan the tag with the user device and be taken to a live wagering portal, which could be browser based or in the form of a cloud or locally based mobile application, including a progressive Web app.
  • a live wagering portal which could be browser based or in the form of a cloud or locally based mobile application, including a progressive Web app.
  • analytics portal the user would be able to see their past wagers across the entire system and place their wager utilizing a digital wallet solution such as Apple Pay or Google Wallet, or through traditional payment methods. All of the interactivity and wager-based actions will be facilitated without the need for the user to create a traditional user profile, unless so required by law.
  • This same wagering configuration could be utilized to offer “brand wagers” wherein the prize given to the user is a physical item given to the user such as a promotional item from a team sponsor or a digital reward which can be downloaded or emailed to the user’s device.
  • Fan engagement at sports venues often goes beyond the game itself. When the moment arises, fans are often generous to causes that are supported by their team, which may be provided to nonprofit organizations. Therefore, in a venue, the team may request support of one or more charities, and the platform could allow for the ability to donate money in real time directly from their venue seat via the NFC and/or MRC.
  • the user would, either with or without prompting from the venue multimedia display system or jumbo screen, scan their tag and be prompted to donate money either using their digital wallet or traditional payment methods.
  • the system would allow proprietors to deploy various customizable donation templates to every seat, row, or section if desired.
  • the user could be offered a physical or digital reward that could be used inside or outside of the venue.
  • the benefit of the system is that the user device contains a unique ID stored in a manifest that is indicated in the system. Accordingly, this allows the system to identify a user device corresponding to a particular user ID as donating a certain dollar amount.
  • the system can be prepopulated with “rewards” or incentives to donate or reach a cause.
  • a cause may be for a single section of a venue to raise $100 (i.e., 224 from FIG.2). All donations originating from tag within the particular section can then be aggregated to determine if the section reached the $100 donation goal, or if a certain percentage of the section participated in reaching the goal. Accordingly, if there are 200 people in the section, a donation of an average of 50 ⁇ would be sufficient to hit the goal.
  • the system can then populate a predetermined digital or physical reward, i.e., a coupon or some other offer that can be used at the venue, or some other tangible or intangible reward.
  • the real-time polling is enabled by the individualized nature of both the user device and also of the tag. For example, where only one of the user devices or the tags is unique, it is impossible to identify both the user and also a population of similar users. If a section of a stadium is competing against another section, we need to have each user device connect to a tag in their particular section, via a tag ID grouping, and then participate as a group to reach the offer threshold. If the group element is missing, such “sectional” competition would not be possible. [0266] While the group may participate together, because of the unique ID, individual user rewards can be provided, for example, as a user makes a larger donation, that user is provided with a larger reward than another user from the winning section.
  • the unique ID stored in a manifest on a user device allows for tracking of actions, i.e., the donation by the user, individual rewards can be provided to that user, corresponding to that particular unique ID. [0267] All of these actions provide opportunities for the system to capture user data.
  • analytical data may be, for example, date, time, GPS location of a tag, GPS location of a user device (14a) when it scanned a tag, the type of user device used to scan a tag, orientation of a user device when a machine-readable code was scanned, and type of operating system on a user device that scanned the tag.
  • the exemplary method and system couple the collected analytical data from the physical scanning of the plurality of tags (16a) with data collected once the individual is directed to the target.
  • the data may be, for example, time spent on a Web page, purchases made, IP address, personal information input by the user, and products viewed.
  • Such data is of high value to, for example, advertisers, team owners, and venue owners as it provides a large insight into consumers purchasing and Web browsing habits.
  • the user data can remain anonymous to a large extent, as it is collected based upon the user device scanning a tag and not dependent on the user logging into the system. Therefore, data does not need to be correlated with the actual identity of the person controlling the user device.
  • Data can also be gathered outside of the system, for example, through an API connecting the system to a third-party server or database.
  • the benefit of also utilizing user data that is gathered from outside of system itself is that it provides data that might not otherwise be gathered, while also offering an opportunity to “preset” content when a user scans the tag at their seat.
  • Example 1 If event ticket provider such as Ticketmaster®, provided data to the system’s analytics portal revealing that Joe purchased tickets to the football game to sit in seat 1, row 1, while also providing data, known to Ticketmaster, such as that Joe is a 32 year old male (data that is provided to Ticketmaster from Joe when he creates his Ticketmaster account), because each tag in the system is uniquely encoded down to the individual seat or specific location via a tag ID, the analytics portal would have the ability to “preschedule” content that would appeal to a 32 year old male when Joe takes his seat at the game. This use case could be valuable for marketers looking to market to a particular subset of attendees, vs the entire stadium or venue. The data can be from more than just one event as well.
  • Joe has previously purchased other tickets from Ticketmaster, that data may also be available and provides further details and information relevant to Joe, which can be used to provide better content to Joe. If Joe only buys rock concert tickets, for example, providing country music listings for new concerts would not be the best targeted advertising for Joe – so modifying the content to that of Joe’s interests (rock concerts) provides greater value for advertisers and also to Joe.
  • a machine learning component of the system would allow sports teams to provide more relevant real- time offers to fans by customizing content based on user interaction.
  • Example 2 If Joe scans his tag and is taken to the team fan portal where he selects “buy merchandise”.75% of the time Joe purchases a shirt, but he never buys a hat, then the system would have the ability to adjust Joe’s offerings in real time to show him a larger selection of shirts, instead of hats, based off of his past purchasing and browsing habits. Alternatively, the system could use this data stored on Joe’s purchasing habits to deliver a customized digital offer to Joe to entice him to buy merchandise that is not a shirt such as a 25% discount if Joe buys a hat. This could be valuable to proprietors, teams, performers, promoters, or venues looking to sell items from merchandise to food inside of the venue or based upon inventory considerations.
  • the system has the ability to learn user characteristics from user input within various user portals mentioned above (Web browsers, PWAs, etc.).
  • This component would provide a user with customized content based on their previous content interactions inside of one venue, or interactions across the entire system network of tags. It would also allow said system to store user and/or the user device information in order to offer specialized incentives based on past usage statistics. For example, the system may reward Joe for scanning the tag at his tenth straight baseball game by delivering an offer for “team VIP” merchandise. Or the system could provide Joe an offer for a hot dog, peanuts, or soda at a reduced rate based on his purchase history or incentivize him to make a purchase with a digital offer, if he typically does not purchase food or beverages.
  • the benefit of the unique ID, in combination with the tag ID is that a single tag, having its own tag ID, can be scanned by multiple user devices, and each scan by a different device will have a different unique ID.
  • proprietors such as venue owners, teams, universities, marketers, performers, promoters etc.
  • the system offers unique digital wallet certificates for each user upon scanning the tag, which means that if fifty users scan the same tag with their user device, all fifty user devices will individually have a unique record within the system database.
  • a single tag could be located in a centralized location and would still allow for unique content (the digital offer) to any user who scanned that tag.
  • the system might deliver a different digital offer to each user so if Joe scans the tag, his digital offer might be for a half price soda at the concession stand, but if Joe’s wife scans the same tag from a different user device, having a different unique ID stored in a manifest, her digital offer might be for a half price hamburger at the concession stand. Likewise, the system will be able to track if a user activated and redeemed his or her digital offer.
  • the storage of data corresponding to each unique ID is what provides for the ability to create rules to provide the different data to each unique ID. This data can be provided to third-parties to utilize the data, for example, to identify and target users with unique content based on their history of uses.
  • the system may offer “group passes” wherein the system could offer a digital offer that was only able to be issued to a predetermined number of users.
  • the first person the first 5, the first 10, 25, 50, 100, 500, 1000, 10,000, nth, person to scan the tag (and all numbers in between), may be included within a group.
  • the distribution of such group passes and counting of executions of the system to a user device can be used as a game or for other giveaway plans. It is common knowledge of the types of games where the “100th person to download wins a prize,” or “only the first 100 people can claim a prize if they buy or click now.”
  • the ability to track these types of programming through the system provides a new way to manage such programs.
  • the system could also be implemented within a traditional mobile application or Web-based platform whereas the user would be offered the unique digital offer once they visit said application or URL address. Because of the individualized nature of the unique ID in the system, the unique digital offer can then be directly modified based upon chance, some data, or trigger occurring which allows the provider of that unique digital offer the opportunity to modify an offer. For example, an offer is for 10% off a pizza, but the offer becomes 25% off once the offer is shared with at least 2, 5, 10, 25, 50, n number of people, who also download an offer. This allows tracking of who downloads an offer, how many are tracked to a particular offer, and allows for modification and improvement of an offer based on metrics related to sharing.
  • a proprietor such as a retailer to provide a digital offer in the form of real time discounts to users in specific venues via the tags (16a) upon the occurrence of a threshold set by the retailer.
  • a proprietor such as a retailer to provide a digital offer in the form of real time discounts to users in specific venues via the tags (16a) upon the occurrence of a threshold set by the retailer.
  • the tags (16a) inside of the venue (202) are linked to a specific retailer via a tag grouping or geofencing, then that retailer could offer discounts in real time that could only be accessed by users inside of the venue (202) upon the occurrence of meeting a threshold of interest in that particular offer.
  • the trigger event is that at least five people scan a tag related to a particular offer.
  • Embodiments of the invention also provide individuals an ability to establish interactive communication via tags (16a).
  • the plurality of tags (16a) can be programmed to perform various designated actions such as, for example, an ability to download a digital offer (e.g., a digital coupon) straight onto the user devices (14a) which could be redeemed at a concession area or retail location.
  • Example 4 If a tag is scanned by Joe at a football game in Arlington on a Sunday, and then a tag is scanned by Joe in a rideshare vehicle in Boston the following Wednesday, the system would understand that the user, Joe, was the same for both interactions, without Joe having to log into the system, and display content accordingly based on data provided from the analytics portal. This is because the system knows the user, Joe, because of the unique ID stored in either on the manifest on the user device or on the server, or both. By scanning a tag, the system can also upload data to generate more information about Joe and his activities and interests, so as to provide better content to Joe through the content.
  • Administrator device (12) which is shown in FIG.1, may be any type of computer such as a laptop computer, desktop computer, tablet, and the like.
  • user device (14a or 14b) may be any type of processing device such as a handheld computer (e.g., phone, smartphone, tablet, personal digital assistant), wearable computer (e.g., watch, glasses), or portable computers (e.g., laptop, netbooks).
  • Scanning of the tag (16a, 16b) from the user device (14a or 14b) is performed through nearfield communication (NFC) or use of a camera on the user device (14a or 14b) to scan the visible quick response code (QR code).
  • NFC nearfield communication
  • QR code visible quick response code
  • Administrator device (12) and user devices (14a or 14b) typically include a browser application to facilitate communications with one or more servers among other things.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • RAM Random Access Memory
  • DRAM Dynamic Random-Access memory
  • SRAM Static RAM
  • servers e.g., 302, 306, 310, 312, 320, 322, and/or 324) may include database server functionality to manage database (308) or another database.
  • database (308) 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.
  • database (308) may comprise more than one database, the more than one database may be distributed across many locations, and data may be redundantly recorded in the more than one database. Furthermore, data may be stored in blocks that are part of a chronological blockchain (314) and may be dispersed across a decentralized distributed ledger. Blocks of data in a blockchain are linked in such a way that tampering with one block breaks the chain. Thus, digital data stored in a blockchain is verifiable with an elevated level of integrity. Therefore, the database (308) may also be a distributed database system, utilizing blockchain (e.g., 314) to provide for storage of NFTs or the like related to the system.
  • blockchain e.g., 314
  • one proprietor’s goals for an interactive DEP may differ from another proprietor’s goals, and as such interactive DEPs may expressed in a multitude of different formats, layouts, designs, versions etc., that may include numerous variations on functions, features, rules, instructions, etc. Nonetheless, interactive DEPs typically include at least one feature/module with dynamic content that may be altered in some manner at least during the course of the event. Thus, what an individual user may experience via that user’s interactive DEP is not necessarily the same as what any other user will experience.
  • FIG.2 as a nonlimiting example, all in- venue users may receive an interactive DEP in response to scanning a tag (16a) with their respective user device (14a).
  • Each stadium section (222, 224, 226), however, may receive a different version of the interactive DEP, due to redirection as was explained with respect to FIG.4. And within a particular version, content that one user sees may be different based on user data and/or rules as was explained with respect to FIG.5. Even if the version and content are the same, individual users typically will not interact with the interactive DEP in the same way at the same time, which will also cause each user to have a unique experience.
  • a proprietor may include in an interactive DEP, including, without limitation, a map (1602), a roster (1604), replays (1606), augmented reality (1608), fan camera/fan filter (1610), live statistics (1612), NFT (1614),wagering (1616), audience participation (1618), upcoming events (1620), merchandise (1622), concessions (1624), and other (1626), as is shown on the features page of the interactive “l Game Day Program” (1600) of FIG.6.
  • the game day program (1600) is an extensive “fan portal” (218) type format for an interactive DEP.
  • advertising and other content may be included on the home page, and/or any other page/pages of the game day program (1600). Further, advertising, especially dynamic advertising, is an important feature of an interactive DEP since advertising may offset proprietors’ costs and allow users to obtain an interactive DEP for free.
  • a proprietor may select a book-like format rather than a “fan portal” type format to implement an interactive DEP.
  • a proprietor may include a book-like interactive DEP as a feature/module of a “fan portal” type interactive DEP (1600).
  • FIG.7 depicts a nonlimiting example of a few pages taken from a book-like interactive DEP (1700) distributed by a city zoo.
  • the cover page (1702) of the interactive DEP (1700) may be what zoo visitors see after they scan a tag (16a), or it may be what a user sees after linking to the interactive DEP (1700) via a selectable option on a home page of a fan portal type interactive DEP.
  • the cover page (1702) may emulate a cover page of a traditional paper program. However, icons, images, or the like on the cover page (1702) may link to other pages either within the interactive DEP or external thereto.
  • Features/modules listed on the Game Day Program (1600) may be included on the pages of the interactive DEP (1700) shown in FIG.7, or the interactive city zoo DEP (1700) may include modifications of a “standard” feature/module.
  • the “exhibits” (1712) and/or “animals” (1714) feature/modules may be variations on a game-day “roster” feature depicting an animal, here a seal (1704).
  • the book-like interactive DEP (1700) may also include a navigation pane/bar to assist with navigating a digital document as is known in the art. Since interactive DEPs are meant to fit many different proprietors’ needs, features/modules may be created/customized to meet those needs and are not limited to the examples described herein.
  • Map Feature It is not unusual for an interactive DEP to include an interactive map of the venue/event, especially where the venue/event is large or difficult to navigate.
  • the interactive map may utilize one or more third party integrations (320), other integrations, databases or other sources information, rules, instructions, API calls, other calls, user device data and/or capabilities, or combinations thereof to provide the desired map functionality.
  • a stadium wants to know where the nearest restroom is located, she may select the map feature (e.g., FIG.6, [1602]) to link to a map of the stadium.
  • the map feature e.g., FIG.6, [1602]
  • Janet is at the zoo and she wants to know where the nearest restroom is relative to her current location she may turn or navigate to the page that has the map of the zoo or a link to the map of the zoo (FIG.7, [1706]).
  • Map features may include a search function to search for a specific location within the stadium, may automatically provide routes to the most frequently visited locations such as restrooms and concessions, locations that Janet has visited in the past in the same venue or at different venues (e.g., restrooms), or combinations of the forgoing.
  • Janet may simply tap her desired destination on the map to receive a route to the destination.
  • the route may be the shortest route, route with the least traffic, destination with the shortest line, or the like, in a manner that is analogous to routes that are shown on street maps using data gathered from various sources.
  • Such maps can also be utilized, therefore, for scavenger hunt like games, which require a user to find, identify, and scan certain tags as part of an event or as part of a challenge or task within one or more of the embodiments.
  • Remote users have little need for an interactive map of a venue, event, or the like.
  • a map function may not be included in the interactive DEP distributed to a remote user.
  • the map feature may use GPS coordinates, geolocation information, geofence data, tag ID information, other such information, or the like, and provide a suitable map to the map feature such as the area surrounding the remote user device (14b). This may be especially helpful to those users who are out of town and do not know their surrounding areas.
  • a digital offer for the restaurant may be displayed on or in the interactive DEP, delivered to the digital wallet (24b) on the remote user device (14b), or other such location. Since the digital offer is being sent to a remote user it may have an expiration date that is longer than an in-venue digital offer, which typically expires when the venue closes after the event.
  • Roster It is also not unusual to have a roster, or a modified roster in an interactive DEP. As is shown on the game day program (1600) there may be a selectable link to a roster (1604). Rosters formats and layouts are practically limitless and can range from simple to complex.
  • one or more rules may be written to monitor for a metric or trigger related to a particular player such as a personal best, event record, world record, or the like in the same or similar manner that was detailed in FIG.5.
  • a metric/trigger is detected while the event is in progress (e.g., most passing yards in a single game)
  • dynamic content may be updated with fresh content.
  • an image of the player making the historic pass may replace a current image
  • a video clip of the historic pass may replace the current video
  • the player’s statistics should update a pre-recoded video may be released
  • merchandise related to the player may be promoted and/or discounted
  • a commemorative NFT may be released
  • wagers may be taken as just a few examples.
  • a roster may be the same or different on different versions of an interactive DEP (e.g., going to different groupings of tags [16a]) or for in venue and remote users or both.
  • the city zoo interactive DEP (1700) includes a modified roster for exhibits (1712) and one for animals (1714). Modified rosters may also be included in interactive DEPs for other sites such as museums, historic buildings, and similar places.
  • the modified roster for the zoo exhibits (1712) may include images and videos showing highlights of the exhibits including feeding times, times when the animals are most likely going to be active, and other information of interest to zoo visitors.
  • the modified roster for zoo animals (1714) may include one or more pages dedicated to the animals as individuals, groups, or both, trivia (1716) regarding animals or other games related to the animals or the zoo in general. These pages may also include images, videos, merchandise, and the like. Further, video of the exhibits, animals, or both may be streamed in the interactive DEP (1700) so that if a special program (e.g., feeding time, meet the trainer, a show, etc.) is happening and a user who cannot get close enough to the action or who is at the other side of the zoo can still see the special program via the interactive DEP. Images may be updated dynamically as well.
  • a special program e.g., feeding time, meet the trainer, a show, etc.
  • the counter may be enabled to count the number of times a particular user uses his/her device (14a) to scan distinct tags (16a) in the zoo.
  • a predetermined number e.g., 10, 100, 1000, etc.
  • content may be released, unlocked, or otherwise made available per a rule to which the metric/trigger is tied.
  • a zoo sponsor may provide a giveaway to the 100,000th user to scan a particular tag (16a) such as a free zoo membership for the next year, which may appear as a digital offer for the winning user to redeem.
  • Video Replays and Other Video A unique feature of embodiments of interactive DEPs includes the ability to watch a replay of some or all of the event.
  • the game day program (1600) may have a replay module/feature (1606).
  • the replay module/feature (1606) may include a listing of replays that have occurred during the game. Thus, the user may select a replay from the list as it becomes available, watch a replay that happened earlier in the game, or both.
  • replays may be distributed elsewhere in the interactive DEP. As one nonlimiting example, replays may be shown on a page dedicated to a player or several players, especially if the replay captured a momentous occasion. Or the same replay may be accessed from more than one location in an interactive DEP. This may be especially true in a book-like format where a user may want to see the replay in context.
  • a list of replays of exciting, cute, or other unique animal activity may be associated with an exhibit (1712), animal (1714), or both.
  • games may exist, such as zoo trivia (714) or other scavenger hunts or activities.
  • the city zoo interactive DEP (1700) may have a feature/module (1718) dedicated to recordings that can be themed for funny things that animals do, educational videos, or both. Regardless of where replay/recorded videos may be displayed in interactive DEPs, video recordings/e-plays may be cycled, listed, or other presentation to allow the user to select and control the video as the user desires.
  • Video content is not limited to replays taken from action in the game or the like. Video content may also include interviews with owners, managers, trainers, professional commentators, sponsors; team footage or other footage, advertisements, digital offers, and other content made in video format, or combinations thereof and regardless of interactive DEP format. This type of content may be listed, switched out in real time, cycled, etc., as determined by various rules and/or other instructions that enable the content to be acquired from a data source (e.g., at 512) and delivered to the interactive DEP in a manner the same as or similar to that described with respect to method (500).
  • a data source e.g., at 512
  • the back-end changes may be global to be applied to all versions of the interactive DEP for the event or select to be applied only for interactive DEPs distributed within the venue, for a particular grouping, both, etc.
  • Back end changes may be made to one or more templates, rules, a “master templet,” “master code,” or other such back end changes.
  • Time slots may also be purchased in advance so that certain content is shown during the purchased time much like television advertising is purchased.
  • an advertiser, sponsor, other organization, or the like may purchase time for their message to be shown on the jumbo screen (e.g., FIG.2 at [204]) or a live televised message. The advertiser et.
  • an embodiment offers real-time value added pricing of advertisements or the like, while simultaneously offering users the most dynamic experience with immediate and actionable content in the interactive DEP.
  • Augmented Reality Many of the experiences afforded by an interactive DEP may also be augmented via an augmented reality (AR) feature/module (1608, 1722).
  • AR augmented reality
  • the AR feature/module (1608, 1722) enables a user device (14a, 14b) to digital elements to be added to or overlayed on objects, images, video, or the like that the camera (FIG.2, [212]) on the user device (14a, 14b) is pointing at or that is being displayed on the user device (14a, 14b) screen.
  • the camera FOG.2, [212]
  • Janet when Janet is navigating to the restroom, she may point the camera (212) on her device (14a) in front of her to see the route superimposed on the image provided by the device camera (212).
  • an AR feature/module may be utilized with the interactive DEP distributed by the city zoo (1700).
  • the zoo may provide supplementary information about exhibits, animals, and other points of interest when in AR mode (1722) so that when the user points the camera (212) on her/his device (14a) at a particular exhibit, animal, or similar point of interest, information about that exhibit, animal, etc., may be overlayed onto the image displayed on the user device (14a).
  • the platform may utilize hardware and/or native software on the user device (14a, 14b), instructions delivered via the interactive DEP, code executed by one or more platform (20) servers (e.g., 302, 306, 310, 312, etc.,); data from the user device (14a, 14b), database (308), or any other data source; one or more third party integrations (320); or combinations thereof to gather data about the user’s surroundings for augmentation thereof.
  • platforms may also view captured video with AR objects, effects, filters, etc., disposed thereon. For example, cameras (FIG.2, [206a-206d]) at the venue (202) may be used to record the game in progress.
  • Cameras (206a-206d) may also be equipped or associated with Lidar sensors (light detection and ranging sensors), have high definition capabilities, have, or be associated with other such enhanced features/capabilities, or combinations thereof.
  • recorded video may be made available to user in a manner that is the same as or similar to regular video replays except to implement AR activities, the video may first need to be processed to be compatible with certain AR effects.
  • the user may be able to place an avatar on a replay either in a position on the field, on a particular player, on an object such as a ball, or other such options.
  • the replay may then be shown with the avatar disposed thereon, viewed from the perspective of the avatar whether it be on the field, player, object or other, or combinations thereof.
  • the user may wish to “draw” on the replay much like a professional commentator or the like.
  • Some of the AR playbacks may depend upon third party integrations, especially where there is a need for specialized equipment, specialized processing, etc., This is easily achievable through the platform (20) providing the interactive DEP utilizing one or more third party integrations (320).
  • These integrations (320) may be via APIs, may be directly provided to the platform (20), or combinations thereof.
  • native hardware/software on the user device (14a) may be utilized to send and receive data, instructions, or the like to/from the platform (20), and the platform (20) may provide additional server- side processing of data etc. received from the user device (14a, 14b), the third party integrations (320), or combinations thereof to allow the user to manipulate the AR (or other) replay as desired.
  • the proprietor does not have to make AR content available all of the time. Certain content may be tied to a rule or rules having one or more metrics/triggers to be satisfied before being made available to users. For example, certain replays (AR enabled or not) may only be available for a window of time after initial release, whereas other replays may only be available if the footage includes a significant occurrence such as a record being broken.
  • a user may have to watch a promotion, take a survey, or participate in some other activity before content is made available to the user. These rules can be controlled by the proprietor to turn on or turn off certain aspects for delivering content.
  • Advertisers, sponsors, organizations, etc. may also use aspects of the AR feature/module to their advantage. Advertisements or other messages may have to be viewed before the user can access the AR feature/module, they may be overlayed on the AR content, popup during viewing of the AR content, and/or other such similar ways advertising is made available.
  • AR content may be sponsored by a specific advertiser and although not an ad per se, a notation regarding the business, organization, etc., sponsorship of certain content may also serve advertising purposes.
  • sponsored content may have “brought to you by XYZ company” or the like disposed over the content such as at the beginning or end of the content.
  • the type of sponsorship may be tied directly to the unique ID, so that individual users may have a sponsor to the same target.
  • a family of users having two adult parents and two 18 year old children may each receive different sponsorships, targets, or offers even in the same location at the same time, based upon the rules formed by the proprietor based on the data in their unique ID.
  • a fan camera and/or fan filter (1610) may be made available to users.
  • the fan filter feature/module (1610) may be a specific use of AR similar to filters used by various types of social media.
  • the filters available via the interactive DEP may be tailored to meet the proprietors needs such as by only offering options that support the team, game, venue, event, or other purpose.
  • the user may be limited to using team colors, mascot, logos, emblems, and the like.
  • fan filters may be integrated with social media platforms to be shared with remote users or others.
  • the city zoo interactive DEP may also offer a zoo camera/zoo filter feature (1720) that is the same as or similar to the one found in the game day program (1600). In this case, the available filter may be based on animals at a particular zoo or other famous animals.
  • the fan camera/zoo camera may be used alone or in connection with the AR feature/module.
  • the fan camera/zoo camera utilizes one or more third party integrations (320) to provide video images from any angle.
  • This capability may rely on specialized equipment including cameras, computers, sensors, etc., which were mentioned above.
  • the result of this integration is to enable users to see a replay or the like from any available angle: top, bottom, and all around (e.g., the venue/exhibit, etc.) regardless of where the user is located.
  • top, bottom, and all around e.g., the venue/exhibit, etc.
  • Live statistics may be on one or more dedicated pages, sprinkled throughout the DEP such as on a page dedicated to a player, proximate an article, or combinations thereof.
  • statistics may be presented as usual for the event or may be presented as the proprietor desires.
  • statistics for a football game may be by team, player, offensive team, defensive team, special teams, quarter, half, game, season, or combinations thereof and without limitation.
  • Statistics may also be used to highlight team and/or player milestones and may even provide a countdown toward the milestone, used to dynamically rank players across a league, on a team, or the like, to play fantasy sports, and for wagering, to list a few examples.
  • the live statistics module/feature (1612) may be updated in real time using one or more rules to push or pull data for the interactive DEP, much like the rules described with respect to FIG.5.
  • statistics and related data e.g., scores, time remaining, time elapsed, other time considerations, etc.,
  • may be updated at regular intervals e.g., every N seconds, minutes
  • Updates may be made using data sources such the database (308), analytics server (312), third party integrations (320), and other data sources.
  • as an image element or the like associated with a statistics element so that when the statistics change so does the image in the image element.
  • the platform (20) may draw from images of players stored in the database (308) and associated with an identifier that relates the images with a statistics identifier such as a name, player number, position, etc. [0308] Advertisers, sponsors, and other organizations may use statistics to distribute digital offers via the interactive DEP.
  • a rule may be written to allow a sponsor offer to be unlocked, pushed, pulled, or the like if the home team scores 20 points in the first half, or if the home team intercepts twice during the second half, or any other conditions that an advertiser or sponsor may want to tie their digital offer to. Further, the advertiser et. al. may want only certain users to receive their offer.
  • the rule may also include a second, third, or fourth metric (as was explained with respect to FIG.5), to limit distribution to a certain segment of the user population.
  • Data may be gathered and analyzed with respect to a wide variety of topics. Taking the zoo for example, statistical information may be distributed within the interactive DEP among other content, be put in a “trivia” form, gathered onto one or more dedicated pages, any other layout option, or combinations thereof.
  • the statistics may relate to animals (e.g., gestation period, life span, estimated numbers in the wild, conservation efforts, feeding habits and amounts), habitats, global warming impacts, and the like or to the zoo or zoos in general such as the average number of visitors per day, week, year, etc., daily, weekly, yearly, etc., costs to run, number of employees, ranking compared to other zoos, area attractions, or other similar type of data.
  • Non-fungible tokens Many proprietors are taking advantage of the ability to tokenize memorabilia, collectables, and the like as a way for users to commemorate their participation in and/or attendance at an event. Generally, an NFT is associated with subject matter (digital or physical) that is perceived to have some value. The NFT may record a transaction relating to the subject matter on a blockchain such as a distributed ledger.
  • the subject matter itself, and the metadata may be stored elsewhere such the interplanetary file system (IPFS).
  • IPFS interplanetary file system
  • Proof of the transaction e.g., purchase of the NFT
  • a digital wallet e.g., 24a, 24b
  • the NFT feature/module (1618, 1724) allows event and/or remote users to acquire an NFT whether it be through a purchase, an auction, freely distributed, or another mode of acquisition.
  • a business may sponsor an NFT to be given away to only those people who purchased tickets for certain seats.
  • the platform (20) may query data sources such as the database (308), third party integrations (320), or any other data source to determine if the user device (14a) that scanned the tag (16a) identifying the “winning” seat (208) belongs to the ticketholder for that seat (208).
  • the platform (20) may check to see if there is information associated with the unique ID for the device (14a) and a ticket for the seat identified by the tag ID such as a digital ticket on the device, a ticket purchased via a third party, a paper ticket that can be scanned and confirmed or the like.
  • a proprietor may grant the first 100 fans that have scanned an in-venue tag (16a) an NFT for the interactive DEP.
  • the platform (20) could gather data from the user devices (14a), the geofence (316), and the time (318) to ensure that only the confirmed 100 devices are enabled to acquire the NFT.
  • user 101 and beyond may receive a message that the offer has expired or the like.
  • the city zoo may offer what appears to be an unlimited NFT of, for example, a photo of a baby animal right after it was born.
  • the zoo may provide different editions of a photo or ownership rights in a photo by limiting the acquisition to those users at the zoo on a particular day, have scanned a tag (16a) by the exhibit with the baby animal, and by patron level (e.g., gold, silver, bronze, none).
  • patron level e.g., gold, silver, bronze, none.
  • the platform (20) would verify all of the metrics/triggers to enable NFT acquisition to only those users who have satisfied the rule and how they have satisfied the rule (e.g., patron level, if any) so that the users are only aware of the subject matter for which they qualify per the rule.
  • NFT feature/module (1614, 1730) the ways to incorporate the NFT feature/module (1614, 1730) into an interactive DEP are only limited by what a rule and associated metrics/triggers dictate if a rule is even used to limit the acquisition of an NFT.
  • Wagering Although wagering, betting, or the like may be more applicable to sporting events or the like, a wagering feature/module (1616) may be adapted to enable proprietors to offer raffles, prize drawings, and other enter-to-win type prizes (1726). Thus, a wagering feature/module (1616, 1726) is not limited to sports betting or the like.
  • an interactive DEP may have a selectable option (1616) to launch one or more pages dedicated to wagering or the wagering feature (1616, 1726) may be distributed throughout the interactive DEP such as with statistics, on a player page, or other similar setting.
  • wagering is related to sports betting or the like, the wagering may be limited to the game in progress, related fantasy sports, or the like, although embodiments are not so limited.
  • a third party integration (320) may be employed with one or more vetted gambling venues are available to the user. To be able to use such a third party integration, the platform may first determine, or attempt to determine that the user device (14a, 14b) is being operated by a person who is of legal gambling age.
  • Third party gambling venues proprietors, advertisers, sponsors, ticketing agents, or others may provide gambling opportunities as incentives for their products.
  • ticketing agents may offer a gambling credit (to qualified users) for expensive seats or hard-to-sell seats
  • gambling venues may (320) provide a gambling credit to certain sections, seats, or other grouping, as two nonlimiting examples.
  • a third party gambling venue (320) may randomly select a winning seat, a winning tag (16a) scanned (e.g., at [310]) for the event or the like, where the winner gets free beer for the entire game, a gambling credit, or similar type of prize.
  • the platform (20) may seek to verify that the device (14a) that scanned a tag (16a) identifying a qualified/winning seat belongs to the person that purchased the ticket for the seat as was described with reference to NFTs, and that the person is of a qualified age (e.g., 21), as was described with respect to FIG.5.
  • the interactive DEP may provide an avenue to placing live or in-play wagers while being able to see real time statistics, odds, and the like all while an event is in progress and by the scan of a tag (16a, 16b).
  • the platform (20) may randomly select a winner using data associated with a unique ID or the like.
  • a server may randomly select a unique ID associated with those users who opted to enter to win.
  • a notification may be sent to the user device (14a) associated with that unique ID.
  • a zoo employee may have a “verification code” on a handheld device or the like that the user device(14a) has to scan to confirm that the unique ID for the user device (14a) that scanned the verification code is the same as the one that was selected to win. If the unique IDs match, the user holding the device (14a) may collect the prize.
  • Real time polling and other types of audience participation events may be on an individual basis or a group basis.
  • the platform (20) may take individual polling responses in each section, 222, 224, 226, determine the answer with the highest frequency, and assign that answer/response to the section as a whole.
  • polling activities may be based on a grouping of tags (16a, 16b) instead of individual tags (16a, 16b).
  • Group polling activities are not limited to averaging or the like; they may occur via alternative mechanisms.
  • Such polling is not limited to sporting events; any event or venue may offer real time participation activities that appeal to their particular audiences.
  • the city zoo may have a “vote now” (1728) or other adaptation of an audience participation feature. Since zoo visitors are typically widely dispersed, results of polling may be tallied at the end of a predetermined time and sent to the user device (14a, 14b) [0318]
  • Upcoming Events Many event programs include a listing of events that are scheduled for a given time (e.g., season, year, month, etc.). Traditional paper programs typically only included a list of events to be held at a particular venue (202), although sometimes they may list events to be held nearby such as within the same city or other geographical area. Thus, a listing of upcoming events tends to be thought of as static list.
  • the upcoming events feature/module (1620, 1708) of an interactive DEP is dynamic at least by being able to reflect changes to event line ups as they are noted in a data source from which the list draws information.
  • the interactive DEP as described herein may customize a listing of upcoming events for a particular user. For example, the unique ID and data aggregated therewith may give insights into what type of events a particular user enjoys.
  • the user may receive a listing of upcoming events that weighs heavier on these types of events even though the user is presently at a sporting event and looking at the corresponding sporting event interactive DEP.
  • the platform (20) may use the unique ID to determine where the user is primarily located geographically so that if the user scans a tag (16a, 16b) outside of his/her primary geographic location the platform (20) may use the unique ID, associated data, and other data to provide a customized list for the user’s current geographical location that corresponds to the time that the user is estimated to be away from his/her primary geographical location, a customized list for the user’s primary geographical location and after the user is estimated to return, or both. And if the platform (20) determines that the user who scanned a tag (16a) such as for a sports team that is not at the sports team’s home arena, the user may be able to select between an interactive DEP for the home team or for the away team.
  • the user may be able to keep up with information relating to his team of preference.
  • a listing of upcoming events may relate to locations where the team, company, ensemble, or the like is next appearing.
  • the user may be able to use the interactive DEP (e.g., other [1626]) to link to a third party ticketing broker via a third party integration (320) to purchase tickets at the out of town venue.
  • the interactive DEP provided by the city zoo includes a special days/daily special feature/module (1708). This is essentially the same as upcoming events (1620) described above.
  • the daily specials may provide dynamic content such as a video, an article, or other updatable element to inform users about a unique activity happening at the zoo that day such as a special exhibit, NFT raffle, face painting, as just a few examples.
  • Special days may relate to upcoming holidays, days with a special theme or activity, extended or reduced hours, fundraisers, or any other special day.
  • These types of interactive DEP elements may only be updated every so often, but the fact remains that they are still dynamic.
  • the proprietor does not have to print a new list if something changes--it is a simple update of data that will automatically bring the new listing to users via the interactive DEP.
  • the zoo too can provide a customized list of upcoming events as was detailed above with respect to the game day program (1600).
  • Contactless transactions Users, whether at the event or remote, may take advantage of one or more interactive DEP features/modules that enable contactless transactions such as ordering food (1624, 1734), merchandise (1622, 1736), tickets (e.g., other [1626, 1732]), or the like.
  • the platform (20) knows which tag (16a) was scanned by the user device (14a) via the tag ID.
  • the in-venue vendor may deliver the purchase to the user at the location identified by the tag (16a), such as the user’s seat or another location specified by the user when the order was placed.
  • the user may opt to pick up his/her purchase at the vendor location after placing the order, receiving a notice that the order is ready, or other such messaging/notification.
  • Remote users may still be able to take advantage of contactless transactions via the interactive DEP.
  • a remote user may be able to connect to participating local eateries to have food delivered.
  • the platform (20) may use a data associated with the users device (14b) including data associated with the unique ID assigned to that remote user device (14b) to determine the user’s primary location or exact location (e.g., GPS), use third party integrations (320) to access participating vendors in the remote user’s geolocation, and allow the user to place a food or other order to be delivered to the user’s location.
  • remote users may also make in-venue purchases for merchandise (1622) or other non-perishables that can be delivered to an address provided by the remote user via the interactive DEP, connect to in-venue or third party ticket providers to purchase ticket for one or more upcoming events or other similar transactions.
  • In-venue retailers may be able to take particular advantage of the interactive DEP. For example, digital offers can be sent to user devices (14a, 14b) via the game day program (1600, 1700).
  • the customized offer could BOGO hotdogs.
  • Such information can be encoded through a third party integration (320) that generates and automates this information.
  • the total inventory of food or beverages may be displayed to an in-venue user or can be accessible to a manager of the concessions so as to effectively manage the operations for the venue.
  • the merchandise portion of the interactive DEP may be linked, via a third party integration (320) to the POS to the team store. This would allow for dynamic pricing of merchandise based on information from the POS.
  • the platform (20) may generate a digital offer for a discount to purchase merchandise.
  • a player, zoo animal, or the like celebrated a milestone, such as player scoring his 10,000th point, a zoo animal being the first of its kind to be born in captivity, or other such milestone, a dynamic digital offer in the interactive DEP may change to advertise the discounted merchandise.
  • NFC applications such as, for example, contactless transactions are expected to be the most widely adopted form of mobile payments.
  • advertising and/or digital offers may be unlocked, released, ungrayed, or the like per one or more rules having one or more metrics/triggers associated therewith as is described with respect to FIG.5.
  • Digital offers may be loaded directly into a digital wallet (24a, 24b) or may be tapped to be downloaded to a digital wallet (24a, 24b).
  • the user may download “VIP Card” or the like to their digital wallet (24a, 24b).
  • the proprietor, advertisers, sponsors, or the like may then use the VIP Card to send notifications to the user about venue/event promotions, updates, or any other information to the user device (14a, 14b).
  • an interactive DEP obtained by scanning an in-venue tag (16a) may include an advertising space (e.g., in only in-venue versions of the interactive DEP) linked to a specific in-venue retailer.
  • the individual may select individual a digital offer and download it to her/his device (14a, 14b).
  • the digital offer may be linked to the unique ID for the device (14a, 14b), a unique certificate, or the like to track sharing. If the user transfers the digital offer to, for example, five other devices within a fixed time period such as, for example, a week, the digital offer automatically upgrades so that when the user goes to redeem the offer, the offer has been increased from 10% to 20% off. This capability offers further incentives for users to transfer their digital offers to family and friends so that they will receive greater discounts.
  • this capability will allow brands and retailers to watch their promotion go viral from a first point of download (e.g., via the interactive DEP) to various locations where the digital offers are transferred between various user devices.
  • Some digital offers may be shared and tracked via NFC, MMS, SMS, social media such as Facebook, Twitter, Snapchat, etc.
  • digital offers may be browser based, stored in a digital wallet (24a, 24b), or both.
  • a digital offer, advertisement, or other dynamic content may be made available to users based upon the fulfillment of one or more metrics/triggers or other condition to satisfy a rule.
  • a rule may be written to allow dynamic content to be released at or near the end of the event, if a particular team wins at a sporting event, if one or both teams at a sporting event scored a predetermined number of points, if a particular metric, trigger, or the like occurred such as a touchdown, a homerun, a stolen base, a 3point shot, etc., or any other conceivable metric, trigger, condition or the like, or combinations thereof.
  • a rule or other instructions may be written so that a third party advertising integration (320) may check on another third party integration (320) such as statistics, to see if a metric, trigger, condition, or the like has occurred (e.g., the quarter back threw a record number of touchdown passes), which would then release the digital offer for user consumption.
  • a metric, trigger, condition, or the like e.g., the quarter back threw a record number of touchdown passes
  • advertising, digital offers, and the like in the interactive DEP may also be customized in a manner that is the same as or similar to customization described with respect to FIG.5.
  • conditions, triggers, metrics, or the like may be used to generate specific and tailored information, offers, and content based upon the particular user information and actions of the user that may be associated with the unique ID.
  • the unique ID may be used to determine the type of content that the user typically views on the user device (14a, 14b) and display an advertisement, digital offer, or the like based on that user’s unique history. Additionally, advertisers, sponsors, or the like may want their content to only be displayed in the interactive DEP to users who fit their demographic profile. As such, unique IDs may be used together with other available information to deliver the designated content to just those users. Alternatively, user demographics may be assumed based on where the user is sitting or otherwise located at an event. In this way, advertisements, offers, and other content relating to luxury items may be distributed to only those users who purchased seats that are indicative of the ability to purchase such luxury items.
  • different versions of an interactive DEP may receive exclusive content, digital offers, advertisements, etc., based on the perceived preferences for users sitting in those seats. It may be perceived that younger users will sit in discounted areas of a stadium, buy cheaper tickets to concerts, or the like and as such, advertisements, offers, and other content may be included in the interactive DEP version for such a grouping. At the other extreme, it may be believed that only those users with large disposable incomes will spend the money for expensive seats, locations, or the like and so content, including advertisements, digital offers and the like for high-end items may be included in the version of the interactive DEP to be distributed to that grouping. In this way certain exclusive content may be offered to different versions of an interactive DEP.
  • content, advertisements, and the like may in some instances be customized based on information associated with a unique ID.
  • a young person may be extremely wealthy, but likes to sit in discount seats.
  • the interactive DEP distributed to that user device may be a version that is the same as or similar to one to be distributed to expensive seats.
  • advertising space in an interactive DEP may be limited, it may be more valuable.
  • advertising, offers, and other purchased content time/space may be priced accordingly. For example, advertising to be distributed to a grouping including expensive tickets for the event may cost more than to a grouping including cheaper tickets. Additionally, pricing for an event that is more exclusive may also cost more to the advertiser, sponsor, or the like.
  • the cost to advertise in a particular version or all versions of an interactive DEP may also be dynamic.
  • advertising space and the like may be sold on a “pay per click” basis, such as by the number of tags (16a, 16b) were scanned at a particular event, on a particular day, in a given time frame or the like, by the number of digital offers that were downloaded, by the number of digital offers that were used, or any other trackable pricing scheme.
  • Advertising space may also be sold on a tiered basis. For example, advertising on a home page, or top features/modules viewed may have one cost level, which decreases as the determined usage of the feature/module decreases.
  • advertising, digital offers, and the like may be dynamically moved during the event if the feature, module, page, etc. that receives the most usage during a particular event is different than what is expected.
  • an advertiser may pay for a space on the first page seen for an interactive DEP, but a replay of some exciting action is being viewed by most of the users and they are skipping over the first page.
  • An administrator may be able to move the content to the page that is in actual use, or it may happen automatically, thereby ensuring that the paid for content is in fact being displayed per the purchase plan, price, etc. [0334]
  • Eventually the event will end, even if it is a daily event such as a zoo, museum, or the like.
  • connection to the interactive DEP is also cut off.
  • the interactive DEP may continue to be used use by the user.
  • the proprietor may opt to have the interactive DEP maintained by the platform (20), and as such it may function much like a traditional web site, but one that is only available to users who have previously scanned a tag (16a, 16b) for the interactive DEP during the event. In this way, proprietors may stay in communication with their customers (i.e., event users, remote users) an updated the interactive DEP latest content, offers, etc. on an ongoing basis.
  • the proprietor may keep one or more “expired” (i.e., for an event that is over) interactive DEPs as a historic document such as for a season, keeping certain content, offers, etc. static while providing new dynamic content.
  • a historic version of an interactive DEP may provide recaps (video, images, text) of the event or related sequence of events (e.g., over a sports season), change or reup digital offers, keep certain digital offers open for subsequent use, among other possibilities.
  • Keeping a historic document will not interfere with a user being able to scan the same tag (16a) at the venue to receive the latest interactive DEP as each DEP has a different URL, ID, etc.
  • Proprietor Administrative or other Administrative Activities Proprietors may manage their network of tags (16a, 16b) using the proprietor portal (FIG.3, [322]).
  • proprietor portal (322) is software suite running on platform (20). The proprietor may access the portal (322) via a Web browser, other application, or both executing on the administrator device (FIG.1, [12]).
  • the interface for the proprietor portal may be one or more browser-based Web pages, a Web-based application, a progressive Web application, a downloadable application, a native application, and a cloud-based application (to name just a few examples), which may be delivered to the administrator device (12) by the redirect/identification server (302).
  • the proprietor may be able to view and manage various aspects associated with the proprietor’s venue, event, network, etc. including viewing the real-time status of all tags (16a, 16b), interactive DEP templates, URLs, content, and more.
  • the analytics server (312) may retain device (14a, 14b) requests and/or data from past user interactions with one or more tags (16a, 16b), including interactions assigned to individual user devices (14a, 14b) and/or collective interactions of some or all user devices (14a, 14b).
  • the analytics server (312) may also incorporate third party data from outside sources third party integrations (320), blockchains (314), and others.
  • the analytics server (312) may run software to analyze collected data from some or all of the forgoing to help optimize what a particular user experiences through his/her interactive DEP.
  • analytics server (312) may use information from cookies, log files, page tags (e.g., JavaScript code embedded in Web pages), associated with a unique ID, and combinations thereof for reporting to the interface server (306), administrator server (310) or the like.
  • some or all of the administrative tasks may be performed by a platform (20) administrator via administrator server (310).
  • a platform (20) administrator may be called upon to write rules for one or more versions of an interactive DEP, especially when the rule(s) need to be written in a specific coding language that the proprietor is not familiar with.
  • Typical administrative activities associated with a network of tags (16a, 16b) include those relating to tag (16a, 16b) management, creating, updating, managing interactive DEP templates, reporting, and more.
  • tag (16a, 16b) management creating, updating, managing interactive DEP templates, reporting, and more.
  • the examples detailed herein are for illustrative purposes only and are not intended to limit how a proprietor may choose to view, manage, generate, store, or otherwise manipulate data. Additionally, it should be realized that the actual proprietor may not be performing administrative or other such tasks. Typically, these are handed off to agents, employees, or other representatives of the proprietor. In some circumstances, stadium officials may be able to access the proprietor portal (322) from a handheld device such as a smartphone, tablet or the like so that they may perform certain tasks on the go.
  • Tag management may include tasks such as, without limitation, assigning each tag (16a, 16b) in a network to a distinct point of interest, creating tag groupings, assigning an employee to one or more tags or groups of tags, and additional tasks. Assigning each tag (16a, 16b) to a distinct point of interest includes linking the tag ID to the distinct point of interest so that when the tag (16a, 16b) is scanned by a user device (14a, 14b) the point of interest is known via the tag assigned thereto.
  • the interactive DEP may include a reference to the point of interest it is associated with such as “This Game Day Program is for seat 1, row A, section 100” or something similar thereto. If tampering is a problem, the user may even be required to confirm that the tag (16a) scanned corresponds to the seat or other point of interest before the interactive DEP is displayed on the user device (14a).
  • the proprietor may also group tags (16a, 16b) via the proprietor portal (322).
  • Tag (16a, 16b) grouping is flexible to meet the needs of the proprietor at any time. Thus, tags (16a, 16b) may be grouped, regrouped, sub-grouped, etc. on demand.
  • Grouping tags (16a, 16b) may be advantageous for many reasons. As one nonlimiting example, tags (16a, 16b) may be grouped to deliver different versions of interactive DEPs to different users such as those in the venue, remote from the venue, and other such grouping which have been detailed herein. Although grouping tags (16a, 16b) enables certain activities to belong to the grouping such as content pushed or the like, each tag (16a, 16b) remains autonomous e.g., the platform (20) still knows which particular tag (16a, 16b) was scanned by a user device (14a, 14b) and it knows to which group the particular tag (16a, 16b) belongs.
  • scanning a tag (16a, 16b) does not always result in the loading of an interactive DEP on a user device.
  • the proprietor can associate each tag ID with an endpoint outcome such changing certain phone settings, creating and sending a text, launching an application other than one associated with an interactive DEP, turning on device via Bluetooth or any number of commands to be executed, limited only by the communication device.
  • Another endpoint outcome may be to redirect the user device (14a, 14b) to a Web page/Web site other than the interactive DEP such as one for a particular advertiser, sponsor, organization, or the like.
  • This type of redirection may occur at different times during an event so that if a user scans a tag (16a, 16b) for the first time or if the user rescans the tag (16a, 16b) during the event, the user device (14a, 14b) will be redirected to the advertiser et. al.’s page instead of the interactive DEP. In this way, multiple different advertisers can utilize the plurality of tags (16a, 16b) during the event.
  • the endpoint outcome may also be loading a version of the interactive DEP on the user device (14a, 14b).
  • the proprietor may log in to the proprietor portal (322) to access one or more Web- based templates for a given interactive DEP.
  • the proprietor may choose a format (e.g., like the game day program [1600] or the book-like program [1700]) and drag and drop placeholders for features, elements, content, etc. in the template to correspond with a desired visual layout. For instance, placeholder for an article may be dragged and dropped on a particular page and in a particular location on the page. Other placeholders for surrounding content such as images, video, advertising, etc. may also be dragged and dropped as desired.
  • This flexible approach may be handled in-house, which also enables the proprietor to alter the template at any time, even during the event. Further, it is easy to create versions of the interactive DEP from such a back-end template driven approach.
  • the same basic layout may be used for several different versions of the interactive DEP for the same event.
  • the proprietor may assign different content to go with the different versions and make other tweaks to a particular version of the interactive DEP. Of course, the proprietor may always create a completely different format, layout, or both for a version of the interactive DEP.
  • Assigning different content to different placeholders may be as simple as causing the placeholder in one version to be linked to one advertisement, image, NFT, or the like, and the placeholder in a second version of the interactive DEP to be linked to a second advertisement, image, NFT, or the like.
  • a link to content may be via a URI such as a URL.
  • the link may lead to a third party integration (320), which may utilize one or more APIs, although embodiments are not so limited.
  • content may continuously be delivered to the interactive DEP via the third party integration.
  • a template placeholder for statistics may be substituted with statistics content in the interactive DEP that is continuously updated , but a third party integration for a journal article may be substituted for its placeholder only one time without additional updates, as is the general nature for journal articles.
  • Actual content inserted into the interactive DEP in lieu of a placeholder may be governed by a rule having one or more metric, triggers, or the like. Savvy proprietors may be able to write their own rules and cause them to accurately function within the interactive DEP.
  • Rules may be written to allow certain content to become available when certain metrics, thresholds, triggers, etc. have been met. Such conditions may be simple, e.g., update every N second, or they may be very sophisticated and complex. Nevertheless, rules, metrics, triggers, thresholds, and other conditions may allow each interactive DEP distributed to users during an event to be highly customized for a particular user. [0343] When a template, its content, rules, etc.
  • the URL for the template may be assigned and attached to a venue (e.g., if the proprietor has several venues), an event, both, a group within the venue (202), a geographical location, a Web page (e.g., for the venue, event, both), a network, a regional network, or any other designation for accurate distribution.
  • a venue e.g., if the proprietor has several venues
  • an event both, a group within the venue (202), a geographical location, a Web page (e.g., for the venue, event, both), a network, a regional network, or any other designation for accurate distribution.
  • the tag ID may be used to redirect the user device (14a, 14b) to the proper template for the interactive DEP for the particular event in which the user is engaged.
  • placeholders may be populated with content for user consumption and dynamically updated such as by content updating instructions including one or more rules.
  • a template allows for easy distribution and simple modification by proprietors.
  • savvy users can modify and use their own forms or unique formatting as necessary for each instance other than rely on a platform (20) provided template.
  • simple formatting such as in a template
  • information including those being captured in a live format from a third party integration (320)
  • drag and drop type creation, which allows for extremely simply modifications.
  • content can be created before an event and continually modified as an event unfolds.
  • the interactive digital interactive program can be mobile first and contain various native features that allow for an engaging fan experience.
  • Proprietors have the ability to monitor their network of tags (16a, 16b) via the proprietor portal (322) viewing data in various graphic forms such as graphs, charts, diagrams, etc.
  • the proprietor may monitor the status of points of interest (e.g., via the network of tags) in real time as the event is in progress. In this way, the proprietor may see how users interact with tags (16a, 16b) and can make any adjustments as the proprietor sees fit.
  • the proprietor may manually update content based on data collected, feedback received, and the like. If a change is made to a template while the event is in progress, the change is automatically applied to the interactive DEP on the user device (14a, 14b).
  • a proprietor may want to receive feedback from users.
  • User input may be a valuable source of information for a wide variety of purposes such as determining user satisfaction.
  • a feedback feature/module may be placed in the interactive DEP so that users can submit comments directly to the proprietor. Such feedback may be in the form of fillable fields, surveys, written comments, or combinations thereof.
  • a proprietor may also run reports utilizing the proprietor portal (322). For example, the proprietor may view information relating to overall usage statistics, group statistics, individual tag statistics, statistics about which features/modules are used the most, if they are used more on one page versus another page, and much more.
  • the proprietor may even be able to run a report on tag usage across several events, venues, or the like. Usage reports may be configured for information such as the number of times a given tag has been scanned by any user during a period of time (e.g., day, week, hour, etc.) or the number of times any tag has been scanned by a particular user during a period of time, or many other ways in which a proprietor may want to analyze the data.
  • the name can simply be the seat information for that user.
  • someone sitting in seat 1, row 1, section 101 could be S1R1S101 – or another variation of the same.
  • This will allow for users to immediately understand where they are on a scoreboard without having to create an entry or profile.
  • This information can be utilized for both in-venue and for external 3 rd parties. I believe there is a lot of value in both using that seat data inside of our own platform, and passing that data to 3rd parties, as a naming convention/username. So players would not have to sign up for accounts or create their own username in order to be placed on a leaderboard.
  • this seat information can be used for easy distribution of purchases, whether that is concessions, novelties, or other.
  • this convention/username can be the tag ID, or a portion of the tag ID, or a completely separate set of numbers and/or letters can be the tag ID and associate the same with the username within a database.
  • the username can be associated with a unique ID, so that if John frequently sits in seat 1, row 1, section 101 at baseball games, the system will understand that John likes to play trivia and know his back scores at that seat.
  • This provides another avenue for the system as a whole to gather information about a given user. The end goal is that upon obtaining information from users, the system can implement one or more rules corresponding to the user, i.e., at the unique ID level, or at the seat level, to a section level. These can be performed by the controller pushing certain rules and then content to these users. Furthermore, this will allow for the creation of more, complex rules that can provide unique opportunities for fan engagement.
  • a complex rule may include features such as where you are sitting, the number of times you attend games, the trivia or other events you participate in, your ticket purchase history, your concession history, your novelty history, your wagering history, purchase of NFT’s or ownership of an NFT, etc.
  • the aggregation of data regarding the user base allows for the system and the teams or venue operators to identify trends and to provide content to users who are not participating in a similar manner to similarly situated users. The goal remains to create improved fan engagement and fan enjoyment opportunities.
  • EXAMPLE 2 it may be advantageous to send a user an e-mail or push a text comprising their MRC with a tag ID before or after attending an event.
  • a user may want to pre-order food to their seat, pre-order concessions, or to engage with the team or venue in ways that are not previously available.
  • wagering on the game is provided and in certain of these venues, there may be sections within the stadium wherein benefits are provided based on the particular section or seat.
  • the venue can offer a dynamic offer capability based on seat pricing, sports book tie into API offers based on price of ticket.
  • a sports book is seeking to pre-sell value at the sports book for the game.
  • the sportsbook can pre-sell seats/tickets that include a voucher or value within a wagering wallet tied to the unique ID and tag ID for the wagering wallet.
  • the sportsbook first offers a $500 ticket with a $100 to get me to gamble. However, after the first game, only 10 seats were purchased for this situation. By contrast, in a separate section, the sportsbook offered a $50 ticket only need to give me $10. Interestingly, this sold 750 seats. Thus, the sports book provided $1000 to the 10 seats at the $500 level, and $7500 for the 750 seats at the lower level but obtained many more touches with the wagering system for the lower level award. This could mean a lot of different things for purposes of seeking to engage with bettors. [0355] For example, it may mean that higher value bettors already have accounts and place wagers, without the need to entice the purchase.
  • the sportsbook can modify this offer, and offer $250, or $500, or even $1000 or more for the $500 seats. Sportsbooks typically prefer to entice “whale” bettors, or those who will place larger wagers, as compared to many smaller bettors. However, this is not the case in all scenarios.
  • the seat can be tied into a third-party ticket provider as well as a sportsbook to identify the payment terms, exchange of the value and fulfilling of the dollars into a wagering wallet. These offers can be modified per game, or on a live basis.
  • a seat may be offered in the premium wagering section during the game.
  • the seat may be a premium seat and contain $500 wagering credit, for $1000.
  • a user can upgrade their seat, by exchanging their seat to obtain the new seat and wagering offer.
  • the old seat can then be placed back for sale for subsequent sale or exchange with another user who desires the now empty seat.
  • These offers and opportunities can fluctuate based on price of seat, availability, in-game metrics, etc.
  • the pricing may change before the game starts. For example, the price may increase or decrease as it gets closer to game time, or the credit can be adjusted up and down.
  • the platform can be used in a medical setting such as a hospital where a user can scan a tag with a QR code that is located on the bed, the tray or anywhere else in the room to place mobile order.
  • the tag ID is associated with the room number or any other convention adopted by the hospital.
  • the system/platform is able to identify that the device that scanned the tag is located in a specific room similar to the way the system/platform is able to link users to locations in venues described in detail herein. Hospital settings, long term care, and other places that have many rooms and patient needs, frequently have needs to rapidly assist patients and to ensure safety.
  • a user device can scan a tag within the system.
  • the user can then have the tag ID corresponding to the room number and match that tag ID with the unique ID on the user device.
  • This allows for a simple mechanism to identify the venue, location, and who scanned the tag ID.
  • a user through scanning a tag via a user device can give feedback in real time about the experience of staying at hospital, report issues, request things, engage with staff, etc.
  • the system can be used to assist with scheduling and communication with patients. Because the user device, after scanning, can receive a template or a DEP, information can be dynamically pushed to the user device. Thus, the user can schedule activities, schedule meetings and appointments, receive updates on their appointments, etc.
  • the user device can be used to control certain electronic components within the room, as simple as the tv and volume, or can control and request things, such as a robot for order and delivery of foods, medicines, and other accessories.
  • the system can then utilize the unique ID tied to the user to provide for necessary feedback, information and the like, based upon the needs of the user.
  • EXAMPLE 4 [0361]
  • the system/platform can also be implemented in a parking garage or parking lot.
  • an NFC or RFID chip can be imbedded in the concrete or other parking surface or a QR or bar code can be painted or otherwise displayed on top of the parking space surface.
  • the system can be used to automatically charge the user for the time the user’s vehicle is parked in the space.
  • the system can charge the user for wireless charging of the user’s electric vehicle which is paid on entry if the parking garage is equipped with charging stations.
  • parking spaces will need to increase the charging opportunities and to pay for the same, provide updates as to charge, etc.
  • a tag employed at a parking spot can allow a user to identify their user device through a unique ID, identify their car, either by creating an account or scanning, for example the VIN number or the license plate. This information can then be pulled from an API to identify the make, model, owner, etc. of the vehicle, or it can be provided, if needed.
  • the user can pay for any charging or services desired through the user device. [0362]
  • the charging may be desired, but also washing the car.
  • the system can then identify when the vehicle is fully charged and then move the vehicle to the washing location and notify the owner through the user device, when both the charging and the cleaning are complete.
  • the user can pre-pay for these services and even plan them, so that, for example, the work is complete by 1:00 if the user has to leave, or by 5:00 or a different time, based on the user’s needs.
  • EXAMPLE 5 [0363]
  • the system can push content that is a video replay or live video, audio, augmented reality or virtual reality feed.
  • users often desire the ability to see all the action that may be occurring at a different spot or from a different view. This is often an issue in venues that have multiple stages or vantage points.
  • the user can quickly swap to the camera view on a section different from their vantage point. This can also be done for patrons at a golf event, where they can sit at hole 9, but watch the tee shots at all other holes, by accessing the video fee for those tees. This is also a common issue at tennis tournaments, where a user can only watch one match at a time. By accessing video feed, the user can be in the stadium, but watch the matches on, for example, court 18. [0364] Thus, a user can scan a tag, for example on their seat, or on their ticket or their badge and receive access to a video playback feed. This may be presented in the DEP, or in another GUI as provided by the various embodiments.
  • the user’s desire to have services provided for them for a fee.
  • Such services are typically “VIP” like services, and may be provided for free for certain individuals, or paid for with the purchase of certain tickets or won through opportunities.
  • VIP virtual private polymer
  • a user can upgrade to certain access or treatments, buy a ticket to upgrade to the same, or access such treatments by winning experiences through the system.
  • One examples is a venue wide contest, such as a trivia contest, a scavenger hunt or the like. Where the users have to perform and ultimately win some prize.
  • the prize may be a VIP treatment, or back-stage access, or locker room access, etc.

Abstract

A system for aggregating data in response to detecting that a device scanned an encoded tag comprising: a server system having a computer processor, memory, and one or more applications thereon; databases operatively connected to the server system which store a venue ID, event ID, target ID assigned to a Web application, tag ID corresponding to a point of interest, an ID assigned to the user device, and recorded data linked to one or more of the foregoing IDs. The server system executes code to: receive a request from the user device in response to scanning the tag together with the tag ID; receive the unique ID from the user device; use the tag ID to identify the venue or event; determine a target Web application ("TWA") and redirect the user device thereto; and record each action taken with respect to the TWA, linking those actions to one or more of the aforementioned IDs.

Description

DATA AGGREGATION
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of US Provisional Patent Application No. 63/363,597 filed on April
26, 2022, with the United States Patent and Trademark Office, the contents of which are incorporated herein by reference in their entirety.
FIELD OF THE INVENTION
[0002] The invention is related to systems and methods for delivering content to users through a system comprising machine readable codes defined on a tag; and wherein users engage with the system with a user device, wherein the system aggregates data from the user device to populate dynamic content to the user.
BACKGROUND OF THE INVENTION
[0003] Use of smart phones and other handheld computing devices has allowed users to be in control of the content they receive. However, many users remain stuck in the same content, often called the “echo chamber” and thus they do not see or receive content that may be of interest to them. This is a problem for marketing, in which a portion of the Hable population may not see content of interest. This is also a problem for users, as they miss out on the interesting/desirable content.
[0004] Applicant has detailed an elegant solution using a system and methods to aggregate data and push content through a user device, based upon a system of tags comprising a tag ID and matching a scan of a tag to a user device compnsing a unique ID; wherein actions by the user device are stored in a database and can be mined to determine content that is of interest to a user/group of users; to generate/evaluate tag groupings, campaigns, or the like; to define rules or other devices to push data to user devices, or combinations thereof.
SUMMARY OF THE INVENTION
[0005] The present invention is a system for delivering content to users only when a predetermined threshold has been met by users on the system. Upon the occurrence of that predetermined threshold, the system knows that there are enough users on the system so that the content will have maximum impact. The embodiments detailed herein specifically detail systems and methods for generating content by accessing a machine-readable code (“MRC”). In particular, preferred embodiments generate unique content, and wherein the system utilizes a unique ID to identify a user device within the system. These advantages allow for novel and unique opportunities that are not possible in the prior art. The system includes a plurality of tags, each with a MRC, each of the MRCs encoding a unique address and/or identification number that will direct the user device to a server system. [0006] Thus, the present embodiments are directed to a method and system for aggregating data from a plurality of user devices, wherein the user data is utilized to define a tag grouping corresponding to a similarly situated user device; said tag grouping defining a set of content to be received by all user devices within said tag grouping. [0007] A method for delivering dynamic content to a user device via a machine-readable code comprising: in response to scanning a tag comprising the machine-readable code, receiving a request from a user device and detecting the presence of a manifest packet or locally stored data file comprising a unique ID, wherein if no unique ID is present, creating a unique ID and associating a record with the unique ID within a database; detecting from the tag a tag ID and determining: whether a venue corresponding to the tag ID has been defined; and whether an event is in progress corresponding to the tag ID; redirecting to a default target if no venue exists or no event is in progress, and determining if a tag ID is grouped where the venue exists and an event is in progress; counting, via a counting mechanism, the total number of user devices identified by unique IDs that have scanned a tag while the event is in progress and determining, via the counting mechanism, whether a threshold number of user devices have scanned a tag; upon meeting the threshold number, in response to the detecting from the tag ID, obtaining tag ID group information and associating the tag ID with the unique ID; and associating the unique ID and a unique ID record with the tag ID and redirecting a user to an appropriate target. [0008] The method further comprising: providing a first supplemental content to the user device when the threshold number is unmet and a second supplemental content upon meeting the threshold number. [0009] The method wherein the threshold number is selected from the group consisting of: a total number of unique users on a system at a time t, the total number of unique users accessing a system after a time t, x number of scans corresponding to a unique ID and x number of tags, and combinations thereof. [0010] The method wherein the total number of unique users on the system at a time t is greater than 1,000. [0011] The method wherein the total number of unique users on the system after a time t is greater than 1,000. [0012] The method wherein the first supplemental content and the second supplemental content are provided the user device by: redirection to a new target, a push notification a dynamic element update, unlocking a module, an overlay, a popup, a mobile wallet offer, a video file, a short messaging service, a multimedia service, an email, or combination thereof. [0013] The method wherein the machine-readable code is selected from the group consisting of: a barcode, a quick response (QR) code, a near-field communication (NFC) code, a radio-frequency identification (RFID) code, and combinations thereof. [0014] The method wherein the target is stored within a database and is automatically provided upon the occurrence of the event. [0015] The method wherein the second supplemental content is selected from the group consisting of: a digital offer and an advertisement. [0016] A system for displaying unique content to users at a venue via at least one user device, the system comprising: a server system having a computer processor and computer memory; a plurality of machine-readable codes, each of the machine-readable codes encoding an address controlled by the server system, each of the machine- readable codes being operatively mounted within the venue for access by all user devices in the venue; a counting mechanism operably connected to said server system; and wherein the computer memory of the server system stores executable code, wherein when executed the executable code enables the server system to perform a process comprising the following steps: receiving a request from one user device, the request generated by scanning one of the machine-readable codes with said user device; determining whether a unique ID is associated with said user device or generating a new unique ID to the user device that scanned the machine-readable code and associating said unique ID to a database record; collecting user data associated with the user device and storing the same within the database record, wherein each user device comprises a unique ID; setting a threshold for delivery of unique content upon meeting said threshold, said threshold determined by the counting mechanism; and providing the unique content to the user device upon meeting the threshold. [0017] The system wherein the threshold is selected from the group consisting of: a total number of unique users on the system at a time t, a total number of users accessing the system after a time t, and combinations thereof. [0018] The system wherein upon each subsequent scan of the machine-readable code a new unique content is generated within said server system for delivery to the user device. [0019] The system wherein the unique content is a digital offer or an advertisement. [0020] The system wherein the digital offer is modified by a provider of said digital offer. [0021] The system wherein a digital offer is provided based upon meeting the threshold and wherein said digital offer may be modified based upon meeting a subsequent threshold. [0022] The system wherein the threshold is selected from the group consisting of: an action in a game, a score in a game, a charitable donation, a purchase, a predetermined time, inventory, and combinations thereof. [0023] The system wherein the machine-readable code is printed on a surface. [0024] The system wherein the machine-readable code is embedded within a surface. [0025] The system wherein the machine-readable code identifies a specific location via a known location of the machine-readable code, GPS, or both. [0026] The system wherein the user data is selected from the group consisting of: a date, a time, a GPS location of the machine-readable code, a type of communication device used to scan the machine-readable code, an orientation of a communication device when the machine-readable code was scanned, a type of operating system on a communication device that scanned an interactive code, and combinations thereof. [0027] The system wherein the unique content directs the user device to a Web page, and wherein analytical data from the Web page is collected and consists of data selected from the group consisting of: time spent on a Web page, purchases made, IP address, personal information input by a user, products viewed, cookies, pixels, and combinations thereof. [0028] The system wherein the user device further receives in-venue metrics via an in-venue metrics API and wherein said in-venue metrics are utilized as data or to modify the unique content. [0029] The system wherein the user device further receives third party metrics via a third party metrics API, and wherein said third party metrics are utilized as data or to modify the unique content. [0030] The system wherein the machine-readable code is displayed upon a video board located within the venue. [0031] The system wherein a trigger is related to an action performed by at least one fan in attendance of an event. [0032] A system for generating unique content to at least one user device upon meeting a threshold of users to the system comprising: a server system having at least one server, at least one computer processor, and a computer memory; a plurality of machine-readable codes, each of the machine-readable codes encoding an address controlled by the server system, each of the machine-readable codes being operatively mounted within a venue for access by all user devices in the venue; and wherein the computer memory of the server system stores executable code, wherein when executed the executable code enables the server system to perform a process comprising the following steps: receiving a request from one user device, the request generated by scanning one of the machine-readable codes with said user device; directing the user device to a URL that is uniquely encoded to the machine-readable code; receiving the request at an identification server, determining a result of whether the at least one user device is new or returning, and informing an interface server of the result; generating an unused unique ID for a new user which is stored in a database; receiving an instruction at the interface server from a target determination process regarding digital content to be generated upon meeting the threshold; providing a second URL to the identification server; sending the second URL to the at least one user device; displaying, from said second URL, unique digital content on said at least one user device; obtaining a data from said at least one user device; and upon an occurrence of a trigger, receiving a new URL from said interface server. [0033] A method for distributing different versions of an interactive digital event program corresponding to an event to a plurality of user devices comprising: receiving a request for an interactive digital event program from a first user device, the request received in response to scanning a first tag having a machine readable code with the first user device; determining that the first tag belongs to a first group of tags to which a first version of the interactive digital event program is to be distributed; providing the first user device with the first version of the interactive digital event program, the first version of the interactive digital event program to include at least one dynamic content element that is capable of being updated through a third party integration while the event is in progress; and updating the at least one dynamic content element in the first version of the interactive digital event program in response to detecting an occurrence of a predefined trigger. [0034] The method wherein updating the at least one dynamic content element includes updating dynamic content selected from the group consisting of: a map, a video replay, augmented reality, a fan camera, a fan filter, live statistics, a non-fungible token, wagering, an audience participation activity, upcoming events, merchandise, concessions, a digital offer, or a ticket. [0035] The method wherein the digital offer is unlocked in response to using an in-venue map. [0036] The method wherein additional tags are distributed around a venue and the location of the additional tags is marked on the map. [0037] The method wherein the additional tags are used to facilitate an event wide scavenger hunt. [0038] The method wherein the dynamic content element is for a digital offer, which is downloaded to the first user device. [0039] The method wherein the dynamic content element is streamed live action taking place at the event. [0040] The method wherein the dynamic content element is recorded action taking place at the event. [0041] The method wherein the dynamic content element has an augmented reality object overlayed or embedded thereon. [0042] The method wherein the dynamic content element is for a digital offer, the digital offer linked to the dynamic content element after the event has started. [0043] The method wherein the dynamic content element is dynamically positioned within the interactive digital program to have the maximum exposure to a plurality of users. [0044] The method wherein the dynamic content element is for a digital offer that is synced to advertising shown on a jumbo screen, a televised broadcast of the event, or both. [0045] The method wherein the dynamic content element is for statistics that are updated in real time as the event is taking place, a dynamic image element proximate the dynamic content element to dynamically display an image corresponding to the statistics, or both. [0046] The method wherein the dynamic content element is an offer for a non- fungible token for the first version of the interactive digital program. [0047] The method wherein the dynamic content element is a listing of upcoming events that is customized for the user device based on past event history, primary geographical position, current geographical position, or combinations thereof. [0048] The method wherein the digital offer is a dynamic digital offer based on inventory levels on merchandise available at the event. [0049] The method wherein the digital offer is customized based on version of the interactive DEP and demographic associated with users of user devices receiving the first version of the interactive digital event program. [0050] The method further including updating the interactive digital event program after the event is over. [0051] The method further including updating the interactive digital event program over the course of a season to document a season of events. [0052] The method further including basing the interactive digital event program on a template, the at least one dynamic content element dragged and dropped into a desired position within the template, and wherein the dynamic content element can be modified by an administrator within the template. [0053] The method further including repositioning the at least one dynamic content element in the template while the event is in progress. [0054] The method further including, receiving a second request for an interactive digital program from a second user device, the second request received in response to scanning a second tag having a machine readable code with a second user device; determining that the second tag belongs to a second group to which a second version of the interactive digital event program is to be distributed; and providing the second user device with the second version of the interactive digital event program the second version to include a dynamic content element to be populated throughout the event using the third party integration. [0055] The method where in the first tag is at a venue in which the event is being held and the second tag is on or in a televised video stream. [0056] A method of distributing different versions of an interactive digital event program for a particular event to user devices comprising: designing a template for each of at least two versions of the interactive digital program by dragging and dropping a plurality of dynamic content elements into each template to complete a desired layout; associating each dynamic content element in the plurality with a distinct data source to dynamically update content within the dynamic content element while the event is in progress; assigning each version of the at least two versions of the interactive digital program to separate groups of tags, each tag in each separate group having a unique tag identifier; in response to receiving a request for the interactive digital program from the user device that has scanned a particular tag, determining to which group the particular tag belongs based on the unique tag identifier for the particular tag; sending the version of the interactive digital event program assigned to the group of tags in which the particular tag belongs to user device that sent the request; and causing the distinct data sources to populate the associated dynamic content elements in the template for the sent version of the interactive digital event program and at the content of least one of the associated dynamic content elements to be updated during the course of the event in response to a predefined trigger that has occurred in the event. [0057] A system for providing an interactive digital event program comprising: a plurality of tags, each tag in the plurality having a machine readable code and a unique tag identifier; a server having a computer processor and a computer memory; a database operatively connected to the server, the database including information relating to each tag in the plurality of tags, the information relating to each tag including: the unique tag identifier; a group identifier to identify a group to which the tag belongs; and a template for an interactive digital event program to be distributed to the group in which the tag belongs; and wherein the computer memory of the server stores executable code, which when executed enables the server to perform a process comprising: in response to receiving a request from a user device, using the unique tag identifier to identify the group to which the scanned tag belongs; populating the template for the interactive digital event program to be distributed to the group in which the tag belongs with one or more dynamic content elements; sending the populated interactive DEP to the user device that sent the request; and updating the content of at least one dynamic content element in response to detecting a predefined trigger based on activity within the event that optionally occurred during the event. [0058] The system wherein updating the content of the at least one dynamic content element includes pushing updated content from a third party data source to the at least one dynamic content element in response to detecting the predefined trigger. [0059] The system wherein the predefined trigger is a pause in the activity and updating the content of at least one dynamic content element includes pushing updated content from the third party data source in response to detecting a pause in the activity. [0060] The system wherein updating the content of at least one dynamic content element includes unlocking content in response to detecting the predefined trigger. [0061] The system wherein the predefined trigger is a threshold number and dynamically updating includes detecting that the threshold number has been reached unlocking the content in response to reaching the threshold. [0062] The system wherein the content of the at least one dynamic content element is subject matter associated with a non-fungible token (NFT) and updating the content of at least one dynamic content element in response to detecting a predefined trigger includes unlocking the subject matter in response to detecting predefined trigger to enable acquisition of the NFT. [0063] The system wherein the interactive digital event program continues to be updated after the event ends. [0064] The system wherein the database stores plural identifiable images and the server selects an identifiable image to display in association with the at least one dynamic element. [0065] The system of claim 51, wherein the at least one dynamic content defines an augmented reality video. [0066] The system wherein the MRC is located within a video stream; wherein the unique tag identifier is utilized to determine which DEP to display to said user device. [0067] The system further comprising a geolocation determining, wherein the location of the user device is defined within a rule within a tag group to alter the DEP directed to said user device. [0068] The system wherein the venue is selected from the group consisting of: a school, a cultural event location, a zoo, a music venue, and combinations thereof. [0069] The system wherein the dynamic content element is connected to a third party API, and wherein the third party API disseminates the dynamic content upon the occurrence of a trigger. [0070] The system wherein the tag grouping defines a version of the DEP displayed to said user device. [0071] The system further comprising wherein a camera defined on a user device captures video, wherein the captured video is uploaded into a the DEP and the captured video is released as the dynamic content element. [0072] The system further comprising wherein the dynamic content element displays a portion of video, said portion of video being a replay, highlight or augmented reality. [0073] The system wherein the dynamic content is an advertisement. [0074] The system wherein the unique ID defines an entry within a database, and wherein the entry comprises information regarding the actions of the unique ID; aggregating the data regarding the unique ID from said database; creating a tag grouping based upon the aggregated data on the unique ID and modifying the dynamic content on said DEP. [0075] The system wherein the system collects and aggregates analytical user data corresponding to said unique ID, when said user device is interacting with the DEP. [0076] The system wherein the dynamic content is a real time polling question; and wherein a result from the real time polling question is displayed. [0077] The system wherein the tag grouping is defined within a section of said venue; and wherein the tag grouping is awarded a prize which is pushed into the user device within the dynamic content within the DEP. [0078] The system wherein the dynamic content is related to fantasy sports or wagering. [0079] A method of charging and automating an electronic vehicle comprising: Positioning the electronic vehicle within a parking spot and adjacent to a charging field; Scanning, with a user device or a camera incorporated in the electronic vehicle, a scannable tag, said user device and said camera comprising a unique ID, and said scannable tag comprising a tag ID; Linking the unique ID to the tag ID; and Pushing to said user device or display integral with the electronic vehicle a dynamic content comprising a payment module and a timing module corresponding to payment for charging the electronic vehicle and a duration of the charging. [0080] In a further embodiment, the method further comprising, in response to scanning the scannable tag, automatically charging the electronic vehicle utilizing a wireless charging system, gathering data in relation to the unique ID, tag ID, or both, and recording the gathered data to a data file, data record or both. [0081] In a preferred embodiment, a method of using a network of encoded tags to gather data relating to an event comprising: (a) in response to receiving a request from a user device that has scanned an encoded tag linked to the event, identifying a tag identifier to determine where the encoded tag is physically or digitally installed and identifying a device identifier to determine if the user device has previously scanned any tag in the network of tags, wherein if the user device has not previously scanned any tag in the network of tags assigning a device identifier to identify the user device upon a subsequent scan of any tag in the network, and sending the device identifier to the user device; (b) determining, using the tag identifier, an event for which data is to be gathered, the event identified by an event identifier; (c) determining a target to which the user device is to be redirected, the determined target identified by a target identifier, wherein the target is a default target if the event is not in progress and the target is a web-based application if the event is in progress, and redirecting the user device to the determined target; (d) linking one or more of the tag identifier, the device identifier, the event identifier, or the target identifier; and (e) recording each use-related action that occurs with respect to the web-based application as the use-related action occurs, each recorded action stored in a database with reference to, related to, or both, one or more of the tag identifier, the device identifier, the event identifier, or the target identifier. [0082] In a further embodiment, the method wherein receiving the request from the user device comprises receiving the tag identifier in conjunction with the request. [0083] In a further embodiment, the method wherein identifying the device identifier comprises receiving the device identifier in conjunction with the request or in response to a request for the device identifier from the user device. [0084] In a further embodiment, the method wherein determining if the user device has previously scanned any tag in the network of tags comprises making the determination where the network of tags that belongs to more than one proprietor, the network of tags that belongs to more than one venue, or both. [0085] In a further embodiment, the method further comprising physically installing one or more tags in the network of tags on or near a point of interest, integral with the point of interest, digitally installing one or more tags in the network of tags on a display screen, or both, wherein the display screen is selected from a group consisting of a computer screen, a television screen, a handheld device screen, a screen integrated into a piece of furniture, a screen integrated into an internet of things device. [0086] In a further embodiment, the method wherein determining the event for which data is to be gathered comprises determining if the event is in progress at a time the user device scanned the tag. [0087] In a further embodiment, the method wherein the event is perpetually in progress, is a recurring event, or is a single event scheduled to occur during a predetermined window of time. [0088] In a further embodiment, the method wherein recording data comprises recording data, storing data, or both as long as the event is in progress, or the determined target is opened on the user device. [0089] In a further embodiment, the method wherein redirecting to a web-based application comprises redirecting to a progressive web application, cloud-based application, browser-based application, or an active server page. [0090] In a further embodiment, the method further comprising counting and recording the number of tags in the network of tags that have been scanned while the event is in progress, a counted number retrievable in real time, after the event ends, or both and optionally graphically displayed on an administrator device. [0091] In a further embodiment, the method further comprising, transferring some or all of the data recorded while the event is in progress to a third party customer relationship management service, data management software, or both, the transferred data including at least one identifier that enables the third party to identify a user of the user device. [0092] In a further embodiment, the method further comprising, using the tag identifier to determine the venue in which the scanned tag is installed, the determined venue having a venue identifier assigned thereto, or using the tag identifier to determine a point of interest that the scanned tag points to, or both. [0093] In a further embodiment, the method wherein redirecting to the web-based application comprises redirecting the user device to a web-based application comprising a module identified by a module identifier and recording each use-related action attributed to the module in association with the module identifier. [0094] In a further embodiment, the method further comprising, digitally installing the encoded tag for display in a television broadcast, a cable broadcast, content that is streamed, or a feed and the tag identifier points to the television broadcast, the cable broadcast, the content that is streamed, or the feed in which the tag was digitally installed. [0095] In a further embodiment, the method further comprising defining a rule relating to the web-based application that causes the web-based application to release tickets to a subsequent event in response to determining that the event in progress is about to end, the web-based application releasing said tickets by unlocking a module within the application, pushing content to the user device, redirecting the user device to an external website that sells the tickets, or updating a dynamic element within a module of the web-based application. [0096] In a further embodiment, the method wherein defining the rule comprises defining the rule to release tickets in response to determining that a home team has won a game-based event. [0097] In a further embodiment, the method further comprising defining a rule relating to the web-based application that causes the web-based application to release an offer to preorder an item in response to determining that a threshold number of user devices have scanned a tag in the network of tags, scan an encoded tag, the web-based application releasing said offer by unlocking a module within the web-based application, pushing the offer to the user device, redirecting the user device to an external website that is promoting the offer, or updating a dynamic element within a module of the web-based application. [0098] In a further embodiment, the method wherein the offer to preorder an item comprises an offer to preorder merchandise at a discounted price or an experience-related item. [0099] In a preferred embodiment, a system for aggregating data in response to detecting that a user device has scanned an encoded tag comprising: (a) a server system having a computer processor, a computer memory, and one or more web applications, versions of web applications, or both installed thereon; (b) one or more databases operatively connected to the server system and storing a venue ID assigned to a venue, an event ID assigned to an event linked to the venue; a target ID assigned to a web application built for the event, a tag ID assigned to a tag installed within the confines of the venue and that points to a particular point of interest associated with the venue, event, or both, a unique ID assigned to a user device, and recorded data linked to one or more of the unique ID, venue ID, event ID, target ID, or tag ID; and (c) wherein the computer memory of the server system stores executable code that, when executed the executable code enables the server system to: (ⅰ) receive a request from the user device, the request made in response to using the user device to scan the tag, the tag ID received with the request from the user device; (ⅱ) receive the unique ID from the user device; (ⅲ) use the tag ID to identify the venue, the event, or both; (ⅳ) determine a target web application and redirect the user device to the determined target web application; and (ⅴ) record each user action taken with respect to the determined target web application and linking the recorded actions to one or more of the unique ID, the tag ID, the venue ID, the event ID, the target ID. [0100] In a further embodiment, the system wherein each web application installed on the server system has a target ID assigned thereto and at least one module contained therein, each module having a module ID assigned thereto, wherein recording each user action further comprising identifying the module ID for the module in which the user action was taken and recording the user action in association with the module ID. [0101] In a further embodiment, the system wherein the at least one module is selected from the group consisting of a merchandise module, a concessions module, an enter to win module, an audience participation module, an incident reporting module, a wagering module, an augmented reality module, a digital program module, an NFT acquisition module, a map module, a replay module, a roster module, a live statistics module, a fan filter module, and an upcoming events module. [0102] In a further embodiment, the system wherein the executable code enables the system to search the recorded data, filter the recorded data, or both to obtain metrics relating to one or more of a number of tags scanned during the event, a number of modules engaged with during the event, a number of particular user actions performed during the event, a number of tags scanned by venue location, or a number and type of modules engaged with by venue location. [0103] In a further embodiment, the system wherein the executable code enables the system to turn the web application built for the event to turn on at a predetermined time before the event begins and turn off at a predetermined time after the event ends, wherein data relating to the event is recorded as long as the web application built for the event is turned on. [0104] In a further embodiment, the system wherein the module is an enter to win module, actions recorded with respect to the enter to win module include recording opening the enter to win module and recording enter to win submissions and compare the number of enter to win modules opened to the number of enter to win submissions. [0105] In a further embodiment, the system further comprising, recording identifying information obtained from the enter to win submission, identifying information selected from the group consisting of: name, email address, telephone number, age, gender, or combinations thereof, in a data file related to the unique ID, the tag ID, the target ID, the module Id, or combinations thereof. [0106] In a further embodiment, the system further comprising identifying via unique IDs associated with enter to win submissions, the users that also requested to receive more information relating to future events at the venue and saving the identified requests to a data file associated with the unique IDs. [0107] In a further embodiment, the system further comprising analyze recorded actions to provide customized content to the user device based on one or more past actions. [0108] In a preferred embodiment, a system for appraising a value of a user based on data obtained as a result of scanning an encoded tag with a user device comprising: (a) a server system comprising a computer processor and a computer memory; (b) at least one database operatively connected to the server system, the at least one database storing data files relating to a plurality of venues, each venue in the plurality identified by a corresponding venue ID; a plurality of events, each event in the plurality identified by a corresponding event ID, tied to a particular venue in the plurality of venues, and in progress during a predetermined time window; a plurality of web-based applications, each web-based application in the plurality identified by a corresponding target ID and tied to a particular event in the plurality of events, wherein each web-based application is only active during a predetermined time window based on, and corresponding to when the tied event is in progress; a plurality of encoded tags, each encoded tag identified by a corresponding tag ID, wherein each tag in the plurality is installed in relation to a particular venue in the plurality of venues and points to a particular point of interest (POI) tied to the particular venue; a plurality of unique IDs, each unique ID in the plurality corresponding to and identifying a user device, and data linked to a particular unique ID, venue ID, event ID, target ID, or tag ID within the pluralities thereof, or combinations thereof; and (c) wherein the computer memory of the server stores executable code, which when executed enables the server to perform a process comprising: (ⅰ) in response to receiving a request from every user device that has scanned a tag in the plurality of tags, identifying the tag ID obtained by the user device as a result of scanning the tag, the tag ID received from the user device with the request and identifying the user device that has scanned the tag using the unique ID received from the user device or newly assigned to the user device; (ⅱ) identifying the venue in which the scanned tag is installed, the POI to which the tag ID points, or both using tag ID received with the request; (ⅲ) determining which event in the plurality events is tied to the identified venue and in progress; (ⅳ) determining a web-based application to which the user device is redirected, the determined web-based application selected from the plurality of web-based application and tied to the event determined to be in progress, the web-based application determined, using one or more of the unique ID, the tag ID, or venue ID identifying the identified venue, the event ID identifying the determined event, or combinations thereof; and (ⅴ) recording each action taken with respect to the determined web-based application, wherein each recorded action is linked to, points to, or both, one or more of the target ID identifying the determined web-based application, a defined action, the unique ID identifying the user device, the tag ID identifying the tag that was scanned by the user device, venue ID identifying the identified venue, or the event ID identifying the determined event; (ⅵ) parsing recorded data to be able to analyzed the recorded data as a function of at least one unique ID, at least one tag ID, at least one venue ID, at least one target ID, at least on event ID, or combinations thereof; and (ⅶ) assigning a valuation to a particular user associated with a particular unique ID, the valuation based on data parsed as a function of the at least one unique ID. [0109] In a further embodiment, the system further comprising, wherein assigning a valuation to a particular user further comprises assigning a number, a dollar amount, or both to identify the likelihood that the particular user will take an identified action based on aggregated user data relating to the identified action. [0110] In a further embodiment, the system further comprising assigning the number, the dollar amount, or both to each unique ID in the plurality of unique IDs. [0111] In a further embodiment, the system wherein the number, the dollar amount, or both assigned to each unique ID in the plurality of unique IDs is updated in real time. BRIEF DESCRIPTION OF THE FIGURES [0112] FIG.1 depicts an embodiment of a system for user device generated interactions with a system and platform for accessing and viewing targets, such as content and digital offers. [0113] FIG.2 depicts a stadium comprising a plurality of video cameras and a user device that is accessing a user portal including access to content such as video, augmented video playback, and digital offers. [0114] FIG.3 depicts an embodiment of a system for accessing target information from a user device from within a venue or outside of a venue and various back-end platforms for implementing certain target information or for delivering content to the user device. [0115] FIG.4 depicts an embodiment of a system for identifying and using information particular to a user device and/or to a tag for directing the user device to an appropriate target. [0116] FIG.5 depicts an embodiment of a system wherein the system is enabled to push or pull data or information or due to triggering events or rules to modify or augment a target delivered to a user device. [0117] FIG.6 is a diagram of one embodiment of a system that enables delivery of the customized content. [0118] FIG.7 is a flowchart illustrating the operation of the system of FIG.6. [0119] FIG.8 is a diagram illustrating a further embodiment of the system. [0120] FIG.9 is a diagram illustrating a variation of an embodiment of the system. [0121] FIG.10 is a flowchart illustrating the operations of the system of FIG.9. [0122] FIG 11 depicts an area comprising a plurality of tags positioned at multiple locations. [0123] FIG.12 details a flow diagram of various tags, applications and report and related tasks and information for implementing the system of the present embodiments. [0124] FIG.13 depicts a flow diagram for use of an embodiment of the system from an admin user. DETAILED DESCRIPTION OF THE INVENTION [0125] Historically macro offers were made to an entire stadium such as if the home team wins you get a free taco at the taco store. Embodiments enable micro offers to be made to select users/groups of users. Aggregating data gathered during one or more events enables envisioning trends for a user or a group of users based on factors such as purchasing habits, seat section, as nonlimiting examples. This follows the marketing trend of obtaining more data, which enables targeted marketing towards individual users. Such targeted marketing provides better leads and a lower cost of acquisition for new users. Furthermore, this data allows for new marketing and targeted approaches towards users who are not seeing advertisements or offers that would drive their engagement. The system and methods detailed herein provide for an improved mechanism to identify user interests and to provide content to the user or groups of similarly situated users that will drive engagement. [0126] 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. Moreover, embodiments are not limited to the specified order and number of steps in a given process or the like. The number and order of steps may be altered to achieve a desired end. The following detailed description is, therefore, not to be taken in a limiting sense. [0127] The embodiments detailed herein and as depicted in the drawing figures illustrate several embodiments of the invention, which is directed to a method and system for generating unique content to a one or a plurality of users based upon data collected within the system. Typically, these include forming rules or meeting a metric, whether done by a plurality of users and user devices or a single user device. The unique content provided to the users can then be further tracked, the engagement with the content can be tracked, and the content modified to increase engagement with the content. [0128] As used herein, the below terms will have the following meanings as may be supplemented elsewhere in this specification: [0129] 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. [0130] ADDRESS: Code used to direct a user device, browser, Web app, progressive Web app, administrator device, server, database, API, tool, software, etc., to a resource within the system or a network. Nonlimiting examples of addresses include a uniform resource identifier (URI) or a uniform resource locator (URL). [0131] ADMINISTRATOR: The individual or group of individuals with the ability to control and set rules and parameters within the system. This could be a third-party administrator, the proprietor, the venue, the owner of the tags, the team or performer participating in the event, a designated employee of any of the foregoing, etc. [0132] ADMINISTRATOR DEVICE: Any type of mobile or non-mobile processing device such as a desktop computer, handheld computer (e.g., phone, smartphone, tablet, personal digital assistant), wearable computer (e.g., smart watch, smart glasses), portable computers (e.g., laptop, netbooks, Chromebook), or wearable or implantable device, and the like using wireless communication, a camera or other connectivity element that is accessible only to an administrator or proprietor or an employee designated by the administrator or proprietor. [0133] ANALYTICS OR ANALYTICAL DATA: Data collected by the system or retrieved by the system via an API call to an external server or database as a nonlimiting example. Nonlimiting examples of analytical data include date, time, GPS location, personal identifying information, etc. [0134] APPLICATION PROGRAMMING INTERFACE (“API”): An application programing interface or programming code that enables data transmission within the system, between the system’s server and an external server or between one software product and another. Nonlimiting examples of API connections to the system may be third-party vendor databases such as ticketing sales platforms, e-commerce sites such as merchandise sales, social media sites, or any other third-party software product that makes their API available for use by others. [0135] API CALL – Code used by the system software to access data, server software or other applications within the system or external to the system, acting as an intermediary between any two devices or servers that want to connect with each other for a specified task. As used herein, API can mean (ⅰ) representational state transfer or Rest (RESTful) API; (ⅱ) Simple Object Access Protocol (“SOAP”) API; (ⅲ) extensible markup language – Remote Procedure Calls (“XML-RPC”); (ⅳ) JSON Remote Procedure Calls (“JSON-RPC), (ⅴ) open API; (ⅵ) partner API; (ⅶ) internal or private API; (ⅷ) composite API; or (ⅸ) any other API that is generally known, or will be come to be known in the art. Thus, the system frequently uses an API, or sends an API request, to an internal or external program, server or database to deliver requested information. [0136] BLOCKCHAIN: Any digitally distributed, decentralized, public or private ledger that exists across a network such as those offered by the providers including but not limited to Ethereum, Binance Smart Chain, Polkadot, Flow by Dapper Labs, EOS, Tron, Tezos, WAX, Theta, etc. [0137] BROWSER APPLICATION: An application that runs within the Web browser of a user device or computer. The instructions or executable code, typically written in a combination of HTML and JavaScript, are embedded within the Web page that is downloaded from a Web site. [0138] COMPUTER: May be any type of computer such as a laptop computer, desktop computer, tablet, and the like, and includes the appropriate hardware, firmware, and software to enable the computer to function as intended. [0139] CONTENT: Any type of information, images, videos, etc. Nonlimiting examples of content can be a video file, an image file, text, executable code, a digital offer, a digital coupon, a digital wallet offer, an AR, VR or mixed reality filter, a game, a poll, an app, an NFT, etc. Content can be specifically formatted for optimal viewing on a user device. [0140] CRYPTO CURRENCY: Any digital currency in which transactions are verified and records maintained on a distributed ledger such as blockchain, for example, Bitcoin, Ethereum, Cardano, Binance Coin, Tether, Solana, XRP, Dodgecoin, etc. [0141] DATABASE MANAGEMENT SYSTEM: A software package designed to define, manipulate, retrieve and manage data in a database, or any other generally accepted definition known to those skilled in the art. [0142] DIGITAL OFFER: Any incentive or reward, for example an incentive to purchase at a discounted price or a free giveaway, offered by a proprietor and delivered to users from a server to a user device through a variety of channels. A digital offer can be code stored in the user’s digital wallet, an MRC displayed in Web browser and presented to a proprietor for redemption, an e-mail with a unique redemption code, a text message, SMS/MMS, push notification or socket notification with a unique redemption code. Digital offers can be stored anywhere on a user device or can be downloaded or turned into physical offers by printing. Digital offers can be limited to a particular user, or a user may share the digital offer with other users. If a digital offer is shared, the same offer can be shared to multiple other users, or the digital offer can be modified by the system when it is shared. Digital offers can also be associated with a unique code that is stored in a database on a server internal or external to the system. [0143] DIGITAL WALLET: A software-based system that securely stores users’ information such as payment information, passwords, digital certificates, digital coupons, crypto currency, tokens, NFTs, digital ID such as a digital driver’s license or passport, etc. A digital wallet can be a blockchain or crypto currency wallet. A digital wallet can be stored locally on any user device or can be cloud based and accessed by a user device. Digital wallet can also mean digital storage in general on any user device or computer. Digital wallet can also be referred to as a mobile wallet. [0144] DISTRIBUTED DATABASE SYSTEM: Any database that consists of two or more files located in different sites either on the same network or on entirely different networks. [0145] DISTRIBUTED LEDGER: Any database that is consensually shared and synchronized across multiple sites, institutions, or geographies, accessible by multiple people. [0146] DATA SERVER OR SERVER: Any form of electronic device or plurality of devices having at least one computer processor, e.g., a central processing unit (CPU), and some form of computer memory having a capability to store data, as is well known in the art. The server may comprise hardware, software, and firmware for receiving, storing, and/or processing data as described below. The hardware may be in a single unit, or operably connected via a network. For example, a computer or server may comprise any of a wide range of digital electronic devices, including, but not limited to, a server, a desktop computer, a laptop, a smart phone, a tablet, a smart watch, smart glasses, a wearable device or an implantable device or any form of electronic device capable of functioning as described herein. [0147] DYNAMIC ELEMENT: An element that is updated, altered, customized, etc., in response to a change in the status of a metric, trigger, or any other datapoint as determined by the system. A nonlimiting example of a dynamic element is the score of a game. If a goal is completed, then the score is updated to reflect this change. [0148] EVENT: Nonlimiting examples of an event include a professional, amateur or intermural sporting events (i.e., football, baseball, hockey, basketball, soccer, rugby or cricket game, tennis or golf match, track and field or figure skating event or automobile race), a theatrical performance (play, musical or opera), a musical concert, elementary school, middle school, high school, college or university event, a service or ceremony (i.e., religious or worship), a tradeshow or conference, guided or self-guided tours (museums, galleries and historical site), time spent in a venue such as a visit to a zoo or amusement park, etc. An event may be for a limited time, extended time, or perpetual. [0149] FAN PORTAL: A web application, progressive web application, cloud-based application or the like with a visual layout displayed on a user device via a web browser that provides links or access to other pages or interactive modules via buttons or other means of selecting options from a menu of choices. The fan portal can also be used for viewing content and receiving digital offers. [0150] INTERFACE SERVER: Within the system, a program, executable code or API stored on a physical server, cloud storage system or in a serverless environment such as Amazon Web Services, which is capable of communicating with other servers, databases and API’s internal or external to the system. The interface server is able to make and receive calls, request and receive data, or execute other functions within systems. The interface server is also capable of running AI and/or utilizing machine learning. [0151] GEOFENCE: A virtual perimeter for a real-world geographic area or an area in or around a venue. [0152] GUI OR GRAPHICAL USER INTERFACE: An interface with graphics to enable interactions between a user and the user’s device, such as but not limited to a visual interface fa the Web app. [0153] JUMBO SCREEN: Any display within a venue visible to users attending an event at a venue. The jumbo screen can be one display or multiple displays within the venue that can be controlled by the venue. Jumbo screen may also be known as a jumbotron. [0154] LOCATION: An area whose perimeter or parameters are defined in an abstract way without boundaries that are clearly visible to users or proprietors. Nonlimiting examples of a location include a town, city, state, country, region, continent, time zone, or geofenced area. [0155] MACHINE-READABLE CODE (“MRC”): A barcode, a quick response (QR) code, near-field communication (NFC) code, radio-frequency identification (RFID) code, universal product code (UPC), machine readable graphics (e.g., having a pattern, matrix, or the like) coding, instructions coded on a chip, or combinations thereof. A MRC may be may be included into (ⅰ) a tag that is mounted to a surface, (ii) identification badges such as, for example, student identification badges, employment identification badges, concert badges, and the like, (iii) merchandise such as t-shirts, sweatshirts, hats, mugs, glasses, posters, CD’s, and the like, (iv) a piece of paper, cardstock, or plastic that is handed to users, (v) a video stream viewed over the internet or network television channel, (vi) an LCD/LED/e ink display device embedded, attached or affixed to a surface. [0156] MANIFEST: A file containing metadata for a group of accompanying files that are part of the system that instructs the user device how to handle the system when it is started. [0157] MINTING: Uniquely publishing a token on the blockchain to make it purchasable, saleable, or tradeable. [0158] NON-FUNGIBLE TOKEN (“NFT”): A non-interchangeable unit of data stored on a digital ledger, such as but not limited to blockchain, that can be purchased, sold, auctioned, and traded. As used herein, NFT includes the contract and subject matter associated with the NFT and can also mean semi-fungible token or fractional NFT. Nonlimiting examples of the smart contracts that could govern a NFT include (ⅰ) 1/1 NFTs - known as ERC-721 tokens on Ethereum and Polygon, KIP17 on the Klatyn blockchain; (ii) Semi-fungible NFTs - known as ERC-1155 tokens on Ethereum and Polygon, KIP37 on Klatyn. [0159] NFT MARKETPLACE: A platform where NFTs can be stored, displayed, bought, sold, traded, auctioned and in some cases minted. [0160] PROPRIETOR: Any person or entity who purchases, subscribes to, or otherwise uses the system and/or platform and who is not a user. A Proprietor may or may not have administrative privileges to the system. Nonlimiting examples of proprietors include, venue owners, event promotors, teams, performers, theatre troupes, religious organizations, educational institutions (i.e., elementary school, middle school, high school, college, university), restaurants, bars, retail establishments, amusement parks, museums, art galleries, advertisers, media outlets (i.e., network television, cable television, radio, internet broadcasts), hospitals and health care systems, ticketing platforms, airlines, ride share services, organizations, etc. [0161] PROPRIETOR PORTAL: An access point for a proprietor to enter the system and/or platform typically displayed in a browser. [0162] RECORD: The act of capturing and storing delayed data that is stored in an electronic or other intangible medium without limitations on how the data is structured. [0163] REDIRECT/IDENTIFICATION SERVER: The server within the system that makes a determination on if a user and/or user device that has entered the system is unique, by locating the manifest stored on a user device and if a manifest exists, associating the unique ID stored in the manifest on the user device with the database of known unique ID’s stored on the redirect/identification server, or for confirming other data based on one or more requests to the redirect/identification server. [0164] REDIRECT URL: An address generated by a server, such as the redirect/identification server or the interface server, in response to an incoming request that points the browser on a user device to a different target. [0165] REQUEST: A message sent by one device to another (e.g., phone to server, server to server, computer to server, server to database, etc.) using an address to send the request. For example, upon selecting from the options available in the Web browser, the selection is coded into a request that the Web browser sends to the server via an address. The request typically provides instructions to the server. Nonlimiting examples of a request can be – GET, POST, PUT, DELETE, CONNECT, OPTIONS. [0166] RULE: A set of conditional statements that tells the system how to react to a particular situation. Rules can be preprogrammed into the system or can be set or changed by an administrator or proprietor. [0167] SYSTEM: The network, tags, digital seat platform, etc. [0168] TAG: A physical (e.g., tangible) form, a digital (e.g., virtual/intangible) form, or maybe combinations of both forms that contains an MRC. Physical versions of tags may be constructed from diverse types of materials. The MRC may be printed, etched, or fabricated onto the tag materials such as paper, glass, plastic, metal, fabric, and the like as a few nonlimiting examples. In the case of tags that contain MRC’s that are NFC or RFID, the tags may be adhered to, attached to, embedded in, or fabricated on (or combinations thereof) a natural or manmade material such as metal (e.g., aluminum, stainless steel), wood, polymer (e.g., plastic), film, glass, and combinations thereof. The material may then be incorporated into or affixed (e.g., adhesive or other form of attachment) to an object or location. A tag may be printed on a single or multiple use badge or ticket or the tag itself may be a video display such as LCD, LED, or e-ink. Digital tags may include LED/LCD screens, television screens, computer screens, appliance screens, and the like, or a designated location within a video stream in which the MRC is located. A tag may also be incorporated into a magnet or lanyard. [0169] TAG ID: A unique identifier for the MRC affixed to the tag. The unique identifier can be any combination of letters, numbers, and symbols. The tag ID is stored in a database on a server and is coded with information specific to the location of the tag. For example, the tag ID might generally identify the geographic location of the tag (i.e., the United States, Pennsylvania and/or Philadelphia), the general venue location of the tag (i.e., Fenway Park, Madison Square Garden, Carnegie Hall, The Natural History Museum), the specific location of the tag within the venue (i.e., Section A, Row 1, Seat 10, next to Van Gogh’s “Starry Night”), or any combination of information. [0170] TAG URL: A unique address assigned to the MRC on each tag that may optionally include the tag ID. [0171] TARGET: A Web page, file, address, GUI, Web app, progressive Web app, portal, content or digital offer delivered to a user device. Those skilled in the art may also refer to a target as an endpoint. [0172] TARGET ID: A unique identifier for the target. The unique identifier can be any combination of letters, numbers and/or symbols that can be stored in a database, on a server, and/or both. The target ID allows the platform to distinguish one target from another. [0173] TICKETING PLATFORM: Both the primary ticketing platform and the secondary ticketing platform. [0174] TRIGGER: The magnitude or condition that must be reached for a certain result to materialize. Triggers can be determined either by the system, an administrator or a proprietor. Nonlimiting examples of a trigger can be the start or end of an event, something of significance that occurs during the event (i.e., the 10th goal scored, the first encore by a musical act), a single user completing a certain task, or N-number of users completing a task. [0175] TOKEN: A digital asset that is stored securely on the blockchain, representing a tradeable asset. [0176] TOOLS: Cookies, pixels, widgets, plug-ins, etc. [0177] UNIQUE ID: A unique identifier for the user device. The unique identifier can be any combination of letters, numbers and/or symbols, cookies, digital credentials or it can be a digital certificate such as TLS, SSL, code signing certificate, client certificate, etc... The unique ID can be stored on the user device in any location on the user device such as the manifest, local storage or digital wallet, in a database on a server, and/or both, and is used to associate the user device with the unique user record stored in a database on a server in the system. [0178] UNIQUE IDENTIFYING INFORMATION: Personal information and demographics collected about a particular user’s such as name, address, phone number, e-mail address, credit card information, gender, marital status, academic affiliation (student, faculty, alumni), driver’s license number, age, username, password, pin number, social security number, bank account number, salary, etc. [0179] USER DEVICE: Any type of mobile processing device such as a handheld computer (e.g., phone, smartphone, tablet, personal digital assistant), wearable computer (e.g., smart watch, smart glasses), portable computers (e.g., laptop, netbooks, Chromebook), or wearable or implantable device, and the like using wireless communication, a camera or other connectivity element. [0180] USER/DEVICE ID RECORD: A record stored within a database on a server that contains the unique ID and unique identifying information associated with that unique ID for each user that accesses the system. The user/device record can contain an unlimited amount of information about the user device and presumably the user who owns the user device such as, but not limited to a history of events attended, digital offers used, gambling wagers made, NFTs minted or purchased, venues or locations visited, concession or merchandise purchases, donations made, incident reports, tags scanned, other actions taken, etc. This may further include certain information related to demographics, event attendance history, purchasing history) as well as information about the user device (type of device, GPS location of the device when is scans an MRC). [0181] VENUE: A physical location with defined perimeters and parameters such as a stadium, arena, court, track, concert hall, theatre, course, museum, restaurant, place of worship (church, synagogue, temple, mosque, etc.), historical site, cultural site, amusement park, zoo, aquarium, conference center or any other place where events are held, or users gather. Venues can also be hotel rooms, cruise ships, trains, airplanes, schools (elementary, middle or high school) or a college campus or dorm. A venue may also be defined by a non-physical boundary or containment area such as a geographical area. [0182] WEB APP: Executable code that is stored on a remote server and delivered via the system or a network to a browser interface on a user device. The Web app may facilitate communication between the user device and one or more servers such as the redirect/identification server or the interface server. Web app includes different types of Web apps such as progressive Web apps, cloud-based apps, browser based apps, active server pages, etc. [0183] The embodiments herein are directed toward a system and methods for aggregating data obtained via user devices in response to scanning encoded tags and using that data to enhance user enjoyment while participating in an event. This and other elements can be performed on the system as detailed in the following embodiments. A high- level overview of an exemplary system (10) is shown in FIG.1 with respect to a single proprietor for ease of understanding. Embodiments are not limited to a single proprietor. Additional proprietors have the same or similar system components as the proprietor described herein. The system (10) may include an administrator device (12), a platform (20), a user device (14a) associated with an event user (e.g., physically at the event/in the venue), a user device (14b) associated with a remote user (e.g., not necessarily at the event/in the venue), a plurality of tags (16a, 16b) and one or more networks (18). Generally, each user device (14a, 14b) may be used to scan, read, or otherwise detect (collectively “scan”) machine-readable code (“MRC”) (17a, 17b) associated with a respective tag (16a, 16b). The act of scanning a tag (16a, 16b)/MRC (17a, 17b) initiates communications between the user device (14a, 14b) that scanned the tag (16a, 16b) and the platform (20), which may result in the rendering of a Web page, Web app or the like (e.g., related to the event) by a Web browser and/or other application running on the user device (14a, 14b). Communications between user devices (14a, 14b) and platform (20) is typically via one or more networks (18), which may include, without limitation, the Internet, mobile networks, cloud-based platforms, or combinations thereof. Thus, the platform (20) may provide one or more services to a proprietor to enhance user experiences in association with the proprietor. [0184] 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 is encoded with a unique identifier (tag ID), which may be used by the platform 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. [0185] As is implied in FIG.1, a certain number of tags (16a) may be present at the venue (“in-venue tag”), and additional one or more tags (16b) may be remote from the venue (“remote tag”) where the MRC (17b) is digitally displayed in/on a video transmission, signal, or the like, or on a Web page associated with the event, venue, and/or television network, as a few nonlimiting examples. Thus, a digitally displayed MRC/tag is visually displayed to the user regardless of whether the MRC/code is transmitted in a digital format. Of course, there is the possibility that a user at the event/in the venue scans the remote tag (16b) with his/her user device (14a). Each user device (14a, 14b) may also include, or may eventually include, a unique identifier (22a, 22b) to uniquely identify the user device (14a, 14b) to the platform (20) and a digital wallet (24a, 24b) to securely store sensitive information such as a driver’s licenses, account information (e.g., banks, crypto currencies, credit cards), titles, tokens, tickets, vouchers, coupons, other digital file (301a, 301b), and the like. [0186] 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 (FIG.3 at [322]) hosted by platform (20) to perform administrative and/or other activities such as determining what content (or other) will be sent to the user device (14a, 14b) in response to scanning a tag (16a, 16b). Since more than one proprietor may access the platform, each proprietor is assigned a proprietor ID to identify the particular proprietor to the platform (20). Furthermore, a given proprietor may be linked to one or more venues and each venue is assigned a venue ID to associate the venue with the proper proprietor and to identify the particular venue to the platform (20). In turn, venues host multiple events and perhaps multiple teams. As such, each event (e.g., Event ID) and each team (e.g., Team ID) are assigned an identifier to identify the respective event and/or team to the platform. In this way, collected/recorded data may be linked to one or more of a given proprietor, venue, event, team, tag, or user device as a result of a tag (16a, 16b) scan by a user device (14a, 14b). [0187] 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, external websites, Web applications and more, which is detailed below, with reference to accompanying figures. Thus, features of the present invention and embodiments thereof are designed to allow easy installation for proprietors, easy use for end users, increased flexibility for proprietors to provide end users with a wide variety of content, engagement opportunity, etc., while collecting/recoding a vast amount of data all without downloading a native type application to the end users device to be enabled to engage with the system (20). Nor is the proprietor required to purchase expensive equipment in order to implement service provided via the platform (20). To implement the system, all the proprietor has to do is install a network of encoded tags (16a, 16b) and configure its investment to produce a desired outcome for an end user or group of end users. The tags (16a, 16b) are unobtrusive and can be attached (e.g., adhesively, printed on a badge, displayed digitally, etc.) to a point or location of interest (POI). The proprietor can make/adjust configurations directly (via the administrator device [12]) or via platform (20), or the proprietor can direct personnel to do so in real time while an event is in progress. [0188] FIG.2 shows an exemplary venue (202), which includes a portion of system (10) shown in FIG.1. In this case, the venue (202) is a football stadium including a jumbo screen (204), recording devices (206a, 206b, 206c, 206d), seats (208), and a plurality of encoded tags such as tag (16a). Although a stadium is shown, the venue (202) can be any venue: small, large, indoor, outdoor, permanent, temporary, one structure, several structures, a geolocation such as a city, and variations thereof. Thus, a venue (202) can be any area or space occupied by or intended for something in which tags (16a, 16b) are contained and events may take place, each venue (202) having a venue ID and linked to the proprietor controlling the venue (202). As such, associated amenities and accoutrements may drastically vary from venue to venue. In this example, the stadium has jumbo screen (204), which may display a wide variety of video content as is customary for a football game, though such display screen is not necessary for functionality of the system. The stadium also includes optional recording devices (206a, 206b, 206c, 206d) such as video cameras for recording the football game and other activity, which is also customary for this type of venue (202). Likewise, an event may be any event including sporting events, artistic performances, trade shows, conferences, ceremonies, services, self-guided tours (e.g., at cities, museums, historic sites), zoos, promotions, campaigns and the like as a few nonlimiting examples. In some implementations, museums, historic sites, zoos, cities, and similar examples may be identified by a venue ID, and event ID, or both. [0189] In the example of FIG.2, each seat (208) has a seatback (210) with a tag (e.g., 16a) disposed thereon. In this way, event users can easily see a tag (e.g., 16a) directly in front of them while they are sitting in their seats (208). Thus, the tag (e.g., 16a) that the event user sees is associated/linked with the seat (208) in which the user is sitting. Linking/associating each encoded tag (16a, 16b) to a particular POI enables the platform (20) to use the encoded tag ID to link data obtained as a result of a tag scan by the user device to the POI. In this way a proprietor can analyze/use the recorded data from the perspective of the POI. As one nonlimiting example, a user can have food or merchandise delivered directly to the seat (208), since the platform (20) can determine the user’s location via the tag ID. In-venue tags (e.g., 16a), however, are not limited to being positioned on seatbacks (210); they may be placed in a wide variety of locations within a venue (202). For example, if in-venue tags (16a) are associated with particular seats (208), they may be placed in any other location on or near the associated seat (208) such as an arm rest, a cup holder, on the seat (208) next to the event user’s leg, on the ground, or on a structure near the seat (208) such as a wall, a pillar, or the like. It should be noted that in-venue tags (16a) may be associated with other locations/points of interest, and thus may be placed at or near the locations/points of interest such as entrances, levels, sections, isles, loge seats, individual people (e.g., with a tagged badge, tagged ticket, or the like), restrooms, various additional possibilities, or combinations thereof. Therefore, while one example of in-venue tag (16a) placement is illustrated in FIG.2, in-venue tag (16a) placement should be broadly construed to include any placement suitable for use as described herein. Tags (16a) may be associated with one or more groupings, for example, by a section, (222, 224, or 226), wherein grouping of tags (16a) may provide certain benefits in the various embodiments detailed herein. Alternative tag placement schemes may be devised as desired by the proprietor and consistent with the teachings of the present invention, should be considered within the scope of the present disclosure. [0190] In-venue tags, in certain embodiments, may be installed in a movable venue and/or event, for example a vehicle, a bike, a boat, train, airplane, etc. A tag installed on such movable venue and/or event may be linked to a particular vehicle, POI within the vehicle, or both to be able to identify the venue, event, etc. linked to the scannable tag. If exact GPS coordinates or the like are needed or desired, the coordinates may be obtained from one or more of the user devices that scanned the tag, the vehicle, a third party, or another reliable source. As such, a movable tag can be accessed several times in a series of time (e.g., minutes or seconds) and generate a different GPS location each time a user device scans the tag (or queries a server) and allows the system to identify the movement of the user device, vehicle, POI in the vehicle or combination thereof. [0191] As was mentioned with respect to FIG.1, each tag (16a, 16b) in the system (10) has a machine-readable code (17a, 17b) encoded thereon. The term machine-readable code (“MRC”) as used herein should be broadly construed to include “graphics” type codes such as quick response (QR) codes, universal product code (UPC), snap codes, and/or any other type of machine-readable graphics (e.g., having a pattern, matrix, or the like) coding known in the art or later developed. Importantly, as used herein, the term machine-readable code/MRC should also be construed to include “chip” technologies that store data on a chip such as, without limitation, nearfield communication (NFC) and radio-frequency identification (RFID) technologies, as is known in the art or is later developed. Embodiments may also include one or more types of MRC such as a QR code and NFC chip, as one nonlimiting example. Thus, MRC can be read, scanned, detected or otherwise decoded (collectively, “scanned”) by an appropriately enabled (e.g., camera, QR scanner, and/or NFC reader [212]) user device (14a, 14b). [0192] 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. [0193] Information encoded on or in each tag in the system (10) may include an address to direct a request (e.g., for a file, Web page, Web application, etc.) 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 nonlimiting 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 FIG.3, when the event user uses his/her user device (14a) to scan tag (16a), the event user device (14a) obtains an address from the MRC (17a) and linked to the scanned tag (16a) and sends a request via the network (18) to the address destination. As one nonlimiting example, the address is a URL that causes the event user device (14a) to send a request to a redirect/identification server (302), on platform (20), which receives the request. Similarly, when the remote user uses his/her user device (14b) to scan the MRC (17b) on a screen (304), a similar URL is obtained which causes the request from the remote user device (14b) to be sent to the redirect/identification server (302), which receives the request. Either way, server receipt of a request in response to a user device being used to scan a tag. [0194] 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/determine the point of interest/location that is linked to the tag (14a, 14b). In an embodiment, the platform (20)/server on the platform (20) may look up the tag ID to determine the linked POI upon receipt of the tag ID from the user device or at any other time when information about the linked POI is requested/needed. Furthermore, the tag ID may also be used to determine the event, venue, proprietor, or any other information linked to the tag ID. In this way, when a request comes from the event user device (14a), the platform (20) knows that the request came from the particular venue (202) and was made in response to scanning the tag linked to the seat (208) in which the event user is sitting. Similarly, 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 tied to 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. [0195] FIG.3 details an exemplary infrastructure that may be used by platform (20) although infrastructures are not limited thereto. This infrastructure may include the redirect/identification server (302), an interface server (306), a database (308), an administration server (310), an analytics server (312), a blockchain, access to a blockchain, or both (314), a geofence (316) a timestamp (318), one or more third party integrations (320), the proprietor portal (322), and a socket server (324). Generally, user device (14a, 14b) communicates with the platform (20) via redirect/identification server (302) as was previously described. Redirect/identification server (302), accept requests from user devices (14a, 14b), sends responses to user devices (14a, 14b), and performs various other methods as described herein. As one nonlimiting example, the redirect/identification server (302) may forward information (e.g., URLs, parameters, etc.,) from user device (14a, 14b) requests/queries, etc. to the interface server (306). The interface server (306) manages most, if not all the tasks involved with processing requests, such as handing off/directing tasks, functions, calls, queries and the like where needed. The interface server (306) may also return request/query responses to the redirect/identification server (302). If a request came from a user device (14a or 14b), then the redirect/identification server (302) forwards the response to the requesting user device (14a or 14b). Examples of tasks, functions, calls, and the like that the interface server (306) may hand off include, without limitation, database (308)/blockchain data recordation retrieval storage, lookups, etc., administrative and back-end tasks/functions to the administration server (310), analytical tasks/functions to the analytics server (312), geolocation tasks/functions (316), time/timestamps (318), API calls to third-party servers for third party integrations (320), linking to third party resources via URLs and establishing socket connections via socket server (324). [0196] Referring to FIGS.3 and 4 together and using the request from event user device (16a) as an example, a method (400) may begin with the redirect/identification server (302) receiving the request (step 402) from the event user device (14a) and in response using the device to scan an encoded tag. The redirect/identification server (302) may check to see if the event user device (14a) has a unique ID assigned by the platform (20), loaded thereon (step 404). If no, the redirect/identification server (302) may generate/assign a unique ID for the event user device (14a, step 406) so that the user device (14a) can be identified by the platform (20) every time the user device (14a) linked to the assigned unique ID scans a tag (16) belonging to any proprietor using platform (20) services. The redirect/identification server (302) will also cause the unique ID for the event user device (14a) to be stored in a database such as database (308), as is appropriate for the database management system (step 406). As used herein, the term “record” refers to information that is stored in an electronic or other intangible medium without limitations on how the data is structured. A record may include and/or point to related/linked data. For example, a record for a unique ID may include/point to the unique ID and/or any other data tied thereto, which may be stored in database (308) or other appropriate data storage. The term “record” may also refer to the act of storing, requesting, etc. data in a reproduceable/retrievable form. Thus, the term “record” may be a noun or a verb. In addition to recording the newly assigned unique ID for the requesting user device, the platform (20), via the redirect/identification server (302) may then send the unique ID to the event user device (14a, step 408). The unique ID may be tied to a manifest packet, locally stored data file, in a digital wallet, other secure repository, or combinations thereof maintained on the event user device (14a). In an embodiment, the manifest packet, locally stored data file, or the like, including the unique ID may be obtained from the user device (14) for use by the platform (20) to identify the user device assigned to the unique ID, although embodiments are not limited thereto. At step (410), the unique ID is recorded for further use in the method (400), other methods described herein, or both. In an embodiment, the date and time that the unique ID is recorded (in response to a tag scan/responsive to a tag scan) may also be recorded to “timestamp” the tag scan by the user device. Furthermore, the platform (20) may add the tag scan by the user device to one or more counts such as a count of the total number of tags scanned in the venue for a given time, as one non limiting example. If the event user device (14a) already has a unique ID assigned thereto (step 404, yes), the redirect/identification server (302) obtains and records the unique ID (step 410). In an embodiment, the redirect/identification server (302) and/or other platform server may also obtain data such as current time, date, location, etc. from the event user device (14a) the platform (20), the venue (202), a third party provider, or other reliable source, or combinations thereof at step (410) or thereafter. As a nonlimiting example, date and time information may be obtained from a timer/time source (318) on or linked to the platform such as a system clock, CPU clock or other such clock. [0197] 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) that scanned the tag (16a). 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. The tag ID may be used by the platform (20) to make one or more determinations. For example, the redirect/identification server (302) and/or interface server (306) may use the tag ID from a request to determine one or more of a linked POI, venue, event, proprietor, or any other information tied in some way to the tag via the tag ID. To clarify, a particular venue (202), proprietor, organization or the like, installs tags (16a) and/or uses tags (16b) as desired. Each tag refers to/is linked to a particular point of interest such as a seat, a person, a transmission, etc. A proprietor and/or platform personnel can see, via the proprietor portal (322) or administrator device (310), respectively, a listing and/or digital representation of the tag’s MRC and assign a POI thereto. Thus, using stadium seating as an example, each MRC in the list can point to a particular seat, row and section. In a similar manner, an MRC on a badge, lanyard, or the like can point to a particular person together with other identifying information such as security level, department, permissions, supervisor, or any other identification scheme desired by the proprietor. Also in a similar manner, an MRC displayed on a screen such as a monitor, TV or other display screen may point to information identifying the particular distribution parameters in which the MRC was provided such as channel, broadcast, geolocation, distribution method, network streaming services, etc. as is most appropriate for the particular implementation. As yet another example, the proprietor may be a city or other organization that does not have a physical venue per se. In this situation tags may be installed within a geographical area or containment area, which is tantamount to a venue. Thus, MRCs may be tied to various points of interest within the containment area and identified as appropriate such as geographical coordinate (latitude, longitude), historical site, artistic installment, bus stop, street address and any other information that can identify where the tag/MRC is installed. Since each tag belongs to a particular proprietor, and the proprietor can install its tags in a venue, the tag ID may be used to determine the venue in which it is installed (416) and/or the proprietor that owns the tag as tags are tied to both the proprietor and the particular venue via a proprietor ID and a venue ID respectively. This, regardless of where the tag is located/installed, the platform (20) can determine who owns the tag (proprietor), the venue in which the tag is installed (416) and the POI to which the tag/MRC is tied, all via the tag ID. These determinations may be made by the redirect/identification server (302), , the interface server (306), the administration server (310), any other suitable server, or combinations thereof using data from the request, database (308), the user device, or any other data repository. [0198] At step (418), the method (400) may determine if a particular event is “in progress”. An event may be in progress from a first date/time to a second date/time. For example, if the event is the type of event that takes place during a window of time, such as a sports game, concert, performing arts production, ceremony, and other such events, the event may be in progress from a time before the event begins (first date/time) to a time after the event ends (second date/time). If an event does not continue within a designated time frame, the event may always be in progress, be in progress during hours of operation or some other such definition. For example, if the proprietor is a city and the venue is “downtown” and the tags are tied to art installations throughout the downtown area, the event (e.g., viewing art installations) may always be in progress, be in progress during daylight hours, be in progress during business hours, or any other designation/definition of being “in progress”. In an embodiment, event “in progress” determination is made (step 418) using the tag ID, proprietor ID, venue ID or combinations thereof. If a venue hosts more than one team, organization, or the like, the team, organization, etc. is assigned a team ID or equivalent thereof. Since the team ID is tied to the tag ID, proprietor ID and/or venue ID, it too may be used to determine if the event is in progress. Generally, each event is assigned an event ID to identify a particular event to the platform (20). Thus, to determine if an event is in progress, the platform (20) tag ID may be used to determine the venue, and the venue ID may be used to determine which event has an “in progress” time corresponding to the time that the tag was scanned by the user device or time close thereto. The event ID for the event in progress may be tied to the unique ID, tag ID or both, or any other relevant identifier. Thus, the unique ID, tag ID, and/or event ID may have one or more time stamp, counter, or both recorded therewith to approximate the time that the event user device (14a) scanned the tag (16a) while the event is in progress. In other words, the unique ID, tag ID, and time event in progress determination may be recorded for later use, in certain embodiments. If an event is determined to be not in progress, the event user device (14a) may be redirected to a default or fallback target (step 422) such as a Web page for the venue, proprietor, team, etc., 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. [0199] If the event is in progress, the method (400) may also determine if the tag/tag ID belongs to a group (step 420). 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 nonlimiting example, in the stadium of FIG.2, the tags (16a) may be grouped by seating type or section (e.g., FIG.2, 222, 224, or 226), e.g., VIP seats may belong to one group, loge seats to another group, and discount/student seats may belong to yet another group. If data linked to the tag ID indicates that the tag belongs to a group, the event user device (14a) may be redirected to a target for the particular group. For instance, the target for users sitting in VIP or loge seats may be a Web app associated with event that includes premium modules content, offers, and the like, whereas the target for users sitting in discount/student seats may be a Web app having content and features/modules that typically appeal to students, recent graduates, or the like. In an embodiment, tag groups may be turned on or turned off. For example, a tag group that may be relevant for one type of event may not be relevant to another type of event taking place at the same venue, such as a game played by a men’s team and a game played by a women’s team. Each event may have different tag groupings. Thus, a particular tag group may be created, turned on, and/or turned off, as desired or as is determined to be relevant for a particular event. Thus, the method (400) obtains the information it needs to determine the appropriate target to which the tag ID points or refers to while the event is in progress. In other words, the method (400) uses some or all of a target determination process (424) to determine the content or target a user device that scanned the tag should be redirected whether it be a default/fallback target or a particular version of a Web app or the like signed for one or more groupings of tags. As one nonlimiting example, a college campus may create a version of a Web app for a football game for each of the students/a student section of seats, parents/a parent section of seats, users who bought season tickets, parents who have made donations to the athletic department, and so on, each version including offerings determined to appeal to those users/tag groupings. Each version may be routed to the appropriate user, tag grouping, or the like using one or more of the unique ID, the tag ID, the venue ID, the event ID, the team ID, etc. Thus, the method (400) obtains the information it needs to enable the redirection (step 422) to the determined target for the user, seat, tag group, etc. In an embodiment, the information needed for redirection may include a URL for the target with parameters, values, patterns, or the like appended thereto such as a target ID to identify the target and the tag ID. [0200] Method (400) may simultaneously process other data, such as looking up information associated with the unique ID to determine the appropriate target for redirection, as is suggested by the example above. In embodiments, the platform may gather information relating to user activities via the unique ID, the tag ID, the event ID, and combinations thereof. In a particular embodiment, as soon as the target is rendered on a user device, each action that the user makes with respect to the target is recorded. Thus, the tag scan, the unique ID, the time and date of tag scanning, the venue ID, the event ID, and the target ID, or combinations thereof may all be recorded in association with the tag scan and/or the event ID. Any action that the user takes while using the target on the user device is recorded and stored in a database. User actions include without limitation, include selections, data input, voting, submissions, purchases, enter to win, wagering, viewing rosters, concession purchases, content viewed, coupons downloaded and other such actions and/or sub actions that the user may make while the user is interacting with the target during the identified event. Recording may stop when the user closes out of the target, the target is no longer available for use, when the event has ended, or combinations thereof. As one non limiting example, a target may offer an enter to win module. The enter to win module may be identified by a module identifier. When the user selects the enter to win module, this action may be recorded together with the module identifier. In this way, the number of users that selected the enter to win module while the event was in progress (or other designated data gathering parameter) can be determined either by a continuous tally, or a count at the time the determination is requested. Similarly, users that fill in fields for personal identification such as name, e-mail address, phone number, without limitation, and submit that information to the platform may also be tallied, or a number determined when a request for such information is made. Thus, the platform can determine the number of users who opened the enter to win module to the number of users that submitted an enter to win entry. Furthermore, the platform can record and save the personal information inputted in the fillable fields. This information may be tied to the event ID, the tag ID, the unique ID, the target ID, the module ID, or combinations thereof. Using the college football game as an example, it is easy to envision how data such as student or parent status, donation status, or some other criteria, may be used in the target determination process. If data associated with past activity (across the entire system [10]) attributed to a particular unique ID is not available on the platform, the platform may be able to import data about a particular user/related to a particular unique ID from a third party provider such as a ticket provider to assist in the target determination process. Likewise, the platform may be able to export data relating to a particular unique ID to a third party provider, other proprietor, or both. [0201] The method (400) is essentially the same when a request is received from a remote user device. In this case, however, the target determination process may determine that the venue is not an arena, stadium, or the like. Rather the venue may be a different tag containment designation/definition such as the stream, transmission, broadcast, or other similar content distribution mechanism in which the tag is installed or where the tag/MRC originated. Nonetheless, the venue ID is determined as is the event ID in an analogous manner. As some distributed content may be recorded, the platform (20) may determine if an event is in progress based on a timestamp or similar indicated tied to the recording. In such a situation, the determined target may be a different version than the one that was built for use while the event is live. Likewise, the determined target for remote users may also be a different version than that available to event users. The target determination process may be as easy as one target for the event, with customization per the unique ID regardless of the POI the tag points to, or several different targets/versions of a target to be distributed/customized based on the POI to which the tag points (seats, sections, rows, levels, etc.), a common characteristic tied to unique IDs (e.g., parent, booster club member, sponsor, season ticket holder, etc.), or both. [0202] 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 determined target. For instance, the method (400) may return a target ID to identify the particular target/version of the 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 determined 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. [0203] In an embodiment, the target is a web app such as a progressive web application. As one non limiting example, the target is a fan portal (218). The fan portal (218) or version thereof are each identified by its own target ID. The fan portal (218) may include application code wrapped or embedded in an HTML document. Application code includes, but is not limited to, web application code, progressive web application code, cloud based application code, 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. As is used herein, the term “user interface” and/or “graphical user interface” (UI/GUI respectively) may be used colloquially to refer to the format/layout of the web application. [0204] 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 the circumstances under which a particular tag (16A) is scanned. For example, venue (202) hosts many events over the course of a season, year, decade, etc... Each event may have its own target with its own target ID as the individual events are distinct and identified by their own distinct event ID’s. For example, the fan portal (218) may be the target of a game in progress, such as the football game shown in FIG.2. The game in progress is between team A and team B. The next game, or other event, hosted by the venue (202) may be a soccer game; thus, the fan portal (218) for the soccer game is different from the fan portal (218) for the football game. In other words, the two fan portals (218) are distinct targets for redirection. As such, information related to each distinct target and its corresponding event, team, or the like, are tied/linked via respective identifiers. For example, the tag that is scanned by the user device is linked to the venue in which the tag is installed and the event that is determined to be in progress, which is either the football game or the soccer game. If the football game is determined to be in progress, then the target is the fan portal (or a version thereof) for the football game, and if the soccer game is determined to be in progress, then the target is the fan portal (or a version thereof) for the soccer game. Thus, identifiers for each of the forgoing help ensure that the user device is redirected to the intended/determined target for the event, in the venue, owned/operated by the proprietor all in response to scanning the same encoded tag (installed in the venue) with a user device even if it is the same user device. If for some reason the target determination process fails, the user device may be redirected to a default/fallback URL or other page indicating that an error has occurred. It should be understood that forgoing example is illustrative, and embodiments are not limited. A given tag may be used by a proprietor to redirect a user device to any desired target. [0205] In an embodiment, a target, such as the fan portal or another web application based target may be turned on and turned off. For example, a fan portal/versions of the fan portal may be built for the football game between home team A and away team B. The teams only play each other once a season. The date, time, and venue in which the game is to be played can be determined before the season starts. Thus, the date and time when the game will be in progress is known. The fan portal/versions of the fan portal may be built (in whole or in part) in advance of the game. It is generally desirable to have the fan portal(s) available to event users before and/or after the game is actually in progress. Thus, the fan portal(s) may be turned on at a time before the event is in progress and turned off at a time after the event is in progress. If the fan portal or another target is turned off, then the target determination process will return a different result such as a default target/fallback URL. If the target is turned on, then it is available as a potential result of the target determination process. The ability to turn on/off a particular target may assist in accurate target determination. For example, if the fan portal(s) for the football game are turned off then they cannot be an outcome of the target determination process while a soccer game or other game is in progress. Scheduling software may be used to turn on and off targets linked to a particular event, venue, team, proprietor, or combinations thereof. If an event is a perpetual event, occurs daily between daylight hours, business hours or the like, one or more interactive targets built for the event may be turned on and/or off at scheduled times or they may be kept on without being turned off, at least until a given build is retired or replaced. As such, user actions related to a particular target (e.g., Web app) can be recorded as long as the target is turned on or opened on the user device. [0206] As targets are linked/tied to a particular event, venue, proprietor, team, etc. data may be recorded so that it may be recalled/retrieved as a function of the event, venue, proprietor, team, sport, etc. In a preferred embodiment, all data gathered via a particular target is recorded in association with the event identified by the determined event ID/identifier. Once recorded, however, data may be moved/copied to different levels (e.g., proprietor, team, sport, venue, etc.) and/or parsed, redistributed, exported in a variety of different ways so that data retrieval/display may be achieved at various levels of granularity. As one non limiting example, data such as the number of tags scanned during the event may be retrieved and displayed to show the total number of tags scanned while the event is in progress at the time the data retrieval was requested or after the event/targets are finished/turned off. The number of tags scanned may also be displayed as a different function such as the section, level, row, etc. of an arena, stadium, etc. or however the POIs for a given venue are defined (e.g., room, art installation, person, etc.). As another example of various levels of data retrieval/graphical display, a web application or other target may include one or modules such as the modules shown on fan portal (218) or the Game Day Program (1600) shown in FIG.12. In addition, each target (e.g., fan portals/game day programs) having its own target ID/target identifier, each module offered in the particular target has its own module ID/module identifier, which is related to the particular target such as via its target ID. Thus, each user action with respect to each module, action within module, or other engagement action in association with the target/web application, among others may be recorded in conjunction with the particular event, such as was previously described with respect to an enter to win module. Thus, data relating to user action within a particular target may be retrieved and graphically displayed at various levels of granularity while an event is in progress, after the target is turned off, or both. Examples of levels of data retrieval and display (e.g., via the proprietor portal/administrator device) include total number of modules viewed, module views by module type, tracked activity within the module (e.g., purchases made and for what, food purchases, content viewed, coupons used, coupons downloaded, submissions made, merchandise viewed but not purchased, fan filter use, map use, wagers made and won/lost, NFTs acquired, wallet offers viewed, used, downloaded etc.), total module/particular modules used/viewed by seating section or other POI parameter and much more. Data retrieval, analysis, and/or display (graphically or otherwise) may also take place on the level of one or more unique IDs, across several events at the same venue, at different venues owned by the same proprietor, or combinations thereof. For example, data related to unique IDs, or any other identifiers may be searched, filtered, or both to identify various commonalities, trends, habits, etc. In this and other ways, proprietors may analyze collected/recorded data to determine what content, modules, offers, coupons, food choices, merchandise choices, etc. are the most frequent with respect to a particular unique ID, tag ID, tag ID grouping, unique ID grouping, demographic, venue, seating section, etc., which may affect future module offerings, discounts, tag groupings, unique ID grouping, target versions, rules, etc. made in the future. Similarly, platform personnel may make similar inquires across the entire platform, for a particular proprietor, venue, event, and/or other levels of data aggregation such as any level, grouping, date, time, frequency, or the like associated with an identifier. [0207] A proprietor may also change a target during the course of a particular event. For example, an initial target at the beginning of an event may be a fan portal such as the fan portal (218) shown in FIG.2. A user may access the fan portal (218) to partake in activities such as buying food or merchandise, placing a wager, view replays (220), the delivery of content based on a trigger, etc. At some point during the event, targets may be reassigned by changing target IDs or simply turning desired targets on or off. As a nonlimiting example, a tag scan may be related to dynamic content. At any time during the event, the jumbo screen (204) may display a hidden “unique offer” (214) that is only available to the first 1,000 (or other number) users who respond to the “unique offer” (214) after it is displayed on the jumbo screen (204) by scanning a tag (16a) or the like. A countdown (216) on the jumbo screen (204) shows the number of event user devices (14a) that have claimed the “unique offer” (214). When the threshold number (e.g., 1,000) is reached, the unique offer may be revealed and is no longer available to any other users. This countdown and the limited nature then become a type of dynamic content. One way an event user may respond to the hidden “unique offer” (214) is by scanning or rescanning the tag (16a) while the unique offer (214) is available. In this case, the user device (14a) may be redirected to a Web page or the like, for the unique offer (214), e.g., to input information, make payment, or the like, per a process that is the same as/similar to the method (400), especially if the tag scan for the “unique offer” (214) is the first time the user device is used to scan a tag during the event in progress. The redirect target (e.g., via a target determination process) of this scan, however, is the “unique offer” (214) and not the fan portal (218). Another way a user may be able to respond to the “unique offer” (214) is by a pop-up window (e.g., in/over the fan portal [218]) or the like, which may be pushed to some or all user devices currently engaging with a target via the socket server (324) in a nonlimiting embodiment. Thus, the term “target” should be broadly construed although it may be described herein with respect to obtaining a fan portal (218) or other specific examples. One of ordinary skill in the art would understand a target of redirection as described herein may be a multitude of different targets with various purposes, designs, capabilities, and the like. Therefore, the target to which a particular tag (16a, 16b) is assigned, may be changed by simply changing the target identifier (“target ID”) associated therewith. [0208] 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 nonlimiting example, the target delivered as a result of the target determination process (at 424) detailed in FIG.4 may include a Web application, such as a progressive Web application (PWA), that has a pull function, which may be rule-based. The pull function, as one nonlimiting example, may be time based, requesting information to be pulled from the platform (20) via the interface server (306) every 10 seconds, minutes, N seconds, N minutes or the like. As another nonlimiting example, the pull function has the ability to have data updated on a rolling basis. In the sporting world, this is common when updates are provided to the score of a game, the time left in a game, or both as nonlimiting examples. The platform (20), however, may push rolling data to a user device (14a, 14b) instead of having it pulled from the platform. Pushed data may be sent to user devices (e.g., 14a, 14b) without being requested. Data may be pushed to a user device (14a, 14b) for any number of reasons, a few of which are detailed herein. Thus, information, data, etc., may be pushed to a user device (14a, 14b), pulled for a user device (14a, 14b,) or both. In many instances, a Web application or the like may be based on a template having dynamic elements embedded therein. The contents of such dynamic elements may be altered via push techniques, pull techniques, or both. Content, data, information, and the like, may be pushed and/or pulled via a socket connect utilizing a socket server (324) or any other socket connection, communication connection, protocol, or combinations thereof as is available to the platform (20) under a set of given circumstances. [0209] The method detailed in FIG.5 may be invoked while the target of redirection (e.g., fan portal [218]) is loading on the requesting user device (e.g., 14a and/or 14b), after the target is already loaded on the requesting user device (14a and/or 14b), or both. As with all methods detailed herein, steps in the method (500) may be used in whole or in part, in the order shown or a different order, be executed on one device or more than one device, be used in combination with some/all of the other methods described herein or as is known in the art, or combinations thereof. [0210] Using fan portal (218) as a nonlimiting example while referring to FIG.5, oftentimes it may be desired to alter information, regardless of type (e.g., video, images, instructions, etc.,) while the user is using the fan portal (218). Information may be altered using push, pull, and other techniques, taking advantage of the communication connection (504). The communication connection (504), which may be a socket connection or any other appropriate type of connection, allows communications between the user device (14a and/or 14b) and the platform (20) via the one or more networks (18). A controller (at 506) may be a set of software code for managing, directing, or generally being in charge of one or more rules, enabling pushing and/or pulling of information per the rules. In this example, rules may be used to change content on the user device (14a and/or 14b). The interface server at (510) may be the same interface server shown in FIG.3 (306), just at the data sources at (512) may be the same data sources shown in FIG.3 such as database (308), administrator server (310), analytics server (312), blockchain (314), geofence (316), time (318), third party integrations (320), and proprietor portal (322), without limitation. Moreover, interface server at (510) may facilitate utilization of the forgoing, in the same manner or similar manner as described with respect to FIG.3. Thus, in a sense, user device (14a or 14b), communication connection (504), interface server (510), and data sources (512) are shown in FIG.5 just to help the reader visualize interactions detailed in FIG.5. [0211] Examples of rules that are detailed with respect to FIG.5 include event rules and local rules, although embodiments are not so limited. Generally, an event rule is monitored by the platform (20) and if satisfied causes data to be pushed to one or more user devices (14a, 14b) and a local rule, when invoked, causes a user device (14a, 14b) to request data (i.e., pulls data) from the platform (20). An illustrative example of an event rule is if team “A” scores a touchdown, push a digital offer to all user devices (14a, 14b) that have scanned tags (16a, 16b). Here, the metric or trigger of the rule can be monitored (step 516) such as by directly sending a request or query to a data source (at 512) via the interface server (at 510), receiving data from the data source (at 512) on a regular basis such as every 5 seconds, 5 minutes, or the like (via the interface sever [at 510]), or combinations of both. The platform (20) may monitor for the metric/trigger e.g., a touchdown (steps 515/520) and continue to do so (step 522) until a metric/trigger e.g., a touchdown has occurred (step 520, yes). If the rule has been satisfied, the platform (20), can push the digital offer to all of the qualifying user devices (i.e., that have scanned a tag [16a, 16b]). [0212] 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. [0213] Local rules, as an example, may be tied/linked to one or more targets being utilized for a given event. Referring again to FIG.2 as one example, each section of seats (222, 224, 226) may represent a grouping of tags (16a) such as student/discount seats, loge seats and all other seats. As such, when a tag (16a) is scanned by a user in section (222) the device (14a) may be redirected to first version of fan portal (218), when a tag (16a) is scanned by a user in section (224), the user device (14a) may be redirected to a second version of a fan portal (218), and when a tag (16a) in section (226) is scanned the user device (14a) it may be redirected to a third version for a fan portal (218). Thus, all users may be redirected to a fan portal (218), but each fan portal (218) may be a different version, each version having its own target ID. In this way, a proprietor may deliver customized content to users in different sections based on the version of the target application to which the user device (14a) was redirected. Local rules, other elements, or both may be written into each version to further customize content, which in some instances may be on an individualized level. That is, elements of application code may written as rules built into the system to provide the content delivery determined by the system by the target determination process and/or rules, which can be an additional feature of the target determination process. For example, rules may be applied during the target determination process using data tied to a unique ID, tag ID (e.g., tag group), or both to redirect to a determined target pointed to the pre the required rule. [0214] Referring back to FIG.5, the interface server (306, at 510) may determine, or cause to be determined, if there are any rules associated with a given version of a target (e.g. for fan portal [218]) or another target. This is especially true where the rule may be designed as an event-type rule where content may be pushed to a device (14a). In this case, however, the rule may only be provided in a given version of a target (e.g., for users sitting in loge seats). A given version, however, may also have local rules written therein. For example, a rule associated with a fan portal (218) version to be distributed to loge seats, may be: if the user has season tickets, then include a digital offer for discounted season tickets for the following year. Thus, per this illustration the local rule may desire to pull/acquire (at 508) season ticket information before, during, or after the version of the target determined/identified for the loge seats is loaded on the event user device (14a). To obtain this data, the database may be queried (at 512), via the interface server (at 510), using the unique ID to check data records for the requested information (e.g., purchased season tickets). As with the push example, if the database (at 512) does not store such information, the information is inconclusive, the local rule requires confirmation from an outside source, or other such situations, other data sources (at 512) may be consulted via the interface server (at 510). If the local rule is satisfied, then a digital offer for discount tickets (next season) is sent to the target displayed on the event user device (14a). If the local rule is not satisfied, then the target version uses a “default” digital offer/content such as an ad for non-discounted season tickets, upgraded tickets for the next event to be held at the venue (202) or another, similar example. In an embodiment, data associated with the unique ID may be pre-analyzed to see if the local rule has been satisfied. Alternatively, data associated with the unique ID may be gathered (e.g., from a database, a third-party integration such as a ticketing service, or the like) and analyzed when the event user device (14a) makes the request. As yet another option, the data may be pre-analyzed and verified/checked for changes upon the event user device (14a) request. The interface server (306) may take all of the variables from the version of the target application code, rules, and the like and send requests/queries to the appropriate data sources or links (e.g., via, API, URI for file transfer, standard mail transfer protocol, etc.) to the data sources (at 512). The data sources may include data from the database (308), blockchain (314), geofence (316), timestamp (318), third party integrations (320) such as data servers/databases, analytics server (312), and administration server (310), and a counter (at 512), without limitation. [0215] In some implementations, a counter may be needed. For example, a counter may be enabled to maintain the countdown shown in FIG.2 (216) to count the number of tags scanned during an event, or for any other counting purpose. A counter may be software on platform (20) that may be used as a counting mechanism for rules, usage metrics, or other reasons. As such, the counting mechanism may be configured to meet the counting requirements of a rule metric or other counting need. To illustrate, a counter may count the number of tags (16a) scanned in a venue (202) during a particular event; count the number of tags (16a, 16b) scanned by a particular user device (14a, 14b) in a predetermined time window; count the tags (16a) scanned by a particular user during a particular event; count the number of times a user has interacted with the target/target modules delivered to that user device; aggregate counts from various events, venues, proprietors, teams; segregate counts by seat, section, row, level; or other such nonlimiting illustrations. [0216] 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 FIG.5. However, dynamic updates/changes may further take place through the use of various third-party application programming interfaces (APIs) and their respective functionality. At a high level, the interface server (306) may connect, or may cause the third party integration server (320) to connect, to third-party hardware/software (e.g., server) via one or more third-party APIs/API calls to access the respective third-party integration/functionality as is known or will be known in the art. Thus, third-party integrations/functionality may push or pull information through analytics server (312), retrieve it from database (308) or another data store, or combinations thereof, for real time/live streaming, updating, changing, and the like as is called for by rules/ instructions associated with the target pointed to by the tag ID or other controlling factor. Furthermore, embodiments allow for the use of interactive, two-way communications between user devices (14a, 14b) and the platform (20) such as via the socket server (324) and/or a socket API, or the like as is known in the art. As yet another option, dynamic content may result via a URL or other link to an external source, which may change in its own right, aside from the target being displayed. Certain communications may then end, such as upon the end of the event, the target/module is turned off or where the user closes the target application, where the communication (at 504) is severed. [0217] As is also indicated in FIG.5 at (508), the platform (20) may collect a large amount of data via user devices (14a, 14b). For example, after scanning a tag (16a, 16b) the platform (20) may receive data from the user device (14a, 14b) such as date, time, and GPS or other location (although not required), the device orientation (i.e., landscape, portrait), type (e.g., iPhone, Android), browser type, IP and other addresses, and operating system as a few examples. Thus, methods such as methods (400, 500, or both) may be configured to collect and aggregate data. As was previously detailed, every action that the user makes via the user’s device (14) with respect to the platform (20), event, determined target for the event, modules/module activity within the determined target is recorded/stored and tied to one or more of the forgoing via their respective ID and the unique ID assigned to the particular device, tag ID assigned to the tag (16) scanned by the particular device. Additionally, tools such as cookies, widgets, plug-ins, and similar tools may also be used to obtain data from user devices (14a, 14b). This, and other, information may be stored in a data source (at 512) such as database (308) or other data storage and in association with the unique ID, tag ID for scanned tag, event ID, target ID, module ID, etc., so that related data may be searched, filtered, counted and other manipulations in a wide variety of different ways. Data acquired using the aforementioned tools and other tools/techniques may relate to user engagement with a target such as a fan portal (218) as one nonlimiting example. Such data may relate to digital offers presented to the user, digital offers downloaded by the user, products viewed by the user, purchases made by the user, to name a few examples. Such tools/techniques may also gather data relating to other user engagements such as total screen time, Internet browsing (times, sites/pages accessed, software used), updates to Web pages, other Web sites visited, the Internet, and the like. The user may also directly provide information via the user device (14a, 14b) such as by inputting personally identifiable information to obtain opportunities or offers such as unique information relating to user interests, user responses to questions, generic information about age or sex, or any other type of personally identifiable information. Such data is of high value to, for example, advertisers, proprietors, and the like, as it provides a large insight into consumer purchasing and Web browsing habits. In this way, customer relations management (CRM) systems can be utilized to mine the data, associate data with a unique ID, and provide content to the user via the user device having the unique ID. [0218] TRANSFERRING COLLECTED DATA TO A THIRD PARTY: In an embodiment, some, or all of the data (e.g. all user actions relating to the platform) aggregated while an event is in progress may be transferred to a third party such as a customer relationship management (CRM) system and/or data management software, without limitation. The data selected for transfer may be transferred in real time, during the event and/or after the event has ended. Furthermore, the data selected for transfer may include one or more identifiers understood by the third party to identify platform (20) users to the third party such as an email address, phone number, or other such personal information. In this way, the third party may use a person’s personal data to determine if the third party already has a file corresponding to the person identified by the personal data and add the transferred data relating to that person to the file. If a file cannot be found, the third party may create a new file for a new person and add related data thereto. Transfer may occur via an API or simple mail transfer protocol (SMPT). Adding data acquired via the platform (20) to a third party system may help build a more robust picture of an individual user, total fan behavior, or both. Having a broader picture of individual and/or total fan behavior may be used to provide heightened marketing, offers, content, and the like to individuals, groups, and/or an entire fan base via the platform (20). As one non-limiting example, a heightened marketing campaign may be incorporated into one or more versions of a web-based application for an event in progress or a future event. As another non-limiting example, aggregated data may be available to the proprietor, the venue, a team, or the like directly or via a third party system so that past user actions may influence future user experiences. For instance, gathered transactional data, browsing data, and the like may be analyzed to enable the platform to use the unique ID received in response to a tag scan to determine that the user has ordered only hotdogs at the last three events attended at the venue. As a result, the platform may cause the first item the user sees on a concessions menu to be hotdogs. Other customizations may also occur such as offering the hotdog at a discount price as a form of customer appreciation. As another example, the platform may customize digital wallet offers, discount codes, and/or exclusive content to the user in the same or similar manner. [0219] 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 user’s information/unique ID, tag/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 ID/information, or combinations thereof. As one nonlimiting example, service providers such as mobile/cellular providers may be queried to obtain information about user devices (14a, 14b). The unique ID or other information identifying a particular user/user device may be sent to the service provider to obtain information about the particular device, and/or user of the 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) and data related thereto. As another nonlimiting 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 their respective identifiers, target identifier, event identifier, tag ID, the unique ID and combinations thereof. 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 and record that information so that it relates to a unique ID, other relevant identifier or combinations of identifiers. Such information can then be utilized by CRM entities to provide content to such users who meet a specific criteria, because the unique ID allows for control of the data, which defines the actions performed by a given user. [0220] In addition to collecting and storing data associated with unique ID and other identifiers, the platform (20) may analyze such data, the analysis of which may or may not be recorded in association with unique IDs and/or other identifiers. 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, metrics, 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 nonlimiting example or any other identifier as is appropriate for the situation. For example, during and/or after an event, the platform may determine how many tags were scanned, how many enter to win offers were opened/submitted and graphically display the data, couple the data to corresponding identifiers and/or new identifiers and more. [0221] 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 emails, push content, 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 related thereto 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 FIGS.4 and/or 5 and that data/information gathered as the user is engaged with the event target or the like, may be used to update/modify target content in real time, upon a subsequent scan of tag (16a, 16b) by the user device (14a, 14b), or both (e.g., at 508). For example, the socket connection (at 504) may be used to deliver pulled content, push content, notifications, and the like, and/or dynamically update content while the event is in progress. Indeed, such socket connection may be particularly useful where a plurality of users are online at one moment and the total creates an occurrence of a trigger which provides some dynamic content to be released, for example, through a push of that target to the then active user devices that have met the limitation to receive that target. [0222] 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, e.g., such as by tracking engagements with a module, other target uses, etc.. 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. [0223] USER VALUATION: In an embodiment, the value of a user to a proprietor, a group of proprietors, a third party (e.g., advertiser, CRM system, ticket broker, etc.), and the like may be appraised. The value of the user is based on data relating to the user and acquired by the platform in ways that have been previously described. As a recap, data may be acquired by the platform via a web-based application, or version thereof that is built for a particular event taking place at a particular venue. For example, the web-based application may be a fan portal built for a football game taking place at Lincoln Financial Field, home of the Philadelphia Eagles. Users may use their own devices (e.g., smartphone) to scan a tag that is associated with the seat in which they are sitting. Each user device has platform- assigned unique ID assigned thereto or that will be assigned thereto upon first engagement with a tag installed at/for any venue. Each tag at all venues has a tag ID, which is transmitted to the platform by the user device and in response to scanning the tag. That is, when a user device scans any tag, the user device is automatically pointed to the platform via a URL or the like. The tag ID, in an embodiment is part of the URL and as such is transmitted to the platform with the request. Thus, as a result of scanning a tag, the platform receives the tag ID for the scanned tag and the unique ID for the user device from the user device, if the user device already has an identifying unique ID assigned thereto. The platform may use the tag ID to identify one or more of the venue that it is tied to (e.g., Lincoln Financial) , the event that the user is attending (e.g. Eagles v. Dallas), or the seat in which the user is sitting (e.g., level 1, section 500, row 10, seat 2). The platform may also identify data tied to the unique ID. The platform can use the tag ID, the unique ID, the event ID, the venue ID, or combinations thereof to determine the web-based application or version thereof (e.g. fan portal for Eagles v. Dallas) to which the user device is redirected. Each web-based application built using the platform has a target ID assigned thereto. Each target ID may point to the event that it was built for, the venue in which the event is or will be taking place, the tags installed with/for the venue, the teams playing the game, the owner/organization that is the customer for the venue, the type of sport being played, etc., each identified by its own respective identifier, and each of the forgoing may point to/be tied to one or more of the other. Thus, complex relationships for users, venues, customer proprietors, events, etc. can exist. Data gathered via the web-based application is collected for each user engaged with the application (and versions thereof) and is recorded based on the event, user, tag, venue, etc. individually or in combination. All user actions relating to the platform and web-based applications are recorded as data so that multiple metrics at multiple levels of granularity may be discerned by the customer proprietor, third party, platform personnel, for a venue, event, user, plurality of users, web-based application use, and much more. For example the number of users that have scanned a tag while at the football game may be counted, analyzed, displayed, etc. Additionally the number of users that opened a module such as an enter to win module may also be counted, analyzed, displayed, etc. Furthermore, the number of users that submitted identifying information such as name, phone number, address, email address, etc. in order to enter to win may be counted, analyzed, displayed, etc. Such actions are recorded for each user engaging with each redirected target at each event at each venue supported by the platform. Thus, a plethora of data can be collected, stored, analyzed, searched, filtered, etc. to identify a wide variety of user habits, groups of user habits, trends, etc. based on data aggregated by the platform. [0224] Data collected/aggregated by the platform can be parsed, digested, grouped, compiled, etc. into formats/metrics that are easy for teams, owners, venues, artist, etc. to view and digest. In this way a proprietor user can take a detailed look at user content consumption, purchasing habits, activity habits, etc., that can be used to create a valuation/scoring system useable by proprietors, proprietor users (e.g., administrators, teams etc.), third parties, and the like. For example, each user associated with a unique ID can have one or more score in their file/records, such a score from 1-100. The score may indicate the likelihood of the user performing a desired action such as purchasing tickets, buying season tickets, buying merchandise, etc. In an embodiment the user may have multiple scores, each assigned to a different desired outcome based on the user’s past engagement data. For example, Jimmy has a score of 85 for likelihood of purchasing season tickets, a score of 22 for purchasing a single game ticket, and a score of 87 for purchasing a new jersey that is released by the team. In an embodiment, a score may be expressed as a dollar amount. A dollar amount score may indicate how much the user has spent across merchandise, food and beverages, ticket sales, etc. In an embodiment, a dollar amount score can be placed in Jimmy’s file to indicate the likely value of how much he will spend in each monetizable category for the current season, future season, lifetime, etc. The collected/aggregated data can be a data that is collected via the platform alone or in combination with third party data. [0225] Aggregated data can also be parsed, digested, grouped, compiled, etc. into formats, metrics, scores etc. based on tag ID installed in a venue. For example, the aggregated data may be analyzed to determine the likelihood of an occurrence and assign a score thereto. As one non-limiting example, the platform may determine there is a 73% likelihood that users sitting in a lower level of a venue will purchase season tickets and compare it to the 22% likelihood that users sitting in the uppermost section of the venue will purchase season tickets. Furthermore, because the platform identifies each event by an event ID, it is possible for proprietors and their personnel to view scores, numerically or in dollar amounts, across different types of events based on the event ID’s and for any data category, type, action, etc. As one non-limiting example a proprietor may ask the platform to show it the likelihood that attendees sitting in lower level seats will purchase a hotdog at all country-music concerts held in its venue. As with other data, scored data may be transferred to a third party such as a customer relationship management (CRM) system, data management software and the like as described above. [0226] 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. [0227] 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 tag installment 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 determined 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 nonlimiting 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. Much the same as a user at the event, the Unique ID tied to the user, and who scans the tag, provides data and information regarding the habits of a remote user. Because of their remote location, it may be further advantageous to geolocate the user device, as a further requirement before sending content to said user, in order to provide the most relevant content. The data corresponding to the remote user can then be tracked and filtered as with any other user, allowing for mining of data of remote users who access the system remotely. [0228] 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 nonlimiting 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. [0229] Historic sites, museums, zoos, cities and the like may use any of the forgoing tag installment strategies and other unique tag installment/use strategies to enhance visitor experiences via one or more targets of a tag (16a, 16b). As one nonlimiting example, tags (16a) may be located at or near entrances for users to scan with their devices (14a) to obtain the determined target for those tags (16). 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 nonlimiting 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. [0230] The system (10) therefore can be implemented in entertainment venues, as well as other venue-defined areas where user engagement is desired and/or required, such as college dorm rooms, hotel rooms, cruise ships, trains, aircraft, rideshare vehicles and the like. Thus, users become familiar with the benefits of system-wide use via a variety of proprietors implementing the platform (20), and proprietors gain an appreciation of their users and how the users interact with their services. While some examples of the uses of this system are discussed herein, the scope of the present invention should not be limited to the specific examples provided, and the terms “venue” and “event” should be construed to include alternative or equivalent embodiments which could be devised based on details herein. [0231] As discussed in greater detail below, a differentiator of the platform (20) is that it uses data input from several variables in order to provide real-time content to the end user, specifically at a trigger of some predefined requirement or rule. These data sets can be from a multitude of sources such as ticket brokers, which can provide details on a user who purchased tickets to an event, or to advertising database data, which can provide past content interactions from various sources on and off the Internet for a particular user. These analytical datasets can also be used to provide in-venue content or offers to users inside of an event on an individual basis, on a group basis, or to the whole venue based upon the collected data/feedback gleaned from users at an event (i.e., if the analytics portal data reveals that 75% of users select hamburgers as their favorite type of food, the in-venue multimedia displays could be triggered to display content relevant to the selling of hamburgers). The platform (20) can also implement machine learning algorithms which, when coupled with a combination of some or all of the data provided from the analytics (312) and database (308), can provide real-time content that is predicted to be favorable to the end user. The fan portal can be in various forms from browser-based Web pages, cloud-based Web apps, progressive Web apps, downloadable apps, etc. The platform (20) could provide multiple options to the fan portal such as ordering food, purchasing merchandise to be delivered to a seat location, viewing replay footage, and/or placing wagers inside of the stadium. The platform (20) would provide the ability to offer all users engaged with the platform (20)/event target determined by the platform (20) the same interactive content options, or to offer different content to users based on predetermined data sets or based on variables and data within the system. [0232] Because of the known location of the tag, whether static or movable, the precise location, or GPS location can be utilized as part of the data to generate content to the user device. Similarly, an API related to a vehicle can be used to identify a starting location and an ending location of the vehicle trip, to the extent that one is available. Accordingly, via the API data can be provided to the platform (20) that identifies the planned route of the vehicle and content relevant to that particular location may be provided to the user along that route, which may be attractive to the user. Data from the views, page views, time spent on a page, advertisements viewed, or digital offers downloaded by the user can provide further data regarding the habits or interests of the user and can be further utilized by the platform (20) to generate unique and individualized content to the user. [0233] A unique feature of one embodiment of the methods and systems detailed herein is the generation of unique content upon the aggregation of a total number of users within a particular event, multiple concurrent/overlapping events, in which the group as a whole is responsible for meeting a threshold to access content, digital offers, or combinations thereof. [0234] For example, Home Team has announced that they are providing a unique digital offer to all fans in the stadium if x number of fans are all on the system at a given moment. Home Team has a total of 10,000 fans in attendance and the unique digital offer is being triggered upon meeting a threshold of 1,000 fans all being engaged with the platform (20) at a given moment. Upon meeting the threshold, a unique digital offer is provided. This would be operable, as detailed in FIG.6. [0235] A first user, and a plurality of users would use a user device (14a) to scan a tag (16a) having an MRC (17a) therein, for example on a seatback (210). Scanning by the user device (14a) engages the redirect/identification server (302), and to the interface server (306) as described with respect to FIG.4. Here, the target determination process (644) includes a rule that is defined by requiring a counting of a total of 1,000 user devices being active on the platform (20) at a given moment. Accordingly, a counting module (602), receives and manage the number of user devices active on the system at a given moment from the interface server (306). The threshold being the 1,000 active users, provides that the database is storing a particular target, which is the release of a special coupon for a free hotdog to all active users. The counting module (602) receives and tracks the number of active users as it increases or decreases. For example, the counting module (602) may count the number of tags scanned as they are scanned by the user device. The counter (602) may export the current scan number to a routine that subtracts the number of users that closed out of the target from the current number of tag scans to determine a current number of active platform (20) users. Alternatively, the counter may simply determine the number of active target users on an ongoing basis as part of monitoring the rule criteria, or similar set up. The foregoing are just a few non-liming examples of how a counter may manage counting the number of active users that is dynamically changing. The counting module (602) may also populate or display the total number of users, either on the user device (14a) within the fan portal, on the jumbo screen, on a video display, or combos thereof. Upon meeting the 1,000 active user threshold, the target determination process receives confirmation from the interface server to retrieve the target, being the free hotdog, and then pushes that information form the database to the interface server (306), through the redirect/identification server (302) to the user device (14a). Thus, as the target is pushed while users are engaged with the platform (20), the pushed target may be a target determined via the target determination process or a component thereof (e.g. module, popup, etc.) for users who are in the process of initial target determination or it may be a “rule target” that is added to a dynamic element of a target application, overlayed over the target in use on the user device, a popup, a new module, a redirect from the target in use, or the like. Alternatively, the rule target may be sent to the user device apart from an active target/target in use such as via SMS, MMS, email, etc. [0236] The venue can then set this particular rule, wherein additional users, who later access the system may also receive the offer, or only users within x number of minutes receive the offer, or any other rule as determined by the proprietor. The user can then use the free hotdog offer. As the platform (20) is gathering data while users are engaging with their determined targets, the platform (20) knows/can determine the seat of each user awarded with the 1,000 hotdogs and could automatically deliver those hotdogs to the users in the determined seats, as it would have the tag ID corresponding to each seat. Otherwise, the user could request the hotdog be delivered, and have it brought to the user’s seat by accessing this option through the fan portal, or the user could walk to a concession stand to redeem the free hotdog using the digital offer delivered to the user device. [0237] RULE-BASED OFFERS: In an embodiment, a rule may be defined to cause an offer to be presented to users engaged with a web-based application such as a fan portal while an event is in progress. For example a rule may be defined to release tickets to a subsequent event at the venue in which the user is currently situated or a venue in which a home team is playing the next game, the performer is making his/her next performance or the like. The rule may be a server side rule or a device side rule; either way the result is the same or similar—if the rule is satisfied the tickets are released. The rule may be triggered in response to detecting that the current event is at the end or about to end, that the home team is going to win/has won, or another such triggering event. The ticket offer may be released to users via a variety of mechanisms such as unlocking a module within the web-based application, pushing content to the user device, redirecting the user device to an external website that sells the tickets, or updating a dynamic element within a module of the web-based application, without limitation. [0238] As another example, the rule may be defined to offer an item for sale in response to a threshold number of users engaging with the platform, preordering the offered item, or another such trigger. As was previously explained, the platform may count the number of tag scans such as while an event is in progress. This is a non-limiting example of how the platform may determine if the threshold number has been met. The threshold number may be any number, which may be based on expected event attendance, maximum occupancy, or an arbitrary number. And the offer may be any offer such as for food, merchandise, discounted items, experiences (e.g., backstage passes) or any other purchase that may be made in conjunction with the event. If the threshold number is met, then the offer may be released such as by mechanisms detailed above. [0239] FIG.7 details this in a flow diagram (700), with the first step (702) being to scan the tag. The user is authenticated, verified (704), as detailed in FIGS 4 and 5. As each user ID passes through the interface server, a request is received at the target determination process which is recapped in part at step 704, is modified to incorporate a rule into the process. Here, the rule indicates that when 1,000 users are online, a free hotdog will be provided to those 1,000 users. When less than 1,000 users are online, then the target determination process (706) occurs as was described in FIG.4 as the set rule has not been triggered (706). Meanwhile, the interface server then looks for the tag ID/unique ID to count the active user (708). However, upon the meeting of an occurrence of a trigger or threshold (710), and as further detailed by FIG.7, the target determination process determines that the rule of 1,000 users online is met (712) and triggers the release of the pre-loaded content (e.g., free hotdog offer). Thus, the target determination process identifies the target rule from the database (714), and whatever target material was predetermined. The interface server then instructs the redirect/identification server or other server how to release the content to the qualifying user devices. For example, a user device may be redirected to a URL end point, pushed data/socket pushed data (e.g., overlay, popup, dynamic content), a module/feature of a module that opens/turns on/updates when the rule is triggered, or otherwise provided through a Web app (718), which here is the digital offer for the free hotdog. [0240] Instead of a plurality of users meeting a threshold, a single user may need to meet some threshold, for example, scanning a tag at ten venues within the city, as shown in FIG.11. Joe user scans one tag each day for ten days (i.e., the tag at location [1101], the tag at location [1102] and the tag at location [1103]), and on the tenth day, upon meeting the requirement threshold, the unique content or digital offer is delivered. Thus, a new movie pilot is released, and the special digital offer is the first 500 users to complete 10 scans receive a special viewing of the movie. Joe User completes the task and is one of the first 500 users and thus receives the special digital offer. These elements are defined within the system described herein. [0241] Upon the occurrence of scanning into the system, the user and a unique ID are determined. The system can determine the total number of users on the system at a given time, i.e., the number of users who have scanned the tag (16a) within a given time period. In certain embodiments, the threshold may be defined as a total number of users who have scanned a tag (16a) during an event, and not simply who are presently online at a given moment. Thus, as in FIG.2, the countdown (216) may refer to the total number of scans from unique user IDs at the venue during a particular event. Even if individuals are not currently on a user device, the act of scanning the tag (16a) is sufficient for the purposes of unlocking the unique digital offer (214) or content. [0242] In other embodiments, the countdown (216) and the threshold are referring not simply to a single venue, but to the system as a whole across all venues and/or events, or proprietors who utilize the system. In such an embodiment, a plurality of tags at one venue or location and a plurality of tags at N number of other venues or locations are combined together. Thus, while a single venue may only have 10,000 unique tags, across the entire system, there may be 10,000,000 unique tags. This provides a much larger pool of users from which to access for generating the unique offer (214). In certain embodiments, once on the system, a user may need to engage with a particular element, a particular offer, or perform some action so as to be counted for the unique offer (214). [0243] For example, a new movie is coming out in the BEST MOVIE EVER series. The prior movies in the BEST MOVIE EVER series generated more than 1 billion in ticket sales and there is already interest in the next to-be- released film in the series. A special movie trailer is being advertised, but to date only teaser shots of a few seconds have been released. Upon generating 1,000,000 unique users to the system, the full movie trailer will be released. By scanning a tag (16a) a user and the user ID are engaged to the system and count as one of the 1,000,000 unique users. A threshold is set for 1,000,000 unique users in a time period t, which is set for three hours on a given day. Thus, unique IDs that are counted as entered into the system before that time period t and after that time period t will not count. Only those unique IDs on the system during the given time period t will count toward the n number. [0244] Alternatively, the movie trailer will be released if 500,000 unique user IDs are online and active within the system at any point during time period t. The system can track and identify both counting numbers and upon meeting one of the thresholds, release the full movie trailer. The full release movie trailer may be only provided to those users who are engaged in the system or can be released publicly at that point. The method here relates to communal interest in unlocking content. The proprietor, in this example, the movie company, may provide further digital offers to those users who participated, and, such digital offers can be modified based on the behavior and characteristics of the unique digital offer as it relates to the unique ID (i.e., the unique digital offer is shared on a social media and viewed 1 time as compared to a social media that is viewed 1,000,000 times). Such shares have significantly different value and thus the digital offer can be modified accordingly. These data points, of who engaged with the offer, who shared the offer, and the like, are tracked to the Unique ID. Such information may then be utilized within CRM solutions to further provide unique content to users based upon their particular actions and data within their Unique IDs. [0245] FIG.8 is a block diagram illustrating a further embodiment of the system (800). In this embodiment, the feature is determining whether a user is a new user or a returning user. This is important as a new user can claim a specific digital offer, but a returning user cannot. This way, when a specific offer is provided, a user can only obtain the offer once. Thus, following the logic of the prior figures, following a scan of the tag (16a) with the user device (14a), the user is redirected to a tag URL that is uniquely encoded to the tag (16a). The redirect/identification server (302) receives the tag URL request checks for a manifest and unique ID and if located, informs the interface server (306) whether the user device (14a) is new or a returning device into the system (10). In this embodiment, the interface server (306) includes a database (308) of unique IDs. If the unique ID is determined to be a returning user, for the purpose of claiming the digital offer, then that user is denied access to the digital offer to prevent the user from redeeming multiple digital offers. If the user is new and does not have a unique ID on his user device, the process of FIG.4 is followed to generate the same. Otherwise, if the unique ID is not new, but has not claimed the digital offer, the new user and returning, but unclaimed user, now claim the digital offer. The target determination process (844) determines what content to display based upon data received from the redirect/identification server (302), and the target determination process (844) communicates with the analytics portal (46), and the analytics database (66), in view of the unique ID (22a) to return a target (807) (FIG.6) through the interface server and redirect/identification server to the user device (14a). Notably, all of this information is stored in a database corresponding to the unique ID, so as to create a profile and information related to the user. [0246] By including a check for the unique ID, two aspects occur. One, there is a confirmation that a single device is not scanning multiple tags to unlock special content multiple times. And two, it allows for each of the unique users to be counted and to be provided with the unique content upon its release. [0247] As part of this process, the user could be prompted to input personal information (38) (FIG.9) in exchange for the digital offer. The provided information could be stored in an analytics database (66) of the analytics portal (46). The analytics portal (46) may perform a number of tasks, including access to the unique ID database to retrieve information related to that particular unique ID. This can be performed on a multi-level server and database system as is known in the art. Thus, data can be stored in one or more databases and can be retrieved to allow for mining of data or to provide different data to one user over another based on the data within the portal. Thus, these databases retain data from past user interactions, including interactions assigned to individual user and/or interactions of all users who have scanned machine-readable code (17a). [0248] Turning to FIG.9, and a flow diagram (1000) of FIG.10. These examples define variations of rules that can be implemented on the system to deliver dynamic content. FIG.9 details one such embodiment, with a flow diagram (1000) depicted in FIG.10. Additional examples and iterations described in further detail. FIG.9 provides a first step (902) where a user device (14a) scans a tag (16a) on a seat (208). Following a scan of the tag (16a) with the user device (14a), the user is redirected to a tag URL that is uniquely encoded to the specific tag (16a) through step (904). The redirect/identification server (302) receives the tag URL request, checks for a manifest with a unique ID on the user device and informs the interface server (306) and determines the status (new or not new) of the user device (14a) to the system (900). By checking for a manifest and a unique ID on the user device and correlating it with the unique ID stored in the database a confirmation can be made of a new (34) or returning user (36). If the user is new, a new unique ID is generated (906) by the system and stored in the database and on the user device. [0249] The interface server (306) includes a database (308) of URLs containing unique certificates used to issue digital wallet passes. If the user is determined to be a returning user (36), the interface server confirms that the unique ID located on the user device matches the unique ID in the database. If the user is a new (34) user, the system obtains a manifest with a unique ID and sends it to the user device (steps [406] and [408] from FIG.4) and records the same within the database. At this point, the user is confirmed with an existing unique ID (22a) or possesses a new unique ID, in either case, the certificate used to issue a digital wallet pass being specific to that user device (14a). [0250] Subsequently, the unique ID being confirmed or generated, the target determination process (844) determines what content to display based upon data received from the redirect/identification server (302) in step (908), and the target determination process (844) is told what to show the end user (910). The interface server and the target determination process (844) further check for dynamic rules and directs back to the server (912). The redirect/identification server sends the end user to the redirect URL directed by the interface server (914). However, while content is provided, a trigger then occurs (918). The occurrence of a trigger, as defined in the several examples herein, then generates a new target. Accordingly, the interface server determines the new target to display based upon the trigger occurrence (920). The process may repeat as additional occurrences of triggers are repeated to provide new targets (922). [0251] As part of this process, a step (916) may include that the user is prompted to input unique identifying information (54) (FIG.6) into the system (10), which allows for better analytic information on the user device (14a). The provided information could be stored in an analytics database (66) of the analytics portal (46) or in a primary database (308) among a variety of storage options. [0252] Therefore, a target that was previously provided can actually be modified by the occurrence of a trigger. For example, the digital coupon (32), based upon a live trigger, or based upon the actions taken by a user. For example, the trigger/outcome occurs (68), may be that a home team wins a game. Upon the occurrence of the trigger, the target or offer, which was prepopulated within the database, a coupon can be modified. Thus, the digital offer/target (32) first provided for a free drink with an order of a slice of pizza can be changed through the target determination process (844) upon any rule being met, but specifically here upon a trigger event. Thus, upon the occurrence of the trigger (68), the digital offer (32) now provides a free drink and salad with the order of a slice of pizza. [0253] Another example of a trigger (68) may include: making donation, making a wager, playing a game within the system (10), a predetermined lottery, the purchase of an item within the system, the purchase of an item outside of the system (10), but tracked via an outside API that connects to the system (10). Because of the unique ID, we can track and identify each user device (14a) and allow for customized communication based upon the occurrence of a trigger (68). [0254] In another embodiment, following a scan of the tag (16a) with the user device (14a), the unique user ID is able to communicate with other unique user ID’s currently on the system (10) via push notifications, via a chat link, or via a socket notification all within the fan portal on the user device (14a). Because the MRCs (17a) are uniquely coded to a particular seat, section or other fixed location, a user is able to communicate with other users in the same row, section, venue or other location that is part of the system, without having access to the other user’s unique identifying information such as cell phone number, e-mail address or social media username. Users would have the option of receiving communications from other users based on certain parameters such as, receive communications from users in my same row, users in my same section, users from the entire venue or alternatively, not to receive any communications. [0255] In a typical embodiment, remotely updatable machine-readable code programming provides an ability for individuals to download digital offers directly to their user devices and transfer the digital offer to other user devices. In a typical embodiment, once the individual transfers the digital offer to a predefined number of user devices, the incentivized offer increases. The system uses the unique ID stored in a manifest on the user device and in a database on the server; therefore, this digital offer is now unique to the user device on which the manifest with the unique ID is stored and must be in order to track the sharing of the digital offer. If the individual transfers the digital offer from his/her user device to, for example, five other communication devices within a fixed time period such as, for example, a week, the digital offer automatically upgrades from 10% to 20% off at the local retail store. This capability offers further incentive for individuals to transfer their digital offers to family and friends so that they will receive greater discounts. Also, this capability will allow proprietors such as brands and retailers to watch their promotion go viral from a first point of download to various locations where the digital offers are transferred between various user devices. These digital offers could also be shared and tracked via NFC, MMS, Text Message, social media such as Facebook, Twitter, Snapchat, etc. Digital offers could be browser based or stored into user’s digital wallet located on his/her user device. [0256] In a further example, BW Films is releasing a new motion picture trailer. BW Films wants the initial trailer to be viewed by at least 10,000 viewers on the initial launch and is marketing the film to college students. ZY University is hosting a football game at the campus stadium. As described more fully in FIG.2 and FIG.4, each seat in the stadium has a tag (16a) installed on the armrest and each tag contains an MRC that is uniquely coded to the system via a tag ID. When the fans arrive at the stadium, each fan who wants to interact with the system scans the tag on his or her armrest. Once scanned, method (400) is executed. The redirect/identification server can be programed with certain rules. For example, a rule could be if a user device does not rescan the tag within thirty minutes, or if the user does not interact with any of the redirect URLs the interface server sends to the user device within a thirty-minute time period, that user device may be categorized as inactive and removed from the count of total number of user devices currently active on the system. A counting mechanism (FIG.6, 602) can be utilized with any of the embodiments to track and account for any rule or metric that requires some form of tabulation of users, whether a total or active, as nonlimiting examples of counting. Once the redirect/identification server has verified that there are 10,000 unique and active user devices on the system, it directs the interface server to deliver a unique redirect URL to each user device that will allow the user to view the motion picture trailer. [0257] In another example, BW Films wishes to reach a larger market to launch a new motion picture trailer. BW Films would like a total of 500,000 viewers with a minimum of 5,000 viewers in each of ten venues. BW Films knows that Saturday is traditionally game day for college football. As fans arrive at the campus stadium where tags are installed on the armrests of the seats, the fans scan the tags with their user devices and method (400) is executed. The redirect/identification server continues to tally user information, via the counting mechanisms described in FIG.4, FIG.5, and FIG.6 until each parameter set by BW Films is met. Therefore, when the redirect/identification server knows that each of the ten venues designated by BW Films has 5,000 unique and active users and that there are a total of at least 500,000 unique and active users on the system, the redirect/identification server will direct the interface server to deliver a unique redirect URL to each user’s device so that the user can view the film trailer. Alternatively, the interface server can tally the number of unique user devices currently on the system rather than the tally being completed by the redirect/identification server. [0258] In another example, tags are installed in hotel rooms throughout the country. WS Airlines would like to offer a flash sale on air travel and sets the parameter that there must be 10,000 unique users on the system at one time in order for the digital discount offer to launch. When a user enters his hotel room, the user scans the tag with the tag that is installed in the user’s hotel room and method (400) is executed. Once the redirect/identification server has tallied that the number of unique users has reached the minimum threshold set by WS Airlines, the redirect/identification server directs the interface server to deliver a target, i.e., a digital offer for the flash sale. The digital offer can be a unique discount code for each user, a single discount code for all users, a digital or mobile wallet offer that can be added to the user device, pushed to the user device, sent through a socket, updated in a Web app, or the user can be sent a unique redirect URL. [0259] In another example, N & N Candy is launching a new flavor of candy bar. The marketing campaign consists of a video advertisement and a digital offer for a free candy bar. N & N sets the parameters that this campaign will be launched on college campus when the unique number of users on each campus reaches 50,000. Each dorm room on the college campus contains a tag. The tag contains a tag ID that is coded in the system to identify that it is located on a particular college campus. Optionally, the tag ID can also be part of a tag grouping. When the student enters his dorm room, he uses his user device to scan the tag which executes method (400). In this instance, the counting mechanisms described in FIG.4, FIG.5, and FIG.6 not only counts user is new or existing, but the count also tracks the university campus on which the MRC is located because each tag ID is part of a tag grouping for a specific campus. The redirect/identification server tallies the number of unique and active users at each college campus location. Once the number of unique and active users at any one location exceeds the number specified by N & N Candy, the redirect/identification server directs the interface server to deliver a unique redirect URL to the user device which allows the user to watch the video advertisement on his user device and the interface server also delivers a digital offer for a free candy bar. The digital offer can be in the form of unique discount code for each user, a single discount code for all users, a unique digital or mobile wallet offer that can be added to the user’s device or the same digital or mobile wallet offer that can be added to all user devices. In this example, the users at ZY University may meet the minimum threshold set by N & N Candy within one hour of the launch of the marketing campaign and thus be given access to the video content and free candy bar offer within one hour. However, the users at BA University may not meet the minimum threshold set by N & N Candy for several days and therefore, the users at BA University will receive access to the video content and free candy bar offer several days after the users at ZY University receive their offer. [0260] In another example, a musical group would like to provide their fans with an opportunity to download the group’s latest single. The group is performing in a venue that has a tag installed on the armrest of each seat and each tag contains an MRC that is uniquely coded to the system via a tag ID. The group is also live streaming the event over the internet and the online production of the performance will display a QR or similar MRC in the bottom corner of the video feed. The group has decided that they will release the single when the total number of unique and active viewers reaches 100,000 users regardless of the location of the user device. Users at the venue scan the tag with their user device which executes method (400). Likewise, users viewing the concert’s live stream can scan the QR code that appears in the broadcast with their user device which also executes method (400). Once the total aggregate number of unique users meets the minimum threshold set by the musical group, the redirect/identification server directs the interface server to deliver a unique redirect URL to each user device allowing the user device to download the musical group’s latest signal. [0261] While counting of a plurality of users is important for mass marketing, in certain embodiments, individualized marketing is more important. Thus, in a further example, a user must scan a certain number of tags in order to unlock specific digital content or offers. In this example, as shown in FIG.11, tags are placed throughout one location or in multiple locations (i.e., a bus bench [1101], a coffee shop [1102], or a billboard [1103]). However, this configuration could also work for a museum with tags at multiple exhibits, a shopping mall with tags at multiple stores, multiple tags placed throughout a particular town or city at certain establishments in that town or city or multiple tags placed at particular locations throughout a larger geographical area. For purposes of the example, the tags have been placed at restaurants throughout Fort Worth, Texas. Stockyards Rodeo wishes to launch a marketing campaign where they provide a mobile or digital offer of buy-one, get-one-free tickets to users if the user has frequented a certain number of restaurants in the Fort Worth area. Stockyards has set the parameter (i.e., rule) that users must visit four restaurants in order to unlock the digital offer. When a user arrives at the restaurant, he uses his user device to scan the tag that may be mounted next to the door or the restaurant, in the lobby of the restaurant, or at a particular table in the restaurant, which executes method (400). If the user is new, the identification server notes the device, location, date, and time of the scan and creates a new user/device ID record for this campaign. If the user is existing, the server retrieves the user’s existing user/device ID record for this campaign, notes the location, date and time of the scan and updates the user/device ID record to reflect the total number of scans. This process is repeated each time the user scans a tag at a restaurant in Fort Worth until the user meets the parameter set by Stockyards to unlock the digital offer, in this instance, the user must visit four restaurants. Once the user/device ID record for this campaign meets the parameter set by Stockyards, the redirect/identification ID server directs the interface server to deliver a unique redirect URL or digital offer to the user device for buy-one get-one-free tickets at Stockyards. [0262] In certain embodiments, the system may be utilized in conjunction with a digital wallet or wagering wallet for wagering. In the event of a wagering component, users would be able to scan the tag with the user device and be taken to a live wagering portal, which could be browser based or in the form of a cloud or locally based mobile application, including a progressive Web app. Using the system’s analytics portal, the user would be able to see their past wagers across the entire system and place their wager utilizing a digital wallet solution such as Apple Pay or Google Wallet, or through traditional payment methods. All of the interactivity and wager-based actions will be facilitated without the need for the user to create a traditional user profile, unless so required by law. This same wagering configuration could be utilized to offer “brand wagers” wherein the prize given to the user is a physical item given to the user such as a promotional item from a team sponsor or a digital reward which can be downloaded or emailed to the user’s device. [0263] Fan engagement at sports venues often goes beyond the game itself. When the moment arises, fans are often generous to causes that are supported by their team, which may be provided to nonprofit organizations. Therefore, in a venue, the team may request support of one or more charities, and the platform could allow for the ability to donate money in real time directly from their venue seat via the NFC and/or MRC. For example, if the donation were to Salvation Army, the user would, either with or without prompting from the venue multimedia display system or jumbo screen, scan their tag and be prompted to donate money either using their digital wallet or traditional payment methods. In keeping with the earlier claims, the system would allow proprietors to deploy various customizable donation templates to every seat, row, or section if desired. Additionally, after the donation transaction is complete, the user could be offered a physical or digital reward that could be used inside or outside of the venue. Indeed, the benefit of the system is that the user device contains a unique ID stored in a manifest that is indicated in the system. Accordingly, this allows the system to identify a user device corresponding to a particular user ID as donating a certain dollar amount. The system can be prepopulated with “rewards” or incentives to donate or reach a cause. [0264] For example, a cause may be for a single section of a venue to raise $100 (i.e., 224 from FIG.2). All donations originating from tag within the particular section can then be aggregated to determine if the section reached the $100 donation goal, or if a certain percentage of the section participated in reaching the goal. Accordingly, if there are 200 people in the section, a donation of an average of 50^ would be sufficient to hit the goal. The system can then populate a predetermined digital or physical reward, i.e., a coupon or some other offer that can be used at the venue, or some other tangible or intangible reward. The system can go one step further as it can quickly tabulate the donations and, in real time, the system can allow sections to compete with one another. Thus, section 1 (i.e., 224 from FIG.2) could “race” section 2 (i.e., 226 from FIG.2), to reach a donation goal. This allows for gamification within the system based upon the use of tags that are provided in a venue or location. [0265] Embodiments may also allow for real time data/polling of event attendees, i.e., voting for your favorite player, predicted outcome of the game, predicted score, games displayed on a jumbo screen, real-time events/outcomes at the stadium, etc. However, the real-time polling is enabled by the individualized nature of both the user device and also of the tag. For example, where only one of the user devices or the tags is unique, it is impossible to identify both the user and also a population of similar users. If a section of a stadium is competing against another section, we need to have each user device connect to a tag in their particular section, via a tag ID grouping, and then participate as a group to reach the offer threshold. If the group element is missing, such “sectional” competition would not be possible. [0266] While the group may participate together, because of the unique ID, individual user rewards can be provided, for example, as a user makes a larger donation, that user is provided with a larger reward than another user from the winning section. Because the unique ID stored in a manifest on a user device allows for tracking of actions, i.e., the donation by the user, individual rewards can be provided to that user, corresponding to that particular unique ID. [0267] All of these actions provide opportunities for the system to capture user data. When the plurality of tags (16a) is scanned with the user devices (14a), analytical data is collected. The analytical data may be, for example, date, time, GPS location of a tag, GPS location of a user device (14a) when it scanned a tag, the type of user device used to scan a tag, orientation of a user device when a machine-readable code was scanned, and type of operating system on a user device that scanned the tag. The exemplary method and system couple the collected analytical data from the physical scanning of the plurality of tags (16a) with data collected once the individual is directed to the target. In a typical embodiment, the data may be, for example, time spent on a Web page, purchases made, IP address, personal information input by the user, and products viewed. Such data is of high value to, for example, advertisers, team owners, and venue owners as it provides a large insight into consumers purchasing and Web browsing habits. [0268] The user data can remain anonymous to a large extent, as it is collected based upon the user device scanning a tag and not dependent on the user logging into the system. Therefore, data does not need to be correlated with the actual identity of the person controlling the user device. It is immaterial whether the user is male or female, or young or old, instead it is the particular set of data that creates a picture and certain mobile offers or content can be provided based upon that data, and then modified based upon the occurrence of one or more actions, such as donations as above, or other purchases, or an outcome in an embedded game or task, or upon the outcome of the game at the venue, as nonlimiting examples. [0269] Data can also be gathered outside of the system, for example, through an API connecting the system to a third-party server or database. The benefit of also utilizing user data that is gathered from outside of system itself is that it provides data that might not otherwise be gathered, while also offering an opportunity to “preset” content when a user scans the tag at their seat. Example 1: If event ticket provider such as Ticketmaster®, provided data to the system’s analytics portal revealing that Joe purchased tickets to the football game to sit in seat 1, row 1, while also providing data, known to Ticketmaster, such as that Joe is a 32 year old male (data that is provided to Ticketmaster from Joe when he creates his Ticketmaster account), because each tag in the system is uniquely encoded down to the individual seat or specific location via a tag ID, the analytics portal would have the ability to “preschedule” content that would appeal to a 32 year old male when Joe takes his seat at the game. This use case could be valuable for marketers looking to market to a particular subset of attendees, vs the entire stadium or venue. The data can be from more than just one event as well. If Joe has previously purchased other tickets from Ticketmaster, that data may also be available and provides further details and information relevant to Joe, which can be used to provide better content to Joe. If Joe only buys rock concert tickets, for example, providing country music listings for new concerts would not be the best targeted advertising for Joe – so modifying the content to that of Joe’s interests (rock concerts) provides greater value for advertisers and also to Joe. [0270] A machine learning component of the system would allow sports teams to provide more relevant real- time offers to fans by customizing content based on user interaction. Example 2: If Joe scans his tag and is taken to the team fan portal where he selects “buy merchandise”.75% of the time Joe purchases a shirt, but he never buys a hat, then the system would have the ability to adjust Joe’s offerings in real time to show him a larger selection of shirts, instead of hats, based off of his past purchasing and browsing habits. Alternatively, the system could use this data stored on Joe’s purchasing habits to deliver a customized digital offer to Joe to entice him to buy merchandise that is not a shirt such as a 25% discount if Joe buys a hat. This could be valuable to proprietors, teams, performers, promoters, or venues looking to sell items from merchandise to food inside of the venue or based upon inventory considerations. The system has the ability to learn user characteristics from user input within various user portals mentioned above (Web browsers, PWAs, etc.). This component would provide a user with customized content based on their previous content interactions inside of one venue, or interactions across the entire system network of tags. It would also allow said system to store user and/or the user device information in order to offer specialized incentives based on past usage statistics. For example, the system may reward Joe for scanning the tag at his tenth straight baseball game by delivering an offer for “team VIP” merchandise. Or the system could provide Joe an offer for a hot dog, peanuts, or soda at a reduced rate based on his purchase history or incentivize him to make a purchase with a digital offer, if he typically does not purchase food or beverages. [0271] The benefit of the unique ID, in combination with the tag ID is that a single tag, having its own tag ID, can be scanned by multiple user devices, and each scan by a different device will have a different unique ID. This allows proprietors such as venue owners, teams, universities, marketers, performers, promoters etc., to offer individualized digital offers to every user device that scans a tag. Example 3: The system offers unique digital wallet certificates for each user upon scanning the tag, which means that if fifty users scan the same tag with their user device, all fifty user devices will individually have a unique record within the system database. Thus, a single tag could be located in a centralized location and would still allow for unique content (the digital offer) to any user who scanned that tag. The system might deliver a different digital offer to each user so if Joe scans the tag, his digital offer might be for a half price soda at the concession stand, but if Joe’s wife scans the same tag from a different user device, having a different unique ID stored in a manifest, her digital offer might be for a half price hamburger at the concession stand. Likewise, the system will be able to track if a user activated and redeemed his or her digital offer. The storage of data corresponding to each unique ID is what provides for the ability to create rules to provide the different data to each unique ID. This data can be provided to third-parties to utilize the data, for example, to identify and target users with unique content based on their history of uses. [0272] The system may offer “group passes” wherein the system could offer a digital offer that was only able to be issued to a predetermined number of users. Thus, the first person, the first 5, the first 10, 25, 50, 100, 500, 1000, 10,000, nth, person to scan the tag (and all numbers in between), may be included within a group. The distribution of such group passes and counting of executions of the system to a user device, can be used as a game or for other giveaway plans. It is common knowledge of the types of games where the “100th person to download wins a prize,” or “only the first 100 people can claim a prize if they buy or click now.” The ability to track these types of programming through the system provides a new way to manage such programs. [0273] The system could also be implemented within a traditional mobile application or Web-based platform whereas the user would be offered the unique digital offer once they visit said application or URL address. Because of the individualized nature of the unique ID in the system, the unique digital offer can then be directly modified based upon chance, some data, or trigger occurring which allows the provider of that unique digital offer the opportunity to modify an offer. For example, an offer is for 10% off a pizza, but the offer becomes 25% off once the offer is shared with at least 2, 5, 10, 25, 50, n number of people, who also download an offer. This allows tracking of who downloads an offer, how many are tracked to a particular offer, and allows for modification and improvement of an offer based on metrics related to sharing. [0274] Another embodiment would be for a proprietor such as a retailer to provide a digital offer in the form of real time discounts to users in specific venues via the tags (16a) upon the occurrence of a threshold set by the retailer. For example, if the tags (16a) inside of the venue (202) are linked to a specific retailer via a tag grouping or geofencing, then that retailer could offer discounts in real time that could only be accessed by users inside of the venue (202) upon the occurrence of meeting a threshold of interest in that particular offer. Here, the trigger event is that at least five people scan a tag related to a particular offer. The occurrence of a real time discount is a trigger, wherein the trigger executes a modification of a digital offer or of the content that is provided to the user device (14a) as soon as the at least five people scan the tag for that offer. [0275] Embodiments of the invention also provide individuals an ability to establish interactive communication via tags (16a). In a typical embodiment, the plurality of tags (16a) can be programmed to perform various designated actions such as, for example, an ability to download a digital offer (e.g., a digital coupon) straight onto the user devices (14a) which could be redeemed at a concession area or retail location. For example, the digital offer could be redeemed by the individuals upon performing a transaction at a retail or concession area using, for example, the NFC enabled user device. This provides proprietors such as concession owners, retail owners, and advertisers an ability to immediately see conversion rate of a digital offer that is issued (i.e., 100 coupons were scanned via the plurality of tags and 80 were redeemed). These digital offers could be redeemed at retail locations inside or outside of the venue. If the offer rate is lower than desired, the proprietor can increase the offer to improve the rate of use of the offer. [0276] The machine learning and custom content aspect of the system is not limited to in-venue applications and can be utilized across multiple industries such as rideshare vehicles, aircraft, ships, trains, hotel rooms, dorm rooms, vacation rentals, etc. The broad spectrum of the embodiments is to offer location based custom content solutions to user devices. [0277] In the case of hotels and collegiate dorm rooms, the system would be comprised of a plurality of uniquely encoded tags (16a) placed inside of guest rooms whereas there is one NFC enabled and/or MRC tag per room, or one per guest/resident of said room. Each tag (16a) would be connected to system servers which would allow said tags to offer predetermined content based on presupplied data points. In the collegiate dorm use case, users would scan the tag (16a) located within their room and be shown content based on various factors such as their gender, education major, year of schooling, etc. The content on these tags would also utilize data points and usage reports from the system itself to better serve users with relevant content. These tags could also allow marketers, and the university at which they are deployed, to offer incentives such as game tickets or retail store coupons, directly to the students in their dorms via a digital offer or mobile wallet offer, while providing the option to provide the offers and content to only select, or all, tags based on various analytics provided within the system. Tags would also allow students and hotel guest to offer real time feedback on the system in the form of user submissions to conduct live polling procedures. This use case would provide a valuable platform for universities, marketers, and hotel owners to offer customized content to their guest on an individualized basis. [0278] Another unique feature of the system is that the data that is collected in order to provide content can be gathered system wide when a user scans one of the plurality of tags in any location. This feature would allow marketers to understand consumers characteristics more closely from a location experience, and to provide the user relevant content across a multitude of markets. Example 4: If a tag is scanned by Joe at a football game in Arlington on a Sunday, and then a tag is scanned by Joe in a rideshare vehicle in Boston the following Wednesday, the system would understand that the user, Joe, was the same for both interactions, without Joe having to log into the system, and display content accordingly based on data provided from the analytics portal. This is because the system knows the user, Joe, because of the unique ID stored in either on the manifest on the user device or on the server, or both. By scanning a tag, the system can also upload data to generate more information about Joe and his activities and interests, so as to provide better content to Joe through the content. [0279] The step of collecting user data associated with the user may also include the step of receiving in-venue metrics via an in-venue metrics API (50). This API (50) may enable information about the user to be gathered based upon purchases of tickets (past and present), purchases of food, merchandise, and other goods and services from the venue. The step of collecting user data associated with the user may also include the step of receiving third-party metrics via a third-party metrics API (52). This third-party metrics API (52) may enable information about the user to be gathered from third parties who participate in a shared program, or who sell or otherwise provide marketing information, demographics, and other data about the user. The step of collecting user data associated with the user may also include the step of receiving information from other data forms available to the system. [0280] Finally, as ticketing is a key feature of many of the embodiments, the step of collecting user data associated with the user may also include the step of receiving information from ticket brokerage metrics via a ticket brokerage metrics API (56). These metrics may include information gathered by the ticket brokers who sell tickets at the venue (202) (in FIG.2), and may include a wide range of marketing data, not only about ticket purchases made, but also related information about the user. [0281] Rolling offers may also be desirable. For example, a restaurant at a sporting venue may want to discount food (so none is wasted at the end of the game) and selling food for discount when a specific time point in the game or event is reached. This allows for real-time feedback within the event and within the system of inventory, wherein price or an offer can be modified based on the particular inventory. An advertisement or coupon can be generated as mobile content in real time to users on the system to incentivize such consumption. For purposes of this application, the terms “real time” and “real-time” means any interactions that are provided within ten seconds of a trigger occurring, or longer, as determined by the proprietor, but not longer than 60 seconds after the occurrence of a trigger occurring. [0282] Referring back to FIG.3, the infrastructure detailed therein is exemplary, dividing processing between at least two servers (e.g., redirect/identification server [302] and interface server [306]), but embodiments are not so limited. The numbers and types of servers and software may be scaled up, down, and distributed according to platform (20) demands/needs. Furthermore, more than one virtual machine may run on a single computer and a computer/virtual machine may run more than one type of server software (e.g., the software that performs a service, e.g., Web service, application service, and the like). Thus, in some instances platform (20) may include one computer for all processing demands, and in other instances platform (20) may include several, hundreds, or even more computers to meet processing demands. Additionally, hardware, software, and firmware may be included in or removed from platform (20) to increase functionality, storage, and the like as needed/desired. [0283] Administrator device (12), which is shown in FIG.1, may be any type of computer such as a laptop computer, desktop computer, tablet, and the like. Similarly, user device (14a or 14b) may be any type of processing device such as a handheld computer (e.g., phone, smartphone, tablet, personal digital assistant), wearable computer (e.g., watch, glasses), or portable computers (e.g., laptop, netbooks). Scanning of the tag (16a, 16b) from the user device (14a or 14b) is performed through nearfield communication (NFC) or use of a camera on the user device (14a or 14b) to scan the visible quick response code (QR code). Administrator device (12) and user devices (14a or 14b) typically include a browser application to facilitate communications with one or more servers among other things. [0284] 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 include 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. [0285] In an embodiment, servers (e.g., 302, 306, 310, 312, 320, 322, and/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 FIG.3, in embodiments database (308) may comprise more than one database, the more than one database may be distributed across many locations, and data may be redundantly recorded in the more than one database. Furthermore, data may be stored in blocks that are part of a chronological blockchain (314) and may be dispersed across a decentralized distributed ledger. Blocks of data in a blockchain are linked in such a way that tampering with one block breaks the chain. Thus, digital data stored in a blockchain is verifiable with an elevated level of integrity. Therefore, the database (308) may also be a distributed database system, utilizing blockchain (e.g., 314) to provide for storage of NFTs or the like related to the system. As with any distributed database, the number of databases and particular nature of the blockchain storage is dependent on the particular exchange or blockchain utilized for the NFT as one nonlimiting example. The use of a distributed database system is well known and the storage of an NFT or the like requires the use of such systems. Geofence (316) and Time (318) may be software services provided by the platform (20). These services (316, 318) may be executed by any or all of the computing machines, virtual or otherwise, found on the platform (20). These services may use data from one or more user devices (14a, 14b) and other data sources to provide their intended functionality as is known in the art. [0286] Thus, per the forgoing description, it should be appreciated that an interactive DEP can be tailored to achieve the proprietor’s goals. Clearly, one proprietor’s goals for an interactive DEP may differ from another proprietor’s goals, and as such interactive DEPs may expressed in a multitude of different formats, layouts, designs, versions etc., that may include numerous variations on functions, features, rules, instructions, etc. Nonetheless, interactive DEPs typically include at least one feature/module with dynamic content that may be altered in some manner at least during the course of the event. Thus, what an individual user may experience via that user’s interactive DEP is not necessarily the same as what any other user will experience. Using FIG.2 as a nonlimiting example, all in- venue users may receive an interactive DEP in response to scanning a tag (16a) with their respective user device (14a). Each stadium section (222, 224, 226), however, may receive a different version of the interactive DEP, due to redirection as was explained with respect to FIG.4. And within a particular version, content that one user sees may be different based on user data and/or rules as was explained with respect to FIG.5. Even if the version and content are the same, individual users typically will not interact with the interactive DEP in the same way at the same time, which will also cause each user to have a unique experience. [0287] There are many features/modules that a proprietor may include in an interactive DEP, including, without limitation, a map (1602), a roster (1604), replays (1606), augmented reality (1608), fan camera/fan filter (1610), live statistics (1612), NFT (1614),wagering (1616), audience participation (1618), upcoming events (1620), merchandise (1622), concessions (1624), and other (1626), as is shown on the features page of the interactive “l Game Day Program” (1600) of FIG.6. The game day program (1600) is an extensive “fan portal” (218) type format for an interactive DEP. Although advertisements are not shown on the home page for the game day program (1600) of FIG. 6, it should be understood that advertising and other content may be included on the home page, and/or any other page/pages of the game day program (1600). Further, advertising, especially dynamic advertising, is an important feature of an interactive DEP since advertising may offset proprietors’ costs and allow users to obtain an interactive DEP for free. [0288] In some instances, a proprietor may select a book-like format rather than a “fan portal” type format to implement an interactive DEP. As yet another alternative, a proprietor may include a book-like interactive DEP as a feature/module of a “fan portal” type interactive DEP (1600). FIG.7 depicts a nonlimiting example of a few pages taken from a book-like interactive DEP (1700) distributed by a city zoo. The cover page (1702) of the interactive DEP (1700) may be what zoo visitors see after they scan a tag (16a), or it may be what a user sees after linking to the interactive DEP (1700) via a selectable option on a home page of a fan portal type interactive DEP. The cover page (1702) may emulate a cover page of a traditional paper program. However, icons, images, or the like on the cover page (1702) may link to other pages either within the interactive DEP or external thereto. Features/modules listed on the Game Day Program (1600) may be included on the pages of the interactive DEP (1700) shown in FIG.7, or the interactive city zoo DEP (1700) may include modifications of a “standard” feature/module. For example, on p.2 (1710) of the City Zoo’s interactive DEP (1700) the “exhibits” (1712) and/or “animals” (1714) feature/modules may be variations on a game-day “roster” feature depicting an animal, here a seal (1704). And, although not shown in FIG. 7, the book-like interactive DEP (1700) may also include a navigation pane/bar to assist with navigating a digital document as is known in the art. Since interactive DEPs are meant to fit many different proprietors’ needs, features/modules may be created/customized to meet those needs and are not limited to the examples described herein. Furthermore, although only two types of formats are shown herein, it would be understood that such formatting is a matter of choice, and an interactive DEP may be formatted, designed, laid out, have features, functions, and other accessories not detailed herein, that are still within the spirit of the invention. [0289] Map Feature: It is not unusual for an interactive DEP to include an interactive map of the venue/event, especially where the venue/event is large or difficult to navigate. The interactive map may utilize one or more third party integrations (320), other integrations, databases or other sources information, rules, instructions, API calls, other calls, user device data and/or capabilities, or combinations thereof to provide the desired map functionality. For example, if Janet, who is sitting in seat 1, row A, section 100, of a stadium wants to know where the nearest restroom is located, she may select the map feature (e.g., FIG.6, [1602]) to link to a map of the stadium. Alternatively, if Janet is at the zoo and she wants to know where the nearest restroom is relative to her current location she may turn or navigate to the page that has the map of the zoo or a link to the map of the zoo (FIG.7, [1706]). [0290] Map features may include a search function to search for a specific location within the stadium, may automatically provide routes to the most frequently visited locations such as restrooms and concessions, locations that Janet has visited in the past in the same venue or at different venues (e.g., restrooms), or combinations of the forgoing. Alternatively, Janet may simply tap her desired destination on the map to receive a route to the destination. The route may be the shortest route, route with the least traffic, destination with the shortest line, or the like, in a manner that is analogous to routes that are shown on street maps using data gathered from various sources. As one nonlimiting example, the analytics server (312) may receive data about Janet from database (308) using the unique ID for her device (14a), mapping and/or other functionality from a third party source (320), geofence (316) data to determine how many user devices (14a) are within a predetermined area (e.g., to estimate line length, traffic patterns etc.,), GPS data from Janet’s user device (14a), other user devices (14a), or both, any other available data, or combinations thereof, to determine the best route for Janet to reach her best destination and display that route on the map in the interactive DEP. The analytics server (312) may receive data directly via queries to the various data sources or via the interface server (306), which may manage the activities to get Janet the information she is seeking. Map related content may be pushed, pulled, or both, via the socket or other connection between the user device (14a) and the platform (20). [0291] In an embodiment, dynamic content may be unlocked in response to using the map feature/module. For example, if Janet is trying to find her favorite concession or restaurant at the event/venue and she uses the map, a digital offer for the concession or restaurant may be displayed on or in the interactive DEP, may automatically be loaded into the digital wallet (24a) on her device, or other such examples. When Janet goes to pay for her food, she may then redeem the digital offer. The map feature may also identify additional tags and or areas of interest, wherein a user may be directed, via the map, to certain tags to engage with the event or the environment defined by the map. Such maps can also be utilized, therefore, for scavenger hunt like games, which require a user to find, identify, and scan certain tags as part of an event or as part of a challenge or task within one or more of the embodiments. [0292] Remote users have little need for an interactive map of a venue, event, or the like. Thus, a map function may not be included in the interactive DEP distributed to a remote user. Alternatively, the map feature may use GPS coordinates, geolocation information, geofence data, tag ID information, other such information, or the like, and provide a suitable map to the map feature such as the area surrounding the remote user device (14b). This may be especially helpful to those users who are out of town and do not know their surrounding areas. Like with Janet, if the remote user searches for a participating restaurant, a digital offer for the restaurant may be displayed on or in the interactive DEP, delivered to the digital wallet (24b) on the remote user device (14b), or other such location. Since the digital offer is being sent to a remote user it may have an expiration date that is longer than an in-venue digital offer, which typically expires when the venue closes after the event. [0293] Roster: It is also not unusual to have a roster, or a modified roster in an interactive DEP. As is shown on the game day program (1600) there may be a selectable link to a roster (1604). Rosters formats and layouts are practically limitless and can range from simple to complex. For example, a simple roster may show an image of the person and their associated data such as name, position, schools attended, and certain statistics. A complex roster may include full pages dedicated to each person with images, videos, complete professional history, personal history, personal statistics, player analysis, associated merchandise, NFTs, wagering opportunities, the ability to donate to the player’s charitable cause, and more. In contrast to a regular event program, in an interactive DEP typically static elements (e.g., statistics, images, videos, etc.,) may be dynamic, updating as the event takes place. These changes may be the result of one or more rules used to push, pull, or both dynamic content to the interactive digital program (e.g., 1600, 1700). For example, one or more rules may be written to monitor for a metric or trigger related to a particular player such as a personal best, event record, world record, or the like in the same or similar manner that was detailed in FIG.5. If the metric/trigger is detected while the event is in progress (e.g., most passing yards in a single game), then dynamic content may be updated with fresh content. For example, an image of the player making the historic pass may replace a current image, a video clip of the historic pass may replace the current video, the player’s statistics should update, a pre-recoded video may be released, merchandise related to the player may be promoted and/or discounted, a commemorative NFT may be released, and wagers may be taken as just a few examples. As one specific example, a statistic such a record-breaking number of passing yards in a single game, may be tied to an advertising integration such that if the metric/trigger is detected, then a digital offer for a fast food restaurant may be unlocked for users (in- venue and/or remote) to redeem. The user may simply tap on the digital offer to move the digital offer out of the interactive DEP and into the user’s digital wallet for redemption at any time and without the interactive DEP. All of this may take place within the interactive DEP during the event as the user is looking at the particular players page or when the user gets to the page (or any other page that the content may be contained on) thanks to various API functionalities and other functionalities connected to the interactive DEP. A roster (1604) may be the same or different on different versions of an interactive DEP (e.g., going to different groupings of tags [16a]) or for in venue and remote users or both. [0294] As is shown in FIG.7, the city zoo interactive DEP (1700) includes a modified roster for exhibits (1712) and one for animals (1714). Modified rosters may also be included in interactive DEPs for other sites such as museums, historic buildings, and similar places. The modified roster for the zoo exhibits (1712) may include images and videos showing highlights of the exhibits including feeding times, times when the animals are most likely going to be active, and other information of interest to zoo visitors. The modified roster for zoo animals (1714) may include one or more pages dedicated to the animals as individuals, groups, or both, trivia (1716) regarding animals or other games related to the animals or the zoo in general. These pages may also include images, videos, merchandise, and the like. Further, video of the exhibits, animals, or both may be streamed in the interactive DEP (1700) so that if a special program (e.g., feeding time, meet the trainer, a show, etc.) is happening and a user who cannot get close enough to the action or who is at the other side of the zoo can still see the special program via the interactive DEP. Images may be updated dynamically as well. For example, images may be cycled, taken from a video feed, uploaded by users to share, other similar examples, and combinations thereof. A metric or trigger may be associated with an exhibit or animal so that upon satisfaction of the metric/trigger an action may be taken. As one nonlimiting example, tags (16a) may be associated with each exhibit to direct in-venue users to additional content related to the exhibit and/or animals in the exhibit. Additional content may include histories, stories, video interviews with zoo personnel about the exhibits/animals, additional images, videos, and the like. The platform (20) may be enabled to count, via a counter, the number of times the tag (16a) for the exhibit has been scanned in a day, week, month, year, in total, etc. Alternatively, the counter may be enabled to count the number of times a particular user uses his/her device (14a) to scan distinct tags (16a) in the zoo. When the number reaches a predetermined number (e.g., 10, 100, 1000, etc.) content may be released, unlocked, or otherwise made available per a rule to which the metric/trigger is tied. For example, a zoo sponsor may provide a giveaway to the 100,000th user to scan a particular tag (16a) such as a free zoo membership for the next year, which may appear as a digital offer for the winning user to redeem. Alternatively, after an individual user scans a predetermined number of tags the individual user may receive a digital certificate that enables the user to go “behind the scenes” with a trainer or paint a picture with an elephant or the like. The digital offer, certificate, or the like may be delivered directly to the digital wallet (24a) on the user device (14a), or it may be displayed on/in the interactive DEP and downloaded to the digital wallet (24a) by simply clicking on the offer/certificate. [0295] Video Replays and Other Video: A unique feature of embodiments of interactive DEPs includes the ability to watch a replay of some or all of the event. Although sports games often show replays of something that just happened, especially when the action is exciting or undergoing analysis viewers generally have little control over what is displayed, when it is displayed and how it is displayed. Within the interactive DEP, however, users may have control over what replay the user watches, how the replay is watched, and when the user wants to watch it. For example, the game day program (1600) may have a replay module/feature (1606). The replay module/feature (1606) may include a listing of replays that have occurred during the game. Thus, the user may select a replay from the list as it becomes available, watch a replay that happened earlier in the game, or both. The user may also be able to control replay speed (regular, fast, slow motion), pause the replay, rewind the replay, stop the replay at any point, and other functions while watching the replay of choice. [0296] Although the game day program (1600) has a replay module/feature (1606) dedicated to video replays, replays may be distributed elsewhere in the interactive DEP. As one nonlimiting example, replays may be shown on a page dedicated to a player or several players, especially if the replay captured a momentous occasion. Or the same replay may be accessed from more than one location in an interactive DEP. This may be especially true in a book-like format where a user may want to see the replay in context. Taking the city zoo interactive DEP (1700) as an example, a list of replays of exciting, cute, or other unique animal activity may be associated with an exhibit (1712), animal (1714), or both. Furthermore, games may exist, such as zoo trivia (714) or other scavenger hunts or activities. Nevertheless, the city zoo interactive DEP (1700) may have a feature/module (1718) dedicated to recordings that can be themed for funny things that animals do, educational videos, or both. Regardless of where replay/recorded videos may be displayed in interactive DEPs, video recordings/e-plays may be cycled, listed, or other presentation to allow the user to select and control the video as the user desires. [0297] Video content is not limited to replays taken from action in the game or the like. Video content may also include interviews with owners, managers, trainers, professional commentators, sponsors; team footage or other footage, advertisements, digital offers, and other content made in video format, or combinations thereof and regardless of interactive DEP format. This type of content may be listed, switched out in real time, cycled, etc., as determined by various rules and/or other instructions that enable the content to be acquired from a data source (e.g., at 512) and delivered to the interactive DEP in a manner the same as or similar to that described with respect to method (500). [0298] Indeed, real time exchange of advertising videos, sponsorship videos, or other videos that may require “viewing time” to be purchased, would allow viewing time to be sold on an ongoing basis, even during the event, which is not possible in print programs. As one nonlimiting example, an in-venue retailer (e.g., concessions, merchandise, etc.,) may realize that it has an overstock or surplus of inventory that it would like to unload before the event ends. The in-venue retailer may purchase a time slot for video or other content to be displayed in the interactive DEP. As one option, the back end for an interactive DEP can be modified so that the changes are immediately viewable in the front end (e.g., what the user sees) of the digital program. The back-end changes may be global to be applied to all versions of the interactive DEP for the event or select to be applied only for interactive DEPs distributed within the venue, for a particular grouping, both, etc. Back end changes may be made to one or more templates, rules, a “master templet,” “master code,” or other such back end changes. Time slots, however, may also be purchased in advance so that certain content is shown during the purchased time much like television advertising is purchased. As yet another option, in much the same way, an advertiser, sponsor, other organization, or the like may purchase time for their message to be shown on the jumbo screen (e.g., FIG.2 at [204]) or a live televised message. The advertiser et. al., may purchase time for their message to be shown in the interactive DEP at the same time it is being shown on the jumbo screen (204) or on a live broadcast. In this way, the user may be prompted to act on the message directly from their interactive DEP, such as by purchasing food, drinks, merchandise, NFTs, etc., placing wagers, or any other action allowed via the particular version of the interactive DEP displayed on the user device (14a, 14b), including downloading a digital offer to the digital wallet (24a, 24b) on the user device (14a, 14b). Thus, an embodiment offers real-time value added pricing of advertisements or the like, while simultaneously offering users the most dynamic experience with immediate and actionable content in the interactive DEP. [0299] Augmented Reality: Many of the experiences afforded by an interactive DEP may also be augmented via an augmented reality (AR) feature/module (1608, 1722). Generally, the AR feature/module (1608, 1722) enables a user device (14a, 14b) to digital elements to be added to or overlayed on objects, images, video, or the like that the camera (FIG.2, [212]) on the user device (14a, 14b) is pointing at or that is being displayed on the user device (14a, 14b) screen. As one nonlimiting example, when Janet is navigating to the restroom, she may point the camera (212) on her device (14a) in front of her to see the route superimposed on the image provided by the device camera (212). At the same time, she may receive information about concessions, restaurants, stores, lines, etc. as she is making her way to her destination. Information may also include digital offers that Janet can tap to download to her digital wallet (24a). Thus, when in AR mode, Janet may receive a wealth of information about her surroundings just by pointing the camera (212) on her user device (14a) in the direction she wants augmented. In much the same way, an AR feature/module may be utilized with the interactive DEP distributed by the city zoo (1700). As another nonlimiting example, the zoo may provide supplementary information about exhibits, animals, and other points of interest when in AR mode (1722) so that when the user points the camera (212) on her/his device (14a) at a particular exhibit, animal, or similar point of interest, information about that exhibit, animal, etc., may be overlayed onto the image displayed on the user device (14a). To enable this type of AR activity, the platform may utilize hardware and/or native software on the user device (14a, 14b), instructions delivered via the interactive DEP, code executed by one or more platform (20) servers (e.g., 302, 306, 310, 312, etc.,); data from the user device (14a, 14b), database (308), or any other data source; one or more third party integrations (320); or combinations thereof to gather data about the user’s surroundings for augmentation thereof. [0300] Users may also view captured video with AR objects, effects, filters, etc., disposed thereon. For example, cameras (FIG.2, [206a-206d]) at the venue (202) may be used to record the game in progress. These cameras may be any type of camera used for this or similar purposes as is known in the art. Cameras (206a-206d) may also be equipped or associated with Lidar sensors (light detection and ranging sensors), have high definition capabilities, have, or be associated with other such enhanced features/capabilities, or combinations thereof. Generally, recorded video may be made available to user in a manner that is the same as or similar to regular video replays except to implement AR activities, the video may first need to be processed to be compatible with certain AR effects. For example, the user may be able to place an avatar on a replay either in a position on the field, on a particular player, on an object such as a ball, or other such options. The replay may then be shown with the avatar disposed thereon, viewed from the perspective of the avatar whether it be on the field, player, object or other, or combinations thereof. In other instances, the user may wish to “draw” on the replay much like a professional commentator or the like. Of course, the forgoing are nonlimiting examples of what a user at any venue or watching any event may do with AR capabilities. Some of the AR playbacks may depend upon third party integrations, especially where there is a need for specialized equipment, specialized processing, etc., This is easily achievable through the platform (20) providing the interactive DEP utilizing one or more third party integrations (320). These integrations (320) may be via APIs, may be directly provided to the platform (20), or combinations thereof. Further, native hardware/software on the user device (14a) may be utilized to send and receive data, instructions, or the like to/from the platform (20), and the platform (20) may provide additional server- side processing of data etc. received from the user device (14a, 14b), the third party integrations (320), or combinations thereof to allow the user to manipulate the AR (or other) replay as desired. [0301] The proprietor does not have to make AR content available all of the time. Certain content may be tied to a rule or rules having one or more metrics/triggers to be satisfied before being made available to users. For example, certain replays (AR enabled or not) may only be available for a window of time after initial release, whereas other replays may only be available if the footage includes a significant occurrence such as a record being broken. As yet another example, a user may have to watch a promotion, take a survey, or participate in some other activity before content is made available to the user. These rules can be controlled by the proprietor to turn on or turn off certain aspects for delivering content. [0302] Advertisers, sponsors, organizations, etc., may also use aspects of the AR feature/module to their advantage. Advertisements or other messages may have to be viewed before the user can access the AR feature/module, they may be overlayed on the AR content, popup during viewing of the AR content, and/or other such similar ways advertising is made available. Furthermore, AR content may be sponsored by a specific advertiser and although not an ad per se, a notation regarding the business, organization, etc., sponsorship of certain content may also serve advertising purposes. For example, sponsored content may have “brought to you by XYZ company” or the like disposed over the content such as at the beginning or end of the content. The type of sponsorship may be tied directly to the unique ID, so that individual users may have a sponsor to the same target. Thus, a family of users, having two adult parents and two 18 year old children may each receive different sponsorships, targets, or offers even in the same location at the same time, based upon the rules formed by the proprietor based on the data in their unique ID. [0303] Although shown as a separate selectable option on the game day program (1600), a fan camera and/or fan filter (1610) may be made available to users. The fan filter feature/module (1610) may be a specific use of AR similar to filters used by various types of social media. The filters available via the interactive DEP, however, may be tailored to meet the proprietors needs such as by only offering options that support the team, game, venue, event, or other purpose. For example, the user may be limited to using team colors, mascot, logos, emblems, and the like. Embodiments, however, are not limited thereto. Moreover, fan filters may be integrated with social media platforms to be shared with remote users or others. The city zoo interactive DEP may also offer a zoo camera/zoo filter feature (1720) that is the same as or similar to the one found in the game day program (1600). In this case, the available filter may be based on animals at a particular zoo or other famous animals. [0304] The fan camera/zoo camera may be used alone or in connection with the AR feature/module. Generally, the fan camera/zoo camera utilizes one or more third party integrations (320) to provide video images from any angle. This capability may rely on specialized equipment including cameras, computers, sensors, etc., which were mentioned above. The result of this integration is to enable users to see a replay or the like from any available angle: top, bottom, and all around (e.g., the venue/exhibit, etc.) regardless of where the user is located. Thus, the user can see the same video footage from several different angles should the user desire. This technology may also be used to add AR overlays on the playback so the user may add an avatar or the like to a player, ball, or at another position and view the playback from the avatar’s point of view. [0305] Advancements in video technologies can generate visual experiences that are beyond normal replay and fan experiences. In an embodiment, the proprietor could deliver a custom message to a user (e-mail, text, push notification), to scan a tag (16a) that would provide a custom AR experience to each user. At the end, the user could be provided with a digital offer to add to the digital wallet. [0306] REAL-TIME STATISTICS: A live statistics module/feature (1612) may be especially useful in game day programs or other programs where statistics are commonly collected with respect to the event. Live statistics may be on one or more dedicated pages, sprinkled throughout the DEP such as on a page dedicated to a player, proximate an article, or combinations thereof. Moreover, statistics may be presented as usual for the event or may be presented as the proprietor desires. As a few nonlimiting examples, statistics for a football game may be by team, player, offensive team, defensive team, special teams, quarter, half, game, season, or combinations thereof and without limitation. Statistics may also be used to highlight team and/or player milestones and may even provide a countdown toward the milestone, used to dynamically rank players across a league, on a team, or the like, to play fantasy sports, and for wagering, to list a few examples. [0307] The live statistics module/feature (1612) may be updated in real time using one or more rules to push or pull data for the interactive DEP, much like the rules described with respect to FIG.5. As one example, statistics and related data (e.g., scores, time remaining, time elapsed, other time considerations, etc.,) may be updated at regular intervals (e.g., every N seconds, minutes), upon a change in the score or statistical change, and other metrics/triggers. Updates may be made using data sources such the database (308), analytics server (312), third party integrations (320), and other data sources. As another example, as an image element or the like associated with a statistics element so that when the statistics change so does the image in the image element. For example, a player Adams has just scored so the statistics for the game have changed, the statistics for player Adams has changed, and other statistics may have also changed. Adams’ image is inserted into the image element next to the statistics change to put a face with the new numbers. Thereafter, Bob sacks the quarterback; thus, statistics change, and so does the image by the statistics (e.g., Bob’s image) In an embodiment, one or more rules may be written to define the dynamic updating detailed above. The platform (20) may draw from images of players stored in the database (308) and associated with an identifier that relates the images with a statistics identifier such as a name, player number, position, etc. [0308] Advertisers, sponsors, and other organizations may use statistics to distribute digital offers via the interactive DEP. For example, a rule may be written to allow a sponsor offer to be unlocked, pushed, pulled, or the like if the home team scores 20 points in the first half, or if the home team intercepts twice during the second half, or any other conditions that an advertiser or sponsor may want to tie their digital offer to. Further, the advertiser et. al. may want only certain users to receive their offer. Thus, the rule may also include a second, third, or fourth metric (as was explained with respect to FIG.5), to limit distribution to a certain segment of the user population. [0309] Although live updated statistics is interesting in the sports world where statistics, scores, and the like are updated in real time in the digital program as the game is being played, statistics per se are not limited to sporting events. Data may be gathered and analyzed with respect to a wide variety of topics. Taking the zoo for example, statistical information may be distributed within the interactive DEP among other content, be put in a “trivia” form, gathered onto one or more dedicated pages, any other layout option, or combinations thereof. The statistics may relate to animals (e.g., gestation period, life span, estimated numbers in the wild, conservation efforts, feeding habits and amounts), habitats, global warming impacts, and the like or to the zoo or zoos in general such as the average number of visitors per day, week, year, etc., daily, weekly, yearly, etc., costs to run, number of employees, ranking compared to other zoos, area attractions, or other similar type of data. [0310] If statistical information is not available from a third-party source, it may be maintained and updated by the interactive digital program provider, the proprietor, or both. Statistics (and/or other information) may be updated manually via one or more platform (20). [0311] Non-fungible tokens: Many proprietors are taking advantage of the ability to tokenize memorabilia, collectables, and the like as a way for users to commemorate their participation in and/or attendance at an event. Generally, an NFT is associated with subject matter (digital or physical) that is perceived to have some value. The NFT may record a transaction relating to the subject matter on a blockchain such as a distributed ledger. The subject matter itself, and the metadata (e.g., including interest/rights in the subject matter) may be stored elsewhere such the interplanetary file system (IPFS). Proof of the transaction (e.g., purchase of the NFT) may be stored in a digital wallet (e.g., 24a, 24b), or another linked wallet that is designed for such a purpose. The NFT feature/module (1618, 1724), allows event and/or remote users to acquire an NFT whether it be through a purchase, an auction, freely distributed, or another mode of acquisition. [0312] The acquisition of an NFT may take advantage of one or more third party integrations (320) such as NFT blockchains that host and mint NFTs, NFT marketplaces that list and sell NFTs, other NFT related resources, and combinations of the forgoing. Before being able to acquire an NFT, certain measures may be taken to ensure that the user is entitled to NFT acquisition. As a few non limiting examples, the platform (20) may ensure that the device (14a, 14b) that scanned the tag (16a, 16b) belongs to the person that bought the ticket to the seat, that the device (14a, 14b) that scanned the tag (16a, 16b) is in the proper location, that the tag (16a, 16b) was scanned at the proper time, other verifications, and combinations thereof. [0313] A business may sponsor an NFT to be given away to only those people who purchased tickets for certain seats. Thus, the platform (20) may query data sources such as the database (308), third party integrations (320), or any other data source to determine if the user device (14a) that scanned the tag (16a) identifying the “winning” seat (208) belongs to the ticketholder for that seat (208). Generally, the platform (20) may check to see if there is information associated with the unique ID for the device (14a) and a ticket for the seat identified by the tag ID such as a digital ticket on the device, a ticket purchased via a third party, a paper ticket that can be scanned and confirmed or the like. In the same way, a proprietor may grant the first 100 fans that have scanned an in-venue tag (16a) an NFT for the interactive DEP. In this scenario, the platform (20) could gather data from the user devices (14a), the geofence (316), and the time (318) to ensure that only the confirmed 100 devices are enabled to acquire the NFT. In this example, user 101 and beyond may receive a message that the offer has expired or the like. As yet another example, the city zoo may offer what appears to be an unlimited NFT of, for example, a photo of a baby animal right after it was born. The zoo, however, may provide different editions of a photo or ownership rights in a photo by limiting the acquisition to those users at the zoo on a particular day, have scanned a tag (16a) by the exhibit with the baby animal, and by patron level (e.g., gold, silver, bronze, none). In this instance, the platform (20) would verify all of the metrics/triggers to enable NFT acquisition to only those users who have satisfied the rule and how they have satisfied the rule (e.g., patron level, if any) so that the users are only aware of the subject matter for which they qualify per the rule. From the forgoing it should be understood that the ways to incorporate the NFT feature/module (1614, 1730) into an interactive DEP are only limited by what a rule and associated metrics/triggers dictate if a rule is even used to limit the acquisition of an NFT. [0314] Wagering: Although wagering, betting, or the like may be more applicable to sporting events or the like, a wagering feature/module (1616) may be adapted to enable proprietors to offer raffles, prize drawings, and other enter-to-win type prizes (1726). Thus, a wagering feature/module (1616, 1726) is not limited to sports betting or the like. As with other features/modules, an interactive DEP may have a selectable option (1616) to launch one or more pages dedicated to wagering or the wagering feature (1616, 1726) may be distributed throughout the interactive DEP such as with statistics, on a player page, or other similar setting. Where wagering is related to sports betting or the like, the wagering may be limited to the game in progress, related fantasy sports, or the like, although embodiments are not so limited. Further, for official wagering, a third party integration (320) may be employed with one or more vetted gambling venues are available to the user. To be able to use such a third party integration, the platform may first determine, or attempt to determine that the user device (14a, 14b) is being operated by a person who is of legal gambling age. Such a determination may be made using the unique ID to search data sources such as database (308), official identification (e.g., driver’s license) in the digital wallet (24a, 24b), third party integrations (320), other data sources, and the like. And if the user is a remote user, the platform (20) may seek to determine that the remote user is located in a geographical area in which gambling is legal. Again, the platform (20) may use any data available to it to make this determination such as the unique ID in combination with a geofence, device GPS coordinates, etc., or combinations thereof. Verified users (in-venue, remote, both) would need to enable their digital wallet (24a, 24b) or another wallet to allow the third party gambling venue (320) to be able to place bets and deposit winnings. Third party gambling venues, proprietors, advertisers, sponsors, ticketing agents, or others may provide gambling opportunities as incentives for their products. For example, ticketing agents may offer a gambling credit (to qualified users) for expensive seats or hard-to-sell seats, or gambling venues may (320) provide a gambling credit to certain sections, seats, or other grouping, as two nonlimiting examples. Alternatively, a third party gambling venue (320) may randomly select a winning seat, a winning tag (16a) scanned (e.g., at [310]) for the event or the like, where the winner gets free beer for the entire game, a gambling credit, or similar type of prize. Of course, in each of the forgoing situations, the platform (20) may seek to verify that the device (14a) that scanned a tag (16a) identifying a qualified/winning seat belongs to the person that purchased the ticket for the seat as was described with reference to NFTs, and that the person is of a qualified age (e.g., 21), as was described with respect to FIG.5. Thus, the interactive DEP may provide an avenue to placing live or in-play wagers while being able to see real time statistics, odds, and the like all while an event is in progress and by the scan of a tag (16a, 16b). [0315] In an enter-to-win type of wagering adaptation (1726), which may be employed by a venue/event such as the city zoo, the platform (20) may randomly select a winner using data associated with a unique ID or the like. For example, a server may randomly select a unique ID associated with those users who opted to enter to win. A notification may be sent to the user device (14a) associated with that unique ID. A zoo employee may have a “verification code” on a handheld device or the like that the user device(14a) has to scan to confirm that the unique ID for the user device (14a) that scanned the verification code is the same as the one that was selected to win. If the unique IDs match, the user holding the device (14a) may collect the prize. holding the unique ID is the selected to win. [0316] Audience Participation: An embodiment of an interactive DEP may also include an audience participation feature (1618, 1728). Not all versions of an interactive DEP for an event may include this feature; it may be distributed to those seats that are more likely to desire this type of content, although embodiments are not so limited. Nonlimiting examples of activities that involve audience participation include polling activities, cheering activities, doing the wave, and other types of activities as appropriate for the event or venue. Both in venue and remote users may participate in real time polling such as voting for a favorite player, predicting the outcome of game, predicting a final score, and the like. Polling questions and results may be displayed on the jumbo screen (204), the interactive DEP (1700), or both. Real time polling and other types of audience participation events may be on an individual basis or a group basis. Referring to FIG.2, the platform (20) may take individual polling responses in each section, 222, 224, 226, determine the answer with the highest frequency, and assign that answer/response to the section as a whole. In this way, polling activities may be based on a grouping of tags (16a, 16b) instead of individual tags (16a, 16b). Group polling activities are not limited to averaging or the like; they may occur via alternative mechanisms. [0317] Of course such polling is not limited to sporting events; any event or venue may offer real time participation activities that appeal to their particular audiences. For example, the city zoo may have a “vote now” (1728) or other adaptation of an audience participation feature. Since zoo visitors are typically widely dispersed, results of polling may be tallied at the end of a predetermined time and sent to the user device (14a, 14b) [0318] Upcoming Events: Many event programs include a listing of events that are scheduled for a given time (e.g., season, year, month, etc.). Traditional paper programs typically only included a list of events to be held at a particular venue (202), although sometimes they may list events to be held nearby such as within the same city or other geographical area. Thus, a listing of upcoming events tends to be thought of as static list. But many events may be inserted into a schedule, rescheduled, canceled and the like. Thus, without the ability to update a listing of upcoming events the list may be incomplete and/or incorrect when distributed in a static program. [0319] The upcoming events feature/module (1620, 1708) of an interactive DEP is dynamic at least by being able to reflect changes to event line ups as they are noted in a data source from which the list draws information. Moreover, the interactive DEP as described herein may customize a listing of upcoming events for a particular user. For example, the unique ID and data aggregated therewith may give insights into what type of events a particular user enjoys. If the user has a high number of tags (16a) scanned at venues relating to performing arts, historic buildings, museums, or the like the user may receive a listing of upcoming events that weighs heavier on these types of events even though the user is presently at a sporting event and looking at the corresponding sporting event interactive DEP. As another example, the platform (20) may use the unique ID to determine where the user is primarily located geographically so that if the user scans a tag (16a, 16b) outside of his/her primary geographic location the platform (20) may use the unique ID, associated data, and other data to provide a customized list for the user’s current geographical location that corresponds to the time that the user is estimated to be away from his/her primary geographical location, a customized list for the user’s primary geographical location and after the user is estimated to return, or both. And if the platform (20) determines that the user who scanned a tag (16a) such as for a sports team that is not at the sports team’s home arena, the user may be able to select between an interactive DEP for the home team or for the away team. In this way, the user may be able to keep up with information relating to his team of preference. In other situations, a listing of upcoming events may relate to locations where the team, company, troupe, or the like is next appearing. In some cases, the user may be able to use the interactive DEP (e.g., other [1626]) to link to a third party ticketing broker via a third party integration (320) to purchase tickets at the out of town venue. [0320] The interactive DEP provided by the city zoo includes a special days/daily special feature/module (1708). This is essentially the same as upcoming events (1620) described above. The daily specials, however, may provide dynamic content such as a video, an article, or other updatable element to inform users about a unique activity happening at the zoo that day such as a special exhibit, NFT raffle, face painting, as just a few examples. Special days may relate to upcoming holidays, days with a special theme or activity, extended or reduced hours, fundraisers, or any other special day. These types of interactive DEP elements may only be updated every so often, but the fact remains that they are still dynamic. The proprietor does not have to print a new list if something changes--it is a simple update of data that will automatically bring the new listing to users via the interactive DEP. The zoo too can provide a customized list of upcoming events as was detailed above with respect to the game day program (1600). [0321] Contactless transactions: Users, whether at the event or remote, may take advantage of one or more interactive DEP features/modules that enable contactless transactions such as ordering food (1624, 1734), merchandise (1622, 1736), tickets (e.g., other [1626, 1732]), or the like. While at a venue (202) the platform (20) knows which tag (16a) was scanned by the user device (14a) via the tag ID. Thus, the in-venue vendor may deliver the purchase to the user at the location identified by the tag (16a), such as the user’s seat or another location specified by the user when the order was placed. Alternatively, the user may opt to pick up his/her purchase at the vendor location after placing the order, receiving a notice that the order is ready, or other such messaging/notification. [0322] Remote users may still be able to take advantage of contactless transactions via the interactive DEP. For example, a remote user may be able to connect to participating local eateries to have food delivered. The platform (20) may use a data associated with the users device (14b) including data associated with the unique ID assigned to that remote user device (14b) to determine the user’s primary location or exact location (e.g., GPS), use third party integrations (320) to access participating vendors in the remote user’s geolocation, and allow the user to place a food or other order to be delivered to the user’s location. Similarly, remote users may also make in-venue purchases for merchandise (1622) or other non-perishables that can be delivered to an address provided by the remote user via the interactive DEP, connect to in-venue or third party ticket providers to purchase ticket for one or more upcoming events or other similar transactions. [0323] In-venue retailers may be able to take particular advantage of the interactive DEP. For example, digital offers can be sent to user devices (14a, 14b) via the game day program (1600, 1700). They can be directly loaded into the user’s wallet (24a, 24b)) or appear in a popup window or a placeholder within the interactive DEP for dynamic content such as in-venue retailer offers or the like so that the user can tap on the offer before it is downloaded to his/her digital wallet (24a, 24b). In this way, the user may redeem the digital offer when making a contactless transaction via the interactive DEP, although the digital offer may not be limited to contactless transactions. This provides concession owners, retail owners, and advertisers an ability to immediately see conversion rate of a digital offer that is issued (e.g., 100 coupons were downloaded via an interactive DEP and 80 were redeemed). [0324] Digital offers may also interface with surplus inventory at the venue. For example, if the concession stand has a surplus of hotdogs, the customized offer could BOGO hotdogs. Such information can be encoded through a third party integration (320) that generates and automates this information. For example, the total inventory of food or beverages may be displayed to an in-venue user or can be accessible to a manager of the concessions so as to effectively manage the operations for the venue. [0325] Additionally, the merchandise portion of the interactive DEP may be linked, via a third party integration (320) to the POS to the team store. This would allow for dynamic pricing of merchandise based on information from the POS. For example, if there is an overstock of merchandise for a particular player, or other merchandise if at the city zoo for example, the platform (20) may generate a digital offer for a discount to purchase merchandise. Alternatively if a player, zoo animal, or the like celebrated a milestone, such as player scoring his 10,000th point, a zoo animal being the first of its kind to be born in captivity, or other such milestone, a dynamic digital offer in the interactive DEP may change to advertise the discounted merchandise. [0326] Mobile payment is a rapidly expanding business segment and NFC applications such as, for example, contactless transactions are expected to be the most widely adopted form of mobile payments. Embodiments of the invention provide users with the ability to establish radio communication (e.g., NFC) or other communication between the user device (14a, 14b) and the plurality of tags (16a, 16b) by touching them together or bringing them into close proximity. In this way, payment information may be automatically transferred from a secure location (e.g., digital wallet [24a, 24b]) to the platform (20) to complete the contactless transaction. [0327] Advertising and Digital Offers: Advertising and digital offers (e.g., at 1724) may also be a form of dynamic content contained in an interactive DEP. Advertising and digital offers may be distributed throughout the interactive DEP, contained on one or more dedicated pages or both. Further, advertising and/or digital offers may be unlocked, released, ungrayed, or the like per one or more rules having one or more metrics/triggers associated therewith as is described with respect to FIG.5. Digital offers may be loaded directly into a digital wallet (24a, 24b) or may be tapped to be downloaded to a digital wallet (24a, 24b). For those users who desire to keep receiving information, digital offers, and the like outside of the interactive DEP, the user may download “VIP Card” or the like to their digital wallet (24a, 24b). The proprietor, advertisers, sponsors, or the like may then use the VIP Card to send notifications to the user about venue/event promotions, updates, or any other information to the user device (14a, 14b). Thus, there is ample opportunity to be creative when it comes to digital offers. [0328] Advertising, digital offers, and the like may be changed within the interactive DEP on a regular basis such as via a designated time slot, in a cycle, or other timing-based basis; based on a trigger/metric defined by a rule, whether the digital offer is shared, based on in-venue inventory levels, or other metrics, triggers, or circumstances. Some of these dynamic alterations have already been discussed with respect to another feature/module such as dynamic pricing of in-venue concessions, merchandise, or the like. [0329] For example, an interactive DEP obtained by scanning an in-venue tag (16a) may include an advertising space (e.g., in only in-venue versions of the interactive DEP) linked to a specific in-venue retailer. That retailer could promote its business in real time offering distinct discounts at different times during the event, upon the occurrence of a metric, trigger, other condition, or another defined parameter. That the advertising, offers, and the like are only going to in-venue users may be controlled by the tag ID (e.g., for an in-venue point of interest), a geofence (316) around the event/venue, GPS coordinates from the user device (14a), time data (318), or combinations thereof. [0330] In some instances where a user has a digital offer downloaded to the user device (14a, 14b), the user may transfer the digital offer to one or more other user devices. If the user transfers the digital offer to a predefined number of other user devices, the digital offer may increase. For example, upon opening the interactive DEP the individual may select individual a digital offer and download it to her/his device (14a, 14b). The digital offer may be linked to the unique ID for the device (14a, 14b), a unique certificate, or the like to track sharing. If the user transfers the digital offer to, for example, five other devices within a fixed time period such as, for example, a week, the digital offer automatically upgrades so that when the user goes to redeem the offer, the offer has been increased from 10% to 20% off. This capability offers further incentives for users to transfer their digital offers to family and friends so that they will receive greater discounts. Also, this capability will allow brands and retailers to watch their promotion go viral from a first point of download (e.g., via the interactive DEP) to various locations where the digital offers are transferred between various user devices. Some digital offers may be shared and tracked via NFC, MMS, SMS, social media such as Facebook, Twitter, Snapchat, etc. As a variation, digital offers may be browser based, stored in a digital wallet (24a, 24b), or both. [0331] As has been detailed with respect to FIG.5, a digital offer, advertisement, or other dynamic content may be made available to users based upon the fulfillment of one or more metrics/triggers or other condition to satisfy a rule. For example, a rule may be written to allow dynamic content to be released at or near the end of the event, if a particular team wins at a sporting event, if one or both teams at a sporting event scored a predetermined number of points, if a particular metric, trigger, or the like occurred such as a touchdown, a homerun, a stolen base, a 3point shot, etc., or any other conceivable metric, trigger, condition or the like, or combinations thereof. In a specific implementation, a rule or other instructions may be written so that a third party advertising integration (320) may check on another third party integration (320) such as statistics, to see if a metric, trigger, condition, or the like has occurred (e.g., the quarter back threw a record number of touchdown passes), which would then release the digital offer for user consumption. [0332] As with other forms of dynamic content, advertising, digital offers, and the like in the interactive DEP may also be customized in a manner that is the same as or similar to customization described with respect to FIG.5. For example, conditions, triggers, metrics, or the like may be used to generate specific and tailored information, offers, and content based upon the particular user information and actions of the user that may be associated with the unique ID. As one nonlimiting example, the unique ID may be used to determine the type of content that the user typically views on the user device (14a, 14b) and display an advertisement, digital offer, or the like based on that user’s unique history. Additionally, advertisers, sponsors, or the like may want their content to only be displayed in the interactive DEP to users who fit their demographic profile. As such, unique IDs may be used together with other available information to deliver the designated content to just those users. Alternatively, user demographics may be assumed based on where the user is sitting or otherwise located at an event. In this way, advertisements, offers, and other content relating to luxury items may be distributed to only those users who purchased seats that are indicative of the ability to purchase such luxury items. As yet another example, different versions of an interactive DEP may receive exclusive content, digital offers, advertisements, etc., based on the perceived preferences for users sitting in those seats. It may be perceived that younger users will sit in discounted areas of a stadium, buy cheaper tickets to concerts, or the like and as such, advertisements, offers, and other content may be included in the interactive DEP version for such a grouping. At the other extreme, it may be believed that only those users with large disposable incomes will spend the money for expensive seats, locations, or the like and so content, including advertisements, digital offers and the like for high-end items may be included in the version of the interactive DEP to be distributed to that grouping. In this way certain exclusive content may be offered to different versions of an interactive DEP. Of course, content, advertisements, and the like may in some instances be customized based on information associated with a unique ID. For example, a young person may be extremely wealthy, but likes to sit in discount seats. Thus, the interactive DEP distributed to that user device may be a version that is the same as or similar to one to be distributed to expensive seats. [0333] Since advertising space in an interactive DEP may be limited, it may be more valuable. Thus, advertising, offers, and other purchased content time/space may be priced accordingly. For example, advertising to be distributed to a grouping including expensive tickets for the event may cost more than to a grouping including cheaper tickets. Additionally, pricing for an event that is more exclusive may also cost more to the advertiser, sponsor, or the like. Thus, the cost to advertise in a particular version or all versions of an interactive DEP may also be dynamic. To offset costs, in an embodiment, advertising space and the like may be sold on a “pay per click” basis, such as by the number of tags (16a, 16b) were scanned at a particular event, on a particular day, in a given time frame or the like, by the number of digital offers that were downloaded, by the number of digital offers that were used, or any other trackable pricing scheme. Advertising space may also be sold on a tiered basis. For example, advertising on a home page, or top features/modules viewed may have one cost level, which decreases as the determined usage of the feature/module decreases. Also, advertising, digital offers, and the like may be dynamically moved during the event if the feature, module, page, etc. that receives the most usage during a particular event is different than what is expected. As one example, an advertiser may pay for a space on the first page seen for an interactive DEP, but a replay of some exciting action is being viewed by most of the users and they are skipping over the first page. An administrator may be able to move the content to the page that is in actual use, or it may happen automatically, thereby ensuring that the paid for content is in fact being displayed per the purchase plan, price, etc. [0334] Eventually the event will end, even if it is a daily event such as a zoo, museum, or the like. In some embodiments, connection to the interactive DEP is also cut off. Thus, although the user may still be able to see a cached copy of the interactive DEP, nothing in copy will be updated, altered, modified or the like. Alternatively, the interactive DEP may continue to be used use by the user. As one example, the proprietor may opt to have the interactive DEP maintained by the platform (20), and as such it may function much like a traditional web site, but one that is only available to users who have previously scanned a tag (16a, 16b) for the interactive DEP during the event. In this way, proprietors may stay in communication with their customers (i.e., event users, remote users) an updated the interactive DEP latest content, offers, etc. on an ongoing basis. In fact, in some instances, the proprietor may keep one or more “expired” (i.e., for an event that is over) interactive DEPs as a historic document such as for a season, keeping certain content, offers, etc. static while providing new dynamic content. For example, a historic version of an interactive DEP may provide recaps (video, images, text) of the event or related sequence of events (e.g., over a sports season), change or reup digital offers, keep certain digital offers open for subsequent use, among other possibilities. Keeping a historic document will not interfere with a user being able to scan the same tag (16a) at the venue to receive the latest interactive DEP as each DEP has a different URL, ID, etc. and the latest tag (16a) scan will lead the user device (14a) to the correct interactive DEP for the current event in progress. [0335] Proprietor Administrative or other Administrative Activities: Proprietors may manage their network of tags (16a, 16b) using the proprietor portal (FIG.3, [322]). In an embodiment, proprietor portal (322) is software suite running on platform (20). The proprietor may access the portal (322) via a Web browser, other application, or both executing on the administrator device (FIG.1, [12]). The interface for the proprietor portal may be one or more browser-based Web pages, a Web-based application, a progressive Web application, a downloadable application, a native application, and a cloud-based application (to name just a few examples), which may be delivered to the administrator device (12) by the redirect/identification server (302). Thus, the proprietor may be able to view and manage various aspects associated with the proprietor’s venue, event, network, etc. including viewing the real-time status of all tags (16a, 16b), interactive DEP templates, URLs, content, and more. [0336] Indeed, much of the platform (20) may be accessible to the proprietor such as the database (308) to manage data relate to tags (16a, 16b), interactive DEP templates, content, unique IDs, data verified using verification techniques/algorithms, data verified as part of a blockchain distributed ledger, other data stored thereon, and combinations thereof. In an embodiment, the analytics server (312) may retain device (14a, 14b) requests and/or data from past user interactions with one or more tags (16a, 16b), including interactions assigned to individual user devices (14a, 14b) and/or collective interactions of some or all user devices (14a, 14b). The analytics server (312) may also incorporate third party data from outside sources third party integrations (320), blockchains (314), and others. Thus, the analytics server (312) may run software to analyze collected data from some or all of the forgoing to help optimize what a particular user experiences through his/her interactive DEP. As nonlimiting examples, analytics server (312) may use information from cookies, log files, page tags (e.g., JavaScript code embedded in Web pages), associated with a unique ID, and combinations thereof for reporting to the interface server (306), administrator server (310) or the like. Indeed, in an implementation, some or all of the administrative tasks may be performed by a platform (20) administrator via administrator server (310). As one nonlimiting example, a platform (20) administrator may be called upon to write rules for one or more versions of an interactive DEP, especially when the rule(s) need to be written in a specific coding language that the proprietor is not familiar with. [0337] Typical administrative activities associated with a network of tags (16a, 16b) include those relating to tag (16a, 16b) management, creating, updating, managing interactive DEP templates, reporting, and more. The examples detailed herein are for illustrative purposes only and are not intended to limit how a proprietor may choose to view, manage, generate, store, or otherwise manipulate data. Additionally, it should be realized that the actual proprietor may not be performing administrative or other such tasks. Typically, these are handed off to agents, employees, or other representatives of the proprietor. In some circumstances, stadium officials may be able to access the proprietor portal (322) from a handheld device such as a smartphone, tablet or the like so that they may perform certain tasks on the go. [0338] Tag management may include tasks such as, without limitation, assigning each tag (16a, 16b) in a network to a distinct point of interest, creating tag groupings, assigning an employee to one or more tags or groups of tags, and additional tasks. Assigning each tag (16a, 16b) to a distinct point of interest includes linking the tag ID to the distinct point of interest so that when the tag (16a, 16b) is scanned by a user device (14a, 14b) the point of interest is known via the tag assigned thereto. To help ensure that tags, in particular in-venue tags (16a) have not been tampered with, the interactive DEP may include a reference to the point of interest it is associated with such as “This Game Day Program is for seat 1, row A, section 100” or something similar thereto. If tampering is a problem, the user may even be required to confirm that the tag (16a) scanned corresponds to the seat or other point of interest before the interactive DEP is displayed on the user device (14a). [0339] The proprietor may also group tags (16a, 16b) via the proprietor portal (322). Tag (16a, 16b) grouping is flexible to meet the needs of the proprietor at any time. Thus, tags (16a, 16b) may be grouped, regrouped, sub-grouped, etc. on demand. Grouping tags (16a, 16b) may be advantageous for many reasons. As one nonlimiting example, tags (16a, 16b) may be grouped to deliver different versions of interactive DEPs to different users such as those in the venue, remote from the venue, and other such grouping which have been detailed herein. Although grouping tags (16a, 16b) enables certain activities to belong to the grouping such as content pushed or the like, each tag (16a, 16b) remains autonomous e.g., the platform (20) still knows which particular tag (16a, 16b) was scanned by a user device (14a, 14b) and it knows to which group the particular tag (16a, 16b) belongs. [0340] It should be noted that scanning a tag (16a, 16b) does not always result in the loading of an interactive DEP on a user device. The proprietor can associate each tag ID with an endpoint outcome such changing certain phone settings, creating and sending a text, launching an application other than one associated with an interactive DEP, turning on device via Bluetooth or any number of commands to be executed, limited only by the communication device. Another endpoint outcome may be to redirect the user device (14a, 14b) to a Web page/Web site other than the interactive DEP such as one for a particular advertiser, sponsor, organization, or the like. This type of redirection may occur at different times during an event so that if a user scans a tag (16a, 16b) for the first time or if the user rescans the tag (16a, 16b) during the event, the user device (14a, 14b) will be redirected to the advertiser et. al.’s page instead of the interactive DEP. In this way, multiple different advertisers can utilize the plurality of tags (16a, 16b) during the event. [0341] Of course, the endpoint outcome may also be loading a version of the interactive DEP on the user device (14a, 14b). In an embodiment, the proprietor may log in to the proprietor portal (322) to access one or more Web- based templates for a given interactive DEP. Generally, the proprietor may choose a format (e.g., like the game day program [1600] or the book-like program [1700]) and drag and drop placeholders for features, elements, content, etc. in the template to correspond with a desired visual layout. For instance, placeholder for an article may be dragged and dropped on a particular page and in a particular location on the page. Other placeholders for surrounding content such as images, video, advertising, etc. may also be dragged and dropped as desired. This flexible approach may be handled in-house, which also enables the proprietor to alter the template at any time, even during the event. Further, it is easy to create versions of the interactive DEP from such a back-end template driven approach. That is, the same basic layout may be used for several different versions of the interactive DEP for the same event. The proprietor may assign different content to go with the different versions and make other tweaks to a particular version of the interactive DEP. Of course, the proprietor may always create a completely different format, layout, or both for a version of the interactive DEP. [0342] Assigning different content to different placeholders may be as simple as causing the placeholder in one version to be linked to one advertisement, image, NFT, or the like, and the placeholder in a second version of the interactive DEP to be linked to a second advertisement, image, NFT, or the like. As one nonlimiting example, a link to content may be via a URI such as a URL. Moreover, if the content is dynamic content the link may lead to a third party integration (320), which may utilize one or more APIs, although embodiments are not so limited. Thus, content may continuously be delivered to the interactive DEP via the third party integration. As one example, a template placeholder for statistics may be substituted with statistics content in the interactive DEP that is continuously updated , but a third party integration for a journal article may be substituted for its placeholder only one time without additional updates, as is the general nature for journal articles. Actual content inserted into the interactive DEP in lieu of a placeholder may be governed by a rule having one or more metric, triggers, or the like. Savvy proprietors may be able to write their own rules and cause them to accurately function within the interactive DEP. Alternatively, an administrator for the platform (20) may assist with this or any other task. Rules may be written to allow certain content to become available when certain metrics, thresholds, triggers, etc. have been met. Such conditions may be simple, e.g., update every N second, or they may be very sophisticated and complex. Nevertheless, rules, metrics, triggers, thresholds, and other conditions may allow each interactive DEP distributed to users during an event to be highly customized for a particular user. [0343] When a template, its content, rules, etc. are finished, or even before it is finished, the URL for the template may be assigned and attached to a venue (e.g., if the proprietor has several venues), an event, both, a group within the venue (202), a geographical location, a Web page (e.g., for the venue, event, both), a network, a regional network, or any other designation for accurate distribution. In this way, when a user device (14a, 14b) scans a tag (16a, 16b) the tag ID may be used to redirect the user device (14a, 14b) to the proper template for the interactive DEP for the particular event in which the user is engaged. Thereafter, placeholders may be populated with content for user consumption and dynamically updated such as by content updating instructions including one or more rules. [0344] Thus, the use of a template allows for easy distribution and simple modification by proprietors. However, savvy users can modify and use their own forms or unique formatting as necessary for each instance other than rely on a platform (20) provided template. By utilizing simple formatting, such as in a template, information, including those being captured in a live format from a third party integration (320), can be added via “drag and drop” type creation, which allows for extremely simply modifications. For example, content can be created before an event and continually modified as an event unfolds. The interactive digital interactive program can be mobile first and contain various native features that allow for an engaging fan experience. [0345] Proprietors have the ability to monitor their network of tags (16a, 16b) via the proprietor portal (322) viewing data in various graphic forms such as graphs, charts, diagrams, etc. The proprietor may monitor the status of points of interest (e.g., via the network of tags) in real time as the event is in progress. In this way, the proprietor may see how users interact with tags (16a, 16b) and can make any adjustments as the proprietor sees fit. During the course of monitoring, the proprietor may manually update content based on data collected, feedback received, and the like. If a change is made to a template while the event is in progress, the change is automatically applied to the interactive DEP on the user device (14a, 14b). [0346] In an embodiment, a proprietor may want to receive feedback from users. User input may be a valuable source of information for a wide variety of purposes such as determining user satisfaction. According to embodiments of the invention, a feedback feature/module may be placed in the interactive DEP so that users can submit comments directly to the proprietor. Such feedback may be in the form of fillable fields, surveys, written comments, or combinations thereof. [0347] A proprietor may also run reports utilizing the proprietor portal (322). For example, the proprietor may view information relating to overall usage statistics, group statistics, individual tag statistics, statistics about which features/modules are used the most, if they are used more on one page versus another page, and much more. In an embodiment, the proprietor may even be able to run a report on tag usage across several events, venues, or the like. Usage reports may be configured for information such as the number of times a given tag has been scanned by any user during a period of time (e.g., day, week, hour, etc.) or the number of times any tag has been scanned by a particular user during a period of time, or many other ways in which a proprietor may want to analyze the data. EXAMPLES EXAMPLE 1: SEAT DATA FOR USERNAME [0348] Users are accustomed to having a username. And in situations where games are played, trivia, or aspects displayed on a jumbotron, as nonlimiting examples, users like to be seen, especially when they win! Accordingly, as a seamless way of automatically providing usernames, the name can simply be the seat information for that user. Thus, someone sitting in seat 1, row 1, section 101, could be S1R1S101 – or another variation of the same. This will allow for users to immediately understand where they are on a scoreboard without having to create an entry or profile. [0349] This information can be utilized for both in-venue and for external 3rd parties. I believe there is a lot of value in both using that seat data inside of our own platform, and passing that data to 3rd parties, as a naming convention/username. So players would not have to sign up for accounts or create their own username in order to be placed on a leaderboard. In some embodiments, it would then be a requirement to have a seat to play in the various games and activities, so that you have a name. [0350] Furthermore, this seat information can be used for easy distribution of purchases, whether that is concessions, novelties, or other. We could also use the same logic at some point to where when the seat data is passed it would only show food or merch available to a particular seat based on the seat ID. On the back end, this convention/username can be the tag ID, or a portion of the tag ID, or a completely separate set of numbers and/or letters can be the tag ID and associate the same with the username within a database. Furthermore, the username can be associated with a unique ID, so that if John frequently sits in seat 1, row 1, section 101 at baseball games, the system will understand that John likes to play trivia and know his back scores at that seat. [0351] This provides another avenue for the system as a whole to gather information about a given user. The end goal is that upon obtaining information from users, the system can implement one or more rules corresponding to the user, i.e., at the unique ID level, or at the seat level, to a section level. These can be performed by the controller pushing certain rules and then content to these users. Furthermore, this will allow for the creation of more, complex rules that can provide unique opportunities for fan engagement. [0352] For example, a complex rule may include features such as where you are sitting, the number of times you attend games, the trivia or other events you participate in, your ticket purchase history, your concession history, your novelty history, your wagering history, purchase of NFT’s or ownership of an NFT, etc. The aggregation of data regarding the user base allows for the system and the teams or venue operators to identify trends and to provide content to users who are not participating in a similar manner to similarly situated users. The goal remains to create improved fan engagement and fan enjoyment opportunities. EXAMPLE 2 [0353] In some embodiments, it may be advantageous to send a user an e-mail or push a text comprising their MRC with a tag ID before or after attending an event. For example, a user may want to pre-order food to their seat, pre-order concessions, or to engage with the team or venue in ways that are not previously available. [0354] In certain venues, wagering on the game is provided and in certain of these venues, there may be sections within the stadium wherein benefits are provided based on the particular section or seat. Thus, the venue can offer a dynamic offer capability based on seat pricing, sports book tie into API offers based on price of ticket. For example, a sports book is seeking to pre-sell value at the sports book for the game. The sportsbook can pre-sell seats/tickets that include a voucher or value within a wagering wallet tied to the unique ID and tag ID for the wagering wallet. Here, the sportsbook first offers a $500 ticket with a $100 to get me to gamble. However, after the first game, only 10 seats were purchased for this situation. By contrast, in a separate section, the sportsbook offered a $50 ticket only need to give me $10. Interestingly, this sold 750 seats. Thus, the sports book provided $1000 to the 10 seats at the $500 level, and $7500 for the 750 seats at the lower level but obtained many more touches with the wagering system for the lower level award. This could mean a lot of different things for purposes of seeking to engage with bettors. [0355] For example, it may mean that higher value bettors already have accounts and place wagers, without the need to entice the purchase. Or, it could mean that those purchasing $500 seats don’t want to place bets during the game, or any other metric. Thus, the sportsbook can modify this offer, and offer $250, or $500, or even $1000 or more for the $500 seats. Sportsbooks typically prefer to entice “whale” bettors, or those who will place larger wagers, as compared to many smaller bettors. However, this is not the case in all scenarios. [0356] Accordingly, to enact the above, the seat can be tied into a third-party ticket provider as well as a sportsbook to identify the payment terms, exchange of the value and fulfilling of the dollars into a wagering wallet. These offers can be modified per game, or on a live basis. For example a seat may be offered in the premium wagering section during the game. The seat may be a premium seat and contain $500 wagering credit, for $1000. Thus, a user can upgrade their seat, by exchanging their seat to obtain the new seat and wagering offer. [0357] The old seat can then be placed back for sale for subsequent sale or exchange with another user who desires the now empty seat. These offers and opportunities can fluctuate based on price of seat, availability, in-game metrics, etc. Furthermore, the pricing may change before the game starts. For example, the price may increase or decrease as it gets closer to game time, or the credit can be adjusted up and down. EXAMPLE 3 [0358] The platform can be used in a medical setting such as a hospital where a user can scan a tag with a QR code that is located on the bed, the tray or anywhere else in the room to place mobile order. In this nonlimiting example, the tag ID is associated with the room number or any other convention adopted by the hospital. [0359] When a user scans a tag in hospital room the system/platform is able to identify that the device that scanned the tag is located in a specific room similar to the way the system/platform is able to link users to locations in venues described in detail herein. Hospital settings, long term care, and other places that have many rooms and patient needs, frequently have needs to rapidly assist patients and to ensure safety. Thus, we can utilize a user device to scan a tag within the system. The user can then have the tag ID corresponding to the room number and match that tag ID with the unique ID on the user device. This allows for a simple mechanism to identify the venue, location, and who scanned the tag ID. Accordingly, a user, through scanning a tag via a user device can give feedback in real time about the experience of staying at hospital, report issues, request things, engage with staff, etc. [0360] Finally, the system can be used to assist with scheduling and communication with patients. Because the user device, after scanning, can receive a template or a DEP, information can be dynamically pushed to the user device. Thus, the user can schedule activities, schedule meetings and appointments, receive updates on their appointments, etc. Finally, the user device can be used to control certain electronic components within the room, as simple as the tv and volume, or can control and request things, such as a robot for order and delivery of foods, medicines, and other accessories. =The system can then utilize the unique ID tied to the user to provide for necessary feedback, information and the like, based upon the needs of the user. EXAMPLE 4 [0361] The system/platform can also be implemented in a parking garage or parking lot. In this nonlimiting example, an NFC or RFID chip can be imbedded in the concrete or other parking surface or a QR or bar code can be painted or otherwise displayed on top of the parking space surface. The system can be used to automatically charge the user for the time the user’s vehicle is parked in the space. Additionally, the system can charge the user for wireless charging of the user’s electric vehicle which is paid on entry if the parking garage is equipped with charging stations. With the increase of electric vehicles, parking spaces will need to increase the charging opportunities and to pay for the same, provide updates as to charge, etc. Thus, a tag employed at a parking spot can allow a user to identify their user device through a unique ID, identify their car, either by creating an account or scanning, for example the VIN number or the license plate. This information can then be pulled from an API to identify the make, model, owner, etc. of the vehicle, or it can be provided, if needed. Finally, the user can pay for any charging or services desired through the user device. [0362] Thus, the charging may be desired, but also washing the car. The system can then identify when the vehicle is fully charged and then move the vehicle to the washing location and notify the owner through the user device, when both the charging and the cleaning are complete. The user can pre-pay for these services and even plan them, so that, for example, the work is complete by 1:00 if the user has to leave, or by 5:00 or a different time, based on the user’s needs. EXAMPLE 5 [0363] The system can push content that is a video replay or live video, audio, augmented reality or virtual reality feed. In the DEP or in the venue, users often desire the ability to see all the action that may be occurring at a different spot or from a different view. This is often an issue in venues that have multiple stages or vantage points. For example, at a horse racing event, the user can quickly swap to the camera view on a section different from their vantage point. This can also be done for patrons at a golf event, where they can sit at hole 9, but watch the tee shots at all other holes, by accessing the video fee for those tees. This is also a common issue at tennis tournaments, where a user can only watch one match at a time. By accessing video feed, the user can be in the stadium, but watch the matches on, for example, court 18. [0364] Thus, a user can scan a tag, for example on their seat, or on their ticket or their badge and receive access to a video playback feed. This may be presented in the DEP, or in another GUI as provided by the various embodiments. EXAMPLE 6 [0365] In certain embodiments, the user’s desire to have services provided for them for a fee. Such services are typically “VIP” like services, and may be provided for free for certain individuals, or paid for with the purchase of certain tickets or won through opportunities. Here, by scanning a tag, a user can upgrade to certain access or treatments, buy a ticket to upgrade to the same, or access such treatments by winning experiences through the system. One examples is a venue wide contest, such as a trivia contest, a scavenger hunt or the like. Where the users have to perform and ultimately win some prize. The prize may be a VIP treatment, or back-stage access, or locker room access, etc. [0366] 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.

Claims

What is claimed is: 1. A method for delivering dynamic content to a user device via a machine-readable code comprising: a. in response to scanning a tag comprising the machine-readable code, receiving a request from a user device and detecting the presence of a manifest packet or locally stored data file comprising a unique ID, wherein if no unique ID is present, creating a unique ID and associating a record with the unique ID within a database; b. detecting from the tag a tag ID and determining: i. whether a venue corresponding to the tag ID has been defined; and ii. whether an event is in progress corresponding to the tag ID; c. redirecting to a default target if no venue exists or no event is in progress, and determining if a tag ID is grouped where the venue exists and an event is in progress; d. counting, via a counting mechanism, the total number of user devices identified by unique IDs that have scanned a tag while the event is in progress and determining, via the counting mechanism, whether a threshold number of user devices have scanned a tag; e. upon meeting the threshold number, in response to the detecting from the tag ID, obtaining tag ID group information and associating the tag ID with the unique ID; and f. associating the unique ID and a unique ID record with the tag ID and redirecting a user to an appropriate target.
2. The method of claim 1 further comprising: d2. providing a first supplemental content to the user device when the threshold number is unmet and a second supplemental content upon meeting the threshold number.
3. The method of claim 2 wherein the threshold number is selected from the group consisting of: a total number of unique users on a system at a time t, the total number of unique users accessing a system after a time t, x number of scans corresponding to a unique ID and x number of tags, and combinations thereof.
4. The method of claim 3 wherein the total number of unique users on the system at a time t is greater than 1,000.
5. The method of claim 3 wherein the total number of unique users on the system after a time t is greater than 1,000.
6. The method of claim 2 wherein the first supplemental content and the second supplemental content are provided to the user device by: redirection to a new target, a push notification, a dynamic element update, unlocking a module, an overlay, a popup, a mobile wallet offer, a video file, a short messaging service, a multimedia service, an email, or combinations thereof.
7. The method of claim 1 wherein the machine-readable code is selected from the group consisting of: a barcode, a quick response (QR) code, a near-field communication (NFC) code, a radio-frequency identification (RFID) code, and combinations thereof.
8. The method of claim 6 wherein the target is stored within a database and is automatically provided upon the occurrence of the event.
9. The method of claim 8 wherein the second supplemental content is selected from the group consisting of: a digital offer and an advertisement.
10. A system using machine-readable codes to gather data relating to an event and to display content on a user device based on the gathered data comprising: a. a server system having a computer processor and computer memory; b. a plurality of machine-readable codes, each machine-readable code encoding a tag identifier and an address directed to the server system, each machine-readable code physically or digitally associated with a recorded point of interest; c. a counting mechanism operably connected to said server system; d. a database operatively connected to said server system for storing gathered data; e. wherein the computer memory of the server system stores executable code, wherein when executed the executable code enables the server system to perform a process comprising the following steps: i. receiving a request from one user device, the request generated by scanning one of the machine-readable codes with said user device; ii. determining whether a unique ID is associated with said user device or generating and assigning a new unique ID to the user device, and linking said unique ID and said tag identifier obtained from the scanned tag in said database together with a date and time stamp identifying the date and time in which the user device scanned the particular tag; iii. collecting user data associated with the user device and storing the same within the database record, wherein each user device comprises a unique ID; iv. setting a threshold for delivery of unique content upon meeting said threshold, said threshold determined by the counting mechanism; and v. providing the unique content to the user device upon meeting the threshold.
11. The system of claim 10 wherein the threshold is selected from the group consisting of: a total number of unique users on the system at a time t, a total number of users accessing the system after a time t, and combinations thereof.
12. The system of claim 11 wherein upon each subsequent scan of the machine-readable code a new unique content is generated within said server system for delivery to the user device.
13. The system of claim 11 wherein the unique content is a digital offer or an advertisement.
14. The system of claim 13 wherein the digital offer is modified by a provider of said digital offer.
15. The system of claim 14 wherein a digital offer is provided based upon meeting the threshold and wherein said digital offer may be modified based upon meeting a subsequent threshold.
16. The system of claim 11 wherein the threshold is selected from the group consisting of: an action in a game, a score in a game, a charitable donation, a purchase, a predetermined time, inventory, and combinations thereof.
17. The system of claim 10 wherein the machine-readable code is printed on a surface.
18. The system of claim 10 wherein the machine-readable code is embedded within a surface.
19. The system of claim 10 wherein the machine-readable code identifies a specific location via a known location of the machine-readable code, GPS, or both.
20. The system of claim 10 wherein the user data is selected from the group consisting of: a date, a time, a GPS location of the machine-readable code, a type of communication device used to scan the machine- readable code, an orientation of a communication device when the machine-readable code was scanned, a type of operating system on a communication device that scanned an interactive code, and combinations thereof.
21. The system of claim 10 wherein the unique content directs the user device to a Web page, and wherein analytical data from the Web page is collected and consists of data selected from the group consisting of: time spent on a Web page, purchases made, IP address, personal information input by a user, products viewed, cookies, pixels, and combinations thereof.
22. The system of claim 10 wherein the user device further receives in-venue metrics via an in-venue metrics API and wherein said in-venue metrics are utilized as data or to modify the unique content.
23. The system of claim 10 wherein the user device further receives third party metrics via a third party metrics API, and wherein said third party metrics are utilized as data or to modify the unique content.
24. The system of claim 10 wherein the machine-readable code is displayed upon a video board located within the venue.
25. The system of claim 10 wherein a trigger is related to an action performed by at least one fan in attendance of an event.
26. A system for generating unique content to at least one user device upon meeting a threshold of users to the system comprising: a. a server system having at least one server, at least one computer processor, and a computer memory; b. a plurality of machine-readable codes, each of the machine-readable codes encoding an address controlled by the server system, each of the machine-readable codes being operatively mounted within a venue for access by all user devices in the venue; and c. wherein the computer memory of the server system stores executable code, wherein when executed the executable code enables the server system to perform a process comprising the following steps: i. receiving a request from one user device, the request generated by scanning one of the machine-readable codes with said user device; ii. directing the user device to a URL that is uniquely encoded to the machine- readable code; iii. receiving the request at an identification server, determining a result of whether the at least one user device is new or returning, and informing an interface server of the result; iv. generating an unused unique ID for a new user which is stored in a database; v. receiving an instruction at the interface server from a target determination process regarding digital content to be generated upon meeting the threshold; vi. providing a second URL to the identification server; vii. sending the second URL to the at least one user device; viii. displaying, from said second URL, unique digital content on said at least one user device; ix. obtaining a data from said at least one user device; and x. upon an occurrence of a trigger, receiving a new URL from said interface server.
27. A method for distributing different versions of an interactive digital event program corresponding to an event to a plurality of user devices comprising: a. receiving a request for an interactive digital event program from a first user device, the request received in response to scanning a first tag having a machine readable code with the first user device; b. determining that the first tag belongs to a first group of tags to which a first version of the interactive digital event program is to be distributed; c. providing the first user device with the first version of the interactive digital event program, the first version of the interactive digital event program to include at least one dynamic content element that is capable of being updated through a third party integration while the event is in progress; and d. updating the at least one dynamic content element in the first version of the interactive digital event program in response to detecting an occurrence of a predefined trigger.
28. The method of claim 27 wherein updating the at least one dynamic content element includes updating dynamic content selected from the group consisting of: a map, a video replay, augmented reality, a fan camera, a fan filter, live statistics, a non-fungible token, wagering, an audience participation activity, upcoming events, merchandise, concessions, a digital offer, or a ticket.
29. The method of claim 28 wherein the digital offer is unlocked in response to using an in-venue map.
30. The method of claim 29 wherein additional tags are distributed around a venue and the location of the additional tags is marked on the map.
31. The method of claim 30 wherein the additional tags are used to facilitate an event wide scavenger hunt.
32. The method of claim 28 wherein the dynamic content element is for a digital offer, which is downloaded to the first user device.
33. The method of claim 28 wherein the dynamic content element is streamed live action taking place at the event.
34. The method of claim 28 wherein the dynamic content element is recorded action taking place at the event.
35. The method of claim 33 or 34 wherein the dynamic content element has an augmented reality object overlayed or embedded thereon.
36. The method of claim 27 wherein the dynamic content element is for a digital offer, the digital offer linked to the dynamic content element after the event has started.
37. The method of claim 27 wherein the dynamic content element is dynamically positioned within the interactive digital program to have the maximum exposure to a plurality of users.
38. The method of claim 27 wherein the dynamic content element is for a digital offer that is synced to advertising shown on a jumbo screen, a televised broadcast of the event, or both.
39. The method of claim 27 wherein the dynamic content element is for statistics that are updated in real time as the event is taking place, a dynamic image element proximate the dynamic content element to dynamically display an image corresponding to the statistics, or both.
40. The method of claim 27 wherein the dynamic content element is an offer for a non- fungible token for the first version of the interactive digital program.
41. The method of claim 27 wherein the dynamic content element is a listing of upcoming events that is customized for the user device based on past event history, primary geographical position, current geographical position, or combinations thereof.
42. The method of claim 28 wherein the digital offer is a dynamic digital offer based on inventory levels on merchandise available at the event.
43. The method of claim 28 wherein the digital offer is customized based on version of the interactive DEP and demographic associated with users of user devices receiving the first version of the interactive digital event program.
44. The method of claim 27 further including updating the interactive digital event program after the event is over.
45. The method of claim 44 further including updating the interactive digital event program over the course of a season to document a season of events.
46. The method of claim 27 further including basing the interactive digital event program on a template, the at least one dynamic content element dragged and dropped into a desired position within the template, and wherein the dynamic content element can be modified by an administrator within the template.
47. The method of claim 46 further including repositioning the at least one dynamic content element in the template while the event is in progress.
48. The method of claim 27 further comprising: a. receiving a second request for an interactive digital program from a second user device, the second request received in response to scanning a second tag having a machine readable code with a second user device; b. determining that the second tag belongs to a second group to which a second version of the interactive digital event program is to be distributed; and c. providing the second user device with the second version of the interactive digital event program the second version to include a dynamic content element to be populated throughout the event using the third party integration.
49. The method of claim 22 where in the first tag is at a venue in which the event is being held and the second tag is on or in a televised video stream.
50. A method of distributing different versions of an interactive digital event program for a particular event to user devices comprising: a. designing a template for each of at least two versions of the interactive digital program by dragging and dropping a plurality of dynamic content elements into each template to complete a desired layout; b. associating each dynamic content element in the plurality with a distinct data source to dynamically update content within the dynamic content element while the event is in progress; c. assigning each version of the at least two versions of the interactive digital program to separate groups of tags, each tag in each separate group having a unique tag identifier; d. in response to receiving a request for the interactive digital program from the user device that has scanned a particular tag, determining to which group the particular tag belongs based on the unique tag identifier for the particular tag; e. sending the version of the interactive digital event program assigned to the group of tags in which the particular tag belongs to user device that sent the request; and f. causing the distinct data sources to populate the associated dynamic content elements in the template for the sent version of the interactive digital event program and at the content of least one of the associated dynamic content elements to be updated during the course of the event in response to a predefined trigger that has occurred in the event.
51. A system for providing an interactive digital event program comprising: a. a plurality of tags, each tag in the plurality having a machine readable code and a unique tag identifier; b. a server having a computer processor and a computer memory; c. a database operatively connected to the server, the database including information relating to each tag in the plurality of tags, the information relating to each tag including: i. the unique tag identifier; ii. a group identifier to identify a group to which the tag belongs; and iii. a template for an interactive digital event program to be distributed to the group in which the tag belongs; and d. wherein the computer memory of the server stores executable code, which when executed enables the server to perform a process comprising: i. in response to receiving a request from a user device, using the unique tag identifier to identify the group to which the scanned tag belongs; ii. populating the template for the interactive digital event program to be distributed to the group in which the tag belongs with one or more dynamic content elements; iii. sending the populated interactive DEP to the user device that sent the request; and iv. updating the content of at least one dynamic content element in response to detecting a predefined trigger based on activity within the event that optionally occurred during the event.
52. The system of claim 51 wherein updating the content of the at least one dynamic content element includes pushing updated content from a third party data source to the at least one dynamic content element in response to detecting the predefined trigger.
53. The system of claim 52 wherein the predefined trigger is a pause in the activity and updating the content of at least one dynamic content element includes pushing updated content from the third party data source in response to detecting a pause in the activity.
54. The system of claim 51 wherein updating the content of at least one dynamic content element includes unlocking content in response to detecting the predefined trigger.
55. The system of claim 51 wherein the predefined trigger is a threshold number and dynamically updating includes detecting that the threshold number has been reached unlocking the content in response to reaching the threshold.
56. The system of claim 51 wherein the content of the at least one dynamic content element is subject matter associated with a non-fungible token (NFT) and updating the content of at least one dynamic content element in response to detecting a predefined trigger includes unlocking the subject matter in response to detecting predefined trigger to enable acquisition of the NFT.
57. The system of claim 51 wherein the interactive digital event program continues to be updated after the event ends.
58. The system of claim 51 wherein the database stores plural identifiable images and the server selects an identifiable image to display in association with the at least one dynamic element.
59. The system of claim 51, wherein the at least one dynamic content defines an augmented reality video.
60. The system of claim 51, wherein the MRC is located within a video stream; wherein the unique tag identifier is utilized to determine which DEP to display to said user device.
61. The system of claim 51, further comprising a geolocation determining, wherein the location of the user device is defined within a rule within a tag group to alter the DEP directed to said user device.
62. The system of claim 51, wherein the venue is selected from the group consisting of: a school, a cultural event location, a zoo, a music venue, and combinations thereof.
63. The system of claim 51, wherein the dynamic content element is connected to a third party API, and wherein the third party API disseminates the dynamic contend upon the occurrence of a trigger.
64. The system of claim 51, wherein the tag grouping defines a version of the DEP displayed to said user device.
65. The system of claim 51 further comprising wherein a camera defined on a user device captures video, wherein the captured video is uploaded into a the DEP and the captured video is released as the dynamic content element.
66. The system of claim 51, further comprising wherein the dynamic content element displays a portion of video, said portion of video being a replay, highlight or augmented reality.
67. The system of claim 51, wherein the dynamic content is an advertisement.
68. The system of claim 51, wherein the unique ID defines an entry within a database, and wherein the entry comprises information regarding the actions of the unique ID; aggregating the data regarding the unique ID from said database; creating a tag grouping based upon the aggregated data on the unique ID and modifying the dynamic content on said DEP.
69. The system of claim 51, wherein the system collects and aggregates analytical user data corresponding to said unique ID, when said user device is interacting with the DEP.
70. The system of claim 51, wherein the dynamic content is a a real time polling question; and wherein a result from the real time polling question is displayed.
71. The system of claim 51, wherein the tag grouping is defined within a section of said venue; and wherein the tag grouping is awarded a prize which is pushed into the user device within the dynamic content within the DEP.
72. The system of claim 51, wherein the dynamic content is related to fantasy sports or wagering.
73. A method of charging and automating an electronic vehicle comprising: a. positioning the electronic vehicle within a parking spot and adjacent to a charging field; b. scanning, with a user device or a camera incorporated in the electronic vehicle a scannable tag, said user device and said camera each comprising a unique ID, and said scannable tag comprising a tag ID; c. linking the unique ID to the tag ID; and d. Pushing to said user device or a display integral with the electronic vehicle a dynamic content comprising a payment module and a timing module corresponding to payment for charging the electronic vehicle and a duration the charging.
74. The method of claim 73 further comprising in response to scanning the scannable tag, automatically charging the electronic vehicle utilizing a wireless charging system, gathering data in relation to the unique ID, tag ID, or both, and recording the gathered data to a data file, data record or both.
75. A method of using a network of encoded tags to gather data relating to an event comprising: a. in response to receiving a request from a user device that has scanned an encoded tag linked to the event, identifying a tag identifier to determine where the encoded tag is physically or digitally installed and identifying a device identifier to determine if the user device has previously scanned any tag in the network of tags, wherein if the user device has not previously scanned any tag in the network of tags assigning a device identifier to identify the user device upon a subsequent scan of any tag in the network, and sending the device identifier to the user device; b. determining, using the tag identifier, an event for which data is to be gathered, the event identified by an event identifier; c. determining a target to which the user device is to be redirected, the determined target identified by a target identifier, wherein the target is a default target if the event is not in progress and the target is a web-based application if the event is in progress, and redirecting the user device to the determined target; d. linking one or more of the tag identifier, the device identifier, the event identifier, or the target identifier; and e. recording each use-related action that occurs with respect to the web-based application as the use-related action occurs, each recorded action stored in a database with reference to, related to, or both, one or more of the tag identifier, the device identifier, the event identifier, or the target identifier.
76. The method of claim 75 wherein receiving the request from the user device comprises receiving the tag identifier in conjunction with the request.
77. The method of claim 76 wherein identifying the device identifier comprises receiving the device identifier in conjunction with the request or in response to a request for the device identifier from the user device.
78. The method of claim 75 wherein determining if the user device has previously scanned any tag in the network of tags comprises making the determination where the network of tags that belongs to more than one proprietor, the network of tags that belongs to more than one venue, or both.
79. The method of claim 75 further comprising physically installing one or more tags in the network of tags on or near a point of interest, integral with the point of interest, digitally installing one or more tags in the network of tags on a display screen, or both, wherein the display screen is selected from a group consisting of a computer screen, a television screen, a handheld device screen, a screen integrated into a piece of furniture, a screen integrated into an internet of things device.
80. The method of claim 75 wherein determining the event for which data is to be gathered comprises determining if the event is in progress at a time the user device scanned the tag.
81. The method of claim 80 wherein the event is perpetually in progress, is a recurring event, or is a single event scheduled to occur during a predetermined window of time.
82. The method of claim 81 wherein recording data comprises recording data, storing data, or both as long as the event is in progress, or the determined target is opened on the user device.
83. The method of claim 75 wherein redirecting to a web-based application comprises redirecting to a progressive web application, cloud-based application, browser-based application, or an active server page.
84. The method of claim 75 further comprising counting and recording the number of tags in the network of tags that have been scanned while the event is in progress, a counted number retrievable in real time, after the event ends, or both and optionally graphically displayed on an administrator device.
85. The method of claim 84 further comprising transferring some or all of the data recorded while the event is in progress to a third party customer relationship management service, data management software, or both, the transferred data including at least one identifier that enables the third party to identify a user of the user device.
86. The method of claim 75 further comprising using the tag identifier to determine the venue in which the scanned tag is installed, the determined venue having a venue identifier assigned thereto, or using the tag identifier to determine a point of interest that the scanned tag points to, or both.
87. The method of claim 75 wherein redirecting to the web-based application comprises redirecting the user device to a web-based application comprising a module identified by a module identifier and recording each use-related action attributed to the module in association with the module identifier.
88. The method of claim 75 further comprising digitally installing the encoded tag for display in a television broadcast, a cable broadcast, content that is streamed, or a feed and the tag identifier points to the television broadcast, the cable broadcast, the content that is streamed, or the feed in which the tag was digitally installed.
89. The method of claim 75 further comprising defining a rule relating to the web-based application that causes the web-based application to release tickets to a subsequent event in response to determining that the event in progress is about to end, the web-based application releasing said tickets by unlocking a module within the application, pushing content to the user device, redirecting the user device to an external website that sells the tickets, or updating a dynamic element within a module of the web-based application.
90. The method of claim 89 wherein defining the rule comprises defining the rule to release tickets in response to determining that a home team has won a game-based event.
91. The method of claim 75 further comprising defining a rule relating to the web-based application that causes the web-based application to release an offer to preorder an item in response to determining that a threshold number of user devices have scanned a tag in the network of tags, scan an encoded tag, the web-based application releasing said offer by unlocking a module within the web-based application, pushing the offer to the user device, redirecting the user device to an external website that is promoting the offer, or updating a dynamic element within a module of the web-based application.
92. The method of claim 91 wherein the offer to preorder an item comprises an offer to preorder merchandise at a discounted price or an experience-related item.
93. A system for aggregating data in response to detecting that a user device has scanned an encoded tag comprising: a. a server system having a computer processor, a computer memory, and one or more web applications, versions of web applications, or both installed thereon; b. one or more databases operatively connected to the server system and storing a venue ID assigned to a venue, an event ID assigned to an event linked to the venue; a target ID assigned to a web application built for the event, a tag ID assigned to a tag installed within the confines of the venue and that points to a particular point of interest associated with the venue, event, or both, a unique ID assigned to a user device, and recorded data linked to one or more of the unique ID, venue ID, event ID, target ID, or tag ID; and c. wherein the computer memory of the server system stores executable code that, when executed the executable code enables the server system to: i. receive a request from the user device, the request made in response to using the user device to scan the tag, the tag ID received with the request from the user device; ii. receive the unique ID from the user device; iii. use the tag ID to identify the venue, the event, or both; iv. determine a target web application and redirect the user device to the determined target web application; and v. record each user action taken with respect to the determined target web application and linking the recorded actions to one or more of the unique ID, the tag ID, the venue ID, the event ID, the target ID.
94. The system of claim 93 wherein each web application installed on the server system has a target ID assigned thereto and at least one module contained therein, each module having a module ID assigned thereto, wherein recording each user action further comprising identifying the module ID for the module in which the user action was taken and recording the user action in association with the module ID.
95. The system of claim 94 wherein the at least one module is selected from the group consisting of a merchandise module, a concessions module, an enter to win module, an audience participation module, an incident reporting module, a wagering module, an augmented reality module, a digital program module, an NFT acquisition module, a map module, a replay module, a roster module, a live statistics module, a fan filter module, and an upcoming events module.
96. The system of claim 93 wherein the executable code enables the system to search the recorded data, filter the recorded data, or both to obtain metrics relating to one or more of a number of tags scanned during the event, a number of modules engaged with during the event, a number of particular user actions performed during the event, a number of tags scanned by venue location, or a number and type of modules engaged with by venue location.
97. The system of claim 93 wherein the executable code enables the system to turn the web application built for the event to turn on at a predetermined time before the event begins and turn off at a predetermined time after the event ends, wherein data relating to the event is recorded as long as the web application built for the event is turned on.
98. The system of claim 95 wherein the module is an enter to win module, actions recorded with respect to the enter to win module include recording opening the enter to win module and recording enter to win submissions and compare the number of enter to win modules opened to the number of enter to win submissions.
99. The system of claim 98 further comprising recording identifying information obtained from the enter to win submission, identifying information selected from the group consisting of: name, email address, telephone number, age, gender, or combinations thereof, in a data file related to the unique ID, the tag ID, the target ID, the module Id, or combinations thereof.
100. The system of claim 99 further comprising identifying via unique IDs associated with enter to win submissions, the users that also requested to receive more information relating to future events at the venue and saving the identified requests to a data file associated with the unique IDs.
101. The system of claim 93 further comprising analyze recorded actions to provide customized content to the user device based on one or more past actions.
102. A system for appraising a value of a user based on data obtained as a result of scanning an encoded tag with a user device comprising: a. a server system comprising a computer processor and a computer memory; b. at least one database operatively connected to the server system, the at least one database storing data files relating to a plurality of venues, each venue in the plurality identified by a corresponding venue ID; a plurality of events, each event in the plurality identified by a corresponding event ID, tied to a particular venue in the plurality of venues, and in progress during a predetermined time window; a plurality of web-based applications, each web-based application in the plurality identified by a corresponding target ID and tied to a particular event in the plurality of events, wherein each web-based application is only active during a predetermined time window based on, and corresponding to when the tied event is in progress; a plurality of encoded tags, each encoded tag identified by a corresponding tag ID, wherein each tag in the plurality is installed in relation to a particular venue in the plurality of venues and points to a particular point of interest (POI) tied to the particular venue; a plurality of unique IDs, each unique ID in the plurality corresponding to and identifying a user device, and data linked to a particular unique ID, venue ID, event ID, target ID, or tag ID within the pluralities thereof, or combinations thereof; and c. wherein the computer memory of the server stores executable code, which when executed enables the server to perform a process comprising: i. in response to receiving a request from every user device that has scanned a tag in the plurality of tags, identifying the tag ID obtained by the user device as a result of scanning the tag, the tag ID received from the user device with the request and identifying the user device that has scanned the tag using the unique ID received from the user device or newly assigned to the user device; ii. identifying the venue in which the scanned tag is installed, the POI to which the tag ID points, or both using tag ID received with the request; iii. determining which event in the plurality events is tied to the identified venue and in progress; iv. determining a web-based application to which the user device is redirected, the determined web-based application selected from the plurality of web-based application and tied to the event determined to be in progress, the web-based application determined, using one or more of the unique ID, the tag ID, or venue ID identifying the identified venue, the event ID identifying the determined event, or combinations thereof; and v. recording each action taken with respect to the determined web-based application, wherein each recorded action is linked to, points to, or both, one or more of the target ID identifying the determined web-based application, a defined action, the unique ID identifying the user device, the tag ID identifying the tag that was scanned by the user device, venue ID identifying the identified venue, or the event ID identifying the determined event; vi. parsing recorded data to be able to analyzed the recorded data as a function of at least one unique ID, at least one tag ID, at least one venue ID, at least one target ID, at least on event ID, or combinations thereof; and vii. assigning a valuation to a particular user associated with a particular unique ID, the valuation based on data parsed as a function of the at least one unique ID.
103. The system of claim 102 further comprising wherein assigning a valuation to a particular user further comprises assigning a number, a dollar amount, or both to identify the likelihood that the particular user will take an identified action based on aggregated user data relating to the identified action.
104. The system of claim 103 further comprising assigning the number, the dollar amount, or both to each unique ID in the plurality of unique IDs.
105. The system of claim 103 wherein the number, the dollar amount, or both assigned to each unique ID in the plurality of unique IDs is updated in real time.
PCT/US2023/020064 2022-04-26 2023-04-26 Data aggregation WO2023212113A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263363597P 2022-04-26 2022-04-26
US63/363,597 2022-04-26

Publications (1)

Publication Number Publication Date
WO2023212113A1 true WO2023212113A1 (en) 2023-11-02

Family

ID=88519614

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/020064 WO2023212113A1 (en) 2022-04-26 2023-04-26 Data aggregation

Country Status (1)

Country Link
WO (1) WO2023212113A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220060759A1 (en) * 2017-06-07 2022-02-24 Digital Seat Media, Inc. System and method for providing synchronized interactive multimedia content to mobile devices based on geolocation of a vehicle
US20220103885A1 (en) * 2014-05-29 2022-03-31 Time Warner Cable Enterprises Llc Apparatus and methods for recording, accessing, and delivering packetized content
US20220116737A1 (en) * 2019-07-23 2022-04-14 1904038 Alberta Ltd. O/A Smart Access Methods and systems for providing context based information

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220103885A1 (en) * 2014-05-29 2022-03-31 Time Warner Cable Enterprises Llc Apparatus and methods for recording, accessing, and delivering packetized content
US20220060759A1 (en) * 2017-06-07 2022-02-24 Digital Seat Media, Inc. System and method for providing synchronized interactive multimedia content to mobile devices based on geolocation of a vehicle
US20220116737A1 (en) * 2019-07-23 2022-04-14 1904038 Alberta Ltd. O/A Smart Access Methods and systems for providing context based information

Similar Documents

Publication Publication Date Title
US11494737B2 (en) Interactive and dynamic digital event program
US20220284478A1 (en) Method and apparatus for advertising on a mobile gaming device
US11769140B2 (en) System and method for location-based individualized content and mobile wallet offers
US20080270163A1 (en) System, program and method for experientially inducing user activity
US20120215637A1 (en) System and method for performing social networking and loyalty program functions at a venue
CN106537901A (en) Computerized method and system for providing customized entertainment content
US20140046818A1 (en) System and Method For Event Related Commerce Utilizing A Portable Electronic Device
US11688029B2 (en) Wagering platforms and access derived from machine-readable codes
US11657337B2 (en) System and method for exchanging tickets via a machine-readable code
WO2022232791A1 (en) Interactive and dynamic digital event program
US20220343328A1 (en) Systems and methods for quality control related to nft purchase
WO2023212113A1 (en) Data aggregation
US11481807B2 (en) Delivery of dynamic content based upon predetermined thresholds
EP4330899A1 (en) Interactive and dynamic digital event program
WO2022232770A1 (en) Delivery of dynamic content based upon predetermined thresholds

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23797235

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)