VENUE NOTIFICATIONS

BACKGROUND

Field of the Invention

The present invention is generally related to web services. More specifically, the present invention concerns a web service platform to improve customer communications within a venue.

Description of the Related Art

Venues such as theme parks, cruise ships, universities, arenas, resorts, and stadiums are popular attractions that host thousands of people on a daily basis. Most of these venues provide static paper maps or signs that are meant to allow guests to explore the venue, encourage engagement in one or more activities at the venue, and otherwise attempt to maximize enjoyment while on the premises. These venues will often have other special events such as concerts, merchandise, culinary, or souvenir sales, and other limited time or new events that are of potential interest to their visitors.

It is difficult if not impossible, however, for guests to communicate their location and plan to one another with respect to when and where to meet for special events. Guests are similarly challenged with respect to simply meeting up throughout the day when they are only provided with a paper map upon entrance into the venue. While signage, flyers, or commercials outside the venue might help communicate information or identify potential meeting points, there is no means to communicate this information in real-time, especially for last minute events, offers, and changes in plans.

There is a need in the art for improved customer communications. An improved guest communication methodology within such venues would improve the guest experience and ultimately improve monetization from the user presence at the venue.

SUMMARY OF THE PRESENTLY CLAIMED INVENTION

A first claimed embodiment of the present invention includes a method for connecting with a contact. Through the method, a determination is made as to whether a user has entered a venue, identifies user contacts within the venue, and then transmits a message to devices associated with each user contact within the venue regarding the user within the venue.

A second claimed embodiment concerns a method for organizing a gathering. Through this method, a rally point at a geographical point in a venue is generating. Selected contacts from a remote device associated with a user receive a transmission of the rally geographic information to allow for subsequent meet ups.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for increasing customer engagement, including venue notifications.

FIG. 2 is a method for sharing user information.

FIG. 3 is a method for providing notification to users.

FIG. 4 is a method for coordinating a meeting point at a venue.

FIGS. 5A-D illustrate exemplary user interfaces for implementing the methods described in the contexts of FIG. 2 and FIG. 3.

FIG. 5A illustrates an exemplary user interface for implementing privacy settings corresponding to particular contacts.

FIG. 5B illustrates an exemplary user interface that displays a notification message identifying that “James Moore” is in a venue.

FIG. 5C illustrates an exemplary user interface that displays a notification message identifying that multiple friends of a user are in a venue.

FIG. 5D illustrates an exemplary user interface that displays a notification message identifying that “Amy White” is in a venue.

FIG. 6 illustrates an exemplary computing system that may be utilized to implement one or more embodiments of the present invention.

FIGS. 7A-F illustrate exemplary user interfaces for implementing the described in the context of FIG. 4.

FIG. 7A illustrates an exemplary user interface with a map view that identifies an optimal rally point, a user location, and locations of several contacts.

FIG. 7B illustrates an exemplary user interface with a map view that identifies a moved rally point.

FIG. 7C illustrates an exemplary user interface with a map view that identifies options for scheduling a rally time.

FIG. 7D illustrates an exemplary user interface that displays a rally point invitation.

FIG. 7E illustrates an exemplary user interface with a map view that identifies options for accepting an identified rally time or proposing an alternative rally time.

FIG. 7F illustrates an exemplary user interface allowing a user to set a reminder to trigger when the user needs to begin travelling to the rally point.

DETAILED DESCRIPTION

The present invention includes a web service platform to improve end-user engagement in a captive audience environment. Mobile and web-based clients enable application users to authorize and communicate their locations with other individuals within the closed environment. Communication may include methods for forming rally points and generating notifications concerning friend arrival and departure.

FIG. 1 illustrates a system 100 for increasing customer engagement, including customer monetization. The system 100 of FIG. 1 includes an ecosystem of data sources 105 such as mobile devices 110, point-of-sale (POS) terminals 115B or point-of-entry/-exit (POE) terminals 115A, and databases 120. Communicatively coupled to data sources 105 are back-end application servers 125. In system 100, application servers 125 can ingest, normalize and process data collected from mobile devices 110 and various POS terminals 115B or POE terminals 115A. Types of information gathered from data sources 105 and processed by back-end application servers 125 are generally inclusive of identity (e.g., user profiles, CRM data, entitlements, demographics, reservation systems and social media sources like Pinterest and Facebook), proximity (e.g., GPS and beacons), and time (e.g., schedules, weather, and queue length).

Mobile devices 110 can execute an application on a user mobile device that shares customer engagement data such as current and prior physical locale within a venue as well as wait times and travel times (e.g., how long was a customer at a particular point in a venue and how long did it take the customer to travel to a further point in a venue). Mobile devices 110 are inclusive of wearable devices. Wearable devices (or ‘wearables’) are any type of mobile electronic device that can be worn on the body or attached to or embedded in clothes and accessories of an individual. Processors and sensors associated with a wearable can gather, process, display, and transmit and receive information.

POS data may be gathered at a sales terminal 115B that may interact with a mobile or wearable device 110 to track customer purchase history at a venue or preference for engagement at a particular locale within the venue. POE terminals 115A may provide data related to venue traffic flow, including entry and exit data that can be inclusive of time and volume. POE terminals 115A may likewise interact with mobile and wearable devices 110.

Historical data may also be accessed at databases 120 as a part of the application server 125 processing operation. The results of a processing or normalization operation may likewise be stored for later access and use. Processing and normalization results may also be delivered to front-end applications (and corresponding application servers) that allow for the deployment of contextual experiences and provide a network of services to remote devices as is further described herein.

The present system 100 may be used with and communicate with any number of external front-end devices 135 by way of communications network 130. Communication network 130 may be a local, proprietary network (e.g., an intranet) and/or may be a part of a larger wide-area network. Communication network 130 may include a variety of connected computing device that provide one or more elements of a network-based service. The communications network 130 may include actual server hardware or virtual hardware simulated by software running on one or more actual machines thereby allowing for software controlled scaling in a cloud environment.

Communication network 130 allows for communication between data sources 105 and front-end devices 135 via any number of various communication paths or channels that collectively make up network 130. Such paths and channels may operate utilizing any number of standards or protocols including TCP/IP, 802.11, Bluetooth, GSM, GPRS, 4G, and LTE. Communications network 130 may be a local area network (LAN) that can be communicatively coupled to a wide area network (WAN) such as the Internet operating through one or more network service provider.

Information received and provided over communications network 130 may come from other information systems such as the global positioning system (GPS), cellular service providers, or third-party service providers such as social networks. The system 100 can measure location and proximity using hardware on a user device (e.g., GPS) or collect the data from fixed hardware and infrastructure such as Wi-Fi positioning systems and Radio Frequency ID (RFID) readers. An exemplary location and proximity implementation may include a Bluetooth low-energy beacon with real time proximity detection that can be correlated to latitude/longitude measurements for fixed beacon locations.

Additional use cases may include phone-based, GPS, real-time location (latitude/longitude) measurements, phone geo-fence-real time notifications when a device is moving into or out of location regions, Wi-Fi positioning involving user location detection based on Wi-Fi signal strength (both active or passive), RFID/Near Field Communication (NFC), and cellular tower positioning involving wide range detection of user device location, which may occur at the metro-level.

Front-end devices 135 are inclusive of kiosks, mobile devices, wearable devices, venue devices, captive portals, digital signs, and POS and POE devices. It should be noted that each of these external devices may be used to gather information about one or more consumers at a particular location during a particular time. Thus, a device that is providing information to a customer on the front-end (i.e., a front-end device 135) such as a mobile device executing an application or a specially designed wearable can also function as a data source 105 as described above.

The system 100 of FIG. 1 provides services to connect venue management with visitors and entertainment consumers while simultaneously providing a messaging platform for consumers. For example, the social network of a consumer may be extended into a map and the physical world associated with the map. Services to extend the social network of a user include finding friends, coordinating rally points, management of proximity based parental controls, friend arrival and departure, and customization and sharing of photos. Venue management may provision consumers with badges, points and rewards, coordinate scavenger hunts and competitions, and provide leaderboard and trivia services. Consumers may also be engaged by collecting feedback and reviews of their experiences, managing favorites and wish lists, conducting surveys and interactive voting, and through the display of messages.

FIG. 2 is a method for sharing user information. The method 200 of FIG. 2 may be executed in a system 100 like that described in the context of FIG. 1. FIG. 1 illustrates a number of mobile devices such as handsets and wearables (110), application service platforms (125), and third-party systems (like those used in communications network 130). The foregoing devices, platforms, and systems are exemplary. The concepts of sharing information as set forth herein may be implemented in any number of devices, machines, and platforms. In some instances, the application service platform 125 may operate in conjunction with a mobile application or mobile interface on a user mobile device or wearable (110).

Returning to the method (200) of FIG. 2, an account may be created at step 210. In some instances, an end user may create an account that is hosted by a web service platform as might be running at application service platform 125 or operating in conjunction with a mobile device or wearable 110. A user account may be configured during account creation to opt-in for various system notifications at step 220. A user may opt-in to allow the service to notify them when certain events occur. For example, a user may opt-in for notifications related to events associated with other users. Such an event might be when other end-users of the service (e.g., friends) enter a geo-fence of the venue.

The identity of friends that would trigger such a notification may be manually created or derived from a “friends list” as might exist in various forms of social media accounts such as Facebook, Instagram, or Twitter. The specifics of a geo-fence can also be defined at this stage. The geo-fence may be related to the entire venue, general geographic areas or “lands” within a venue, or specific geographical points or points-of-interest such as specific rides, vendors, or even specific GPS coordinates. The opt-in step 220 may also allow the user to provide for notifications to be sent to other users of the system 100 concerning passage in or from certain geo-fences. More specifically, User A can configure the system 100 by way of method 200 to receive notifications when Users B and C enter a particular venue. User A can also allow the system 100 to provide for notifications to Users B and C (or perhaps just User B) when User A arrives at the venue or portions thereof. In this regard, the user can set up certain privacy controls to permit certain users to have notifications and deny such notifications to other users, even if those other users are desirous of receiving the same.

During the method 200 of FIG. 2, an end user may also authorize the system 100 (or at least application server 125) to access an address book or other contacts list (such as a social network) at step 230. The address book may be stored on a mobile device or accessible on a cloud network or through a third-party service provider. In some instances, the user may be required to provide credentials to the third-party service provider to allow for access by system 100 and server 125. Allowing for address book access may allow for further notifications to be generated or provided. Address book access may, therefore, occur prior to or in conjunction with the generation or allowance for various notifications in step 210.

Granting access to an address book at step 230 is optional. Generating and/or allowing for certain notifications at step 220 is likewise optional. While generating notifications or allowing for address book access is optional, denying such access may affect the overall functionality of generating and/or receiving certain venue notifications.

Should a user grant access at step 230, the application running on the mobile device 110 or application server 125 downloads or otherwise accesses certain address book information at step 240. The application server 125—alone or in conjunction with mobile device 110 and any corresponding web or mobile application—may attempt to match contacts with other users who have granted similar access to system 100. Matching may occur through the use of phone numbers, email addresses, social network IDs, or instant messaging IDs.

A user may—in a manner similar to granting address book access at step 230—grant social network access at step 250. When a social network service is linked to the system 100, the end-user may authorize the application server 125—alone or in combination with a mobile or web application at mobile device 110—to import social network contact information at step 260. As noted above, granting access to various accounts and importing of data from those accounts may occur in various orders or concurrently with other operations of the method 200 of FIG. 2 (e.g., concurrent with notification set up at step 220). When the platform operating at application server 125 imports social network contacts, certain relationships may be verified relationships such as parent and child, husband and wife, and then associated with information derived from an address book contact list.

Further contact or social network matching may occur at step 270. After importing all contacts and social network information (should such access be granted) or otherwise manually entered, the web service executing at application server 125 will compare the imported information to identify end users who know each other. Step 280 may allow for a user to set, reconfigure, or otherwise eliminate certain privacy settings that may be necessary following the matching operation at step 270.

FIG. 3 is a method 300 for providing notification to users. The method 300 of FIG. 3 may occur in the context of a system (100) like that of FIG. 1. A user may enter a venue at step 305 in FIG. 3. The venue may be stadium, theme park, or other area defined by a geographic region. Said venue may have implemented a system (100) like that illustrated in FIG. 1. The end user location may be sent to a web service platform as may be running at application server 125 at step 310. The location may be received and stored by the application server 125 and corresponding web service platform.

For each contact that an end user imported into the web service platform, the end user can set privacy settings to specify whether they want the contact to receive notifications when they enter and leave the venue (e.g., steps 220 and 280 of FIG. 2) and whether that contact can see the end user's location while they are both inside the venue. An exemplary user interface for implementing such privacy settings is illustrated in FIG. 5A. An end user may update their particular privacy settings for any contact at any time and not just during the contact import process as might otherwise occur in the methodology described in FIG. 2.

A determination is made as to whether any user contacts on the list are within the venue at step 315. The location of end user can be determined by the mobile handset or a wearable device calculating its location through on-device technology like GPS/Wi-Fi, by sensors within the venue detecting the user entering the venue and reporting location to web service platform operating at application server 125, or through beacon technology such as iBeacons interfacing between the mobile handset 110 and the web service platform.

The web service platform may compare a contact list of the end user to other users currently within the venue. If no user contacts are inside the venue, the method of FIG. 3 may temporarily end or suspend. The method of FIG. 3 may be subject to regular polling to determine whether such a situation has changed. If contacts of the user are in the venue as determined at step 315, a determination may be made as to whether the contact is a mutual connection at step 320. For each end user on the contact list (the contact) of the end user entering the venue, web service platform will perform a different workflow depending on whether the connection is mutual (i.e., the end user and the contact are on each on one another's contact lists and that end user authorized the contact to be notified when end user enters the venue. If the contacts are mutual connections as determined at step 320, the method continues to step 325. If the contacts are not mutual contacts, the method continues to step 350.

For mutual contacts, the web service platform sends a message to the contact notifying them at end user has entered the venue at step 325. The contact is added to a list of contacts within the venue at step 330 so that a single message can be sent to the mobile handset, tablet device, or wearable device of the end user. If more contacts exist to be identified as mutual or not mutual at step 335, the method returns to step 320. Hence, steps 320-330 are repeated for each of the user's contacts in the venue. A single message is sent to end user listing all the mutual contacts that are currently within the venue at step 340, and end user can view the location of all contacts on a map at step 345 that authorized their location to be shared on the map. An example user interface for this step on a mobile handset is shown in FIG. 5C. FIG. 5C illustrates how an end user would access a map view to see where their mutual contacts are located on the map.

For contacts on an end user's contact list that do not have a mutual connection and have been authorized by user to receive notifications, a message is sent to the contact at step 350 informing them that the end user is within the venue and asking them if they want to allow that user to be notified that they are within the venue and/or view their location. An exemplary user interface for this operation is shown in FIG. 5B.

If the contact authorizes the user at step 355, the message is sent at step 340 to end user informing them that their contact is within the venue. Additionally, the contact will now visible on end user's map at step 345. An exemplary user interface for this step is shown in FIG. 5D.

Embodiments of the present invention may check for end user contacts on a user contact list at step 315. These checks may be periodic. For example, they may occur while the user remains within the venue in order to identify end user to additional contacts who enter the venue after end user entered.

FIG. 4 is a method 400 for coordinating a meeting point at a venue. The method 400 of FIG. 4 may be implemented by an end user with a mobile handset, tablet device, or wearable device that connect to a web service platform as might be executing at application server 125 in conjunction with an application installed on the mobile handset, tablet device, or wearable.

A shared map is displayed on a user handset or other mobile device at step 405. End user may open the application on mobile handset, tablet device, or wearable device and display a shared map showing both end user's location and the location of all mutual contacts within the venue. A rally point may be created at step 410. End user may, through an interface provided by a mobile device application, provide input to create a rally point at any location within the venue, at a selected point of interest, or an optimal rally point based on the location of the end user and a selected contact or contacts. The user may select the contacts at step 415 that the end user wants to meet at the rally point.

If the end user chooses the optimal rally point location, travel time is calculated at step 420 by the web services platform, the application running on the mobile device, or a combination of the two. The rally point is the location that has equidistant travel times for all users invited to the rally. Travel time takes into account all transportation methods available to each contact including walking times, movable walkways, elevators, and public transit. An example user interface after an optimal rally point has been created on a mobile device is shown in FIG. 7A.

If an end user creating the rally point provides input to move the rally point location at step 425, new calculations are performed to determine the arrival times of each invitee and adjusting time of the rally at step 430. An example user interface after the rally point has been moved is shown in FIG. 7B.

The end user creating the rally point can choose to schedule the rally point for as soon as possible at step 435 or schedule for a future time at step 440. An example user interface for selecting the rally time as soon as possible or scheduled for a future time is shown in FIG. 7C. After configuring the rally point location and time, the end user may send the rally point to all invitees at step 445. Each invitee will receive a rally point message at step 450 on their mobile device. An exemplary user interface rally point invitation is shown in FIG. 7D.

Each recipient 720/750/755/760 can view the rally point time 725 and location on the map 730, directions to the rally point 780, the current location of all other users invited to the rally, the estimated travel time of each invitees 710 (including themselves 720), and whether each invitee has seen and accepted the rally request. The invitee can choose to accept the rally at step 455, reject the rally at step 455 and propose an alternate rally point or time at step 465, or send a message to the rally creator at step 470. An example of this user interface is shown in FIG. 7E. In FIG. 7E, element 750 shows a user (“Jack”) who has accepted the rally, element 755 shows a user (“Alison”) who has rejected the rally, and element 760 shows a user (“Caren”) who has not yet responded to the rally.

If the invitee chooses to accept the rally at step 455, they can set a reminder to rally at step 460. The reminder may be for the number of minutes before they need to begin travelling to the rally point that they should be reminded on their mobile device. An exemplary user interface illustrating the same is shown in FIG. 7F.

If an invitee chooses to propose an alternate rally at step 465 the same workflow as the original rally point creation takes place starting with calculating the optimal rally point location and time at step 420. If the invitee accepts the rally at step 455, their mobile device will display a reminder for them to attend the rally at step 475 (head towards the rally point) at the specified number of minutes before their current travel time to the rally point. For instance, if an invitee is 10 minutes from the rally point and has their reminder to rally set to 5 minutes, they would receive the reminder 15 minutes before the scheduled rally time. The timing of this reminder will take into account the end user's current location and not the location where they accepted the rally. This reminder message may be generated by either the application running on the mobile device.

The method 400 discussed with respect to FIG. 4 allows large groups of users to coordinate planning a meeting point taking into account the location and travel time of each member of the group without needing to ask each user explicitly. Further, this solution allows all members of the group to easily know whether the other members of the group have seen the meeting point request and monitor their progress towards the meeting point without needing to contact them directly to ask.

FIGS. 5A-D illustrate exemplary user interfaces for implementing the methods described in the contexts of FIG. 2 and FIG. 3.

FIG. 5A illustrates an exemplary user interface for implementing privacy settings corresponding to particular contacts.

FIG. 5B illustrates an exemplary user interface that displays a notification message identifying that “James Moore” is in a venue.

FIG. 5C illustrates an exemplary user interface that displays a notification message identifying that multiple friends of a user are in a venue.

FIG. 5D illustrates an exemplary user interface that displays a notification message identifying that “Amy White” is in a venue.

FIG. 6 illustrates an exemplary computing system that may be utilized to implement one or more embodiments of the present invention. System 600 of FIG. 6, or portions thereof, may be implemented in the likes of client computers, application servers, web servers, mobile devices, wearable devices, and other computing devices. The computing system 600 of FIG. 6 includes one or more processors 610 and main memory 620. Main memory 620 stores, in part, instructions and data for execution by processor 610. Main memory 620 can store the executable code when in operation. The system 600 of FIG. 6 further includes a mass storage device 630, portable storage medium drive(s) 640, output devices 650, user input devices 660, a graphics display 670, and peripheral device ports 680.

While the components shown in FIG. 6 are depicted as being connected via a single bus 690, they may be connected through one or more internal data transport means. For example, processor 610 and main memory 620 may be connected via a local microprocessor bus while mass storage device 630, peripheral device port(s) 680, portable storage device 640, and display system 670 may be connected via one or more input/output (I/O) buses.

Mass storage device 630, which could be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor 610. Mass storage device 630 can store software for implementing embodiments of the present invention, including the method 200 described in the context of FIG. 2.

Portable storage medium drive(s) 640 operates in conjunction with a portable non-volatile storage medium such as a flash drive or portable hard drive to input and output data and corresponding executable code to system 600 of FIG. 6. Like mass storage device 630, software for implementing embodiments of the present invention (e.g., method 200 of FIG. 2) may be stored on a portable medium and input to the system 600 via said portable storage.

Input devices 660 provide a portion of a user interface. Input devices 660 may include an alpha-numeric keypad, such as a keyboard, for inputting alpha-numeric and other information, or a pointing device, such as a mouse. Input device 660 may likewise encompass a touchscreen display, microphone, and other input devices including virtual reality (VR) components. System 600 likewise includes output devices 650, which may include speakers or ports for displays, or other monitor devices. Input devices 660 and output devices 650 may also include network interfaces that allow for access to cellular, Wi-Fi, Bluetooth, or other hard-wired networks.

Display system 670 may include a liquid crystal display (LCD), LED display, touch screen display, or other suitable display device. Display system 670 receives textual and graphical information, and processes the information for output to the display device. In some instances, display system 670 may be integrated with or a part of input device 660 and output device 650 (e.g., a touchscreen). Peripheral ports 680 may include any type of computer support device to add additional functionality to the computer system. For example, peripheral device(s) 680 may include a modem or a router or other network communications implementation (e.g., a MiFi hotspot device).

The components illustrated in FIG. 6 are those typically found in computer systems that may be suitable for use with embodiments of the present invention. In this regard, system 600 represents a broad category of such computer components that are well known in the art. System 600 of FIG. 6 can be a personal computer, hand held computing device, smart phone, tablet computer, mobile computing device, wearable, workstation, server, minicomputer, mainframe computer, or any other computing device.

System 600 can include different bus configurations, network platforms, processor configurations, and operating systems, including but not limited to Unix, Linux, Windows, iOS, Palm OS, and Android OS. System 600 may also include components such as antennas, microphones, cameras, position and location detecting devices, and other components typically found on mobile devices. An antenna may include one or more antennas for communicating wirelessly with another device. An antenna may be used, for example, to communicate wirelessly via Wi-Fi, Bluetooth, with a cellular network, or with other wireless protocols and systems. The one or more antennas may be controlled by a processor, which may include a controller, to transmit and receive wireless signals. For example, processor execute programs stored in memory to control antenna transmit a wireless signal to a cellular network and receive a wireless signal from a cellular network. A microphone may include one or more microphone devices which transmit captured acoustic signals to processor and memory. The acoustic signals may be processed to transmit over a network via antenna.

FIGS. 7A-F illustrate exemplary user interfaces for implementing the described in the context of FIG. 4.

FIG. 7A illustrates an exemplary user interface with a map view that identifies an optimal rally point, a user location, and locations of several contacts.

FIG. 7B illustrates an exemplary user interface with a map view that identifies a moved rally point.

FIG. 7C illustrates an exemplary user interface with a map view that identifies options for scheduling a rally time.

FIG. 7D illustrates an exemplary user interface that displays a rally point invitation.

FIG. 7E illustrates an exemplary user interface with a map view that identifies options for accepting an identified rally time or proposing an alternative rally time.

FIG. 7F illustrates an exemplary user interface allowing a user to set a reminder to trigger when the user needs to begin travelling to the rally point.

The foregoing detailed description of the technology herein has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the technology and its practical application to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the technology be defined by the claims appended hereto.

VENUE NOTIFICATIONS

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

CROSS-REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)