Methods and systems for device-attested event participation credit management

Abstract

The present disclosure generally relates to methods, systems, apparatuses, and non- transitory computer readable media for managing participation credits based on verified event attendance. A coordination server subsystem may receive location data and device attestation data from mobile devices, determine whether devices are within geographic boundaries associated with events and whether the devices are authentic, award event-specific participation credit based on duration of verified presence and configurable credit rates, maintain credit balances in a ledger, and process redemption of accumulated credit for rewards. Rewards may comprise merchandise, tickets, experiences, raffle entries, discounts, digital content, or blockchain tokens. In blockchain token embodiments, a blockchain token management component may provide multi-party computation based key management, smart contract wallets with account abstraction enabling gasless transactions, transaction relay with sponsored fees, and social recovery mechanisms for wallet recovery.

Description

NON-PRO VISIONAL UTILITY PATENT APPLICATIONAttorney Docket No. : 226360-401018METHODS AND SYSTEMS FOR DEVICE-ATTESTED EVENT PARTICIPATION CREDIT MANAGEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 737,204, filed on December 20, 2024, which is incorporated herein by reference in its entirety.BACKGROUNDTechnical Field

[0002] The present disclosure generally relates to location-based services and event participation tracking, and more particularly, methods, systems, apparatuses, and non-transitory computer readable media for managing participation credits based on verified attendance at events.Description of the Background

[0003] Events such as sporting competitions, concerts, conferences, and festivals draw attendees who may benefit from recognition or rewards based on their physical presence. Event organizers, sponsors, and venues may wish to encourage attendance, reward loyal participants, or gather information about attendance patterns. Approaches for tracking attendance and distributing rewards to attendees exist. These approaches may involve manual processes, self-reported checkins, or automated detection of user presence.

[0004] Thus, systems and methods for verifying physical presence at events using device-provided information, tracking duration of verified attendance, and enabling redemption of accumulated participation value for rewards are desired.Attorney Docket No. : 226360-401018BRIEF SUMMARY

[0005] The present disclosure describes systems and methods that verify user presence at events using location data and device attestation information, award participation credit based on duration of verified attendance, and enable redemption of accumulated credit for rewards.

[0006] In a first aspect, a system for event participation credit management comprises a coordination server subsystem. The coordination server subsystem comprises a participation verification component configured to receive location data and device attestation data from a user- associated mobile device and determine whether the mobile device is within a geographic boundary associated with an event and whether the device attestation data indicates the mobile device is authentic. The coordination server subsystem further comprises a credit reward component configured to award event-specific participation credit to a user account based on duration of verified presence, a participation credit ledger component configured to store credit balances, and a credit redemption component configured to process requests to redeem credit for rewards.

[0007] In a second aspect, a method for event participation credit management comprises receiving location data and device attestation data from a user-associated mobile device, determining whether the mobile device is within a geographic boundary associated with an event, determining whether the device attestation data indicates the mobile device is authentic, awarding event-specific participation credit based on duration of verified presence, storing the credit in a ledger, and processing requests to redeem the credit for rewards.

[0008] In a third aspect, a non-transitory computer-readable storage medium stores instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising receiving location data and device attestation data, determining whether a mobile device is within a geographic boundary associated with an event, determining whether theAttorney Docket No. : 226360-401018 device attestation data indicates authenticity, awarding event-specific participation credit based on duration of verified presence, and processing redemption requests.

[0009] The above presents a simplified summary in order to provide a basic understanding of some aspects of the claimed subject matter. This summary is not an extensive overview. It is not intended to identify key or critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The disclosure can be better understood with reference to the following drawings. The elements of the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the disclosure. Furthermore, like reference numerals designate corresponding parts throughout the several views.

[0011] FIG. l is a block diagram of a participation credit system in context with external systems according to embodiments of the present disclosure.

[0012] FIG. 2 is a block diagram of a user-associated mobile device subsystem according to embodiments of the present disclosure.

[0013] FIG. 3 is a block diagram of a coordination server subsystem according to embodiments of the present disclosure.

[0014] FIG. 4 is a block diagram of a blockchain token management component according to embodiments of the present disclosure.Attorney Docket No. : 226360-401018DETAILED DESCRIPTION

[0015] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise represented. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the invention. Instead, they are merely examples of apparatuses and methods consistent with aspects related to the invention as recited in the appended claims. Particular aspects of the present disclosure are described in greater detail below. The terms and definitions provided herein control, if in conflict with terms and / or definitions incorporated by reference.

[0016] The present disclosure generally pertains to systems and methods for managing participation credits based on verified event attendance. A coordination server subsystem may receive location data and device attestation data from mobile devices, verify that users are physically present within geographic boundaries associated with events, award participation credit based on duration of verified presence, maintain ledgers of accumulated credit, and process redemption of credit for rewards.

[0017] Event attendance matters to event organizers and promoters because revenue depends on it. Ticket sales generate revenue directly proportional to the number of attendees. An event that sells out generates more ticket revenue than an event that sells half its available capacity. Concession sales depend on attendees being present to purchase food and beverages. Merchandise sales depend on attendees being present to browse and buy. The financial viability of events often depends on achieving attendance levels sufficient to cover production costs and generate returns for organizers, venues, and investors.Attorney Docket No. : 226360-401018

[0018] Beyond direct revenue, attendance affects the quality and atmosphere of events themselves. A sporting event with a full stadium generates crowd energy that enhances the experience for attendees and participants alike. A concert with a packed venue creates an atmosphere that artists and audiences feed off of. A sparsely attended event may feel deflated regardless of the quality of the underlying performance or competition. High attendance creates social proof that an event is worth attending, which may influence future attendance decisions by others.

[0019] Performers, teams, and other principals involved in events may also prefer high attendance. Musicians may prefer performing to full crowds rather than empty seats. Athletes may prefer competing in energized stadiums. Speakers may prefer addressing packed conference rooms. The preferences of these principals may affect their willingness to participate in future events, their enthusiasm during performances, and their contractual arrangements with event organizers.

[0020] Separately from these benefits that accrue to event organizers from high attendance, events create opportunities for outside entities to reach particular populations. Events aggregate audiences with specific characteristics, interests, and demographics. A professional basketball game attracts people interested in basketball, which correlates with particular age distributions, income levels, and consumer preferences. A country music concert attracts people interested in country music, whose demographic profile differs from audiences at hip-hop concerts or electronic music festivals. A technology conference attracts professionals in technology industries who possess particular purchasing authority and product needs. A food and wine festival attracts people interested in culinary experiences who may have disposable income and interest in premium goods.

[0021] Outside entities may wish to engage with event audiences for commercial purposes. A sportswear manufacturer may wish to reach audiences at athletic events because those audiencesAttorney Docket No. : 226360-401018 likely purchase athletic apparel. An automobile manufacturer may wish to reach audiences at motorsports events because those audiences have demonstrated interest in vehicles. A financial services firm may wish to reach audiences at professional conferences because those audiences include individuals making investment decisions. A beverage company may wish to reach audiences at music festivals because those audiences include young adults forming brand preferences. The alignment between event audience demographics and target customer profiles motivates outside entities to seek access to event attendees.

[0022] These outside entities may offer products, services, promotions, or experiences to event attendees. A telecommunications company may offer promotional pricing to attendees at events it sponsors. A software company may offer product demonstrations to conference attendees. A beverage company may offer samples to festivalgoers. These offerings create touchpoints between outside entities and the specific demographics those entities wish to reach, with event attendance serving as the criterion that identifies members of the target population.

[0023] Physical attendance represents a distinct form of engagement compared to other relationships with events. A person who attends an event in person has made commitments of time, money, and effort that indicate depth of interest beyond passive awareness. A person physically present is immersed in an environment where messaging has concentrated exposure. Physical presence creates a context that outside entities may value differently than broadcast viewership or social media engagement.

[0024] Thus, systems capable of verifying physical presence at events using device-provided attestation, tracking duration of verified attendance, accumulating participation credit, and enabling flexible redemption for various reward types while maintaining accessible user experiences are desired.Attorney Docket No. : 226360-401018

[0025] To enable event attendance tracking with participation credit accumulation and flexible reward redemption, embodiments of the present disclosure may provide systems where a coordination server subsystem receives location data and device attestation data from user- associated mobile devices, verifies attendance based on geographic boundary containment and device authenticity assessment, awards event-specific participation credit based on duration of verified presence and configurable credit rates, maintains credit balances in a participation credit ledger, and processes redemption requests to exchange accumulated credit for rewards. In some embodiments where rewards comprise blockchain tokens, a blockchain token management component may provide multi-party computation based key management, smart contract wallets enabling transactions without users holding native cryptocurrency, transaction relay with sponsored fees, and wallet recovery mechanisms.

[0026] FIG. 1 shows a block diagram of a participation credit system in context with external systems according to embodiments of the present disclosure. As shown by the figure, a participation credit system 110 may comprise a user-associated mobile device subsystem 111 and a coordination server subsystem 116. The figure also shows event information provider systems 120, reward provider systems 130, and a network 140 external to the participation credit system 110. The user-associated mobile device subsystem 111 and the coordination server subsystem 116 communicate with each other through the network 140. The coordination server subsystem 116 communicates with the event information provider systems 120 and the reward provider systems 130 through the network 140.

[0027] The participation credit system 110 may incentivize event attendance by enabling users to earn participation credit for being physically present at events and to exchange accumulated credit for rewards. Users who attend events may accumulate credit that has value because it can beAttorney Docket No. : 226360-401018 redeemed for merchandise, experiences, discounts, digital content, blockchain tokens, or other rewards that sponsors and event organizers make available. This creates an incentive structure where users are motivated to attend events and to remain present because continued presence earns additional credit. The longer a user remains at an event, the more credit the user accumulates. Event organizers benefit from increased attendance and more engaged audiences who have reason to arrive early and stay late. Sponsors benefit from the ability to reach verified attendees who have demonstrated interest and commitment through physical presence. Users benefit from receiving tangible value in exchange for their attendance and engagement.

[0028] To accomplish this incentive structure, the participation credit system 110 coordinates between mobile devices carried by users, server infrastructure that performs verification and recordkeeping, and external systems that define events and provide rewards. The user-associated mobile device subsystem 111 executes on user mobile devices where it can access location hardware and operating system attestation services that provide information about device integrity. The coordination server subsystem 116 executes on server infrastructure where it receives data from mobile devices, determines whether users are present within geographic boundaries of events, verifies that device attestation indicates authentic devices, calculates participation credit based on verified attendance duration, maintains authoritative records of accumulated credit, and processes redemption requests. The event information provider systems 120 supply information about events including geographic boundaries that define where attendance qualifies for credit. The reward provider systems 130 supply information about available rewards and handle fulfillment when users redeem credit. The network 140 provides communication pathways connecting these systems and subsystems.Attorney Docket No. : 226360-401018

[0029] The architecture of the participation credit system 110, with separate subsystems for mobile device interaction and server-side coordination, reflects that different capabilities are available in different locations. The user-associated mobile device subsystem 111 can access device sensors and hardware that determine geographic position. The user-associated mobile device subsystem 111 can access operating system services that generate cryptographically signed attestations about device integrity. These capabilities exist on the mobile device and cannot be accessed remotely by servers. The coordination server subsystem 116 can maintain persistent databases that store credit balances across user sessions and across devices. The coordination server subsystem 116 can apply consistent verification logic to data from many users. The coordination server subsystem 116 can coordinate with multiple external systems that provide event information and rewards. These capabilities are appropriately performed on server infrastructure. By separating responsibilities between mobile and server subsystems, the participation credit system 110 enables each subsystem to operate where it can access the resources and information it requires.

[0030] Data flows between the components as users participate in events. The user-associated mobile device subsystem 111 periodically transmits location data and device attestation data to the coordination server subsystem 116 through the network 140. The coordination server subsystem 116 queries the event information provider systems 120 to obtain event definitions including geographic boundaries. The coordination server subsystem 116 compares received location data against boundaries to determine whether users are within event areas. The coordination server subsystem 116 verifies that attestation data indicates authentic devices. When attendance is verified, the coordination server subsystem 116 calculates and records participation credit. The coordination server subsystem 116 queries the reward provider systems 130 to obtain catalogs of available rewards. When users request redemption, the coordination server subsystem 116 deductsAttorney Docket No. : 226360-401018 credit from user balances and submits fulfillment requests to the reward provider systems 130. The reward provider systems 130 handle delivery of rewards to users.

[0031] The network 140 may comprise various communication infrastructure enabling data transmission between the systems and subsystems. In some embodiments, the network 140 may comprise the Internet, with data traveling through Internet service provider networks, backbone networks, and content delivery networks. In some embodiments, the network 140 may comprise cellular data networks including fourth-generation Long Term Evolution (LTE) networks and fifth-generation (5G) networks. In some embodiments, the network 140 may comprise WiFi networks conforming to IEEE 802.11 standards including 802.1 In, 802.1 lac, and 802.1 lax. In some embodiments, the network 140 may comprise wired Ethernet connections for server infrastructure. In some embodiments, the network 140 may comprise combinations of these technologies, with mobile devices connecting via cellular or WiFi and servers connecting via wired infrastructure.

[0032] In some embodiments, communications over the network 140 may be encrypted to protect against interception or modification in transit. In some embodiments, encryption may use Transport Layer Security (TLS) version 1.2 or version 1.3. In some embodiments, the user- associated mobile device subsystem 111 may implement certificate pinning to prevent man-in-the- middle attacks by verifying that server certificates match expected values. In some embodiments, communications may use additional integrity protection such as message authentication codes or digital signatures on request payloads.

[0033] In some embodiments, communications between the user-associated mobile device subsystem 111 and the coordination server subsystem 116 may use REST API protocols with JSON payloads transmitted over HTTPS. In some embodiments, communications may useAttorney Docket No. : 226360-401018GraphQL APIs. Tn some embodiments, communications may use gRPC with Protocol Buffer serialization for efficiency. In some embodiments, communications may use WebSocket connections for persistent bidirectional communication with lower latency than repeated HTTP requests. In some embodiments, WebSocket connections may be used for real-time updates such as pushing credit balance changes to the mobile device as they occur.

[0034] In some embodiments, the user-associated mobile device subsystem 111 may implement retry logic for failed network requests using exponential backoff with randomized jitter to avoid thundering herd problems when many devices retry simultaneously. In some embodiments, the user-associated mobile device subsystem 111 may queue location and attestation reports when network connectivity is unavailable and transmit queued reports when connectivity is restored. In some embodiments, reports may include timestamps indicating when location was determined so that the coordination server subsystem 116 can correctly calculate attendance duration even when reports are delayed.

[0035] The event information provider systems 120 may comprise computing systems operated by entities that create, manage, or have authoritative information about events. In some embodiments, the event information provider systems 120 may be operated by event organizers who produce and manage events. In some embodiments, the event information provider systems 120 may be operated by venues such as stadiums, arenas, convention centers, or amphitheaters that host events. In some embodiments, the event information provider systems 120 may be operated by ticketing platforms such as Ticketmaster, AXS, Eventbrite, SeatGeek, or StubHub that sell admission and maintain event databases. In some embodiments, the event information provider systems 120 may be operated by sports leagues such as the National Football League, National Basketball Association, Major League Baseball, National Hockey League, or Major LeagueAttorney Docket No. : 226360-401018Soccer. Tn some embodiments, the event information provider systems 120 may be operated by concert promoters such as Live Nation or AEG Presents. In some embodiments, the event information provider systems 120 may be operated by conference organizers, festival producers, or other entities involved in event production.

[0036] The event information provider systems 120 may provide event data to the coordination server subsystem 116. Event data may include event identifiers that uniquely identify each event. Event data may include event names and descriptions providing human-readable information about the event. Event data may include venue names and addresses indicating where events occur. Event data may include start times and end times indicating when events occur. Event data may include time zone information enabling correct interpretation of times across different geographic regions. Event data may include status indicators such as draft, active, completed, or cancelled.

[0037] Event data may include geographic boundaries specifying the spatial extent within which attendance qualifies for credit. In some embodiments, geographic boundaries may be defined as polygons specified by ordered sequences of latitude and longitude coordinate pairs. A polygon boundary may comprise a list of vertices, with each vertex specified as a coordinate pair such as (latitude, longitude) in decimal degrees using the WGS84 coordinate reference system. The polygon is formed by connecting consecutive vertices with line segments and connecting the last vertex back to the first vertex to close the polygon. In some embodiments, polygon boundaries may comprise tens to hundreds of vertices to accurately trace complex venue perimeters. In some embodiments, polygon boundaries may be simplified to fewer vertices where high precision is not required.

[0038] In some embodiments, geographic boundaries may be defined as circles specified by center coordinates and radii. A circle boundary may comprise a center point specified as a latitude andAttorney Docket No. : 226360-401018 longitude coordinate pair and a radius specified in meters. All points within the specified distance from the center point are considered inside the boundary. Circle boundaries may be simpler to define than polygon boundaries but may not accurately represent irregularly shaped venues.

[0039] In some embodiments, geographic boundaries may comprise multiple disconnected regions for events that span non-contiguous areas. A festival with multiple stages in different sections of a park may have a boundary comprising multiple polygons. A conference with sessions in multiple buildings may have a boundary comprising multiple circles or polygons.

[0040] In some embodiments, events may have multiple zones within the overall geographic boundary, with different zones corresponding to different areas of the venue. Zones may include VIP sections with premium access. Zones may include premium seating sections closer to the primary action. Zones may include general admission sections. Zones may include floor or fieldlevel areas. Zones may include upper deck or balcony sections. Zones may include concourse areas outside the main seating bowl. Zone boundaries may be defined as polygons or circles nested within the overall event boundary. Zone definitions may include zone identifiers, zone names, and credit rate modifiers that affect how much credit is earned for attendance in each zone.

[0041] In some embodiments, the coordination server subsystem 116 may receive event data from the event information provider systems 120 through REST API calls. API endpoints may be authenticated using OAuth 2.0 tokens or API keys. In some embodiments, the coordination server subsystem 116 may receive event data through webhook notifications where the event information provider systems 120 push updates when events are created, modified, or cancelled. In some embodiments, the coordination server subsystem 116 may receive event data through batch file imports in formats such as CSV or JSON. In some embodiments, the coordination serverAttorney Docket No. : 226360-401018 subsystem 116 may provide administrative interfaces through which event data may be entered or edited manually.

[0042] In some embodiments, the coordination server subsystem 116 may poll the event information provider systems 120 on a scheduled basis to check for updates, such as every hour, every 15 minutes, or at other intervals. In some embodiments, the coordination server subsystem 116 may receive real-time streaming updates for time-sensitive event changes. In some embodiments, the coordination server subsystem 116 may cache event data locally and refresh the cache periodically or in response to invalidation signals.

[0043] The reward provider systems 130 may comprise computing systems operated by entities that offer rewards to event attendees and handle fulfillment. In some embodiments, the reward provider systems 130 may be operated by sponsors who wish to engage with event audiences by offering branded merchandise, promotional items, or exclusive experiences. Sponsors may include beverage companies, apparel brands, automotive manufacturers, technology companies, financial services firms, telecommunications carriers, consumer packaged goods companies, or other businesses seeking to reach event demographics. In some embodiments, the reward provider systems 130 may be operated by merchandise vendors who supply physical goods. In some embodiments, the reward provider systems 130 may be operated by ticket resellers or box offices who can provide tickets to future events. In some embodiments, the reward provider systems 130 may be operated by experience providers who arrange exclusive access, meet-and-greets, behind- the-scenes tours, or premium hospitality. In some embodiments, the reward provider systems 130 may be operated by the same entities that operate event information provider systems 120, such as event organizers offering their own rewards.Attorney Docket No. : 226360-401018

[0044] Rewards available through the reward provider systems 130 may comprise various types. In some embodiments, rewards may comprise physical merchandise such as apparel including t- shirts, jerseys, hats, and jackets; equipment including sporting goods, accessories, and gear; memorabilia including signed items, commemorative products, and collectibles; or promotional items including branded goods from sponsors. In some embodiments, rewards may comprise tickets to future events, including general admission tickets, upgraded seating, VIP packages, or backstage passes. In some embodiments, rewards may comprise experiences such as meet-and- greets with performers or athletes, backstage or sideline access, premium hospitality with food and beverage, exclusive activities or events, or tours of facilities. In some embodiments, rewards may comprise raffle entries providing chances to win high-value prizes such as vehicles, travel packages, signed memorabilia, or large cash amounts. In some embodiments, rewards may comprise discounts such as percentage discounts or fixed-amount discounts on purchases from sponsors, free items with purchase, or promotional pricing. In some embodiments, rewards may comprise digital content such as exclusive videos, music tracks, photos, downloadable content, or access to premium features in applications. In some embodiments, rewards may comprise blockchain tokens as described further below.

[0045] The reward provider systems 130 may provide reward catalogs to the coordination server subsystem 116. Reward catalogs may specify available rewards including reward identifiers, names, descriptions, and images. Reward catalogs may specify credit costs indicating how much participation credit must be redeemed to obtain each reward. In some embodiments, credit costs may range from tens of credits for low-value rewards to thousands of credits for high-value rewards. Reward catalogs may specify inventory quantities indicating how many units of each reward are available. Reward catalogs may specify availability windows indicating when rewardsAttorney Docket No. : 226360-401018 may be redeemed, such as only during an event, for a limited time after an event, or ongoing. Reward catalogs may specify eligibility restrictions such as minimum age requirements, geographic restrictions, or membership requirements. Reward catalogs may specify redemption limits such as maximum redemptions per user.

[0046] In some embodiments, multiple reward provider systems 130 may offer different rewards for the same event, with the coordination server subsystem 116 aggregating catalogs into a unified view for users. In some embodiments, the same reward may be available at multiple events at the same credit cost or at different credit costs. In some embodiments, reward availability and credit costs may vary dynamically based on inventory levels, time remaining in availability windows, or promotional campaigns.

[0047] When users redeem credit for rewards, the coordination server subsystem 116 may submit fulfillment requests to the appropriate reward provider systems 130. Fulfillment requests may include reward identifiers, user identifiers, quantities, and delivery information. For physical merchandise, delivery information may include shipping addresses. For digital content, delivery information may include email addresses or user account identifiers. For ticket rewards, delivery information may include information needed to generate and deliver tickets. The reward provider systems 130 may handle fulfillment activities appropriate to each reward type. For physical merchandise, fulfillment may include picking, packing, shipping, and providing tracking information. For digital content, fulfillment may include generating download links or granting streaming access. For tickets, fulfillment may include generating barcodes, QR codes, or mobile tickets. For raffle entries, fulfillment may include recording entries in drawing databases. For discounts, fulfillment may include generating coupon codes or applying discounts to user accounts in commerce systems.Attorney Docket No. : 226360-401018

[0048] In some embodiments, the reward provider systems 130 may provide fulfillment status updates to the coordination server subsystem 116. Status updates may indicate when fulfillment is pending, processing, shipped, delivered, or failed. For shipped physical merchandise, status updates may include carrier names and tracking numbers. The coordination server subsystem 116 may make fulfillment status information available to users through the user interface component 230.

[0049] In some embodiments, the coordination server subsystem 116 may integrate with reward provider systems 130 through REST APIs with authentication using OAuth tokens or API keys. In some embodiments, the coordination server subsystem 116 may receive inventory updates through webhooks when inventory levels change. In some embodiments, the coordination server subsystem 116 may integrate with order management systems or e-commerce platforms used by reward providers.

[0050] FIG. 2 shows a block diagram of a user-associated mobile device subsystem according to embodiments of the present disclosure. As shown by the figure, the user-associated mobile device subsystem 111 may comprise a location acquisition component 210, an attestation component 220, and a user interface component 230. The figure also shows the coordination server subsystem 116, with which the components of the user-associated mobile device subsystem 111 communicate.

[0051] The user-associated mobile device subsystem 111 serves as the interface between the user's physical mobile device and the rest of the participation credit system 110. The mobile device travels with the user to events and contains hardware capable of determining geographic position and software capable of providing attestation about device integrity. The user-associated mobile device subsystem 111 accesses these device capabilities, gathers the resulting data, and transmits the data to the coordination server subsystem 116 for verification and credit calculation. The user-Attorney Docket No. : 226360-401018 associated mobile device subsystem 1 11 also provides a user interface through which users can discover events, monitor credit accumulation, browse rewards, and request redemption. By executing on the user's mobile device, the user-associated mobile device subsystem 111 can access device-specific capabilities that are not accessible to remote servers while providing a direct interface for user interaction.

[0052] The location acquisition component 210 may be configured to obtain geographic position information from the mobile device. Mobile devices such as smartphones and tablets typically contain hardware and software for determining geographic position using various technologies. Global navigation satellite systems (GNSS) comprise constellations of satellites that transmit signals from which receivers can calculate position. The Global Positioning System (GPS) operated by the United States comprises more than 24 satellites in medium Earth orbit that transmit signals on LI and L5 frequency bands. GPS receivers in mobile devices receive these signals and calculate position through trilateration, determining the device's distance from multiple satellites based on signal timing and computing the position where those distances intersect. GLONASS operated by Russia, Galileo operated by the European Union, and BeiDou operated by China provide similar capabilities with their own satellite constellations. Modern mobile devices may receive signals from multiple GNSS constellations simultaneously to improve accuracy and availability.

[0053] In some embodiments, GNSS positioning may provide accuracy within approximately 3 to 10 meters under favorable conditions with clear sky visibility to multiple satellites. In some embodiments, accuracy may be degraded in urban environments where tall buildings create multipath reflections and block satellite signals. In some embodiments, accuracy may be degraded indoors where satellite signals are attenuated by building materials. In some embodiments, mobileAttorney Docket No. : 226360-401018 devices may use assisted GNSS (A-GNSS) where cellular network data provides satellite orbital information to speed initial position acquisition.

[0054] In some embodiments, the location acquisition component 210 may obtain position using WiFi positioning. WiFi positioning estimates location by observing nearby WiFi access points and comparing their identifiers and signal strengths against databases of known access point locations maintained by companies such as Google, Apple, and Skyhook. WiFi positioning may provide accuracy within approximately 15 to 40 meters depending on the density of mapped access points in the area. WiFi positioning may work indoors where GNSS signals are unavailable.

[0055] In some embodiments, the location acquisition component 210 may obtain position using cellular positioning. Cellular positioning estimates location based on signals from nearby cellular base stations using techniques such as cell tower triangulation or timing advance measurements. Cellular positioning accuracy varies widely from tens of meters in dense urban areas with many cell towers to several kilometers in rural areas with sparse coverage.

[0056] In some embodiments, mobile operating systems provide fused location services that combine multiple positioning technologies to provide the best available position estimate. On Android devices, the Fused Location Provider may automatically select among GPS, WiFi, and cellular positioning based on availability, accuracy requirements, and power constraints. On iOS devices, Core Location provides similar functionality. The location acquisition component 210 may request location information through these operating system services rather than directly accessing positioning hardware.

[0057] In some embodiments, the location acquisition component 210 may request location permissions from the user before accessing location services. On both Android and iOS, applications must request user authorization to access location. Permission levels may includeAttorney Docket No. : 226360-401018 authorization to access location only while the application is in use in the foreground, authorization to access location even when the application is in the background, or authorization limited to approximate location rather than precise location. The location acquisition component 210 may request appropriate permission levels based on the needs of attendance tracking.

[0058] In some embodiments, the location acquisition component 210 may specify accuracy requirements when requesting location. High-accuracy requests may prioritize GNSS positioning, which provides good accuracy but consumes more battery power. Balanced or low-power requests may allow the operating system to use WiFi or cellular positioning, which consume less power but provide lower accuracy. In some embodiments, the location acquisition component 210 may request high accuracy when the user is near event boundaries where precise position affects whether attendance is recognized, and may accept lower accuracy when the user is clearly within an event boundary.

[0059] In some embodiments, the location acquisition component 210 may request location updates at regular intervals during attendance tracking. In some embodiments, the interval between location updates may be approximately 10 seconds, approximately 30 seconds, approximately 1 minute, approximately 2 minutes, or approximately 5 minutes. Shorter intervals provide more frequent position reports enabling finer-grained tracking of attendance duration and quicker detection of boundary crossings. Longer intervals consume less battery power and generate less network traffic. In some embodiments, the location acquisition component 210 may adjust the update interval dynamically based on factors such as proximity to event boundaries, remaining battery level, or user preferences. In some embodiments, the location acquisition component 210 may use geofencing capabilities provided by the operating system to receive notifications when the device crosses event boundaries, supplementing regular interval updates.Attorney Docket No. : 226360-401018

[0060] In some embodiments, the location acquisition component 210 may continue requesting location updates when the application is running in the background, enabling attendance tracking to continue even when the user is interacting with other applications. Background location access may require specific permission grants from the user and may be subject to operating system restrictions on background activity. In some embodiments, the location acquisition component 210 may use significant location change monitoring, which provides updates only when the device moves a substantial distance, to reduce power consumption during background operation.

[0061] Location data obtained by the location acquisition component 210 may include latitude and longitude coordinates specifying geographic position in decimal degrees using the WGS84 coordinate reference system. Location data may include altitude indicating height above sea level or above the WGS84 ellipsoid. Location data may include horizontal accuracy indicating the estimated uncertainty of the latitude and longitude, typically expressed as a radius in meters within which the true position is likely to fall. Location data may include vertical accuracy indicating the estimated uncertainty of the altitude. Location data may include bearing indicating the direction of travel in degrees from north. Location data may include speed indicating the rate of travel in meters per second. Location data may include timestamps indicating when the position was determined.

[0062] In some embodiments, the location acquisition component 210 may transmit location data to the coordination server subsystem 116 individually as each update is obtained. In some embodiments, the location acquisition component 210 may batch multiple location updates and transmit them together periodically to reduce network requests and conserve battery. In some embodiments, location data may be compressed before transmission to reduce bandwidth consumption.Attorney Docket No. : 226360-401018

[0063] The attestation component 220 may be configured to obtain device attestation data from attestation services provided by the mobile device's operating system. Device attestation provides cryptographically signed assertions about the state, configuration, or integrity of the mobile device and the application requesting attestation. These assertions may indicate whether the device appears to be a genuine device from the manufacturer, whether the operating system has been modified from its official distribution, whether security features are enabled, and whether the requesting application is the authentic version obtained through authorized distribution channels. Device attestation may help the coordination server subsystem 116 distinguish between location reports from authentic devices that are likely reporting actual position and location reports from compromised devices that may be spoofing position.

[0064] In some embodiments where the mobile device runs the Android operating system, the attestation component 220 may use the Play Integrity API provided by Google Play services. The Play Integrity API generates attestation tokens that contain verdicts about device and application integrity. To obtain a Play Integrity token, the attestation component 220 makes a request to the Play Integrity API, which communicates with Google's servers to generate a signed token. The token is returned to the attestation component 220 and may be transmitted to the coordination server subsystem 116 for verification.

[0065] Play Integrity tokens may contain device integrity verdicts. A verdict of MEETS DEVICE INTEGRITY indicates that the device passes Google's device integrity checks, suggesting the device has a locked bootloader, is running a verified version of Android, and has not been modified in ways that compromise integrity. A verdict of MEETS BASIC INTEGRITY indicates that the device passes basic integrity checks but may have some modifications such as an unlocked bootloader. A verdict of MEETS STRONG INTEGRITY indicates that the deviceAttorney Docket No. : 226360-401018 has a locked bootloader, is running a recent version of Android with current security patches, and supports hardware-backed key attestation. Devices that fail all integrity checks, such as emulators, rooted devices with modified system images, or devices running unofficial Android distributions, may receive no device integrity verdict.

[0066] Play Integrity tokens may contain application integrity verdicts. A verdict indicating the application is recognized and licensed suggests the application is the genuine version distributed through the Google Play Store. Applications that have been modified, repackaged, or distributed through unauthorized channels may fail application integrity checks.

[0067] In some embodiments where the mobile device runs the iOS operating system, the attestation component 220 may use the DeviceCheck framework or the App Attest framework provided by Apple. The DeviceCheck framework allows applications to query and set per-device bits stored on Apple's servers, which may be used for device reputation or fraud prevention purposes. The App Attest framework provides cryptographic attestation that the application is running on a genuine Apple device with a genuine copy of the application.

[0068] To use App Attest, the attestation component 220 generates a cryptographic key pair within the device's Secure Enclave, a hardware-isolated security processor. The attestation component 220 requests that Apple's attestation service attest the public key. Apple's service verifies that the key was generated in a genuine Secure Enclave on a genuine Apple device running a genuine copy of the application, and returns an attestation object containing a certificate chain that can be verified against Apple's root certificate. Subsequently, the attestation component 220 can use the attested key to sign assertions that prove the assertion was generated on the same genuine device and application.Attorney Docket No. : 226360-401018

[0069] In some embodiments, the attestation component 220 may include a nonce in attestation requests to ensure freshness. A nonce is a value used once, typically a random value generated by the party that will verify the attestation. The coordination server subsystem 116 may generate nonces and provide them to the attestation component 220 before each attestation request. The attestation component 220 includes the nonce in the attestation request. The attestation service incorporates the nonce into the attestation token or signed assertion such that the coordination server subsystem 116 can verify that the attestation was generated in response to its specific request rather than being a previously captured attestation replayed by an attacker. In some embodiments, nonces may be cryptographically random values of at least 128 bits to prevent guessing or collision.

[0070] In some embodiments, the attestation component 220 may cache attestation tokens for limited durations to avoid excessive requests to attestation services. Attestation requests may involve network communication and cryptographic operations that consume time and resources. Caching allows recent attestations to be reused for a short period. However, long cache durations may allow stale attestations to be used after device state has changed. In some embodiments, cache durations may range from seconds to minutes depending on the tradeoff between efficiency and freshness requirements.

[0071] In some embodiments, the attestation component 220 may handle situations where attestation services are unavailable or where the device fails integrity checks. In some embodiments, the attestation component 220 may retry failed attestation requests. In some embodiments, the attestation component 220 may report to the user that attestation is required and unavailable. In some embodiments, the coordination server subsystem 116 may accept locationAttorney Docket No. : 226360-401018 reports without attestation under certain circumstances or may apply additional scrutiny to reports lacking valid attestation.

[0072] The user interface component 230 may be configured to present graphical user interface elements on the mobile device's display and to receive user input through the device's touchscreen or other input mechanisms. The user interface component 230 provides the means by which users interact with the participation credit system 110, discovering events, tracking attendance, viewing credit balances, browsing rewards, and requesting redemption.

[0073] In some embodiments, the user interface component 230 may present a home screen providing an overview of the user's participation in the system. The home screen may display nearby events that the user may attend. The home screen may display the user's credit balances, either as a total across all events or broken down by event. The home screen may display featured or recommended rewards. The home screen may display notifications about recent activity such as credit earned or new rewards available.

[0074] In some embodiments, the user interface component 230 may present an event discovery screen allowing users to find events. The event discovery screen may display a list of events with names, dates, times, venues, and thumbnail images. The event discovery screen may provide filtering options to narrow events by date range, location, event type, or other criteria. The event discovery screen may provide search functionality to find events by name or keyword. In some embodiments, the user interface component 230 may present a map view showing event locations geographically, with markers indicating events that the user may attend.

[0075] In some embodiments, the user interface component 230 may present an event detail screen showing information about a specific event. The event detail screen may display the event name, description, date, start time, end time, and venue name and address. The event detail screen mayAttorney Docket No. : 226360-401018 display a map showing the event's geographic boundary overlaid on a map, allowing the user to see the area within which attendance will be recognized. The event detail screen may display information about credit earning rates for the event, including base rates and any zone-based modifiers. The event detail screen may display rewards available for the event. The event detail screen may provide a button to begin attendance tracking for the event.

[0076] In some embodiments, the user interface component 230 may present an attendance tracking screen while the user is actively tracking attendance at an event. The attendance tracking screen may display the user's current status indicating whether the user is currently inside or outside the event boundary. The attendance tracking screen may display a visual representation of the event boundary on a map with the user's current position indicated. The attendance tracking screen may display a duration counter showing how long the user has been present within the boundary. The attendance tracking screen may display a credit counter showing how much credit the user has accumulated, potentially updating in real-time as additional credit is earned. The attendance tracking screen may provide controls to stop attendance tracking.

[0077] In some embodiments, the user interface component 230 may present a credit balance screen showing the user's accumulated credit. The credit balance screen may display balances for individual events where credit is event-specific. The credit balance screen may display an aggregate balance if credit is fungible across events. The credit balance screen may display transaction history showing individual credit awards and redemptions with timestamps, amounts, and descriptions. The credit balance screen may display graphs or visualizations showing credit accumulation over time.

[0078] In some embodiments, the user interface component 230 may present a rewards catalog screen showing rewards available for redemption. The rewards catalog may display rewards withAttorney Docket No. : 226360-401018 images, names, descriptions, and credit costs. The rewards catalog may be organized by categories such as merchandise, experiences, or digital content. The rewards catalog may provide filtering to narrow rewards by category, credit cost range, or availability. The rewards catalog may provide sorting options to order rewards by popularity, credit cost, or recency. The rewards catalog may indicate reward availability and any eligibility restrictions.

[0079] In some embodiments, the user interface component 230 may present a reward detail screen showing full information about a specific reward. The reward detail screen may display multiple images of the reward. The reward detail screen may display a full description of the reward including any terms and conditions. The reward detail screen may display the credit cost. The reward detail screen may indicate the user's current balance relative to the cost. The reward detail screen may provide a button to redeem the reward.

[0080] In some embodiments, the user interface component 230 may present a redemption confirmation screen when the user initiates redemption. The redemption confirmation screen may display the selected reward, the credit cost, and the user's balance after redemption. The redemption confirmation screen may request any additional information needed for fulfillment such as shipping address or size selection for apparel. The redemption confirmation screen may provide buttons to confirm or cancel the redemption.

[0081] In some embodiments, the user interface component 230 may present redemption status screens showing the status of pending and completed redemptions. Status screens may indicate when redemptions are pending, processing, shipped, or delivered. For shipped physical merchandise, status screens may display carrier names and tracking numbers with links to tracking pages. Status screens may display history of all past redemptions.Attorney Docket No. : 226360-401018

[0082] In some embodiments, the user interface component 230 may present notifications to alert users about relevant information. Notifications may indicate when credit has been earned. Notifications may indicate when new rewards become available. Notifications may indicate when redemption status changes such as when an item ships. Notifications may remind users about upcoming events. Notifications may alert users when they enter or exit event boundaries.

[0083] In some embodiments, the user interface component 230 may present settings screens allowing users to configure preferences. Settings may include notification preferences controlling which notifications the user receives. Settings may include location permission management. Settings may include account management for logging in, logging out, or managing profile information. Settings may include privacy settings.

[0084] In some embodiments, the user interface component 230 may provide onboarding flows for new users. Onboarding may explain how the participation credit system 110 works. Onboarding may guide users through granting necessary permissions such as location access. Onboarding may guide users through account creation or login.

[0085] In some embodiments, the user interface component 230 may be implemented with accessibility features supporting users with disabilities. Accessibility features may include support for screen readers such as VoiceOver on iOS or TalkBack on Android. Accessibility features may include support for dynamic type sizes. Accessibility features may include sufficient color contrast for visibility.

[0086] In some embodiments, the user interface component 230 may support multiple languages with localized text and locale-appropriate formatting for dates, times, numbers, and currencies.

[0087] Communication between the user-associated mobile device subsystem 111 and the coordination server subsystem 116 may occur through the network 140 using various protocolsAttorney Docket No. : 226360-401018 and patterns. Tn some embodiments, the location acquisition component 210 and the attestation component 220 may transmit data to the coordination server subsystem 116 using HTTPS POST requests to REST API endpoints. Request payloads may be formatted as JSON containing location coordinates, accuracy, timestamps, attestation tokens, and user or device identifiers. The coordination server subsystem 116 may respond with acknowledgments, updated credit balances, or error information.

[0088] In some embodiments, the user-associated mobile device subsystem 111 may authenticate requests to the coordination server subsystem 116 using bearer tokens, API keys, or signed requests. Users may authenticate by logging in with credentials or through OAuth providers, receiving tokens that are included in subsequent API requests.

[0089] In some embodiments, the user-associated mobile device subsystem 111 may establish WebSocket connections to the coordination server subsystem 116 for real-time bidirectional communication. WebSocket connections may be used to push credit balance updates to the mobile device as they occur without requiring the device to poll. WebSocket connections may be used to push notifications about events, rewards, or redemption status.

[0090] In some embodiments, the user-associated mobile device subsystem 111 may implement offline queuing to handle network unavailability. When network connectivity is unavailable, location and attestation reports may be stored locally on the device. When connectivity is restored, queued reports may be transmitted to the coordination server subsystem 116. Reports may include timestamps indicating when location was originally determined, enabling accurate duration calculation even when reports are delayed.

[0091] FIG. 3 shows a block diagram of a coordination server subsystem according to embodiments of the present disclosure. As shown by the figure, the coordination server subsystemAttorney Docket No. : 226360-401018116 may comprise a participation verification component 310, an event management component 320, a user data component 330, and a participation credit management component 340.

[0092] As further shown by FIG. 3, the participation verification component 310 may comprise a location detection component 311, an activity detection component 312, and an authenticity assessment component 313. The event management component 320 may comprise an event data management component 321, an event rewards management component 322, and an event participation credit management component 323. The user data component 330 may comprise a participation credit ledger component 331. The participation credit management component 340 may comprise a credit reward component 341 and a credit redemption component 342.

[0093] As further shown by the figure, the location detection component 311 and the activity detection component 312 provide data to the authenticity assessment component 313. The authenticity assessment component 313 communicates with the event participation credit management component 323. The event data management component 321 communicates with external event information provider systems 120. The event rewards management component 322 communicates with external reward provider systems 130. The credit reward component 341 and the credit redemption component 342 communicate with the participation credit ledger component 331. The participation verification component 310 communicates with the participation credit management component 340.

[0094] The coordination server subsystem 116 performs the central server-side functions of the participation credit system 110. The coordination server subsystem 116 receives location and attestation data from user-associated mobile device subsystems 111 and determines whether the data indicates that users are legitimately present at events. The coordination server subsystem 116 manages information about events including their geographic boundaries, credit earningAttorney Docket No. : 226360-401018 parameters, and associated rewards. The coordination server subsystem 116 maintains authoritative records of user credit balances. The coordination server subsystem 116 processes credit operations including awarding credit when attendance is verified and deducting credit when users redeem rewards. By centralizing these functions on server infrastructure, the coordination server subsystem 116 can maintain consistent verification logic, authoritative records that persist across user sessions and devices, and coordination across multiple users, events, and reward providers.

[0095] The participation verification component 310 may evaluate data received from user- associated mobile device subsystems 111 to determine whether the data indicates legitimate event attendance. For attendance to be considered legitimate, the data should indicate that the user's mobile device is located within the geographic boundary of an active event and that the device attestation indicates the mobile device is authentic and has not been modified in ways that would enable location spoofing. The participation verification component 310 combines assessments from its subcomponents to make this determination. The location detection component 311 processes location coordinates to determine whether they fall within event boundaries. The activity detection component 312 may process additional sensor data to infer user activity. The authenticity assessment component 313 evaluates device attestation and detects anomalies that may indicate fraudulent reports.

[0096] The location detection component 311 may receive latitude and longitude coordinates from user-associated mobile device subsystems 111 and determine whether those coordinates fall within geographic boundaries of events. In some embodiments, the location detection component 311 may load boundary definitions for active events from the event data management component 321.Attorney Docket No. : 226360-401018In some embodiments, boundary definitions may be cached in memory for efficient access, with the cache refreshed periodically or when events are updated.

[0097] For polygon boundaries, the location detection component 311 may apply point-in-polygon algorithms to determine whether coordinates are inside or outside the polygon. In some embodiments, the location detection component 311 may use the ray casting algorithm, which casts a ray from the test point in an arbitrary direction and counts how many times the ray crosses the polygon boundary. If the crossing count is odd, the point is inside the polygon. If the crossing count is even, the point is outside. In some embodiments, the location detection component 311 may use the winding number algorithm, which calculates how many times the polygon boundary winds around the test point. A non-zero winding number indicates the point is inside.

[0098] In some embodiments, the location detection component 311 may apply optimizations to improve computational efficiency. The location detection component 311 may first check whether coordinates fall within a bounding box that encloses the polygon, skipping the full point-in- polygon calculation if the coordinates are outside the bounding box. In some embodiments, the location detection component 311 may use spatial indexing structures such as R-trees to quickly identify which event boundaries are candidates for a given location, avoiding the need to check against all boundaries.

[0099] For circle boundaries, the location detection component 311 may calculate the distance from the coordinates to the circle's center and compare the distance to the circle's radius. If the distance is less than or equal to the radius, the coordinates are inside the circle. In some embodiments, distance calculations may use the haversine formula, which calculates great-circle distances on a spherical Earth model. In some embodiments, distance calculations may use the Vincenty formula, which calculates distances on an ellipsoidal Earth model for greater accuracy.Attorney Docket No. : 226360-401018

[0100] In some embodiments, the location detection component 31 1 may account for location accuracy uncertainty. Location reports include accuracy estimates indicating the uncertainty of the reported coordinates. A report with coordinates near a boundary and low accuracy may not reliably indicate whether the user is inside or outside. In some embodiments, the location detection component 311 may require that the entire accuracy circle fall within the boundary for positive determination. In some embodiments, the location detection component 311 may use probabilistic methods to estimate the likelihood that the user is inside the boundary given the coordinates and accuracy.

[0101] In some embodiments, the location detection component 311 may determine not only whether coordinates fall within the overall event boundary but also which zone within the event contains the coordinates. Zone determination may use the same point-in-polygon or point-in-circle algorithms applied to zone boundaries. The location detection component 311 may return a zone identifier along with the containment determination, enabling zone-specific credit rates to be applied.

[0102] In some embodiments, the location detection component 311 may check whether events are currently active based on their scheduled start and end times. Location reports for events that have not yet started or have already ended may not qualify for credit, or may qualify for limited pre-event or post-event credit depending on configuration. Time comparisons should account for time zones, comparing the current time in the event's local time zone against the event's scheduled times.

[0103] The activity detection component 312 may process additional data from user-associated mobile device subsystems 111 to infer user activity. In some embodiments, the activity detection component 312 may receive accelerometer data indicating acceleration along three axes as theAttorney Docket No. : 226360-401018 device moves with the user. Tn some embodiments, the activity detection component 312 may receive gyroscope data indicating rotational velocity. Sensor data may be sampled at rates such as 10 Hz, 50 Hz, or 100 Hz.

[0104] In some embodiments, the activity detection component 312 may classify user activity based on sensor data patterns. Activity classifications may include stationary (user is still), walking (user is moving on foot at walking pace), running (user is moving on foot at running pace), or in vehicle (user is traveling in a car, bus, or train). In some embodiments, activity classification may use rule-based approaches with thresholds on sensor values or derived features. In some embodiments, activity classification may use machine learning models such as decision trees, random forests, or neural networks trained on labeled sensor data from users performing various activities. Features used for classification may include mean acceleration, variance of acceleration, frequency domain components from Fourier transforms, or peak detection patterns.

[0105] In some embodiments, the activity detection component 312 may be omitted from the participation verification component 310. When the activity detection component 312 is omitted, participation credit may be awarded based on location and duration without regard to detected activity. In some embodiments where the activity detection component 312 is present, detected activity may be used to adjust credit earning rates, with more active engagement earning at higher rates. In some embodiments, activity data may be used for analytics provided to event organizers without affecting credit calculations.

[0106] The authenticity assessment component 313 may evaluate device attestation data and patterns in received data to assess whether location reports should be trusted. The authenticity assessment component 313 may help the participation verification component 310 distinguishAttorney Docket No. : 226360-401018 between location reports from authentic devices that are likely reporting actual position and location reports from compromised or manipulated devices that may be spoofing position.

[0107] In some embodiments, the authenticity assessment component 313 may verify cryptographic signatures on attestation tokens. For Android Play Integrity tokens, the authenticity assessment component 313 may call Google's API to decrypt and verify the token, or may verify signatures locally using Google's published public keys. Verification confirms that the token was generated by Google's attestation service and has not been tampered with. For iOS App Attest attestations, the authenticity assessment component 313 may verify the certificate chain in the attestation object against Apple's root certificate, confirming that the attestation was generated by a genuine Secure Enclave attested by Apple.

[0108] In some embodiments, the authenticity assessment component 313 may verify that nonces in attestation tokens match nonces previously issued by the coordination server subsystem 116. The authenticity assessment component 313 may maintain a record of issued nonces with expiration times. When an attestation token is received, the authenticity assessment component 313 extracts the nonce and checks it against issued nonces. A matching, unexpired nonce confirms the attestation was generated in response to a specific recent request. A missing, mismatched, or expired nonce may indicate replay of a captured attestation.

[0109] In some embodiments, the authenticity assessment component 313 may verify that attestation timestamps indicate the attestation was generated recently. Attestations generated long ago may be rejected as potentially stale, even if the nonce matches, to limit the window for replay attacks. Acceptable timestamp age may be configured as seconds or minutes depending on requirements.Attorney Docket No. : 226360-401018

[0110] In some embodiments, the authenticity assessment component 313 may examine verdicts contained in attestation tokens and require certain integrity levels. For Play Integrity, the authenticity assessment component 313 may require that device integrity verdicts indicate MEETS DEVICE INTEGRITY or MEETS STRONG INTEGRITY. Devices that only meet basic integrity or fail integrity checks entirely may be more susceptible to location spoofing. In some embodiments, different events may have different integrity requirements, with high-value events requiring stronger integrity. In some embodiments, the system may operate in a strict mode requiring strong integrity or a permissive mode accepting basic integrity.

[0111] In some embodiments, the authenticity assessment component 313 may analyze patterns in location data to detect anomalies suggestive of spoofing or fraud. Impossible movement detection may identify location reports indicating the user traveled between distant locations faster than physically possible. For example, reports indicating positions hundreds of kilometers apart within minutes would require faster-than-flight travel and likely indicate spoofing. The authenticity assessment component 313 may calculate speed between consecutive reports as distance divided by time and compare against maximum reasonable speeds for walking, driving, or flying.

[0112] In some embodiments, the authenticity assessment component 313 may detect teleportation patterns where location jumps abruptly between distant points without intermediate positions. In some embodiments, the authenticity assessment component 313 may detect boundary oscillation patterns where location rapidly alternates between inside and outside a boundary, which may suggest manipulation at boundary edges. In some embodiments, the authenticity assessment component 313 may detect multiple user accounts reporting identical or suspiciously similar location patterns, which may suggest coordinated fraud or a single user operating multipleAttorney Docket No. : 226360-401018 accounts. In some embodiments, the authenticity assessment component 313 may use device fingerprinting to identify the same physical device across multiple user accounts.

[0113] In some embodiments, the authenticity assessment component 313 may assign trust scores to location reports based on accumulated signals. Reports with valid attestation, consistent location patterns, and no anomalies may receive high trust scores. Reports with failed attestation, anomalous patterns, or other red flags may receive low trust scores. The participation verification component 310 may use trust scores to decide whether to accept reports, reject reports, or flag reports for human review.

[0114] In some embodiments, the authenticity assessment component 313 may flag suspicious reports for manual review by human operators. Flagged reports may be placed in a review queue with associated evidence. Human reviewers may examine the evidence and make final determinations. Outcomes of human review may feed back into the authenticity assessment component 313 to improve automated detection over time.

[0115] The event management component 320 may manage information about events and their configurations for credit earning and reward redemption. The event data management component 321, event rewards management component 322, and event participation credit management component 323 together maintain the data needed to determine where events occur, what rewards are available, and how much credit is earned.

[0116] The event data management component 321 may perform create, retrieve, update, and delete operations on event records. Event records may include fields for event identifier, name, description, venue name, venue address, start time, end time, time zone, boundary type, boundary data, status, creation timestamp, update timestamp, and creator identifier. Boundary data for polygon boundaries may be stored as an array of coordinate pairs representing vertices. BoundaryAttorney Docket No. : 226360-401018 data for circle boundaries may be stored as center coordinates and radius. Zone records may be associated with event records, with each zone having fields for zone identifier, event identifier, zone name, boundary type, boundary data, and credit rate modifier.

[0117] In some embodiments, the event data management component 321 may store event and zone records in relational databases such as PostgreSQL or MySQL. In some embodiments, the event data management component 321 may store records in document databases such as MongoDB. In some embodiments, the event data management component 321 may use spatial database extensions such as PostGIS to enable efficient spatial queries on boundary data.

[0118] In some embodiments, the event data management component 321 may validate event data before storing. Validation may check that required fields are present and correctly formatted. Validation may check that coordinate values are within valid ranges for latitude and longitude. Validation may check that polygons are properly closed and have reasonable area. Validation may check that start times precede end times. Validation may check for conflicts such as overlapping events at the same venue.

[0119] In some embodiments, the event data management component 321 may maintain an audit log recording all changes to event records, including who made each change and when.

[0120] The event rewards management component 322 may manage information about rewards associated with events. Reward records may include fields for reward identifier, name, description, image URL, credit cost, reward type, inventory total, inventory remaining, availability start time, availability end time, eligibility rules, redemption limit per user, provider identifier, and associated event identifiers.

[0121] In some embodiments, the event rewards management component 322 may receive reward catalogs from reward provider systems 130 through API calls or webhook notifications. In someAttorney Docket No. : 226360-401018 embodiments, the event rewards management component 322 may poll provider APIs periodically to fetch updated catalogs. In some embodiments, providers may push updates via webhooks when inventory changes.

[0122] In some embodiments, the event rewards management component 322 may track inventory levels, decrementing remaining inventory when rewards are redeemed. Inventory operations should be atomic to prevent overselling when multiple redemptions occur concurrently. In some embodiments, the event rewards management component 322 may implement inventory reservation, temporarily holding inventory during the redemption flow and releasing held inventory if the redemption is cancelled or times out.

[0123] In some embodiments, the event rewards management component 322 may aggregate rewards from multiple providers into a unified catalog for each event. In some embodiments, the same reward may be associated with multiple events at the same or different credit costs.

[0124] The event participation credit management component 323 may store and manage parameters determining how participation credit is earned at events. Credit earning parameters may include a base credit rate specifying how much credit is earned per unit time of verified attendance. In some embodiments, credit rates may be expressed as credits per minute, such as 1 credit per minute, 0.5 credits per minute, or 2 credits per minute. In some embodiments, credit rates may be stored internally as credits per second for precision, with conversion to human- readable units for display.

[0125] In some embodiments, the event participation credit management component 323 may store zone-based rate modifiers that adjust the credit rate based on which zone within the event boundary the user occupies. Zone modifiers may be expressed as multipliers applied to the base rate. For example, a VIP zone modifier of 2.0 would mean users in the VIP zone earn credit atAttorney Docket No. : 226360-401018 twice the base rate. A premium seating modifier of 1 .5 would mean users in premium seating earn at 1.5 times the base rate. A general admission modifier of 1.0 would mean users in general admission earn at the base rate.

[0126] In some embodiments, the event participation credit management component 323 may store activity -based rate modifiers that adjust the credit rate based on detected user activity. An active engagement modifier greater than 1.0 may reward users who are actively moving or participating. A stationary modifier of 1.0 may provide the base rate for users who are still.

[0127] In some embodiments, the event participation credit management component 323 may store time-based rate modifiers that adjust the credit rate based on when during the event attendance occurs. An early arrival modifier may reward users who arrive before the event officially starts. A full-duration modifier may reward users who remain for the entire event. Different periods during the event may have different modifiers.

[0128] In some embodiments, the event participation credit management component 323 may store bonus configurations awarding flat credit bonuses for achieving milestones. Arrival bonuses may award credits for arriving before a certain time. Attendance milestone bonuses may award credits at duration thresholds such as 1 hour, 2 hours, or full event duration. Streak bonuses may award credits for attending multiple events in a series.

[0129] In some embodiments, the event participation credit management component 323 may store maximum credit caps limiting the total credit earnable at an event regardless of duration.

[0130] The effective credit rate for a user at a given moment may be calculated by combining the base rate with applicable modifiers. In some embodiments, the effective rate may be calculated as: effective_rate = base_rate x zone_modifier x activity _modifier x time_modifier. The credit amount earned over a time interval may be calculated as: credit = effective_ratexduration.Attorney Docket No. : 226360-401018

[0131] The user data component 330 may store information specific to individual users of the participation credit system 110. User records may include fields for user identifier, email address, phone number, name, creation timestamp, authentication provider, external identity provider identifier, profile data, and preferences. Device associations may link user identifiers to device identifiers for devices the user has used.

[0132] The participation credit ledger component 331 may store participation credit balances for users. In some embodiments, the participation credit ledger component 331 may maintain separate balances for each user and each event, representing event-specific credit. A user who attends multiple events may have independent credit balances for each event. In some embodiments, event- specific credit may only be redeemable for rewards associated with that specific event.

[0133] In some embodiments, balances may be stored in ledger records with fields for ledger identifier, user identifier, event identifier, and balance amount. In some embodiments, balances may be stored in a relational database with appropriate indexes for efficient queries by user and by event.

[0134] In some embodiments, the participation credit ledger component 331 may store transaction logs recording individual credit operations. Transaction records may include fields for transaction identifier, user identifier, event identifier, transaction type (credit or debit), amount, balance after transaction, timestamp, reference identifier, and description. Credit transactions record credit earned from attendance. Debit transactions record credit spent on redemption. Transaction logs enable users to see how credit was earned and spent, enable operators to audit system behavior, and support dispute resolution.Attorney Docket No. : 226360-401018

[0135] In some embodiments, balance operations should be atomic to prevent race conditions when multiple operations affect the same balance concurrently. Database transactions with appropriate isolation levels may ensure consistency.

[0136] The participation credit management component 340 may orchestrate credit operations including awarding credit when attendance is verified and processing redemption when users request rewards.

[0137] The credit reward component 341 may award participation credit to users based on verified attendance at events. When the participation verification component 310 determines that a user is legitimately present at an event, it signals the credit reward component 341. The signal may include the user identifier, event identifier, verified location, zone identifier if applicable, and timestamp.

[0138] Upon receiving a verified attendance signal, the credit reward component 341 may query the event participation credit management component 323 to retrieve credit earning parameters for the event, including the base rate and any applicable modifiers. The credit reward component 341 may determine the effective credit rate by applying zone modifiers based on the zone identifier and any other applicable modifiers.

[0139] The credit reward component 341 may calculate the credit amount to award based on the effective rate and the duration of verified presence. Duration may be calculated as the time since the previous credit award or since attendance tracking began. The credit amount may be calculated as effective rate x duration. In some embodiments, credit amounts may be rounded to integer values using floor, ceiling, or nearest rounding.

[0140] The credit reward component 341 may instruct the participation credit ledger component 331 to increase the user's balance for the event by the calculated credit amount. The participation credit ledger component 331 creates a credit transaction record and updates the balance.Attorney Docket No. : 226360-401018

[0141] In some embodiments, credit may be awarded incrementally at regular intervals during attendance. The credit reward component 341 may award credit every 30 seconds, every minute, every 5 minutes, or at other intervals. Incremental awarding provides users with a sense of accumulation during attendance and enables the user interface component 230 to display updating balances.

[0142] In some embodiments, credit may be awarded upon conclusion of attendance rather than incrementally. When the user exits the event boundary, when the event ends, or when the user stops attendance tracking, the credit reward component 341 calculates total credit for the entire attendance duration and awards it as a single transaction.

[0143] In some embodiments, credit awarding may use a combination of incremental awards during attendance and a reconciliation award at conclusion to handle any timing discrepancies.

[0144] In some embodiments, the credit reward component 341 may manage attendance sessions to track when attendance begins, continues, and ends. A session starts when verified attendance is first detected. A session continues as subsequent verified attendance reports are received. A session ends when the user's location is outside the boundary, when the event ends, when the user explicitly stops tracking, or when no reports have been received for a timeout period. In some embodiments, the timeout period may be 10 minutes, 30 minutes, or another configured duration.

[0145] In some embodiments, the credit reward component 341 may handle users who briefly exit and re-enter event boundaries. A user who steps outside briefly, such as to use facilities in an adjacent area, may have a brief gap in verified attendance. In some embodiments, brief gaps below a threshold duration may be treated as continuous attendance rather than ending and starting new sessions. In some embodiments, a grace period may allow users to re-enter within a certain time without losing session continuity.Attorney Docket No. : 226360-401018

[0146] In some embodiments, the credit reward component 341 may check for and apply bonus configurations. When attendance milestones are reached, such as attending for a full hour or staying for the entire event, bonus credits may be awarded.

[0147] In some embodiments, the credit reward component 341 may send notifications to users when credit is earned. Notifications may be pushed through WebSocket connections or mobile push notification services.

[0148] The credit redemption component 342 may process requests from users to exchange accumulated credit for rewards. Redemption requests may be initiated by users through the user interface component 230 and transmitted to the coordination server subsystem 116. Redemption requests may specify the reward identifier, the user identifier, and if the user has credit from multiple events, which event balance to use.

[0149] Upon receiving a redemption request, the credit redemption component 342 may perform validation to ensure the redemption can proceed. Validation may include checking that the reward exists and is currently available by querying the event rewards management component 322. The reward should be within its availability window and have remaining inventory. Validation may include checking that the user is eligible for the reward based on any eligibility rules such as age restrictions or geographic restrictions. Validation may include checking that the user has not exceeded any per-user redemption limits for the reward. Validation may include checking that the user has sufficient credit balance by querying the participation credit ledger component 331.

[0150] If any validation check fails, the credit redemption component 342 may reject the redemption request and return an error response indicating the reason, such as insufficient balance, reward out of stock, user not eligible, or redemption limit reached.Attorney Docket No. : 226360-401018

[0151] If validation succeeds, the credit redemption component 342 may proceed with the redemption. The credit redemption component 342 may perform operations atomically to ensure consistency. The credit redemption component 342 may reserve inventory by decrementing the remaining inventory count for the reward. The credit redemption component 342 may deduct the credit cost from the user's balance by instructing the participation credit ledger component 331 to create a debit transaction and update the balance. The credit redemption component 342 may create a redemption record capturing the details of the redemption.

[0152] The credit redemption component 342 may create and submit a fulfillment request to the appropriate reward provider systems 130. The fulfillment request may include the reward identifier, quantity, user identifier, and delivery information. For physical merchandise, delivery information may include shipping address, which may be collected from the user during the redemption flow or retrieved from stored user profile information. For digital content, delivery information may include email address or user account identifiers. The fulfillment request may be submitted via API call to the reward provider.

[0153] In some embodiments, fulfillment may be synchronous, with the credit redemption component 342 waiting for a response from the reward provider before completing the redemption. In some embodiments, fulfillment may be asynchronous, with the credit redemption component 342 submitting the request and receiving status updates later via webhooks or polling.

[0154] The credit redemption component 342 may track fulfillment status for each redemption. Status values may include pending, submitted, processing, shipped, delivered, or failed. The credit redemption component 342 may update status based on callbacks from reward providers or polling of provider status APIs. For shipped physical items, status may include carrier name and tracking number.Attorney Docket No. : 226360-401018

[0155] In some embodiments, the credit redemption component 342 may handle fulfdlment failures. If a reward provider reports that fulfillment failed, the credit redemption component 342 may reverse the redemption by refunding credit to the user's balance and restoring inventory. Alternatively, the credit redemption component 342 may retry fulfillment, offer an alternative reward, or escalate for manual resolution.

[0156] In some embodiments, the credit redemption component 342 may make fulfillment status information available to users through the user interface component 230. Users may view the status of their redemptions and track shipments.

[0157] FIG. 4 shows a block diagram of a blockchain token management component according to embodiments of the present disclosure. As shown by the figure, a blockchain token management component 410 may comprise a key management component 420, a smart contract wallet component 430, a transaction relay component 440, and a wallet recovery component 450. The key management component 420 communicates with the smart contract wallet component 430 and with the wallet recovery component 450. The smart contract wallet component 430 communicates with the transaction relay component 440.

[0158] In some embodiments, participation credit may be represented by or redeemable as blockchain tokens. Blockchain tokens are entries in distributed ledgers maintained by networks of computers using cryptographic protocols. The distributed ledger records which addresses hold which quantities of tokens. Addresses are derived from cryptographic public keys, and control of tokens at an address requires possession of the corresponding private key to sign transactions. Tokens may be transferred between addresses by creating transactions signed with the sender's private key, which are broadcast to the network, validated by network nodes, and recorded in the ledger.Attorney Docket No. : 226360-401018

[0159] Representing participation credit as blockchain tokens may offer certain characteristics. Users may hold tokens in wallets they control rather than merely having balances in a centralized database. Users may transfer tokens to other users or to third parties without requiring permission from the participation credit system 110. Token holdings may be verifiable by anyone who can read the public blockchain. Tokens may be usable with external applications, services, or exchanges that support the token standard.

[0160] However, blockchain systems traditionally present usability challenges that may limit accessibility for users unfamiliar with the technology. Users traditionally must manage private keys, which if lost result in permanent loss of access to tokens and if stolen enable theft of tokens. Users traditionally must obtain native cryptocurrency to pay transaction fees (gas) to the network for processing transactions. Users must interact with blockchain-specific interfaces and concepts that may be unfamiliar.

[0161] The blockchain token management component 410 may provide infrastructure that addresses these challenges, enabling users to hold and transact blockchain tokens without requiring blockchain expertise, without requiring users to manage private keys directly, and without requiring users to hold native cryptocurrency for transaction fees. By abstracting these complexities, the blockchain token management component 410 may make blockchain-based participation credit accessible to users who would otherwise be unable or unwilling to interact with blockchain systems.

[0162] The key management component 420 may manage cryptographic keys for blockchain transactions using multi-party computation (MPC). Multi-party computation refers to cryptographic techniques that enable multiple parties to jointly compute functions over their inputsAttorney Docket No. : 226360-401018 while keeping those inputs private. Applied to key management, MPC enables private keys to be generated, stored, and used without the complete key ever existing in any single location.

[0163] In some embodiments, the key management component 420 may generate private keys using distributed key generation (DKG) protocols. In DKG, multiple parties engage in a protocol where each party contributes randomness. At the conclusion of the protocol, each party holds a key share, which is a mathematical portion of the key material. The complete private key is never assembled; instead, it exists only implicitly as the combination of all shares. No single party, and no subset smaller than a threshold number of parties, can determine the complete key from their shares alone.

[0164] In some embodiments, key shares may be distributed among multiple parties. One share may be held by the key management component 420 in secure server-side storage. Server-side storage may include encryption at rest, access controls, and potentially hardware security modules (HSMs) that provide tamper-resistant storage for cryptographic material. One share may be held on the user's mobile device in secure storage provided by the operating system, such as the iOS Keychain or Android Keystore, which may leverage hardware security features. One share may be held by a third-party key management service that specializes in custody and security of cryptographic material.

[0165] In some embodiments, signature operations may use threshold signatures where only a threshold number of parties, such as two out of three, must participate to produce a valid signature. No party alone can sign. If one party's share is compromised, the attacker cannot sign without also compromising another party's share. If one party's share is lost, the remaining parties can still sign (assuming the threshold is met) or can engage in share recovery protocols.Attorney Docket No. : 226360-401018

[0166] When a blockchain transaction needs to be signed, the participating parties engage in an MPC signing protocol. Each party contributes their share to the protocol without revealing it to other parties. The protocol produces a valid signature that could only have been produced with knowledge of the complete private key, even though no party possessed the complete key. The signature can be verified by anyone using the corresponding public key.

[0167] In some embodiments, the key management component 420 may support key refresh protocols that generate new shares for the same effective private key. Periodic key refresh limits the window during which a compromised share remains useful to an attacker.

[0168] In some embodiments, user authentication may be required before the key management component 420 participates in signing. Users may authenticate using OAuth-based authentication with identity providers such as Google, Apple, Facebook, or other services. The OAuth flow allows users to log in using existing accounts and credentials they already manage, rather than requiring them to create and remember new blockchain-specific credentials such as seed phrases. Upon successful authentication, the key management component 420 may decrypt or retrieve the user's key share and participate in signing protocols.

[0169] In some embodiments, the key management component 420 may integrate with third-party MPC wallet infrastructure providers that offer MPC key generation, share distribution, and threshold signing as managed services. Such providers may include Web3Auth, Fireblocks, Lit Protocol, Dfns, or others.

[0170] In some embodiments, the key management component 420 may support deriving multiple addresses from a single MPC key setup using hierarchical deterministic (HD) derivation. HD derivation allows a tree of addresses to be generated from a single root, with each address usableAttorney Docket No. : 226360-401018 independently. This may enable generating separate addresses for different purposes, such as different events or different token types.

[0171] The smart contract wallet component 430 may manage smart contract wallets on blockchain networks. A smart contract wallet is a blockchain account where the controlling logic is implemented by smart contract code deployed to the blockchain, rather than being solely controlled by possession of a private key as with standard externally owned accounts (EGAs).

[0172] Smart contract wallets enable account abstraction, which refers to architectural patterns that allow customization of account behavior beyond what is possible with EGAs. Account abstraction as specified in ERC-4337 defines a standard interface for smart contract wallets on Ethereum and compatible networks.

[0173] Smart contract wallets may implement various features not possible with EGAs. Smart contract wallets may implement custom authorization logic, such as requiring multiple signatures, enforcing spending limits, restricting allowed destination addresses, or implementing time delays on high-value transactions. Smart contract wallets may support transaction batching, combining multiple operations into a single transaction. Critically for accessibility, smart contract wallets may support transaction fee sponsorship where parties other than the wallet owner pay transaction fees.

[0174] In some embodiments, smart contract wallets may be deployed on blockchain networks compatible with the Ethereum Virtual Machine (EVM). Compatible networks may include Ethereum mainnet, Polygon, Arbitrum, Optimism, Base, Avalanche, BNB Chain, and numerous other networks. Layer 2 networks built on top of Ethereum, such as Arbitrum and Optimism, may offer lower transaction fees and faster confirmations than Ethereum mainnet while maintaining security guarantees.Attorney Docket No. : 226360-401018

[0175] In some embodiments, the smart contract wallet component 430 may deploy smart contract wallets for users on one or more supported networks. Deployment may occur when users first need a wallet, using counterfactual deployment where the wallet address is computed in advance and the actual deployment transaction occurs with the first transaction that uses the wallet.

[0176] In some embodiments, smart contract wallets may be based on established implementations such as Safe (formerly Gnosis Safe) or implementations from account abstraction infrastructure providers such as ZeroDev, Biconomy, or Stackup. Using established implementations that have been audited and battle-tested may reduce security risks.

[0177] The transaction relay component 440 may submit transactions to blockchain networks on behalf of users. In traditional blockchain usage, users sign transactions and submit them directly to network nodes, paying transaction fees (gas) in the network's native cryptocurrency. The transaction relay component 440 enables a different flow where users sign transaction intents, and the relay handles submission and fee payment.

[0178] In some embodiments, the transaction relay component 440 may operate according to the ERC-4337 architecture. Users create UserOperations, which are data structures describing intended transactions. UserOperations are signed with the user's key (via MPC through the key management component 420 and authorized by the smart contract wallet component 430). A bundler service collects UserOperations and submits them to the blockchain in bundle transactions. A paymaster contract pays the gas fees for the bundle, drawing from a sponsor account rather than from user funds.

[0179] In some embodiments, transaction fees may be sponsored by the operator of the participation credit system 110 as a cost of providing accessible blockchain functionality to users. In some embodiments, transaction fees may be sponsored by event organizers or sponsors whoAttorney Docket No. : 226360-401018 wish to subsidize user interactions. Sponsor accounts must be funded with native cryptocurrency sufficient to cover fees for user transactions.

[0180] In some embodiments, the transaction relay component 440 may estimate gas requirements for transactions before submission to ensure adequate fee payment. Gas estimation may involve simulating transactions or using estimation APIs provided by network nodes.

[0181] In some embodiments, the transaction relay component 440 may monitor network gas prices and set transaction gas prices appropriately to balance confirmation speed against cost. On networks using EIP-1559 fee structures, the relay may set base fees and priority fees based on current network conditions.

[0182] In some embodiments, the transaction relay component 440 may batch multiple user operations into single transactions to reduce per-operation overhead costs. For example, minting tokens to multiple users may be combined into a single batch mint transaction rather than individual transactions for each user.

[0183] In some embodiments, the transaction relay component 440 may monitor submitted transactions to confirm they are included in blocks. The relay may track transactions through pending, confirmed, and finalized states. The relay may handle stuck transactions by resubmitting with higher gas prices. The relay may detect and handle chain reorganizations that may affect transaction status.

[0184] The wallet recovery component 450 may enable users to recover access to their blockchain wallets if primary credentials are lost or compromised. Loss scenarios may include losing a mobile device, forgetting passwords, accidentally deleting applications, or having credentials stolen. Without recovery mechanisms, such losses could result in permanent loss of access to tokens held in the wallet.Attorney Docket No. : 226360-401018

[0185] In some embodiments, the wallet recovery component 450 may implement social recovery mechanisms. Social recovery involves designating trusted parties as guardians who can collectively authorize recovery operations. During initial wallet setup, users may designate guardians from among friends, family members, or other trusted parties. Guardians may be identified by email addresses, phone numbers, or blockchain addresses. In some embodiments, users may designate between 3 and 7 guardians.

[0186] A recovery threshold specifies how many guardians must approve recovery, such as 3 out of 5 or 2 out of 3. The threshold should be high enough that a malicious subset of guardians cannot unilaterally take over the wallet, but low enough that recovery remains possible even if some guardians are unavailable.

[0187] If a user loses access and needs to recover, the user initiates recovery through a new device or session. The wallet recovery component 450 notifies designated guardians of the recovery request, such as by email or SMS. Each guardian who approves the recovery provides confirmation, such as by clicking a link, entering a code, or signing a message. The wallet recovery component 450 collects confirmations. When the threshold number of confirmations is reached, recovery proceeds.

[0188] In some embodiments, recovery may be subject to a mandatory time delay, such as 24 hours, 48 hours, or 7 days. The time delay provides a window during which unauthorized recovery attempts can be detected and cancelled. The legitimate user may receive notifications through multiple channels when recovery is initiated, allowing them to cancel if they did not initiate the recovery.

[0189] Recovery execution may involve generating new MPC key shares that exclude the lost or compromised share, updating the smart contract wallet to recognize new authorized signers, andAttorney Docket No. : 226360-401018 invalidating old authorization. After recovery, the user can access the wallet from the new device with new credentials, and the old credentials no longer provide access.

[0190] In some embodiments, the wallet recovery component 450 may support alternative recovery methods in addition to or instead of social recovery. Users may store encrypted backup recovery files that can be decrypted with a password. Users may use hardware security keys as backup authentication factors. Institutional recovery may involve partnerships with custody providers who can verify identity and authorize recovery.

[0191] The blockchain token management component 410 may integrate with components of the coordination server subsystem 116 in embodiments where participation credit involves blockchain tokens.

[0192] In some embodiments, the credit reward component 341 may interface with the blockchain token management component 410 to mint tokens when participation credit is awarded. When verified attendance generates credit, rather than or in addition to recording the credit in the participation credit ledger component 331, the credit reward component 341 may call the blockchain token management component 410 to mint a corresponding quantity of tokens to the user's smart contract wallet. The blockchain token management component 410 constructs a minting transaction, obtains necessary signatures through MPC, and submits the transaction through the transaction relay component 440. Upon transaction confirmation, the tokens appear in the user's on-chain wallet balance.

[0193] In some embodiments, token minting may occur incrementally during attendance, with tokens minted each time credit is awarded. This approach provides users with real-time token accumulation but incurs transaction costs for each minting operation. In some embodiments, token minting may occur in batches, with accumulated credit converted to tokens at intervals such asAttorney Docket No. : 226360-401018 hourly or daily, or at the conclusion of attendance. Batch minting reduces transaction costs by combining multiple awards. In some embodiments, batch minting may combine awards across multiple users into single batch mint transactions.

[0194] In some embodiments, the credit redemption component 342 may interface with the blockchain token management component 410 for redemption operations that involve tokens. If a reward involves transferring tokens to a recipient address, such as a merchant or service provider, the credit redemption component 342 may call the blockchain token management component 410 to execute the transfer. If redemption involves burning (destroying) tokens, the blockchain token management component 410 may execute a burn transaction.

[0195] In some embodiments, the participation credit ledger component 331 may be supplemented or replaced by on-chain token balances. Rather than maintaining credit balances in an off-chain database, the system may treat the user's token holdings as recorded on the blockchain as the authoritative record of their balance. Querying a user's balance involves reading the token contract state from the blockchain. This approach provides transparency, as users can independently verify their balances using any blockchain explorer or wallet application. This approach also provides user control, as users can transfer their tokens using standard blockchain tools without requiring the participation credit system 110 to facilitate.

[0196] In some embodiments, the system may operate in a hybrid mode where both off-chain ledger balances and on-chain token balances exist, with periodic reconciliation to ensure consistency.

[0197] In some embodiments, participation credit may be automatically converted to blockchain tokens upon being awarded. When the credit reward component 341 awards credit, the blockchain token management component 410 immediately mints corresponding tokens. In suchAttorney Docket No. : 226360-401018 embodiments, the distinction between off-chain credit and on-chain tokens effectively disappears. Earning credit and earning tokens occur simultaneously. The tokens are the credit. This approach corresponds to the architecture described in the original disclosure where earning participation credit results in contemporaneous token minting.

[0198] In some embodiments, event-specific participation credit from multiple events may be redeemable for a common blockchain token type. If credit earned at Event A and credit earned at Event B can both be converted to the same token, then users who attend both events accumulate fungible tokens that are interchangeable regardless of which event generated them. Event-specific credit may thus become functionally fungible across events that share a common token type. Configuration may specify which events share token types, allowing flexibility in how fungibility operates across the event ecosystem.

[0199] In some embodiments, blockchain tokens distributed through the participation credit system 110 may comply with established token standards. The ERC-20 standard defines a common interface for fungible tokens on EVM-compatible networks. ERC-20 tokens implement standard functions including totalSupply, balanceOf, transfer, approve, and transferFrom, and emit standard events including Transfer and Approval. Compliance with ERC-20 enables tokens to be held in any wallet that supports ERC-20 tokens, displayed in wallet applications with proper names, symbols, and decimal places, listed on exchanges, and used with decentralized finance protocols and other applications that support ERC-20.

[0200] In some embodiments, token contracts may include functionality beyond the base ERC-20 interface to support participation credit system requirements. Token contracts may include minting functions that can only be called by authorized addresses (the coordination server subsystem 116) to create new tokens when credit is awarded. Token contracts may include batch minting functionsAttorney Docket No. : 226360-401018 that mint tokens to multiple recipients in a single transaction, reducing gas costs when awarding tokens to many users. Token contracts may include functions or events that associate operations with identifiers such as event identifiers or user identifiers, enabling correlation with off-chain records for auditing and analytics.

[0201] In some embodiments, third parties may accept blockchain tokens distributed through the participation credit system 110 without direct integration with the participation credit system 110. Because users hold tokens in wallets they control, and because ERC-20 tokens can be transferred to any address, users may send tokens to any recipient. Sports venues, merchandise vendors, restaurants, retailers, experience providers, or other businesses may accept tokens as payment or for discounts by implementing standard ERC-20 token acceptance. A merchant may display a payment request with their receiving address and the requested token amount. The user approves a transfer in their wallet. The merchant's system confirms receipt of tokens. The merchant provides the goods or services. This open acceptance model enables an ecosystem where tokens earned through event attendance have utility beyond rewards explicitly configured in the participation credit system 110.

[0202] In some embodiments, tokens may be tradeable on exchanges, allowing users who wish to sell their tokens to do so, and allowing others to purchase tokens. Exchange trading may establish market prices for tokens based on supply and demand. Liquidity on exchanges affects how easily tokens can be bought or sold.

[0203] The participation credit system 110 may support various event types across different industries and contexts. In some embodiments, events may comprise sporting events including professional competitions in football, basketball, baseball, hockey, soccer, golf, tennis, motorsports, combat sports, and other sports; college and amateur competitions; and esportsAttorney Docket No. : 226360-401018 events. In some embodiments, events may comprise concerts including solo artist performances, band performances, orchestra performances, and DJ sets; and music festivals spanning multiple days with multiple stages. In some embodiments, events may comprise conferences including technology conferences, medical conferences, academic conferences, and industry trade shows. In some embodiments, events may comprise festivals including music festivals, food and beverage festivals, cultural festivals, art festivals, and film festivals. In some embodiments, events may comprise community events including parades, fairs, farmers markets, and holiday celebrations. In some embodiments, events may comprise corporate events including product launches, shareholder meetings, and employee events. In some embodiments, events may comprise educational events including lectures, workshops, seminars, and graduation ceremonies.

[0204] The coordination server subsystem 116 may be configured to handle events with varying characteristics. Events may have geographic boundaries ranging from small venues such as clubs or theaters holding hundreds of people to large venues such as stadiums holding tens of thousands to expansive outdoor areas such as festival grounds or parade routes spanning large geographic areas. Events may have durations ranging from a couple of hours for a single performance or game to multiple days for festivals or conferences. Events may have varying attendance patterns, with some events involving continuous presence and others involving attendees coming and going throughout the event.

[0205] In some embodiments, credit earning rates may be configured to accommodate these variations, with higher rates for shorter events to provide meaningful credit accumulation, lower rates for longer events to prevent excessive credit accumulation, and appropriate caps and bonuses to shape desired attendance behaviors.Attorney Docket No. : 226360-401018

[0206] In some embodiments, a non-transitory computer-readable storage medium including instructions is also provided, and the instructions may be executed by a device, for performing the above-described methods. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory, NVRAM, a cache, a register, any other memory chip or cartridge, and networked versions of the same. The device may include one or more processors (CPUs), an input / output interface, a network interface, and / or a memory.

[0207] The devices, modules, and other functional units described in this disclosure can be implemented by hardware, or software, or a combination of hardware and software. In some embodiments, functions described as being implemented in hardware may instead be implemented in software or a combination of hardware and software. Likewise, in some embodiments, functions described as being implemented in software may instead be implemented in hardware or a combination of hardware and software. If something is implemented by software, it may be stored in a non-transitory computer-readable media, like the computer-readable media described above. Such software, when executed by a processor, may perform the function of the device, module or other functional unit the software is implementing. The above described devices, modules, and other functions units may also be combined or may be further divided into a plurality of sub-units.

[0208] In some places reference is made to standards, including standard methods of performing some task. These standards are revised from time to time, and, unless explicitly stated otherwise, reference to standards in this disclosure refer to the most recent published standard as of the time of filing.Attorney Docket No. : 226360-401018

[0209] Spatially relative terms, such as “under”, “below”, “lower”, “over”, “upper” and the like, may be used herein for ease of description to describe one element or feature’s relationship to another when the apparatus is right side up.

[0210] When a feature is referred to as being “on” another feature, the feature may be directly on the other feature with no intervening features present or it may be indirectly on the other feature with intervening features being present. In contrast, when a feature is referred to as being “directly on” another feature, the feature is directly on the other feature with no intervening features present. It will also be understood that, when a feature is referred to as being “connected”, “attached” or “coupled” to another feature, the feature may be directly connected, attached or coupled to the other feature with no intervening features present or it may be indirectly connected, attached or coupled to the other feature with intervening features being present. In contrast, when a feature is referred to as being “directly connected”, “directly attached” or “directly coupled” to another feature, the feature is directly connected, directly attached, or directly coupled to the other feature with no intervening features present.

[0211] The terms “about” and “approximately” shall generally mean an acceptable degree of error or variation for the quantity measured given the nature or precision of the measurements. Typical, exemplary degrees of error or variation are within 20%, preferably within 10%, more preferably within 5%, and still more preferably within 1% of a given value or range of values. Numerical quantities given in this description are approximate unless stated otherwise, meaning that the term “about” or “approximately” can be inferred when not expressly stated.

[0212] Ordinal numbers or terms such as “first” and “second” are used only to differentiate an entity or operation from another entity or operation, and do not require or imply any actual relationship or sequence between these entities or operations. Thus, a first feature or element couldAttorney Docket No. : 226360-401018 be termed a second feature or element, and similarly, a second feature or element could be termed a first feature or element without departing from the teachings of the present disclosure. Moreover, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items.

[0213] As used herein, unless specifically stated otherwise, the terms “or” and “at least one of’ encompasses all possible combinations, except where infeasible. For example, if it is stated that a component may include “A or B,” then, unless specifically stated otherwise or infeasible, the component may include “A,” “B,” or “A and B.” As a second example, if it is stated that a component includes “at least one of A, B, or C,” then, unless specifically stated otherwise or infeasible, the component may include “A,” “B,” “C,” “A and B,” “A and C,” “B and C,” or “A, B, and C.” This same construction applies to longer lists (e.g., “may include A, B, C, or D”).

[0214] As used herein, the singular forms “a”, “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0215] Any statements in this disclosure criticizing or disparaging aspects of the prior art are not intended to indicate that what is claimed excludes any of those criticized or disparaged aspects of the prior art.

[0216] Any given element or step of the embodiments disclosed above may be embodied in a single element or step or may be embodied in multiple elements or steps. Moreover, any given element or step of the embodiments disclosed above may be combined and embodied in single element or step or may be combined and embodied in multiple elements or steps.Attorney Docket No. : 226360-401018

[0217] Any sequence of steps shown in the various figures is only for illustrative purposes and does not necessarily indicate that embodiments of the present disclosure are limited to any particular sequence of steps. As such, steps performed by various embodiments of the present disclosure can be performed in a different order while implementing the same method.

[0218] In the foregoing specification, embodiments have been described with reference to numerous specific details that can vary from implementation to implementation. Certain adaptations and modifications of the described embodiments can be made. Other embodiments can be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims. It is also intended that any sequence of steps shown in the figures is only for illustrative purposes and are not intended to indicate that the embodiments of the present disclosure are limited to any particular sequence of steps. As such, those skilled in the art can appreciate that these steps can be performed in a different order while implementing the same method.

Claims

Attorney Docket No. : 226360-401018CLAIMSNow, therefore, the following is claimed:

1. A system for event participation credit management comprising: a participation verification component configured to receive location data and device attestation data from a user-associated mobile device and to determine, based on the location data, whether the mobile device is within a geographic boundary associated with an event, and to determine, based on the device attestation data, whether the mobile device is authentic; an event participation credit management component configured to store a credit rate associated with the event; a credit reward component configured to, responsive to the participation verification component determining the mobile device is within the geographic boundary and is authentic, cause event-specific participation credit to be awarded to a user account associated with the mobile device, wherein an amount of the event-specific participation credit awarded is based on the credit rate and a duration of verified presence within the geographic boundary; a participation credit ledger component configured to store event-specific participation credit balances for user accounts; and a credit redemption component configured to process requests to redeem accumulated event-specific participation credit for rewards.

2. The system of claim 1, wherein: the credit rate is based at least in part on a location of the mobile device within the geographic boundary.Attorney Docket No. : 226360-4010183. The system of claim 1, wherein: the participation verification component further comprises an activity detection component configured to determine an activity of a user of the mobile device, and wherein the credit rate is based at least in part on the determined activity.

4. The system of claim 1, wherein: the geographic boundary comprises a polygon defined by a plurality of geographic coordinates.

5. The system of claim 1, wherein: the device attestation data comprises attestation data obtained from at least one of Play Integrity API or DeviceCheck API.

6. The system of claim 1, wherein the participation verification component further comprises: an authenticity assessment component configured to detect location spoofing attempts based on analysis of patterns in received location data.

7. The system of claim 1, wherein: the rewards comprise at least one of merchandise, tickets, experiences, raffle entries, discounts, or digital content.

8. The system of claim 1, wherein: the rewards comprise blockchain tokens.Attorney Docket No. : 226360-4010189. The system of claim 8, further comprising: a blockchain token management component comprising a key management component configured to manage cryptographic keys associated with blockchain wallets of users using multiparty computation, wherein the cryptographic keys are split into key shares held by multiple parties.

10. The system of claim 9, wherein the blockchain token management component further comprises: a smart contract wallet component configured to manage smart contract wallets that enable transactions without users holding native blockchain cryptocurrency.

11. The system of claim 10, wherein the blockchain token management component further comprises: a transaction relay component configured to submit transactions to a blockchain network with sponsored transaction fees.

12. The system of claim 9, wherein the blockchain token management component further comprises: a wallet recovery component configured to enable recovery of blockchain wallets through designated guardians using a social recovery mechanism.

13. The system of claim 8, wherein: the event-specific participation credit is automatically converted to blockchain tokens upon being awarded.Attorney Docket No. : 226360-40101814. The system of claim 8, wherein: event-specific participation credit from a plurality of events is redeemable for a common blockchain token type.

15. The system of claim 1, wherein the system further comprises: an event data management component configured to receive event information including the geographic boundary from an event information provider system.

16. The system of claim 1, wherein the system further comprises: an event rewards management component configured to receive reward definitions and exchange rates from a reward provider system.

17. A method for event participation credit management comprising: receiving, by a coordination server subsystem, location data and device attestation data from a user-associated mobile device; determining, by a participation verification component of the coordination server subsystem, based on the location data, whether the mobile device is within a geographic boundary associated with an event; determining, by the participation verification component, based on the device attestation data, whether the mobile device is authentic; responsive to determining the mobile device is within the geographic boundary and is authentic, awarding event-specific participation credit to a user account associated with the mobile device, wherein an amount of the event-specific participation credit awarded is based on a credit rate associated with the event and a duration of verified presence within the geographic boundary; storing the event-specific participation credit in a participation credit ledger; and processing a request to redeem accumulated event-specific participation credit for a reward.Attorney Docket No. : 226360-40101818. The method of claim 17, wherein: the credit rate is based at least in part on a location of the mobile device within the geographic boundary.

19. The method of claim 17, wherein: the reward comprises blockchain tokens; and processing the request comprises: reconstructing, using multi-party computation, a cryptographic key from key shares held by multiple parties; signing a blockchain transaction using the reconstructed cryptographic key; and submitting the signed blockchain transaction to a blockchain network.

20. The method of claim 19, wherein: submitting the signed blockchain transaction comprises submitting the transaction through a transaction relay that sponsors transaction fees such that the user does not pay transaction fees.

Images