Waiting time recommendation device

Abstract

To provide a method for determining whether wait times for attractions of a theme park are shorter or longer than expected and notifying guests of these shorter or longer wait times, a wait time recommendation system and a computer readable medium.SOLUTION: A method determines a wait time value for an attraction by dividing a wait time for the attraction of a theme park by a total wait time for all attractions of the theme park, and compares the wait time value to one or more threshold values based on an expected wait time for the attraction. In this manner, theme park guests may make a more informed decision on which attraction to wait for, and maximize their time at the theme park.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates generally to attraction wait times. More specifically, embodiments of the present disclosure relate to determining expected shorter or longer attraction wait times and notifying guests of these shorter or longer wait times. [Background technology]

[0002] This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present technology described and / or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of various aspects of the present disclosure. As such, it should be understood that these statements are to be read in this light, and not as admissions of prior art.

[0003] Many venues or service providers, such as theme parks, restaurants, ticket sellers, and government agencies, may involve lines or queues for customers to obtain service. For example, a theme park may include multiple attractions, each with at least one line. Thus, each line for each attraction may have its own wait time. A theme park guest may decide which attraction to attend based on several factors, such as attraction preferences, distance to the attraction, time of day, weather, and the wait time (or length) of each line. In some cases, the wait times may be provided via a software application on the guest's mobile device, but any suitable device may be used to display or communicate the wait times, such as on signage inside the theme park, on signage at each attraction, on a posting on a website associated with the theme park, or through messaging via a chatbot on a messaging platform. Summary of the Invention [Problem to be solved by the invention]

[0004] However, assuming more information is available, such as whether the wait times for each line are shorter or longer than the typical or expected wait times, guests may be able to make better informed decisions regarding which attractions to attend. [Means for solving the problem]

[0005] Certain embodiments commensurate in scope with the originally claimed subject matter are summarized below. These embodiments are not intended to limit the scope of the disclosure; rather, these embodiments are intended merely to provide a brief summary of certain disclosed implementations. Indeed, the disclosure may encompass a variety of forms that may be similar to or different from the embodiments set forth below.

[0006] The present disclosure provides systems and methods for determining whether wait times for attractions are shorter or longer than expected and notifying guests of these shorter or longer wait times. Specifically, a theme park may include multiple attractions, each with at least one queue. Accordingly, each queue for each attraction may include or be associated with a respective wait time at a given time. The respective wait times may be notified to guests via a software application on the guest's mobile device, which may display information and tools related to the theme park, such as operating hours, attraction status, and attraction wait times; however, any suitable device may be used to display or communicate this information, such as signage within the theme park, signage at each attraction, postings on a website related to the theme park, or messaging via a chatbot on a messaging platform.

[0007] The wait time recommendation system can use historical wait time data, including wait times for attractions within the amusement park, which is used to determine historical, expected, or typical wait times for individual attractions. These wait times can be provided per attraction and / or as a percentage of the total wait time for all attractions collectively. In one embodiment, the expected wait time can be expressed as the expected proportion or percentage of the total wait time for the amusement park that an individual attraction will account for (e.g., a single attraction can account for 5% to 7% of the total expected wait time for the amusement park). The wait time recommendation logic of the wait time recommendation system can determine the most recent or current wait time value.

[0008] In one embodiment, attraction wait time values ​​are based on the relationship between the current wait time of an individual attraction and the total wait time of all attractions in the theme park. The current wait time of an attraction, or a calculated wait time value representing the relationship of the current wait time of an attraction to the total wait time of all attractions, can be compared to historical data to determine whether any individual attractions are outside of an expected range, e.g., have a wait time that is longer or shorter than expected. For example, if an individual attraction typically accounts for at least 5% of the typical total park wait time, a current wait time that accounts for less than 5% of the most recent total park wait time can be considered shorter than the expected wait time. In another embodiment, the current wait time can be directly compared to historical wait times, which provides a given context for assessing whether the current wait time is shorter or longer than expected. That is, rather than comparing the current wait time to an overall average historical wait time, the historical wait times used for comparison can be selected from a subset of data points from the same day or the same park crowd (e.g., using all park guests for that day).

[0009] If the wait time recommendation logic determines that the wait time value is less than the short wait time threshold (e.g., a ratio or percentage), the wait time recommendation logic can send a notification to a software application on the guest's mobile device that the wait time is shorter than expected. If the wait time recommendation logic determines that the wait time value is greater than the long wait time threshold (e.g., a ratio or percentage), the wait time recommendation logic can send a notification to a software application on the guest's mobile device that the wait time is longer than expected. The short wait time threshold and the long wait time threshold can be based on the expected wait time ratio for the attraction. The expected wait time value can be determined based on historical wait time data for the attraction and theme park, date or time information (e.g., time of day, day of the week, week of the year, or season), weather, attraction characteristics (e.g., whether the attraction is outdoors or indoors), whether the attraction is open or closed (e.g., over a range of time), or holiday or event dates (e.g., holidays such as Thanksgiving or Christmas, school holidays such as spring break, or religious holidays such as Easter). Guests can then use the notification about whether the wait time is shorter or longer than expected as a factor in deciding whether or not to wait in line for an attraction.

[0010] In one embodiment, a wait time recommendation system includes a processor, a memory, and communications circuitry. The memory stores instructions that, when executed by the processor, cause the processor to receive current wait times for theme park attractions and determine a wait time value based on a relationship between the current wait time for the individual attraction and a current total wait time for the theme park attractions. The instructions also cause the processor to generate a wait time recommendation for the individual attraction based on a comparison of the wait time value to a wait time threshold for the individual attraction. The communications circuitry can then send an indication of the wait time recommendation to a wait time recommendation software application on a mobile device.

[0011] In another embodiment, a tangible, non-transitory computer-readable medium includes instructions for generating wait time recommendations for theme park attractions. The instructions, when executed by a processor, cause the processor to receive a total wait time for the theme park attractions, receive a wait time for the attraction, and compare the wait time or wait time value for the attraction to a threshold value associated with the attraction. The wait time value is based on the total wait time and the wait time for the attraction. The instructions also cause the processor to send a notification based on the comparison.

[0012] In yet another embodiment, a method for generating wait time recommendations includes receiving wait times for attractions at a theme park and determining a wait time value for each individual attraction based on the wait times. The method also includes comparing the wait time value for each individual attraction to a wait time threshold for each individual attraction and identifying a subset of attractions having wait time values ​​indicative of a shorter than expected wait time based on the comparison. The method further includes sending a notification including an indication of the subset.

[0013] These and other features, aspects, and advantages of the present disclosure will become better understood from the following detailed description when taken in conjunction with the accompanying drawings, in which like numerals refer to like parts throughout. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a block diagram of a wait time recommendation system according to an embodiment of the present disclosure. [Figure 2] 1 is a flowchart of a process for generating wait time recommendations for theme park attractions based on the total wait times of multiple attractions at the theme park, according to an embodiment of the disclosure. [Figure 3]1 is a flowchart of a process for generating wait time recommendations for theme park attractions based on park attendance, according to an embodiment of the present disclosure. [Figure 4] 1 is an example screenshot of a theme park software application used to provide theme park information to theme park guests, according to an embodiment of the present disclosure. [Figure 5] 5 is an example screenshot of the total wait times page of the theme park software application of FIG. 4 with a graphical notification of shorter than normal wait times, according to an embodiment of the present disclosure. [Figure 6] 5 is another example screenshot of the total wait times page of the theme park software application of FIG. 4 with a text-based indication of shorter than normal wait times, according to an embodiment of the present disclosure. [Figure 7] 5 is yet another example screenshot of the total wait times page of the theme park software application of FIG. 4, in which the queue wait time for an attraction transitions to a shorter wait time than normal, in accordance with an embodiment of the present disclosure. [Figure 8] 10 is an example screenshot of a chat interface capable of providing wait time recommendations, according to an embodiment of the present disclosure. [Figure 9] 10 is an example screenshot of an employee dashboard that can provide wait times and wait time recommendations, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0015] The present disclosure provides systems and methods for determining shorter or longer than expected wait times for attractions and notifying guests of these shorter or longer wait times. Specifically, a theme park may include multiple attractions, each with at least one queue. Accordingly, each queue for each attraction may be associated with a respective wait time. The respective wait times may be provided to guests, for example, via a software application on the guest's mobile device or via a display board within the theme park. In some cases, the theme park may provide guests with a software application that can display information and tools related to the theme park, such as operating hours, attraction status, and attraction wait times.

[0016] The wait time recommendation system can provide a notification based on determining whether the attraction wait time is shorter or longer than expected, for example, by comparing the attraction wait time with historical wait time data for the attraction. The historical wait time data can take into account date or time information (e.g., time of day, day of the week, week of the year, or season), weather, attraction characteristics (e.g., whether the attraction is outdoors or indoors), whether the attraction is open or closed (e.g., over a range of time), or holiday or event dates (e.g., holidays such as Thanksgiving or Christmas, school holidays such as spring break, or religious holidays such as Easter), weather information (e.g., related to temperature, humidity, chance or amount of rain, chance of natural disasters, or the like), parades, shows, or other nearby performances, or any other suitable information that can affect or distort the wait time. Guests can then use the notification of whether the wait time is shorter or longer than expected as a factor in deciding whether to wait in line for the attraction. In this way, guests can make more informed decisions about which attractions to wait for and maximize their time at the theme park. Furthermore, theme park operations can become more efficient because they can distribute guests more evenly among attractions. That is, the disclosed techniques can alert guests when one or more attractions are underserved, thereby facilitating a reallocation of guests to the underserved attraction or attractions. While this disclosure describes embodiments with respect to theme parks and attractions, it should be noted that the systems and methods of this disclosure can be applied to any suitable venue, such as a restaurant, ticket vendor, government agency, or the like, for analyzing queue wait times.

[0017] The disclosed techniques provide improved context for guest wait time estimates. For example, if the wait time for a particular ride is 35 minutes, this wait time may be longer than expected for that ride if the amusement park is relatively empty or on a rainy day, but may be shorter than expected on a busy / sunny day. Furthermore, ranking rides by estimated wait time does not provide guests with information about which rides tend to be busier or which are more popular. By providing a quality rating of wait times for each ride (e.g., shorter than expected, longer than expected), guests can determine which rides are worth the wait and feel like they're getting a bargain, even for rides with long absolute wait times compared to other rides in the park, improving the guest experience and customer satisfaction.

[0018] FIG. 1 is a block diagram of a latency recommendation system 10 according to an embodiment of the present disclosure. The latency recommendation system 10 comprises a controller 12 including one or more processors 14 and one or more memory devices 16. The processor 14 may execute software programs and / or instructions to determine latency recommendations. Additionally, the processor 14 may include multiple microprocessors, one or more “general-purpose” microprocessors, one or more special-purpose microprocessors, and / or one or more application-specific integrated circuits (ASICs), and / or one or more reduced instruction set (RISC) processors. The memory device 16 may include one or more storage devices and may store machine-readable and / or processor-executable instructions (e.g., firmware or software) for execution by the processor 14, such as instructions related to determining latency recommendations. Thus, the memory device 16 may store, for example, control software, lookup tables, configuration data, etc. to facilitate determining latency recommendations. In some embodiments, the processor 14 and the memory device 16 may reside external to the controller 12. Memory device 16 may include tangible, non-transitory machine-readable media such as volatile memory (e.g., random access memory (RAM)) and / or non-volatile memory (e.g., read-only memory (ROM), flash memory, a hard drive, and / or any other suitable optical, magnetic, or solid-state storage medium).

[0019] The controller 12 may employ wait time recommendation logic that determines wait time recommendations for theme park attractions 34. Specifically, the wait time recommendation may include an indication that the wait time is shorter than expected, longer than expected, or as expected. The wait time recommendation may also include an expected (e.g., typical or normal) wait time and an indication of how much shorter or longer the wait time is than expected (e.g., presented in total time, such as minutes saved or additional wait time, or presented as a percentage (e.g., 10% shorter or longer than normal)). It should be understood that the term “logic” as used in this disclosure may include hardware (e.g., circuitry), software (e.g., instructions executed by the processor 14 and stored in the memory 16), or a combination of the two. The wait time recommendation logic may use historical wait time data 22 as input. The historical wait time data 22 may be stored in the memory 16 and / or provided in a database. For example, the wait time recommendation system 10 may include a database that stores historical wait time data 22 and returns the requested historical wait time data 22 in response to receiving a query from the wait time recommendation logic.

[0020] In one embodiment, the wait time recommendation logic can determine a wait time recommendation by determining a wait time value for an attraction. The wait time value can represent the ratio of the current wait time for an attraction to the total wait time for all attractions in the theme park. Thus, the wait time recommendation logic can determine a wait time value by dividing the current wait time for an attraction by the current total wait time for all attractions, such as at the current time or within a rolling time window. The wait time value can be compared to one or more historical wait time values ​​calculated in the same manner but using historical wait time data 22. The historical total wait time can be an average of the total wait times for all attractions over some suitable time period or using a subset of historical wait time data points based on the contextual information provided herein (e.g., time points over a day, a week, a season, or a year). In some embodiments, the historical total wait time can be an average of the total wait times for a period corresponding to the current time or day for which a wait time recommendation is requested. For example, the historical total wait time may be an average of total wait times corresponding to the same dates (across multiple years), the same time of day (across multiple dates), similar weather (across multiple dates), similar characteristics (e.g., weekend wait times, holiday wait times, or parades, shows, or other nearby events), similar attraction conditions (e.g., an attraction being closed), or any other similar suitable information that may affect wait times. Additionally, factors that may distort the historical total wait time may be accounted for, such as by adjusting the distorted historical total wait time to compensate for the distorting factors.

[0021] The wait time recommendation logic may then compare the wait time value to an expected or historical wait time value. The expected (e.g., typical or normal) wait time value may be a ratio based on historical wait time data for the attraction and theme park, date or time information (e.g., time of day, day of the week, week of the year, or season), weather, and / or characteristics of the attraction (e.g., whether the attraction is outdoors or indoors). For example, the expected or historical wait time value may be the expected wait time for the attraction divided by the total wait time for all attractions (associated with this expected wait time). The expected wait time for the attraction may be provided by the historical wait time data 22. In one embodiment, if the wait time value is less than the expected wait time value, the wait time recommendation logic may notify the guest's mobile device 24 that the wait time for the attraction is shorter than expected. On the other hand, if the wait time value is greater than the expected wait time value, the wait time recommendation logic may notify the guest's mobile device 24 that the wait time is longer than expected. If the latency value is greater than or equal to and less than the expected latency value, the latency recommendation logic may determine that the latency is as expected.

[0022] In some embodiments, the wait time recommendation logic may use a threshold value (e.g., a ratio, percentage, or duration) to compare the wait time value to the expected wait time value. As an example, the expected or historical wait time for an attraction may be 60 minutes, where the total historical wait time for all attractions is 600 minutes. Thus, the expected or historical wait time value may be 60 / 600, or 10%. If a 5% deviation is used to set the short wait threshold, the short wait threshold may be defined as 5% (i.e., 10% to 5%). Thus, the wait time recommendation logic may send a notification to the guest mobile device 24 that the wait time is shorter than expected if the wait value is less than 5%. A long wait threshold may be similarly defined and applied. The deviation used for the short wait threshold and the long wait threshold may be any suitable deviation ranging from 1% to 50%. Furthermore, in some embodiments, the thresholds may be customizable (e.g., by the developer, the theme park, or the guest). In some embodiments, the wait time recommendation logic may compare wait time values ​​to expected wait time values ​​without using a threshold. For example, the wait time recommendation logic may determine all deviations for all wait times from the expected wait times for all attractions. The wait time recommendation logic may then display all wait times or a subset of wait times (e.g., the top 10, top 5, top 3, or any suitable top number) that deviate the most from their respective expected wait times.

[0023] While this disclosure uses values ​​to determine wait time recommendations, it should be understood that any suitable numerical representation of wait time can be used, including the wait time itself. For example, in some cases, historical wait time data 22 can receive a current wait time for each attraction, which can be compared to an expected wait time or historical wait time (or a subset of historical wait times based on context, e.g., only wait times from past weekends, only wait times from past Tuesdays, etc.) to determine a wait time recommendation. For purposes of this example, if the expected wait time for an attraction is 60 minutes and a 10-minute threshold deviation is used to set the short wait threshold, then the short wait threshold is 50 minutes (i.e., 60 minutes - 50 minutes). Thus, the wait time recommendation logic can send a notification to the guest mobile device 24 that the wait time is shorter than expected if the wait time is less than 50 minutes. A long wait threshold can be similarly defined and applied.

[0024] The expected wait time value may be determined and / or adjusted based on historical wait time data for the attraction and theme park, and any appropriate context information. Specifically, the wait time recommendation logic may obtain or receive context information, for example, based on a date or time corresponding to when a wait time recommendation is requested. The context information may include date or time information (e.g., time of day, day of the week, week of the year, or season), holiday or event dates (e.g., holidays such as Thanksgiving or Christmas, school holidays such as spring break, or religious holidays such as Easter), weather information (e.g., related to temperature, humidity, probability or amount of rain, probability of natural disasters, or the like), attraction characteristics (e.g., whether the attraction is outdoors or indoors), parades, shows, or other nearby events, the geographic location of the mobile device 24 or the proximity between the attraction and the mobile device 24, and / or any other appropriate information that may affect or distort the wait time. In some embodiments, the controller 12 may be programmed to obtain the appropriate or requested context information. In alternative or additional embodiments, the context information may be received from a variety of sources, such as a calendar software application, a weather software application, and / or a location software application.

[0025] As an example of wait time recommendation logic using context information, the wait time recommendation logic may determine an expected wait time value for a particular date by averaging historical expected wait time values ​​associated with that date in prior years. As another example, the wait time recommendation logic may determine an expected wait time value for a particular hour by averaging historical expected wait time values ​​for that hour over the past 30 days. As yet another example, the wait time recommendation logic may determine an expected wait time value for a particular hour by averaging historical expected wait time values ​​obtained when weather conditions substantially match the weather conditions at the particular hour (e.g., when the temperature is approximately the same (e.g., within 1 to 5 degrees Fahrenheit), the humidity is approximately the same, the amount of rain is approximately the same, etc.). Thus, the wait time recommendation logic may consider or adjust the expected wait time value based on the date, time, weather, characteristics of the attraction, or any other suitable factors that may distort the expected wait time value. For example, if historical wait time data 22 corresponds to one or more attractions in a theme park that are closed, the historical wait time data 22 may be skewed (wait times will not be associated with the closed attractions, causing the remaining attractions to have inflated wait time values). In such cases, the wait time recommendation logic may estimate wait times for the closed attractions (e.g., based on historical wait time data 22) to compensate for the closed attractions. Alternatively, the wait time recommendation logic may not use historical wait time data 22 corresponding to closed attractions (or existing attractions that are no longer in operation). Although this disclosure describes that the wait time recommendation logic can determine expected wait times, it should be understood that any suitable logic (e.g., external to the wait time recommendation logic) can determine expected wait times.

[0026] If the wait time recommendation logic determines that the wait time is shorter than expected, longer than expected, or as expected, the wait time recommendation logic may send a corresponding instruction or notification to the guest's mobile device 24 via the communications network 28. The communications network 28 may be wired and / or wireless, and the communications network may enable the wait time recommendation logic to communicate with and / or send instructions or notifications to the guest's mobile device 24 via any suitable communications protocol. For example, the communications network 28 may include a wireless network, such as a mobile network, WiFi, a LAN, a WAN, the Internet, and / or the like.

[0027] Mobile device 24 may store and execute a wait time recommendation software application 30 that enables mobile device 24 to display wait times and wait time recommendations for theme park attractions. It should be understood that certain features of system 10 may be duplicated or interchanged. For example, wait time recommendation software application 30 may be stored in memory (e.g., sharing certain features of memory 16) and executed by a processor of mobile device 24 (e.g., sharing certain features of processor 14). Mobile device 24 may communicate with controller 12 via communications network 28 using communications circuitry 33 (e.g., sharing certain features of communications circuitry 17).

[0028] Additionally, wait time recommendation system 10 includes a plurality of attractions 34 under the control of attraction information system 35, which communicate with controller 12 via communications network 28 using communications circuitry 36. Historical wait time data 22 can be updated using wait time data from each individual attraction 34 and stored as historical wait time data 22 and as input used by controller 12 to obtain current wait times for the individual attractions 34, which can then be used to determine an overall or total current wait time for all attractions (e.g., by summing all of the current wait times for the attractions 34). In some embodiments, wait time data can be determined manually. For example, a theme park employee can monitor wait times for attractions at the theme park and input or send the wait times to attraction information system 35 and / or controller 12.

[0029] The attraction information system 35 may include memory (e.g., sharing certain features of memory 16) and may be under processor control (e.g., sharing certain features of processor 14). The attractions may also include one or more sensors 38 that generate data used to determine current wait times for individual attractions 34. In one embodiment, the sensors 38 may include guest tracking sensors (e.g., barcode or optical readers, NFC readers) that read identifying information from the mobile devices 24 upon entry into the attraction queue and as each guest enters and exits the queue at the attraction itself. In one embodiment, the current wait time for each attraction 34 may be the average wait time for the last N guests (e.g., the last 10 guests, the last 50 guests). In another embodiment, the sensors 38 may include a camera or image sensor that uses queue image data to estimate queue length and then estimates the current wait time based on the estimated queue length.

[0030] The wait time recommendation application 30 may receive wait time recommendation information (e.g., wait time recommendation instructions or notifications) from the wait time recommendation logic and display wait time recommendations based on the wait time recommendation information. In some embodiments, the wait time recommendation application 30 may be part of a larger software application, such as a software application used to provide theme park information to theme park guests. The mobile device 24 may be any suitable electronic device that receives wait time recommendations, including a smartphone, a wearable device, a laptop, a tablet, etc. In some embodiments, the mobile device 24 may instead be any other suitable device that can display or communicate respective wait times, such as on signage inside the theme park, on signage at each attraction, on a posting on a website related to the theme park, or through messaging via a chatbot on a messaging platform.

[0031] In some embodiments, the wait time recommendation application 30 may provide and / or display wait time recommendations based on user context information provided via a user interface or user input device 32 of the mobile device 24. The user context information 32 may include any suitable information that may facilitate providing a more appropriate display of wait time recommendations. Specifically, the user context information 32 may include the guest's or their associate's user preferences (e.g., relating to which attractions the guest or guest's associate desires to attend or not attend, or which attractions the guest or guest's associate is or is not eligible to attend based on the age or height of the guest or member of the guest's associate), location information (e.g., of the mobile device 24 provided by location-determining logic such as Global Positioning System (GPS) hardware and / or software), and / or the like. For example, the wait time recommendation application 30 may evaluate wait times or display / push wait times only for those attractions that satisfy the user preferences and / or are within a threshold distance from the location of the mobile device 24. In one embodiment, a guest can set or configure what user context information 32 is provided and / or used to determine how wait time recommendations are determined and / or displayed. A guest can then use the notification about whether the wait time is shorter or longer than expected as a factor in deciding whether to wait in line for an attraction.

[0032] 2 is a flowchart of a process 40 for generating wait time recommendations for theme park attractions based on the total wait times for multiple attractions at the theme park, in accordance with an embodiment of the present disclosure. Specifically, wait time recommendation system 10 may execute process 40 to generate wait time recommendations. Process 40 may be in the form of one or more software applications including instructions executed by at least one suitable processor, such as processor 14 of wait time recommendation system 10, via wait time recommendation logic. The illustrated process 40 is presented merely by way of example; in other embodiments, certain illustrated steps of process 40 may be performed in a different order, skipped, repeated, or not depicted in FIG. 3, in accordance with the present disclosure.

[0033] As shown, at process block 42, processor 14 receives total wait times for a plurality of attractions at a theme park. The plurality of attractions at a theme park may include all attractions at the theme park or all attractions at an operating theme park. The total wait time may be an average of the total wait times at all attractions over any suitable period of time (e.g., a day, a week, a season, or a year). Specifically, the total wait time may be provided by historical wait time data 22. In some embodiments, the total wait time may be an average of the total wait times for a period corresponding to the current time or day for which a wait recommendation is requested. For example, the total wait time may be an average of the total wait times corresponding to the same date (across years), the same time of day (across dates), similar weather (across dates), and / or other similar characteristics.

[0034] In some embodiments, processor 14 may consider or adjust the total wait time based on the date, time, weather, attraction characteristics, or any other suitable factors that may distort expected wait time values. For example, if historical wait time data 22 corresponds to one or more attractions in a theme park that are closed, historical wait time data 22 may be skewed (wait times will not be associated with the closed attractions, causing the remaining attractions to increase wait time values). In such cases, wait time recommendation logic may estimate wait times for the closed attractions (e.g., based on historical wait time data 22) to compensate for the closed attractions. Alternatively, wait time recommendation logic may not use historical wait time data 22 corresponding to closed attractions (or existing attractions that are no longer operating).

[0035] At process block 44, processor 14 receives the wait time for the attraction. For example, the wait time may be provided by a timer or counter on attraction 34 or may be entered manually.

[0036] At process block 46, processor 14 determines a wait time value for the attraction based on the total wait time for all attractions in the theme park and the wait time for the attraction. The wait time value may represent a ratio of the wait time for the attraction to the total wait time for all attractions in the theme park. Specifically, the wait time recommendation logic may determine the wait time value by dividing the wait time for the attraction by the total wait time for all attractions. The wait time value may be expressed as a fraction, decimal, or percentage.

[0037] At decision block 48, processor 14 determines whether the wait time value is less than a short wait time threshold. The short wait time threshold may be based on the expected wait time value for the attraction. The expected (e.g., typical or normal) wait time value may be a ratio based on historical wait time data for the attraction and theme park, date or time information (e.g., time of day, day of the week, week of the year, or season), weather, and / or characteristics of the attraction (e.g., whether the attraction is outdoors or indoors). For example, the expected wait time value may be the expected wait time for the attraction divided by the total wait time for all attractions (associated with this expected wait time). The expected wait time for the attraction may be provided by historical wait time data 22. The short wait time threshold may then be determined by subtracting the threshold period from the expected wait time. The threshold period can be any suitable period (e.g., 30 seconds to 30 minutes, 1 minute, 5 minutes, or 10 minutes) or a threshold percentage (e.g., in the range of 0.1% to 10% or 1% to 5%).

[0038] At process block 50, if the processor 14 determines that the wait time value is less than the short wait time threshold, the processor 14 sends a notification that the attraction has a short wait time. Specifically, the processor 14 can send a notification that the wait time is shorter than expected to the wait time recommendation software application 30 on the guest mobile device 24. In one embodiment, the processor 14 ranks all of the attraction wait times based on a comparison to the expected wait times. For example, the ranking can identify a subset of attractions with optimal values ​​compared to the attractions' expected or historical wait time values. The wait time recommendation system 10 can push the subset of attractions with optimal values ​​via a notification to the guest's mobile device 24. In one embodiment, the ranking can be based on the total minutes saved. For example, if an attraction typically has a 45-minute wait on weekends but the current wait time is 35 minutes, the attraction can be ranked higher than an attraction with a shorter absolute wait time (e.g., 15 minutes) that is 5 minutes shorter than normal.

[0039] If processor 14 determines that the latency value is greater than or equal to the low latency threshold value at decision block 52, then processor 14 determines whether the latency value is greater than the long latency threshold value. The long latency threshold value may be determined by adding a threshold period to the expected latency. Note that the threshold period subtracted from the expected latency to determine the low latency threshold may or may not be equal to the threshold period added to the expected latency to determine the long latency threshold.

[0040] At process block 54, if the processor 14 determines that the wait time value is greater than the long wait time threshold, the processor 14 sends a notification that the attraction has a long wait time. Specifically, the processor 14 may send a notification that the wait time is longer than expected to the wait time recommendation software application 30 on the guest mobile device 24. In some embodiments, if the processor 14 determines that the wait time value is greater than or equal to the short wait time threshold (from decision block 48) and less than or equal to the long wait time threshold, the processor 14 may send a notification to the wait time recommendation software application 30 on the guest's mobile device 24 indicating that the wait time is as expected. The processor 14 may provide multiple recommendations corresponding to multiple attractions. In one embodiment, the processor 14 may list the multiple recommendations in ranked order to prioritize queues with the shortest wait time or the greatest wait time savings when compared to the expected wait time. Processor 14 may not provide any recommendations if the wait time value is greater than or equal to the short wait time threshold and less than or equal to the long wait time threshold (thus indicating that theme park guests are evenly distributed among attractions).

[0041] In some embodiments, processor 14 may compare wait time values ​​to expected wait time values ​​without using a threshold. For example, processor 14 may determine all deviations for all wait times from the expected wait times for all attractions. The wait time recommendation logic may then display all wait times or a subset of wait times (e.g., the top 10, top 5, top 3, or any suitable top number) that deviate the most from their respective expected wait times. In this manner, processor 14 may perform process 40 to generate wait time recommendations for theme park attractions based on the total wait times for multiple attractions at the theme park.

[0042] In some embodiments, wait time recommendations may be generated based on other factors in addition to, or as an alternative to, the total wait time for multiple attractions at a theme park. For example, FIG. 3 is a flowchart of a process 60 for generating wait time recommendations for theme park attractions based on park attendance, according to an embodiment of the present disclosure. Specifically, wait time recommendation system 10 may execute process 60 to generate wait time recommendations. Process 60 may be in the form of one or more software applications including instructions executed by at least one suitable processor, such as processor 14 of wait time recommendation system 10, via wait time recommendation logic. The illustrated process 40 is presented merely by way of example; in other embodiments, certain illustrated steps of process 40 may be performed in a different order, skipped, repeated, or not shown in FIG. 3, according to the present disclosure.

[0043] As shown, at process block 61, processor 14 receives current park attendance figures for the theme park. At process block 62, processor 14 receives one or more historical wait times for attractions for times when the corresponding historical park attendance figures are approximately the current park attendance figures. The one or more historical wait times may be provided by historical wait time data 22. In some embodiments, processor 14 may include or exclude historical wait times associated with skewed historical park attendance figures (e.g., due to attraction closures, weather, holiday or event dates, parades, shows, or other nearby performances, or any other suitable information that may affect or distort wait times). In one embodiment, processor 14 may adjust the historical wait times associated with the skewed historical park attendance figures. Processor 14 may determine that the historical park attendance figures are approximately the most recent park attendance figures if the historical park attendance figures are within a threshold attendance figure of the most recent park attendance figures. The threshold attendance number may be any suitable attendance number (e.g., in the range of 1 to 10,000, 1 to 1,000, or 1 to 100) or any suitable percentage of the most recent amusement park attendance (e.g., in the range of 0.1% to 10% or 1% to 5%).

[0044] At process block 63, processor 14 determines an average historical wait time for the attraction based on one or more historical wait times. That is, processor 14 may average one or more historical wait times for the attraction to determine the average historical wait time. In additional or alternative embodiments, another representative value, such as a median, mode, minimum, or maximum, may be used.

[0045] At process block 64, processor 14 determines a short latency threshold and a long latency threshold based on the average historical latency. The short latency threshold may be determined by subtracting a threshold period from the average historical latency, while the long latency threshold may be determined by adding a threshold period to the average historical latency. The threshold period may be any suitable period (e.g., 30 seconds to 30 minutes, 1 minute, 5 minutes, or 10 minutes) or may be a threshold percentage (e.g., in the range of 0.1% to 10% or 1% to 5%).

[0046] At process block 65, processor 14 receives the wait time for the attraction. For example, the wait time may be provided by a timer or counter on attraction 34 or may be entered manually.

[0047] At decision block 66, processor 14 determines whether the wait time is less than a short wait time threshold. If so, at process block 67, processor 14 sends a notification that the wait time for the attraction is short. Specifically, processor 14 may send a notification that the wait time is shorter than expected to wait time recommendation software application 30 on guest mobile device 24.

[0048] If the processor 14 determines that the wait time is not less than the short wait threshold, then at decision block 68, the processor 14 determines whether the wait time is greater than the long wait threshold. If so, then at process block 69, the processor 14 sends a notification that the wait time for the attraction is long. Specifically, the processor 14 may send a notification that the wait time is longer than expected to the wait time recommendation software application 30 on the guest mobile device 24.

[0049] In some embodiments, if processor 14 determines (from decision block 66) that the wait time value is greater than or equal to the short wait time threshold and less than or equal to the long wait time threshold, processor 14 may send a notification to wait time recommendation software application 30 on guest's mobile device 24 that the wait time is as expected. In this manner, processor 14 may execute process 60 to generate wait time recommendations for theme park attractions based on park attendance.

[0050] With the foregoing in mind, FIG. 4 is an example screenshot of a theme park software application 70 used to provide theme park guests with theme park information, in accordance with an embodiment of the present disclosure. Specifically, theme park software application 70 may be stored and executed on a guest's mobile device 24. As shown, theme park software application 70 may display a menu 72, for example, when a guest selects menu button 74. Menu 72 may display various options, including displaying a total wait time page 76 (titled "Total Wait Times") that displays all wait times for all attractions in the theme park, and a recommended wait time page 78 (titled "Recommended Wait Times") that displays recommended wait times for attractions in the theme park.

[0051] While the total wait time page 76 may display all wait times for all attractions in a theme park, in some embodiments, the page 76 may also display recommended wait times. For example, FIG. 5 is an example screenshot of the total wait time page 76 of the theme park software application 70 of FIG. 4 with a graphical notification of a shorter-than-normal wait time, according to an embodiment of the present disclosure. In some embodiments, the wait time recommendation software application 30 may provide the information displayed on the total wait time page 76. For example, the wait time recommendation software application 30 may be part of the theme park software application 70. The total wait time page 76 displays wait times for attraction lines in a theme park. As shown, line A 90 has a 15-minute wait time 92, line B 94 has a 50-minute wait time 96, and line C 98 has a 25-minute wait time 100. Additionally, the total wait time page 76 may provide a graphical indication 102 to notify guests whether a line has a shorter or longer wait time than normal. For example, the total wait times page 76 displays graphical indications 102 for both queue A 90 and queue C 98 to indicate that these queues have shorter than normal wait times. In some embodiments, the total wait times page 76 may also include instructions to notify guests that the queues have longer than normal wait times. Note that the graphical indications may be provided in any suitable format, such as clip art, pictograms, icons, or the like.

[0052] In some embodiments, the total wait time page 76 can include an option to display preferred wait times, or the theme park software application 70 can include a preferred wait time page that displays wait times for theme park attractions based on guest preferences. For example, the theme park software application 70 can receive guest preferences for particular attractions (e.g., as part of the user context information 32). The theme park software application 70 can then instruct the wait time recommendation system 10 to evaluate only wait times for rides that the guest has indicated they prefer, or to display only wait times for rides that the guest has indicated they prefer. As another example, the theme park software application 70 can receive the location of the mobile device 24 and / or its distance from an attraction (e.g., as part of the user context information 32), and then instruct the wait time recommendation system 10 to evaluate only wait times for rides that are within a threshold distance from the mobile device 24, or to display only wait times for rides that are within a threshold distance from the mobile device 24. In some embodiments, theme park software application 70 may instruct wait time recommendation system 10 to weigh multiple factors, including wait time, the difference between the wait time in line and the expected wait time for that line, guest preferences, and / or the location of mobile device 24, to determine which wait times to display as desirable wait times. Similarly, total wait times page 76 may include any suitable options for sorting or filtering wait times, such as by wait time, the difference between the wait time in line and the expected wait time for that line, the ratio of the difference between the wait time in line and the expected wait time for that line to the expected wait time, or the like.

[0053] As shown in FIG. 5 , the graphic indication 102 can be in the form of an icon or a graphic image. In alternative or additional embodiments, the indication can be in text format. For example, FIG. 6 is another example screenshot of the total wait times page 76 of the theme park software application 70 of FIG. 4 with a text-based indication or marker for a shorter-than-normal wait time, in accordance with an embodiment of the present disclosure. Specifically, FIG. 6 shows a text-based indication or marker 110 (e.g., "Recommended!"). While FIGS. 5 and 6 display the indication in the form of an icon and text, respectively, it should be understood that it is contemplated that the indication 102 can be displayed in any suitable format. For example, the text-based marker 110 can have a different font style (e.g., bold, italic, or capital letters) and / or be displayed differently from other text on the total wait times page 76 (e.g., colored differently or using a blinking effect) to draw attention to the marker 110.

[0054] Additionally, if a queue or attraction wait time changes, for example, from an expected wait time to a state that is shorter than the expected wait time, the theme park software application 70 and / or wait time recommendation software application 30 can provide a larger or more prominent notification (e.g., a push notification) to draw the guest's attention to the change in state. For example, FIG. 7 is yet another example screenshot of the total wait time page 76 of the theme park software application 70 of FIG. 4 when a queue wait time transitions to a shorter-than-normal wait time, in accordance with an embodiment of the present disclosure. As shown, Queue A 90 transitions from an expected wait time to a shorter-than-normal wait time. Accordingly, a notification prompt 120 is displayed to notify the guest of this transition. Specifically, the wait time recommendation system 10 can "push" or activate this notification prompt 120 for display on the mobile device 24. The notification prompt 120 also allows the guest to indicate that they intend to join queue A 90 by clicking a "GO" button 122, or that they do not intend to join queue A 90 by clicking a "CANCEL" button 124. In this manner, theme park software application 70 and / or wait time recommendation software application 30 can provide wait time recommendations to the guest.

[0055] In some embodiments, the wait time recommendation may be provided via a chat or messaging interface (e.g., stored and executing on mobile device 24). For example, FIG. 8 is an example screenshot of a chat interface 130 that may provide wait time recommendations according to embodiments of the present disclosure. Chat interface 130 may be provided by any suitable chat or messaging platform, such as a short message service, a messaging software application, an instant messaging software application, a component of wait time recommendation software application 30, or a component of theme park software application 70, running on mobile device 24. Chat interface 130 may communicate with a bot (e.g., a chatbot) or other suitable software application or artificial intelligence that is operated, for example, by processor 14 and that converses with guests via text (or audible) communications provided by wait time recommendation logic.

[0056] The chat interface 130 can respond to a request from a guest to provide wait time recommendations via the wait time recommendation system 10. For example, a guest can send a message 132 requesting the "best" queue (e.g., "Which queue is currently best?"). The chatbot can query the wait time recommendation system 10 for the queue with the shortest wait time, where the difference between the wait time in the queue (most recent) and the expected wait time for that queue is the greatest, or the ratio between the wait time in the queue and the expected wait time for that queue is the greatest, and display a response 134 indicating the results.

[0057] In some embodiments, the chatbot can incorporate guest preferences for a particular attraction (e.g., as part of the user context information 32) into the chatbot's response 134. For example, the chatbot can instruct the wait time recommendation system 10 to only evaluate wait times for rides that the guest indicated as preferred, or to only respond to wait times for rides that the guest indicated as preferred. As another example, the chatbot can incorporate the mobile device's location and / or distance from the attraction (e.g., as part of the user context information 32) into the chatbot's response 134. Specifically, the chatbot can instruct the wait time recommendation system 10 to only evaluate wait times for rides that are within a threshold distance from the mobile device 24, or to only respond to wait times for rides that are within a threshold distance from the mobile device. In some embodiments, the chatbot can instruct the wait time recommendation system 10 to weigh multiple factors, including wait time, the difference between the wait time in line and the expected wait time for that line, guest preferences, and / or the location of the mobile device, to determine the “optimal” queue. As shown, the chatbot's response 134 indicates which queue is "optimal" as well as the difference between the wait time in the queue and the expected wait time for that queue (e.g., "Queue A is currently optimal at 25 minutes, 20 minutes shorter than usual").

[0058] As another example, a guest can send a message 136 requesting wait times for all lines (e.g., What are the wait times for all lines?). The chatbot can query the wait time recommendation system 10 for wait times for all lines at the theme park, as well as an indication of whether any wait times are shorter than expected, and display a response 138 indicating the results. As shown, the chatbot's response 138 displays wait times for all lines, as well as lines with shorter wait times than expected or "short waits" (e.g., "Queue A: 25 minutes - short wait!; Queue B: 40 minutes; Queue C: 30 minutes; Queue D: 15 minutes - short wait!").

[0059] A guest can also send a message 140 requesting the wait time for a particular queue (e.g., "What is the wait time for queue E?"). The chatbot can query the wait time recommendation system 10 about the wait time for this queue and an indication of whether the wait time is shorter than expected, longer than expected, or as expected, and display a response 142 indicating the results. As shown, the chatbot's response 142 displays the wait time for the requested queue and an indication that the wait time is longer than expected (e.g., "The wait time for queue E is 55 minutes. This wait time is 20 minutes longer than normal!"). While FIG. 8 is shown in the form of a chat or messaging interface, it should be understood that the disclosed techniques may be applied to any other suitable form of communication associated with artificial intelligence or bots (e.g., chatbots), such as virtual assistants or smart speakers.

[0060] A guest services employee (e.g., at a theme park) may also use a software application or interface that allows the guest services employee to view wait times and wait time recommendations. For example, FIG. 9 is an example screenshot of an employee dashboard 150 that can provide wait times and wait time recommendations according to an embodiment of the present disclosure. The employee dashboard 150 may be provided by any suitable platform, such as the wait time recommendation software application 30, the theme park software application 70, or a standalone employee dashboard software application running on any suitable electronic device, such as a theme park or guest services employee computing device (e.g., a desktop computer, laptop, tablet, smartphone, or wearable device).

[0061] As shown, employee dashboard 150 can display attraction queue wait times in a "Total Wait Time" window 152. Employee dashboard 150 can also display wait time recommendations in a "Recommended Wait Time" window 154. In this manner, employee dashboard 150 can enable guest service employees to quickly and conveniently retrieve information related to wait times and / or the most efficient, convenient, and / or time-saving attractions for waiting in line. In practice, employee dashboard 150 can enable guest service employees, for example, via a service desk or roaming employees, to contact guests to recommend attraction wait times, providing a human touch and helpful information to guests. As further shown, employee dashboard 150 can also display other convenient information that guests may request or that can facilitate providing service to guests, such as weather updates 156, theme park ticket plan pricing details 158, emergency contact numbers 160, and news and other information 162.

[0062] Although the disclosed embodiments illustrate recommendations for the same type of queue (e.g., regular ticket holder or cancellation queues), the present disclosure contemplates that the disclosed techniques apply to different types of queues, such as express queues, season ticket holder queues, VIP queues, and / or disabled access queues. Specifically, wait time recommendations can be provided for these other types of queues and / or can take into account additional wait times based on these other types of queues.

[0063] The technology shown and claimed herein refers to and applies to tangible objects and specific examples of a practical nature that will materially improve the art, and thus are not abstract, intangible, or purely theoretical. Furthermore, where any claim appended at the end of this specification contains one or more elements designated as "means for [performing] ... [function]" or "step for [performing] ... [function]," such elements are to be construed pursuant to 35 U.S.C. 112(f). Conversely, for any claim containing elements designated in any other manner, such elements are not to be construed pursuant to 35 U.S.C. 112(f).

Claims

1. 1. A method for generating latency recommendations, comprising: receiving theme park attendance figures via a processor; receiving, via the processor, a plurality of historical wait times for attractions among a plurality of attractions in the theme park for times when a historical amusement park attendance number corresponds to the amusement park attendance number; receiving a wait time for the attraction via the processor; determining, via the processor, a representative historical latency based on the plurality of historical latency times; determining, via the processor, a wait time threshold for the attraction based on the representative historical wait times; generating, via the processor, a wait time recommendation for the attraction based on the wait time and the wait time threshold; sending a notification of said waiting time recommendation via said processor; A method comprising:

2. The method of claim 1 , further comprising: determining, via the processor, an average historical latency based on the plurality of historical latency times; and determining the latency threshold based on the average historical latency time.

3. The method of claim 1 , further comprising determining, via the processor, a second latency threshold based on the plurality of historical latency times.

4. 4. The method of claim 3, further comprising sending, via the processor, a second notification that the wait time for the attraction is longer than expected based on the wait time for the attraction being greater than the second wait time threshold.

5. receiving, via the processor, a total wait time for the plurality of attractions; determining, via the processor, a wait time ratio for the attraction based on the wait time for the attraction and the total wait time for the plurality of attractions; determining, via the processor, a total historical wait time for the plurality of attractions based on the plurality of historical wait times; Including, the wait time threshold comprises a ratio based on a historical wait time of the attraction and the total historical wait time of the plurality of attractions; The method of claim 1 , wherein generating the wait time recommendation for the attraction is based on the wait time ratio and the wait time threshold.

6. receiving, via the processor, from a sensor, a location of an electronic device within the theme park; determining, via the processor, a set of attractions from the plurality of attractions that are within a threshold distance of the electronic device; The method of claim 1 , comprising:

7. receiving, via the processor, additional wait times corresponding to additional attractions in the set of attractions; determining, via the processor, an additional wait time ratio between the additional wait time for the additional attraction and a total existing wait time for the plurality of attractions; generating, via the processor, a wait time recommendation for the additional attraction based on comparing the additional wait time to the wait time threshold; The method of claim 6, comprising:

8. 8. The method of claim 7, further comprising sending, via the processor, an additional notification that the wait time is longer than expected based on the wait time for the additional attraction being greater than a second wait time threshold.

9. 8. The method of claim 7, wherein determining the additional wait time via the processor comprises dividing the additional wait time of the additional attraction by the plurality of historical wait times of the plurality of attractions.

10. a sensor configured to detect a location of an electronic device within a theme park including a plurality of attractions; a processor; When executed by the processor, it causes the processor to: determining a set of attractions from the plurality of attractions that are within a threshold distance of the location of the electronic device; receiving wait times corresponding to attractions in the set of attractions; receiving a plurality of historical wait times for the attraction for a time period corresponding to amusement park attendance numbers; determining a representative historical latency based on the plurality of historical latency; determining a wait time threshold for the attraction based on the representative historical wait times; generating a wait time recommendation for the attraction based on the wait time and the wait time threshold; Sending a notification of said recommended wait time; a memory storing instructions for causing the A waiting time recommendation system comprising:

11. 11. The wait time recommendation system of claim 10, wherein the processor is configured to determine a wait time ratio between the wait time and a total wait time of the plurality of attractions, and the wait time recommendation is generated based on comparing the wait time ratio to a wait time threshold.

12. The wait time recommendation system of claim 11 , wherein the wait time threshold is determined based on a relationship between a historical total wait time for the plurality of attractions and a historical wait time for the attraction.

13. 12. The latency recommendation system of claim 11, wherein the latency threshold is a short latency threshold, and the latency recommendation is that the latency is shorter than expected based on the latency ratio being less than the short latency threshold.

14. 12. The latency recommendation system of claim 11, wherein the latency threshold is a long latency threshold, and the latency recommendation is that the latency is longer than expected based on the latency ratio being greater than the long latency threshold.

15. The wait time recommendation system of claim 10 , wherein the processor is configured to remove a second wait time corresponding to a closed attraction from the total wait times of the plurality of attractions.

16. 1. A tangible, non-transitory computer-readable medium comprising instructions for generating wait time recommendations for an attraction among a plurality of attractions at a theme park, the instructions, when executed by a processor, causing the processor to: receiving a location of an electronic device within the theme park from a sensor; determining a set of attractions from the plurality of attractions that are within a threshold distance of the location of the electronic device; receiving a wait time corresponding to the attraction among the plurality of attractions; receiving a plurality of historical wait times for the attraction for a time period during which a historical amusement park attendance number corresponds to an amusement park attendance number for the theme park; determining a representative historical latency based on the plurality of historical latency; determining a wait time threshold for the attraction based on the representative historical wait times; sending a notification that the wait time for the attraction is longer than expected based on the wait time for the attraction being greater than the wait time threshold; A tangible, non-transitory computer-readable medium that causes

17. The instructions, when executed by the processor, cause the processor to: receiving a total wait time for the plurality of attractions at the theme park; determining a wait time ratio for the attraction among the plurality of attractions based on the total wait time for the plurality of attractions and the wait time for the attraction; generating a latency recommendation based on the latency ratio and the latency threshold; 17. The tangible, non-transitory computer-readable medium of claim 16,

18. The instructions, when executed by the processor, cause the processor to: receiving, after a period of time, updated wait times corresponding to the attractions of the plurality of attractions; sending an additional notification that the wait time for the attraction is shorter than expected based on the wait time for the attraction being less than the wait time threshold; 17. The tangible, non-transitory computer-readable medium of claim 16,

19. The tangible, non-transitory computer-readable medium of claim 16 , wherein the latency threshold is determined based on a date, a time, or weather.

20. 17. The tangible, non-transitory computer-readable medium of claim 16, wherein the wait time threshold is determined based on a total historical wait time for the plurality of attractions when historical amusement park attendance is correlated to amusement park attendance at the theme park.

Images