Wait time recommender

Abstract

A system and method are disclosed for determining whether the wait time for an attraction at a theme park is shorter or longer than expected and notifying visitors of such shorter or longer wait times. In particular, the system and method determine a wait time value for an attraction by dividing the wait time for the attraction by the total wait time for all attractions at the theme park, and compare the wait time value to one or more thresholds based on the expected wait time for the attraction. In this way, theme park visitors can make more informed decisions about which attractions to wait for and maximize their time at the theme park.

Description

Background Technology

[0001] The present disclosure generally relates to wait times for attractions. More specifically, embodiments of the present disclosure relate to determining wait times for attractions that are shorter or longer than expected and notifying visitors of such shorter or longer wait times.

[0002] This section is intended to introduce to the reader various aspects of the prior art that may be related to the various aspects of the present technology described and / or claimed below. Such description is believed to be helpful in providing background information to the reader to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that such description should be read in this context and not as an acknowledgment of prior art.

[0003] Many places or service providers, such as theme parks, restaurants, ticket vendors, and government agencies, may include lines or queues through which visitors can obtain services. For example, a theme park may include multiple attractions, each having at least one line. Thus, each line of each attraction may include a corresponding wait time. Theme park visitors may select which attractions to participate in based on various factors, such as attraction preference, distance to the attraction, time of day, weather, and the wait time (or length) of each line. In some cases, each wait time may be provided through a software application on the visitor's mobile device, but any appropriate device may be used to display or convey each wait time, such as signage inside the theme park, signage at each attraction, posting on a website associated with the theme park, or messaging via a chatbot on a messaging platform.

[0004] However, if visitors have access to more information, such as whether the wait times for each line are shorter or longer than the typical or expected wait times, they can make better informed decisions about which attractions to attend. means of solving the problem

[0005] Specific embodiments corresponding to the subject and scope of the original claim are summarized below. These embodiments are not intended to limit the scope of the disclosure, but rather are intended to provide a brief summary of the specific disclosed embodiments. In practice, the disclosure may include various forms that may be similar or different from the embodiments described below.

[0006] The present disclosure provides a system and method for determining whether a wait time for an attraction is shorter or longer than expected and notifying visitors of such short or long wait times. In particular, a theme park may include a number of attractions, each having at least one line. Accordingly, each line of each attraction may include or be associated with a respective wait time at a given time. Visitors may know each wait time through a software application on a visitor's mobile device capable of displaying information and tools related to the theme park, such as operating hours, attraction status, and attraction wait times, but any suitable device may be used to display or convey this information, such as signage inside the theme park, signage at each attraction, posting on a website related to the theme park, or messaging via a chatbot on a messaging platform.

[0007] A wait time recommendation system may use wait time historical data that includes wait times for attractions within a park and is used to determine past, estimated, or typical wait times for individual attractions. These wait times may be provided as a percentage of the total wait time for each attraction and / or the collective total wait time for all attractions. In one embodiment, the estimated wait time may be expressed as an estimated percentage or share of the total wait time for the park indicated by individual attractions (e.g., 5-7% of the estimated total wait time for the park indicated by a single attraction). The wait time recommendation logic of the wait time recommendation system may determine current or existing wait time values.

[0008] In one embodiment, the wait time value for an attraction is based on the relationship between the existing wait time for an individual attraction and the existing total wait time for all attractions within the theme park. The calculated wait time value, representing the relationship between the attraction's existing wait time or the attraction's existing wait time to the existing total wait time for all attractions, is compared to historical data to determine whether any individual attraction is outside the expected boundaries, for example, whether it has a wait time longer or shorter than expected. For example, if an individual attraction generally represents at least 5% of the typical total park wait time, an existing wait time representing less than 5% of the current total park wait time may be considered shorter than the expected wait time. In another embodiment, the existing wait time may be directly compared to past wait times with a given context to evaluate whether the existing wait time is shorter or longer than expected. That is, rather than comparing the existing wait time to the overall average past wait time, the past wait times used for comparison may be selected from data points of the same day or the same park crowd subset (e.g., using the total park visitors of that day).

[0009] If the wait time recommendation logic determines that the wait time value is below a short wait time threshold (e.g., ratio or percentage), the wait time recommendation logic may send a notification to the software application on the visitor'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 a long wait time threshold (e.g., ratio or percentage), the wait time recommendation logic may send a notification to the software application on the visitor's mobile device that the wait time is longer than expected. The short wait time threshold and the long wait time threshold may be based on the expected wait time ratio for the attraction. The estimated wait time value may be determined based on historical wait time data for attractions and theme parks, date or time information (e.g., time of day, day of the week, week or season of the year), weather, characteristics of the attraction (e.g., whether the attraction is outdoors or indoors), whether the attraction is open or closed (e.g., during a specified period), or holiday or event dates (e.g., public holidays such as Thanksgiving or Christmas, school holidays such as spring break, or religious holidays such as Easter). Visitors may use notices that the wait time is shorter or longer than expected as a factor in deciding whether to queue for an attraction.

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

[0011] In another embodiment, a type of non-transient computer-readable medium includes instructions for generating wait time recommendations for attractions in a theme park. When executed by a processor, the instructions cause the processor to receive total wait times for attractions in the theme park, receive wait times for attractions, and compare the wait times or wait time values ​​for attractions to a threshold value associated with the attraction. The wait time values ​​are based on the total wait times and the wait times for attractions. The instructions also cause the processor to transmit a notification based on the comparison.

[0012] In another embodiment, a method for generating wait time recommendations includes receiving wait times for attractions in a theme park and determining wait time values ​​for each individual attraction based on the wait times. The method also includes comparing the wait time values ​​of each individual attraction to a wait time threshold for each individual attraction and identifying a subset of attractions having wait time values ​​that indicate a shorter wait time than the expected wait time based on the comparison. The method further includes the step of transmitting a notification including an indication of the subset. Brief explanation of the drawing

[0013] These and other features, aspects, and advantages of the present disclosure will be better understood when reading the following detailed description with reference to the accompanying drawings, in which similar characters indicate similar parts throughout the drawings. FIG. 1 is a block diagram of a waiting time recommendation system according to an embodiment of the present disclosure. FIG. 2 is a flowchart of a process for generating a wait time recommendation for one attraction in a theme park based on the total wait time for several attractions in a theme park, according to an embodiment of the present disclosure. FIG. 3 is a flowchart of a process for generating a wait time recommendation for a theme park attraction based on the number of park attendees, according to an embodiment of the present invention. FIG. 4 is an exemplary screenshot of a theme park software application used to provide theme park information to theme park visitors, according to an embodiment of the present disclosure. FIG. 5 is an exemplary screenshot of all waiting time pages of the theme park software application of FIG. 4, having a graphic notification indicating a shorter-than-normal waiting time according to an embodiment of the present disclosure. FIG. 6 is another exemplary screenshot of all wait times pages of the theme park software application of FIG. 4, having a text-based display indicating a shorter-than-usual wait time according to embodiments of the present disclosure. FIG. 7 is another exemplary screenshot of all waiting time pages of the theme park software application of FIG. 4 in the case where the waiting time of an attraction line transitions to a shorter waiting time than usual, according to an embodiment of the present invention. FIG. 8 is an exemplary screenshot of a chat user interface capable of providing a waiting time recommendation according to an embodiment of the present disclosure. FIG. 9 is an exemplary screenshot of an employee dashboard that can provide a waiting time and a waiting time recommendation according to an embodiment of the present disclosure. Specific details for implementing the invention

[0014] The present disclosure provides a system and method for determining wait times for attractions that are shorter or longer than expected and notifying visitors of such shorter or longer wait times. In particular, a theme park may include multiple attractions, each having at least one line. Accordingly, each line of each attraction may include a respective wait time. Each wait time may be provided to visitors, for example, through a software application on a visitor's mobile device or a display board within the theme park. In some cases, the theme park may provide visitors with a software application capable of displaying information and tools related to the theme park, such as operating hours, the status of attractions, and attraction wait times.

[0015] A wait time recommendation system may provide a notification if it is determined that the wait time for an attraction is shorter or longer than expected, for example, by comparing the wait time for an attraction to the attraction's wait time history data. The wait time history data considers date or time information (e.g., time of day, day of the week, week of the year, or season), weather, characteristics of the attraction (e.g., whether the attraction is outdoors or indoors), whether the attraction is open or closed (e.g., for a certain period), holiday or event dates (e.g., public holidays such as Thanksgiving or Christmas, school holidays such as spring break, or religious holidays such as Easter), weather information (e.g., temperature, humidity, probability or amount of rainfall, likelihood of natural disasters, etc.), parades, shows, or other performances occurring nearby, or other relevant information that may affect or distort the wait time. Visitors may use the notification that the wait time is shorter or longer than expected as a factor in deciding whether to queue for the attraction. In this way, visitors can make more informed decisions about which attractions to wait for and maximize their time at the theme park. Additionally, theme park operations can be more efficient if visitors are evenly distributed among the attractions. That is, the disclosed technique can notify visitors when one or more attractions are uncrowded, thereby encouraging the redistribution of visitors to one or more uncrowded attractions. While this disclosure describes embodiments for theme parks and attractions, it should be noted that the systems and methods disclosed herein may be applied to any suitable location for line wait time analysis, such as restaurants, ticket vendors, government agencies, etc.

[0016] The disclosed technique provides visitors with an improved context for estimating wait times. For example, if the wait time for a specific ride is 35 minutes, that wait time may be longer than expected on days when the park is relatively empty or rainy, but shorter than expected on crowded or sunny days. Additionally, ranking rides based on estimated wait times does not provide visitors with information on which rides tend to be more crowded or which rides are more popular. By providing a quality rating of wait times for each ride (e.g., shorter than expected, longer than expected), visitors can judge which rides are good and enjoy the feeling that they have gained something regarding the wait time, even for rides with long absolute wait times compared to other rides in the park, thereby improving the visitor experience and visitor satisfaction.

[0017] FIG. 1 is a block diagram of a latency recommendation system (10) according to embodiments of the present disclosure. The latency recommendation system (10) includes a controller (12) comprising 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. Furthermore, the processor (14) may include a plurality of microprocessors, namely one or more "general-purpose" microprocessors, one or more special-purpose microprocessors, and / or one or more ASICS (application-specific integrated circuits) and / or one or more RISC (Reduced Instruction Set) 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) to be executed by the processor (14), such as instructions related to determining latency recommendations. Thus, the memory device (16) may facilitate latency recommendation determination by storing, for example, control software, lookup tables, configuration data, etc. In some embodiments, the processor (14) and the memory device (16) may be located outside the controller (12). The memory device (16) may include a non-transient machine-readable medium of the type of volatile memory (e.g., random access memory (RAM)) and / or non-volatile memory (e.g., read-only memory (ROM), flash memory, hard drive and / or any other suitable optical, magnetic, or solid-state storage medium).

[0018] The controller (12) may use a wait time recommendation logic to determine a wait time recommendation for a theme park attraction (34). In particular, 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 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., this indication may be expressed as a total time, such as saved wait time or added wait time in minutes, or 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., circuits), software (e.g., instructions stored in memory (16) for execution by the processor (14)), or a combination of both. The wait time recommendation logic may use wait time history data (22) as input. Waiting time history data (22) may be stored in memory (16) and / or provided to a database. For example, a waiting time recommendation system (10) may include a database that stores waiting time history data (22) and returns the requested waiting time history data (22) in response to receiving a query from the waiting time recommendation logic.

[0019] In one embodiment, the wait time recommendation logic may determine the wait time recommendation by determining a wait time value for an attraction. The wait time value may represent the ratio of the existing wait time of one attraction to the total wait time of all attractions in the theme park. As such, the wait time recommendation logic may determine the wait time value by, for example, dividing the existing wait time for an attraction within a current time or rolling time window by the existing total wait time for all attractions. The wait time value may be compared in the same way to one or more past wait time values ​​calculated using wait time history data (22). The past total wait time may be the average of the total wait time for all attractions using a subset of past wait time data points over any appropriate period or based on context information provided herein (e.g., a point in time for a day, week, season, or year). In some embodiments, the past total wait time may be the average of the total wait time over a period corresponding to the current time or day of the week for which the wait time recommendation is requested. For example, the historical total wait time may be the average of total wait times corresponding to the same date (over several years), the same time (over several dates), similar weather (over several dates), similar characteristics (e.g., weekend wait times, holiday wait times, or parades, shows, or other performances occurring nearby), similar attraction conditions (e.g., attraction closures), or other similar relevant information that may affect wait times. Additionally, factors that may distort the historical total wait time can be addressed, for example, by adjusting the distorted historical total wait time to compensate for distortion factors.

[0020] The wait time recommendation logic can compare a 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 of 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 of the attraction divided by the total wait time for all attractions (in relation to the expected wait time). The expected wait time of the attraction may be provided by wait time history 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 visitor's mobile device (24) that the wait time for the attraction is shorter than expected. Meanwhile, if the waiting time value is greater than the expected waiting time value, the waiting time recommendation logic can notify the visitor's mobile device (24) that the waiting time is longer than expected. If the waiting time value is less than or not greater than the expected waiting time value, the waiting time recommendation logic can determine that the waiting time is as expected.

[0021] In some embodiments, the wait time recommendation logic may use a threshold (e.g., ratio, percentage, or period) to compare a wait time value to an expected wait time value. For example, the expected or past wait time for an attraction may be 60 minutes in the context that the total past wait time for all attractions is 600 minutes. Thus, the expected or past wait time value may be 60 / 600 or 10%. If a short wait time threshold is set using a deviation of 5%, this short wait time threshold may be defined as 5% (i.e., 10% - 5%). Thus, the wait time recommendation logic may send a notification to the visitor's mobile device (24) that the wait time is shorter than expected if the wait time value is less than 5%. A long wait time threshold may be similarly defined and applied. The deviation used for the short wait time threshold and the long wait time threshold may be any appropriate deviation in the range of 1-50%. Furthermore, in some embodiments, the threshold may be customizable (e.g. by the developer, theme park, or visitor). In some embodiments, the wait time recommendation logic may compare wait time values ​​to expected wait time values ​​without using thresholds. 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 display a subset of wait times that deviate maximally from all wait times or each expected wait time (e.g., top 10, top 5, top 3, or any appropriate top number).

[0022] It should be understood that when using values ​​to determine wait time recommendations in this disclosure, any appropriate numerical representation of wait time, including wait time itself, may be used. For example, in some cases, wait time history data (22) may receive existing wait times for each attraction, and the existing wait time of an attraction may be compared to an expected or past wait time (or a subset of past wait times based on context, e.g., only past weekend wait times, only past Tuesday wait times) to determine wait time recommendations. For the purposes of this example, if the expected wait time of an attraction is 60 minutes and a short wait time threshold is set using a threshold deviation of 10 minutes, the short wait time threshold is 50 minutes (i.e., 60 minutes - 10 minutes). Thus, if the wait time recommendation logic is less than 50 minutes, a notification that the wait time is shorter than expected may be sent to the visitor's mobile device (24). A long wait time threshold may be similarly defined and applied.

[0023] The estimated wait time value may be determined and / or adjusted based on historical wait time data of the attraction and theme park and any appropriate context information. In particular, the wait time recommendation logic may acquire or receive context information based, for example, on the date or time when the wait time recommendation was requested. 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., public holidays such as Thanksgiving or Christmas, school holidays such as spring break, or religious holidays such as Easter), weather information (e.g., temperature, humidity, likelihood or amount of rain, likelihood of natural disasters, etc.), characteristics of the attraction (e.g., whether the attraction is outdoors or indoors), parades, shows, or other performances taking place nearby, the geographical 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 acquire appropriate or requested context information. In alternative or additional embodiments, context information may be received from various sources, such as calendar software applications, weather software applications, and / or location determination software applications.

[0024] As an example of wait time recommendation logic using context information, the wait time recommendation logic can determine the estimated wait time for a specific date by averaging the historical estimated wait time values ​​associated with the corresponding date in the previous year. As another example, the wait time recommendation logic can determine the estimated wait time for a specific time by averaging the historical estimated wait time values ​​for the corresponding time over the previous 30 days. As yet another example, the wait time recommendation logic can determine the estimated wait time for a specific time by averaging the historical estimated wait time values ​​taken when weather conditions substantially match the weather conditions at that specific time (e.g., when the temperature is nearly identical (e.g., within 1 to 5 degrees Fahrenheit), when the humidity is nearly identical, when the precipitation is nearly identical, etc.). Thus, the wait time recommendation logic can consider or adjust the estimated wait time values ​​based on the date, time, weather, attraction characteristics, or other appropriate factors that may distort the estimated wait time values. For example, if the wait time history data (22) corresponds to one or more closed attractions within the theme park, the wait time history data (22) may be distorted (since the wait time is not associated with the closed attraction, the wait time values ​​for the remaining attractions may be inflated). In such cases, the wait time recommendation logic may estimate the wait time for the closed attraction (e.g., based on the wait time history data (22)) to compensate for the closed attraction. Alternatively, the wait time recommendation logic may not use the wait time history data (22) corresponding to the closed attraction (or the attraction that existed but is no longer in operation). While this disclosure describes that the wait time recommendation logic can determine the expected wait time, it should be understood that any appropriate logic (e.g., outside the wait time recommendation logic) can determine the expected wait time.

[0025] If the waiting time recommendation logic determines that the waiting time is shorter than expected, longer than expected, or equal to expected, the waiting time recommendation logic may transmit a corresponding display or notification to the visitor's mobile device (24) via a communication network (28). The communication network (28) may be wired and / or wireless, and enables the waiting time recommendation logic to communicate with the visitor's mobile device (24) via any appropriate communication protocol and / or transmit a display or notification to the mobile device (24). For example, the communication network (28) may include a wireless network such as a mobile network, WiFi, LAN, WAN, the Internet, etc.

[0026] The mobile device (24) can store and run a wait time recommendation software application (30) that enables the mobile device (24) to display wait times and wait time recommendations for the theme park's attractions. It should be understood that certain features of the system (10) may be duplicated or exchanged with one another. For example, the wait time recommendation software application (30) may be stored in memory (e.g., sharing certain features of memory (16)) and executed by the processor of the mobile device (24) (e.g., sharing certain features of the processor (14)). The mobile device (24) may communicate with the controller (12) via a communication network (28) using a communication circuit (33) (e.g., sharing certain features of the communication circuit (17)).

[0027] Additionally, the wait time recommendation system (10) includes a plurality of attractions (34) that communicate with a controller (12) via a communication network (28) using a communication circuit (36) under the control of an attraction information system (35). Wait time history data (22) is updated using wait time data from each individual attraction (34) and is also stored as input and wait time history data (22) used by the controller (12) to obtain existing wait times for individual attractions (34) and subsequently used to determine the collective or total existing wait time for all attractions (e.g., by summing all existing wait times of the attractions (34)). In some embodiments, wait time data may be determined manually. For example, a theme park employee may monitor the wait times of the theme park's attractions and input or transmit the wait times to the attraction information system (35) and / or the controller (12).

[0028] The attraction information system (35) may include a memory (e.g., sharing specific features of the memory (16)) and may be under processor control (e.g., sharing specific features of the processor (14)). The attraction may also include one or more sensors (38) that generate data used to determine the existing wait time for individual attractions (34). In one embodiment, the sensors (38) may include a visitor tracking sensor (e.g., a barcode or optical reader, an NFC reader) which reads identification information from a mobile device (24) when entering the attraction line and when each visitor enters the attraction itself and exits the attraction line. In one embodiment, the existing wait time for each attraction (34) may be the average wait time of the last N visitors (e.g., the last 10, the last 50). In another embodiment, the sensor (38) may include a camera or image sensor that estimates the line length using image data of the line and then estimates the existing waiting time based on the estimated line length.

[0029] A wait time recommendation application (30) may receive wait time recommendation information (e.g., display or notification of wait time recommendation) from a 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 visitors. A 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, instead, the mobile device (24) may be any other suitable device that can display or convey each wait time, such as signage inside the theme park, signage for each attraction, postings on a website related to the theme park, or messaging via a chatbot on a messaging platform.

[0030] In some embodiments, the wait time recommendation application (30) may provide and / or display wait time recommendations based on user context information provided through the user interface or user input device (32) of the mobile device (24). The user context information (32) may include any appropriate information that can facilitate providing a more relevant display of wait time recommendations. In particular, the user context information (32) may include user preferences of visitors or groups of visitors (e.g., attractions that visitors or groups of visitors want to attend or do not want to attend, or attractions that visitors or groups of visitors are eligible to attend or not attend based on the height of members of visitors or groups of visitors), location information (e.g., location information of the mobile device (24) provided by location determination logic such as Global Position System (GPS) hardware and / or software), etc. For example, the wait time recommendation application (30) may evaluate wait times or display / push wait times only for attractions that satisfy user preferences and / or are within a threshold distance from the location of the mobile device. In one embodiment, a visitor may set or configure user context information (32) provided and / or used to determine how a wait time recommendation is determined and / or displayed. The visitor may use a notification that the wait time is shorter or longer than expected as a factor in deciding whether to queue for an attraction.

[0031] FIG. 2 is a flowchart of a process (40) for generating a wait time recommendation for a theme park attraction based on the total wait time for several attractions of a theme park according to an embodiment of the present disclosure. In particular, a wait time recommendation system (10) may implement the process (40) for generating a wait time recommendation. The process (40) may be in the form of one or more software applications comprising instructions executed by at least one suitable processor, such as the processor (14) of the wait time recommendation system (10), through wait time recommendation logic. The illustrated process (40) is provided merely as an example, and in other embodiments, specific illustrated steps of the process (40) may be performed in a different order according to the present disclosure, omitted, repeated, or not illustrated in FIG. 3.

[0032] As illustrated, in process block (42), the processor (14) receives the total wait time for multiple attractions of the theme park. Multiple attractions of the theme park may include all attractions of the theme park or all attractions of the theme park in operation. The total wait time may be the average of the total wait times for all attractions over any appropriate period (e.g., days, weeks, seasons, or years). In particular, the total wait time may be provided by wait time history data (22). In some embodiments, the total wait time may be the average of the total wait times over a period corresponding to the current time or day of the week for which a wait time recommendation is requested. For example, the total wait time may be the average of the total wait times corresponding to the same date (over several years), the same time (over several dates), similar weather (over several dates), and / or other similar characteristics.

[0033] In some embodiments, the processor (14) may consider or adjust the total wait time based on the date, time, weather, attraction characteristics, or any other suitable factor that may distort the estimated wait time value. For example, if the wait time history data (22) corresponds to one or more attractions that are being closed within the theme park, the wait time history data (22) may be distorted (since the wait time is not associated with the closed attraction, the remaining attractions will inflate the wait time value). In such cases, the wait time recommendation logic may estimate the wait time for the closed attraction to compensate for the closed attraction (e.g., based on the wait time history data (22)). Alternatively, the wait time recommendation logic may not use the wait time history data (22) corresponding to the closed attraction (or the attraction that existed but is no longer in operation).

[0034] In the process block (44), the processor (14) receives the waiting time for the attraction. For example, the waiting time may be provided by the timer or counter of the attraction (34) or entered manually.

[0035] In process block (46), the processor (14) determines a wait time value for an 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 the ratio of the wait time for an attraction to the total wait time for all attractions in the theme park. In particular, the wait time recommendation logic may determine the wait time value by dividing the wait time for an attraction by the total wait time for all attractions. The wait time value may be expressed as a fraction, a decimal, or a percentage.

[0036] In the decision block (48), the processor (14) determines whether the wait time value is less than the 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, 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 of the attraction divided by the total wait time for all attractions (related to the expected wait time). The expected wait time of the attraction may be provided by the wait time history data (22). The short wait time threshold may be determined by subtracting the threshold period from the expected wait time. The critical period may be any appropriate period (e.g., 30 seconds to 30 minutes, 1 minute, 5 minutes, or 10 minutes) or a critical percentage (e.g., in the range of 0.1 to 10%, or 1 to 5%).

[0037] In the process block (50), if the processor (14) determines that the wait time value is less than a short wait time threshold, the processor (14) transmits a notification that the wait time for the attraction is short. In particular, the processor (14) may transmit a notification that the wait time is shorter than expected to a wait time recommendation software application (30) on the visitor's mobile device (24). In one embodiment, the processor (14) ranks all attraction wait times based on a comparison with the expected wait time. For example, the ranking may identify a subset of attractions that have the best value compared to the expected or past wait time values. The wait time recommendation system (10) may push the subset of attractions with the best value to the visitor's mobile device (24) via a notification. In one embodiment, the ranking may be based on the total time (minutes) saved. For example, if an attraction typically has a 45-minute wait on weekends but the existing wait time is 35 minutes, that attraction may be ranked higher than an attraction with an absolute wait time that is 5 minutes lower than usual (e.g., 15 minutes).

[0038] In the decision block (52), if the processor (14) determines that the wait time value is not less than the short wait time value threshold, the processor (14) determines whether the wait time value is greater than the long wait time value threshold. The long wait time threshold can be determined by adding a threshold period to the expected wait time. The threshold period subtracted from the expected wait time to determine the short wait time threshold may or may not be equal to the threshold period added to the expected wait time to determine the long wait time threshold.

[0039] In process block (54), if the processor (14) determines that the wait time value is greater than the long wait time threshold, the processor (14) transmits a notification that the wait time for the attraction is long. In particular, the processor (14) may transmit a notification that the wait time is longer than expected to a wait time recommendation software application (30) on the visitor's mobile device (24). In some embodiments, if the processor (14) determines that the wait time value is greater than the short wait time threshold (determination block (48)) but not greater than the long wait time threshold, the processor (14) may transmit a notification that the wait time is equal to the expected wait time to a wait time recommendation software application (30) on the visitor's mobile device (24). The processor (14) may provide multiple recommendations corresponding to multiple attractions. In one embodiment, the processor (14) may list multiple recommendations in a ranked order to prioritize lines having the shortest wait time or the greatest wait time savings compared to the expected wait time. The processor (14) may not provide any recommendations if the waiting time value is greater than or equal to a short waiting time threshold or greater than a long waiting time threshold (thus indicating that visitors to the theme park are evenly distributed among the attractions).

[0040] In some embodiments, the processor (14) may compare the wait time value with the expected wait time value without using a threshold. For example, the processor (14) may determine all deviations for all wait times from the expected wait times for all attractions. The wait time recommendation logic may display a subset of wait times that deviate most significantly from all wait times or each expected wait time (e.g., top 10, top 5, top 3, or any appropriate top number). In this way, the processor (14) may implement a process (40) that generates wait time recommendations for attractions in a theme park based on the total wait times for multiple attractions in the theme park.

[0041] In some embodiments, wait time recommendations may be generated based on other factors in addition to or alternatively to the total wait time for a number of attractions in 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 the number of park attendees according to one embodiment of the present disclosure. In particular, a wait time recommendation system (10) may implement the process (60) for generating wait time recommendations. The process (60) may be in the form of one or more software applications comprising instructions executed by at least one suitable processor, such as the processor (14) of the wait time recommendation system (10), through wait time recommendation logic. The illustrated process (40) is provided merely as an example, and in other embodiments, specific illustrated steps of the process (40) according to the present disclosure may be performed in a different order, omitted, repeated, or not illustrated in FIG. 3.

[0042] As illustrated, in process block (61), the processor (14) receives the current number of park attendees for the theme park. In process block (62), the processor (14) receives one or more past wait times for an attraction where the corresponding past number of park attendees is approximately the current number of park attendees. One or more past wait times may be provided by wait time history data (22). In some embodiments, the processor (14) may include or exclude past wait times associated with distorted past park attendees (e.g., due to the attraction being closed, weather, holidays or event dates, parades, shows or other performances occurring nearby, or other suitable information that may affect or distort the wait times). In one embodiment, the processor (14) may adjust past wait times associated with distorted past park attendees. The processor (14) may determine that the past number of park attendees is approximately the current number of park attendees if the past number of park attendees is within a threshold number of attendees of the current number of park attendees. The critical number of attendees may be any appropriate number of attendees (e.g., 1 to 10,000, 1 to 1,000, or 1 to 100) or any appropriate percentage of the current number of park attendees (e.g., in the range of 0.1 to 10%, or 1 to 5%).

[0043] In process block (63), the processor (14) determines the average past wait time for an attraction based on one or more past wait times. That is, the processor (14) may average one or more past wait times for an attraction to determine the average past wait time. In additional or alternative embodiments, other representative values ​​such as a median, mode, minimum, or maximum value may be used.

[0044] In process block (64), the processor (14) determines a short wait time threshold and a long wait time threshold based on the average past wait time. The short wait time threshold can be determined by subtracting a threshold period from the average past wait time, and the long wait time threshold can be determined by adding a threshold period to the average past wait time. The threshold period can be any appropriate 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%).

[0045] In the process block (65), the processor (14) receives the waiting time for the attraction. For example, the waiting time may be provided by the timer or counter of the attraction (34) or entered manually.

[0046] In the decision block (66), the processor (14) determines whether the waiting time is shorter than a short waiting time threshold. If so, in the process block (67), the processor (14) transmits a notification that the waiting time for the attraction is short. In particular, the processor (14) can transmit a notification that the waiting time is shorter than expected to a waiting time recommendation software application (30) on the visitor's mobile device (24).

[0047] If the processor (14) determines that the waiting time is not less than a short waiting time threshold, in the decision block (68), the processor (14) determines whether the waiting time is greater than a long waiting time threshold. If so, in the process block (69), the processor (14) transmits a notification that the waiting time for the attraction is long. In particular, the processor (14) can transmit a notification that the waiting time is longer than expected to a waiting time recommendation software application (30) on the visitor's mobile device (24).

[0048] In some embodiments, if the processor (14) determines that the wait time value is not smaller than the short wait time threshold (decision block (66)) and not larger than the long wait time threshold, the processor (14) notifies the wait time recommendation software application (30) on the visitor's mobile device (24) that the wait time is as expected. In this way, the processor (14) can implement a process (60) that generates wait time recommendations for theme park attractions based on the number of park attendees.

[0049] Based on the foregoing description, FIG. 4 is an exemplary screenshot of a theme park software application (70) used to provide theme park information to a theme park visitor according to embodiments of the present disclosure. In particular, the theme park software application (70) may be stored and executed on a visitor's mobile device (24). As illustrated, the theme park software application (70) may display a menu (72), for example, when a visitor selects a menu button (74). The menu (72) may display various options, including displaying an all wait times page (76) (labeled "All Wait Times") that displays all wait times for all attractions in the theme park, and displaying recommended wait times (labeled "Recommended Wait Times") that display recommended wait times for the theme park attractions.

[0050] While the All Wait Time page (76) may display all wait times for all attractions in the theme park, in some embodiments, the page (76) may also display recommended wait times. For example, FIG. 5 is an exemplary screenshot of the All Wait Time page (76) of the theme park software application (70) of FIG. 4 having a graphical notification of a wait time shorter than usual, according to an embodiment of the present disclosure. In some embodiments, a wait time recommendation software application (30) may provide the information displayed on the All Wait Time page (76). For example, the wait time recommendation software application (30) may be part of the theme park software application (70). The All Wait Time page (76) displays wait times for the attraction lines of the theme park. As illustrated, line A (90) has a wait time (92) of 15 minutes, line B (94) has a wait time (96) of 50 minutes, and line C (98) has a wait time (100) of 25 minutes. Additionally, all wait time pages (76) may provide a graphic display (102) to notify visitors that a line has a wait time shorter or longer than usual. For example, all wait time pages (76) may display a graphic display (102) for both line A (90) and line C (98) to indicate that these lines have a shorter wait time than usual. In some embodiments, all wait time pages (76) may also include a display notifying visitors that a line has a longer wait time than usual. It should be noted that the graphic display may be provided in any suitable format, such as clip art, emojis, icons, etc.

[0051] In some embodiments, all wait time pages (76) may include an option to display preferred wait times, or the theme park software application (70) may include a preferred wait time page that displays wait times for the theme park's attractions based on the visitor's preferences. For example, the theme park software application (70) may receive the visitor's preference for a specific attraction (e.g., as part of user context information (32)). Then, the theme park software application (70) may instruct the wait time recommendation system (10) to evaluate only the wait times for rides indicated as preferred by the visitor, or to display only the wait times for rides indicated as preferred by the visitor. As another example, the theme park software application (70) receives the location of the mobile device and / or the distance from the attraction (e.g., as part of the user context information (32)), and then instructs the wait time recommendation system (10) to evaluate only the wait times for rides within a threshold distance from the mobile device (24) or to display only the wait times for rides within a threshold distance from the mobile device (24). In some embodiments, the theme park software application (70) may instruct the wait time recommendation system (10) to evaluate several factors, including the wait time, the difference between the wait time of the line and the expected wait time of the line, visitor preferences, and / or the location of the mobile device (24), in order to determine the wait time to display as the preferred wait time. Similarly, all wait time pages (76) may include appropriate options for sorting or filtering wait times, for example, by wait time, by the difference between the wait time of the line and the expected wait time of the line, the ratio between the difference between the wait time of the line and the expected wait time of the line, etc.

[0052] As illustrated in FIG. 5, the graphic display (102) is in the form of an icon or a graphic image. In an alternative or additional embodiment, the display may be in the form of text. For example, FIG. 6 is another exemplary screenshot of all wait time pages (76) of the theme park software application (70) of FIG. 4 having a text-based display or marker with a shorter wait time than usual, according to an embodiment of the present disclosure. In particular, FIG. 6 illustrates a text-based display or marker (110) (e.g., "Recommended!"). FIG. 5 and FIG. 6 each display the display in the form of an icon and text, respectively, but it should be understood that the display (102) may be displayed in any suitable format. For example, the text-based marker (110) may have a different font style (e.g., bold, italic, or uppercase) from other text on all wait time pages to draw attention to this marker (110) and / or may be displayed differently (e.g., in a different color or using a blinking effect).

[0053] Additionally, as the waiting time of a line or attraction changes state from, for example, an estimated waiting time to a state shorter than this estimated waiting time, the theme park software application (70) and / or the waiting time recommendation software application (30) may provide a larger or more noticeable notification (e.g., a push notification) to draw the visitor's attention to the state change. For example, FIG. 7 is another exemplary screenshot of all waiting time pages (76) of the theme park software application (70) of FIG. 4 when the waiting time of a line transitions to a waiting time shorter than usual according to an embodiment of the present invention. As illustrated, line A (90) transitions from an estimated waiting time to a waiting time shorter than usual. In this way, a notification prompt (120) is displayed to inform the visitor of this transition. In particular, the notification prompt (120) may be "pushed" or initiated by the waiting time recommendation system (10) to be displayed on a mobile device (24). The notification prompt (120) also allows the visitor to indicate that they will enter line A (90) via the "Go" button (122) or not enter line A (90) via the "Cancel" button (124). In this way, the theme park software application (70) and / or the wait time recommendation software application (30) can provide wait time recommendations to the visitor.

[0054] In some embodiments, wait time recommendations may be provided through a chat or messaging interface (e.g., stored and executed on a mobile device (24)). For example, FIG. 8 is an exemplary screenshot of a chat interface (130) capable of providing wait time recommendations according to an embodiment of the present disclosure. The 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 a wait time recommendation software application (30), or a component of a theme park software application (70) running on a mobile device (24). The chat interface (130) may communicate with a bot (e.g., a chatbot) or other suitable software application or artificial intelligence that is operated by a processor (14) and engages in conversation with visitors through text (or auditory) communication provided by wait time recommendation logic.

[0055] The chat interface (130) can provide wait time recommendations through the wait time recommendation system (10) in response to a visitor's request. For example, a visitor may send a message (132) requesting the "best" line (e.g., "Which line is the best right now?"). The chatbot may query the wait time recommendation system (10) for the line with the shortest wait time, which has the greatest difference between the line's (current) wait time and the line's expected wait time, or the line's wait time and the line's expected wait time, and display a response (134) indicating the result.

[0056] In some embodiments, the chatbot may incorporate the visitor's preference for a specific attraction into its response (134) (e.g., as part of user context information (32)). For example, the chatbot may instruct the wait time recommendation system (10) to evaluate only the wait times for rides indicated as preferred by the visitor, or to respond using only the wait times for rides indicated as preferred by the visitor. As another example, the chatbot may incorporate the location of the mobile device and / or the distance from the attraction (e.g., as part of user context information (32)) into its response (134). In particular, the chatbot may instruct the wait time recommendation system (10) to evaluate only the wait times for rides within a threshold distance from the mobile device (24), or to respond using only the wait times for rides within a threshold distance from the mobile device (24). In some embodiments, the chatbot may instruct the wait time recommendation system (10) to evaluate several factors, including wait time, the difference between the wait time of a line and the expected wait time of a line, visitor preferences, and / or the location of the mobile device (24), in order to determine the “best” line. As illustrated, the chatbot’s response (134) may indicate not only which line is “best” but also the difference between the wait time of a line and the expected wait time of a line (e.g., “Currently, Line A is the best at 25 minutes, 20 minutes shorter than usual”).

[0057] As another example, a visitor may send a message (136) requesting the wait times for all lines (e.g., "What are the wait times for all of the lines?"). The chatbot may query the wait time recommendation system (10) for an indication of whether any wait time is shorter than expected, as well as the wait times for all lines of the theme park, and display a response (138) indicating the result. As illustrated, the chatbot's response (138) displays the wait times for all lines as well as a shorter wait time than expected or a "Low Wait" line (e.g., "Line A: 25 mins - Low Wait!; Line B: 40 mins; Line C: 30 mins; Line D: 15 mins - Low Wait!").

[0058] Visitors may also send a message (140) requesting a wait time for a specific line (e.g., "What is the wait time for Line E?"). The chatbot may query the wait time recommendation system (10) for the wait time for this line as well as an indication of whether the wait time is shorter than expected, longer than expected, or as expected, and display a response (142) indicating the result. As illustrated, the chatbot's response (142) displays the wait time for the requested line as well as an indication that the wait time is longer than expected (e.g., "The wait time for Line E is 55 minutes. This wait is 20 minutes longer than usual!"). Although FIG. 8 is illustrated in the form of a chat or messaging interface, it should be understood that the disclosed technique can also be applied to any other suitable communication format associated with artificial intelligence or bots (e.g., chatbots), such as virtual assistants or smart speakers.

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

[0060] As illustrated, the staff dashboard (150) can display the wait times for an attraction line in the “All Wait Times” window (152). The staff dashboard (150) can also display wait time recommendations in the “Recommended Wait Times” window (154). In this way, the staff dashboard (150) can enable visitor service staff to quickly and conveniently search for information regarding attractions that are most efficient, convenient, and time-saving for wait times and / or lines. In fact, the staff dashboard (150) can enable visitor service staff to contact visitors, for example, through a service desk or through a roaming staff member, to recommend wait times for attractions and provide visitors with a personal touch and useful information. As additionally illustrated, the staff dashboard (150) may also display other convenient information that may be requested by visitors, or facilitate services for visitors, such as weather updates (156), theme park ticket plan price details (158), emergency contacts (160), news and other information (162).

[0061] While the disclosed embodiments exemplify recommendations for the same type of line (e.g., regular ticket holder or standby line), the present disclosure considers applying the disclosed technology to several different types of lines, such as express lines, season ticket holder lines, VIP lines, and / or disability access lines. In particular, standby time recommendations may be provided for these different types of lines and / or additional standby times based on these different types of lines may be considered.

[0062] The technology presented and claimed in this specification is referenced and applied to material objects and specific examples of a practical nature that can expressly improve the art and are therefore not abstract, intangible, or purely theoretical. Additionally, if any claim appended to the end of this specification includes one or more elements designated as “... means for [performing] [function]” or “... step for [performing] [function]”, such elements shall be interpreted in accordance with 35 USC 112(f). However, for any claim including elements designated in a different manner, such elements do not need to be interpreted in accordance with 35 USC 112(f).

[0063] [Example Implementation]

[0064] (Implementation Example 1)

[0065] A method for generating a wait time recommendation comprises the steps of: receiving a number of park attendees of a theme park through a processor; receiving a plurality of past wait times for a plurality of attractions within the theme park through the processor; receiving a wait time for an attraction among the plurality of attractions through the processor; determining a wait time threshold for the attraction based on the plurality of past wait times through the processor; generating a wait time recommendation for the attraction based on the wait time and the wait time threshold through the processor; and transmitting a notification of the wait time recommendation through the processor.

[0066] (Example 2 of implementation)

[0067] In a first embodiment, the method comprises the steps of determining an average past waiting time based on a plurality of past waiting times through the processor, and determining a waiting time threshold based on the average past waiting time.

[0068] (Example 3 of implementation)

[0069] In a first embodiment, the method includes the step of determining a second waiting time threshold value based on the plurality of past waiting times through the processor.

[0070] (Example 4 of implementation)

[0071] In a third embodiment, the method comprises the step of transmitting a second notification that the waiting time for the attraction is longer than expected, based on the fact that the waiting time for the attraction is greater than the second waiting time threshold, through the processor.

[0072] (Example 5 of implementation)

[0073] In a first embodiment, the method comprises the steps of receiving a total wait time for a plurality of attractions through a processor, determining a wait time ratio for an attraction through a processor based on the wait time of the attraction and the total wait time for the plurality of attractions, and determining a past total wait time for the plurality of attractions through a processor, wherein the wait time threshold includes a ratio based on the past wait time for the attraction and the past total wait time for the plurality of attractions, and the step of generating a wait time recommendation for the attraction is based on the wait time ratio and the wait time threshold.

[0074] (Example 6 of implementation)

[0075] In a first embodiment, the method comprises the steps of receiving the location of an electronic device within the theme park through the processor and from a sensor, and determining, through the processor, a set of attractions among the plurality of attractions that are within a critical distance from the electronic device.

[0076] (Example 7 of implementation)

[0077] In a sixth embodiment, the method comprises the steps of receiving, through the processor, an additional wait time corresponding to an additional attraction among the set of attractions; determining, through the processor, an additional wait time ratio between the additional wait time of the additional attraction and the existing total wait time for the plurality of attractions; and, through the processor, generating a wait time recommendation for the additional attraction based on comparing the wait time threshold and the additional wait time.

[0078] (Example 8)

[0079] In the seventh embodiment, the method comprises the step of transmitting, through the processor, an additional notification that the waiting time is longer than expected based on the fact that the additional waiting time for the additional attraction is greater than a second waiting time threshold.

[0080] (Example 9)

[0081] In the seventh embodiment, the step of determining the additional waiting time ratio through the processor includes the step of dividing the additional waiting time for the additional attraction by the plurality of past waiting times for the plurality of attractions.

[0082] (Example 10 of implementation)

[0083] As a wait time recommendation system, the system comprises a sensor configured to detect the location of an electronic device within a theme park—the theme park includes a plurality of attractions—a processor, and a memory for storing instructions, wherein when the instructions are executed by the processor, the processor determines a set of attractions within a threshold distance from the location of the electronic device among the plurality of attractions, receives a wait time corresponding to an attraction among the set of attractions, generates a wait time recommendation for the attraction based on the wait time and the total wait time of the plurality of attractions, and transmits a notification of the wait time recommendation.

[0084] (Example 11 of implementation)

[0085] In the 10th embodiment, the processor is configured to determine a waiting time ratio between the waiting time and the total waiting time of the plurality of attractions, and the waiting time recommendation is generated based on comparing the waiting time ratio with a waiting time threshold.

[0086] (Example 12)

[0087] In the 11th embodiment, the waiting time threshold is determined based on the relationship between the past total waiting time of the plurality of attractions and the past waiting time of the attractions.

[0088] (Example 13)

[0089] In the 11th embodiment, the waiting time threshold is a short waiting time threshold, and the waiting time recommendation is that the waiting time is shorter than expected based on the fact that the waiting time ratio is less than the short waiting time threshold.

[0090] (Example 14)

[0091] In the 11th embodiment, the waiting time threshold is a long waiting time threshold, and the waiting time recommendation is that the waiting time is longer than expected based on the fact that the waiting time ratio is greater than the long waiting time threshold.

[0092] (Example 15)

[0093] In the 10th embodiment, the processor is configured to remove a second waiting time corresponding to a closed attraction from the total waiting time of the plurality of attractions.

[0094] (Example 16)

[0095] A non-transient computer-readable storage medium of the type comprising instructions for generating a wait time recommendation for an attraction among a plurality of attractions of a theme park, wherein, when the instructions are executed by a processor, the processor receives from a sensor the location of an electronic device within the theme park, determines a set of attractions among the plurality of attractions that are within a threshold distance from said location of the electronic device, receives the total wait time for said attractions of the theme park, receives the wait time corresponding to said attraction among said attractions, and transmits a notification that the wait time for said attraction is longer than expected based on the fact that the wait time for said attraction is greater than a wait time threshold.

[0096] (Example 17)

[0097] In the 16th embodiment, when the instruction is executed by the processor, the processor determines a wait time ratio for the attraction among the plurality of attractions—the wait time ratio is based on the total wait time for the plurality of attractions and the wait time of the attraction—and generates a wait time recommendation based on the wait time ratio and the wait time threshold.

[0098] (Example 18)

[0099] In the 16th embodiment, when the instruction is executed by the processor, the processor receives, after a certain period, an updated wait time corresponding to the attraction among the plurality of attractions, and transmits an additional notification that the wait time for the attraction is shorter than expected based on the fact that the wait time for the attraction is less than the wait time threshold.

[0100] (Example 19)

[0101] In the 16th embodiment, the waiting time threshold is determined based on the date, time, or weather.

[0102] (Example 20 of the implementation)

[0103] In the 16th embodiment, the waiting time threshold is determined based on the past total waiting time for the plurality of attractions at a time when the past number of park attendees is correlated with the number of park attendees of the theme park.

Claims

Claim 1 A method for generating a wait time recommendation, comprising the steps of: receiving a number of park attendees of a theme park through a processor; receiving a plurality of past wait times for a plurality of attractions within the theme park through the processor; receiving a wait time for an attraction among the plurality of attractions through the processor; determining a wait time threshold for the attraction based on the plurality of past wait times through the processor; generating a wait time recommendation for the attraction based on the wait time and the wait time threshold through the processor; and transmitting a notification of the wait time recommendation through the processor. Claim 2 A method according to claim 1, comprising the steps of determining an average past waiting time based on a plurality of past waiting times through the processor, and determining a waiting time threshold based on the average past waiting time. Claim 3 A method according to claim 1, comprising the step of determining a second waiting time threshold based on the plurality of past waiting times through the processor. Claim 4 A method according to paragraph 3, comprising the step of transmitting a second notification that the waiting time for the attraction is longer than expected, based on the fact that the waiting time for the attraction is greater than the second waiting time threshold, through the processor. Claim 5 A method according to claim 1, comprising the steps of receiving a total wait time for a plurality of attractions through the processor, determining a wait time ratio for the attraction through the processor based on the wait time of the attraction and the total wait time for the plurality of attractions, and determining a past total wait time for the plurality of attractions through the processor, wherein the wait time threshold includes a ratio based on the past wait time for the attraction and the past total wait time of the plurality of attractions, and the step of generating a wait time recommendation for the attraction is based on the wait time ratio and the wait time threshold. Claim 6 A method according to claim 1, comprising the steps of receiving the location of an electronic device within the theme park through the processor and from a sensor, and determining, through the processor, a set of attractions among the plurality of attractions that are within a critical distance from the electronic device. Claim 7 A method according to claim 6, comprising the steps of: receiving an additional wait time corresponding to an additional attraction among the set of attractions through the processor; determining, through the processor, an additional wait time ratio between the additional wait time of the additional attraction and the existing total wait time for the plurality of attractions; and, through the processor, generating a wait time recommendation for the additional attraction based on comparing the wait time threshold and the additional wait time. Claim 8 A method according to claim 7, comprising the step of transmitting an additional notification that the waiting time is longer than expected, based on the fact that the additional waiting time for the additional attraction is greater than a second waiting time threshold, through the processor. Claim 9 In claim 7, the step of determining the additional waiting time ratio through the processor comprises the step of dividing the additional waiting time for the additional attraction by the plurality of past waiting times for the plurality of attractions. Claim 10 As a wait time recommendation system, a sensor configured to detect the location of an electronic device within a theme park - said theme park includes a plurality of attractions - and a processor and a memory storing instructions - said instructions, when executed by said processor, cause said processor: Determining a set of attractions among the plurality of attractions that are within a critical distance from the location of the electronic device, and Receive the waiting time corresponding to an attraction among the above attraction set, and Based on the above waiting time and the total waiting time of the plurality of attractions, a waiting time recommendation for the attraction is generated, and A waiting time recommendation system including - transmitting a notification of the above waiting time recommendation. Claim 11 A waiting time recommendation system according to claim 10, wherein the processor is configured to determine a waiting time ratio between the waiting time and the total waiting time of the plurality of attractions, and the waiting time recommendation is generated based on comparing the waiting time ratio and a waiting time threshold. Claim 12 A waiting time recommendation system according to claim 11, wherein the waiting time threshold is determined based on the relationship between the past total waiting time of the plurality of attractions and the past waiting time of the attractions. Claim 13 A waiting time recommendation system according to claim 11, wherein the waiting time threshold is a short waiting time threshold, and the waiting time recommendation is based on the fact that the waiting time ratio is less than the short waiting time threshold, and the waiting time is shorter than expected. Claim 14 A waiting time recommendation system according to claim 11, wherein the waiting time threshold is a long waiting time threshold, and the waiting time recommendation is based on the fact that the waiting time ratio is greater than the long waiting time threshold, and the waiting time recommendation is that the waiting time is longer than expected. Claim 15 A waiting time recommendation system according to claim 10, wherein the processor is configured to remove a second waiting time corresponding to a closed attraction from the total waiting time of the plurality of attractions. Claim 16 A non-transient computer-readable storage medium of a type comprising instructions for generating wait time recommendations for attractions among multiple attractions of a theme park, wherein the instructions, when executed by a processor, cause the processor: Receive the location of the electronic device within the theme park from the sensor, and Determining a set of attractions among the plurality of attractions that are within a critical distance from the location of the electronic device, and Receive the total wait time for the aforementioned multiple attractions of the aforementioned theme park, and Receive the waiting time corresponding to the attraction among the plurality of attractions, and A computer-readable storage medium that transmits a notification that the waiting time for the attraction is longer than expected, based on the fact that the waiting time for the attraction is greater than a waiting time threshold. Claim 17 In paragraph 16, when the above instruction is executed by the processor, the processor: Determining the waiting time ratio for the said attraction among the said plurality of attractions - said waiting time ratio is based on the said total waiting time for the said plurality of attractions and said waiting time of said attraction -, A computer-readable storage medium that generates a waiting time recommendation based on the above waiting time ratio and the above waiting time threshold. Claim 18 In paragraph 16, when the above instruction is executed by the processor, the processor: After a certain period, an updated waiting time corresponding to the attraction among the plurality of attractions is received, and A computer-readable storage medium that transmits an additional notification that the waiting time for the attraction is shorter than expected, based on the fact that the waiting time for the attraction is less than the waiting time threshold. Claim 19 In paragraph 16, the above-mentioned waiting time threshold is determined based on date, time, or weather, in a computer-readable storage medium. Claim 20 A computer-readable storage medium, wherein the waiting time threshold is determined based on the past total waiting time for the plurality of attractions at a time when the past number of park attendees is correlated with the number of park attendees of the theme park.

Images