Patent ID: 12210983

DETAILED DESCRIPTION

Theme park or amusement park attractions have become increasingly popular, and various amusement park attractions have been created to provide passengers with unique motion and visual experiences. Guests entering the various amusement park attractions may utilize a virtual queuing system that places the guests in a virtual queue rather than a physical queue, which allows the guests to enjoy other features of the amusement park while their position in the virtual queue advances. To help guests plan their day, the virtual queuing system may estimate wait times (e.g., a length of time before the guest may enter the attraction) and provide a reminder to the guest that the time to enter the attraction is approaching. However, in determining wait times for guests for each attraction, certain virtual queuing systems assume average wait times or average guest return rates, or may utilize predetermined or preconfigured wait times for a static number of rides (e.g., guest-accepting features of the attraction, such as individual ride vehicles, individual lanes of a multi-lane slide, individual tracks of a multi-track attraction, etc.) within a specific attraction. Using data based on a static number of rides to determine wait times may fail to dynamically react to queue conditions (e.g., ride closures and openings at an attraction). Indeed, such virtual queuing systems may provide inaccurate wait times for guests, which may lead to excessive or deficient wait times and cause inefficient operation of the amusement park attractions.

With this in mind, certain embodiments of the present disclosure relate to virtual queuing systems that determine wait times by monitoring and/or dynamically evaluating the virtual queue based at least on queue conditions and scheduling information for the amusement park attraction. Embodiments of the present disclosure facilitate dynamically modifying queue operations in response to received feedback associated with the wait times. Specifically, certain embodiments of the present disclosure relate to determining wait times by monitoring and evaluating dynamic variations in open/close times for various attractions (or various rides within a specific attraction) in addition to queue conditions when determining wait times for attractions. In particular, the virtual queue system may be configured to utilize scheduled times for each attraction, current or real-time guest throughput for an attraction, estimated guest throughput in the future, a historical throughput for each attraction, and/or historical queue wait time information to accurately determine wait times for a particular attraction to avoid communicating inaccurate wait times to guests. In this manner, the virtual queuing system may help to prevent ride underutilization, ride overcrowding, and/or inefficient use of ride resources over a period of time. Additionally, certain embodiments of the present disclosure relate to automatically or dynamically modifying queue operations or the actual virtual queue in response to deficient or excessive wait times to further prevent inefficient operations, ride underutilization, ride overcrowding, and/or wasting ride resources over a period of time. Further, the virtual queuing system may be configured to monitor and track how the guests transition or move throughout the queue to provide for a more granular control of the virtual queue. Accordingly, based on a more granular control of the virtual queue, the virtual queuing system may be configured to have automatic and dynamic control of attraction access, thereby preventing ride starvation, overcrowding, or wasting other ride resources.

FIG.1is a schematic representation of a theme park110with at least one amusement park attraction112that may be accessed via a virtual queue that is controlled by a virtual queue system114. Certain attractions112may feature a plurality of rides118. For example, in the depicted embodiment, a water slide attraction112amay include multiple lanes or slides (e.g., shown as rides118a,118b, and118c) that are accessed via a single virtual queue, which permits access to a loading area116for the guests. That is, the guests assume a position in a virtual queue for the attraction112ato enter the loading area116. Once in the loading area116, the guests are distributed between separate slides (i.e., rides118a,118b, and118c) to experience the attraction112. Accordingly, in the depicted embodiment by way of example, the attraction112ais capable of accommodating multiple guests (e.g., two, three, or more) at a time. However, the guests may enter their assigned ride118at different rates, leading to dynamically changing real-time guest throughput rates for each ride118of the multi-ride attraction112. For example, certain guests may be more hesitant than others, leading to a temporarily slower real-time guest throughput rate in one ride118relative to another. Further, the ride operators may have different efficiencies in distributing and loading guests into their respective rides118. Accordingly, determining a total guest throughput for a multi-ride attraction112may be complex and may involve taking into account different real-time guest throughput rates at each individual ride118of the attraction112to determine a total guest throughput for the attraction112.

While the depicted embodiments are shown in the context of water attractions, such as water slides, it should be understood that other multi-ride attractions112are contemplated. Further, the rides118of an individual attraction112may include any suitable number of rides118(slides, tracks, paths vehicles, etc.) accommodating any suitable number of guests that are nonetheless accessed via a single virtual queue for the attraction112. In addition, the theme park110may also feature other attractions112that do not include multiple rides118, e.g., single ride attractions112.

In one embodiment, via the virtual queue system114, guests are assigned a position in a virtual queue for the amusement park attraction112after submitting a request from a guest-associated device120(e.g., smart phone, guest wrist band) or a guest kiosk121and need not physically queue to enter the attraction112until a designated time. Thus, guests using a virtual queue may spend less time waiting in lines during their visit to the theme park110. Additionally, data from the virtual queue provides guidance to the theme park for scheduling ride openings and closures to optimize guest throughput and amusement park attraction efficiency.

In some embodiments, the virtual queue system has a plurality of virtual queues, each corresponding to a separate amusement park attraction (e.g.,112aand112b). To aid guests in determining which virtual queue to enter, the virtual queue system114is configured to output a wait time signal122indicating current wait times for each amusement park attraction112. A display unit126may be configured to receive the wait time signal122and display the current wait times for guests within the theme park110. The display unit126may be a central display unit configured to display the current wait times corresponding to a plurality of amusement park attractions. However, in some embodiments, the display unit126may be a localized display unit configured to display a current wait time for a single amusement park attraction. In another embodiment, a guest-associated device120(e.g., smart phone, guest wrist band, guest tracker, etc.) may receive the wait time signal122and display the current wait times for a guest (e.g., text message, smart phone app. notification, etc.).

In certain embodiments, the wait time signal122transmits the current wait time, a guest wait time (i.e., a wait time for an individual guest in the virtual queue), or some combination thereof. The current wait time indicates the time that an unqueued guest should anticipate waiting before entering the amusement park attraction112if joining the virtual queue at that time. In contrast, the guest wait time indicates the time that an individual guest, already having a position in the virtual queue, still has to wait until entering the amusement park attraction112. Thus, the guest wait time corresponds to a specific position of an individual guest already queued in the virtual queue, whereas the current wait time corresponds to the next available position (i.e., an unassigned position) in the virtual queue.

In an embodiment, the virtual queue system114determines wait times based at least on scheduling information or ride schedule data for the attraction112. Ride schedule data includes planned ride openings and closures for the attractions112at specified times during theme park hours as well as dynamic openings or closures in response to desired crowd flow. In the depicted embodiment, the attraction112aincludes three rides118a,118b, and118c(e.g., slides, ride vehicles, seats, etc.) accessed by a single virtual queue. One or more of the three rides118may close during park hours, e.g., at specified times, determined by or included in a ride schedule, for the purpose of increasing attraction efficiency. For example, each of the three rides118may have an average historical guest throughput potential of one hundred and twenty guests per hour. Thus, in the depicted embodiment, a second ride118band a third ride118cmay close during times of the day when guest throughput is historically low. When guest throughput is low, opening only a first ride118amay allow the attraction to maintain sufficient guest throughput to keep the wait times low while requiring fewer employees to operate the attraction112a. In contrast, when guest throughput is historically high, the attraction may open the second ride118band the third ride118cto increase guest throughput in order to minimize the wait times. Because opening and closing rides118of the attraction112dynamically changes real-time guest throughput and future guest throughput during the closure times, having the virtual queue system114determine wait times based at least on scheduling information may provide more accurate wait times for guests. Thus, scheduling information regarding dates, times, and other details as to ride closures and openings is sent to a virtual queue controller130of the virtual queue system114. In certain embodiments, scheduling information is automatically transmitted to the virtual queue controller130from a theme park database. In other embodiments, a user may manually enter or modify scheduling information for the virtual queue controller using an operator interface132.

FIG.2is a flow diagram of a method234of determining the current wait time (e.g., for an as-yet unqueued guest) and the guest wait time for guests in the virtual queue of the attraction112using a virtual queue system114in accordance with present embodiments. The method includes providing ride schedule data for the attraction112to the virtual queue controller114, wherein the ride schedule data includes specified times for the one or more rides to open and close (block236), and wherein opening and closing the one or more rides increases or decreases estimated guest throughput of the attraction accordingly, calculating variable guest throughput data, wherein the variable guest throughput data is calculated based at least on the ride schedule data and historical guest throughput data for the attraction (block238), determining a current wait time for the next available position in a virtual queue for the attraction112based on at least the next available position and the variable guest throughput data (block240), outputting a wait time signal to a display unit, a guest-associated device, or a combination thereof, indicating the current wait time for the next guest to queue for the attraction112(block242), assigning a guest to a position in a virtual queue for an attraction in response to a guest queue request (block244), determining a guest wait time for the guest based on at least the position in the virtual queue and the variable guest throughput data (block246), and outputting a wait time signal to the guest-associated device indicating the guest wait time (block248). Details of the aspects of the method234will be discussed in further detail herein with respect to related system features.

In certain embodiments, the method234includes the step of further calculating the variable throughput data based on current or real-time guest throughput data. In some embodiments, the method234includes the step of providing queue condition data for the attraction112to a virtual queue controller114, wherein the queue condition data includes at least current guest throughput data for the amusement park attraction.

In certain embodiments, the virtual queue controller130is configured to continuously or periodically determine the guest wait time and to continuously output the wait time signal to the guest-associated device120indicating an updated guest wait time. In other embodiments, the virtual queue controller130is configured to determine the guest wait time in response to an update request from the guest. The virtual queue controller130may limit the number of update requests that a guest may issue. In other embodiments, the virtual queue controller130may limit the rate at which guests may issue update requests. In some embodiments, the virtual queue controller130is configured to output the wait time signal when the virtual queue controller determines that the guest wait time has changed by more than a pre-determined amount of time. For example, the virtual queue controller130may output a new wait time signal when the guest wait time has changed by more than two minutes.

FIG.3is a block diagram of the virtual queue system314. The virtual queue system includes a virtual queue controller330(e.g., the virtual queue controller130) in communication with the guest-associated device320, the display unit326, or a combination thereof. To enter the virtual queue for an attraction112, the guest-associated device320transmits a queue request signal350to the virtual queue controller330in response to an input from a guest. The virtual queue controller330receives the queue request signal350, determines a wait time for the guest, and outputs a wait time signal322to the guest-associated device320, the display unit326, or a combination thereof. The guest-associated device320and the display unit326are configured to receive the wait time signal322and display the wait time for the guest. To enable these communications, the guest-associated device320, the display unit326, and the virtual queue controller330may include communications circuitry352, such as antennas, radio transceiver circuits, signal processing hardware and/or software (e.g., hardware or software filters, A/D converters, multiplexer amplifiers), or a combination thereof. The communications circuitry352may be configured to communicate over wired or wireless communication paths via IR wireless communication, satellite communication, broadcast radio, microwave radio, Bluetooth, Zigbee, Wifi, UHF, NFC, etc. Such communication may also include intermediate communications devices, such as radio towers, cell towers, etc.

In certain embodiments, the virtual queue controller330may include a memory device354astoring instructions executable by a processor356ato perform the methods and control actions described herein. For example, the processor356amay execute instructions for dynamically evaluating virtual queue conditions and determining wait times for guests based on guest throughput inputs358and ride schedule data inputs360received by the virtual queue controller330. The ride schedule data inputs may be received through user input, from a memory storage, and/or through cloud services. The virtual queue controller330may receive scheduling (or re-scheduling) information in real-time, and may be configured to update wait times based on the updated schedule. In certain embodiments, the virtual queue controller330may receive and utilize additional inputs in combination with the ride schedule data inputs360and guest throughput inputs358when determining wait times.

Further, in certain embodiments, the processor356amay utilize historical queue condition data inputs362(e.g., historical weather information, previous guest behavior within a particular ride/attraction, calendar information (e.g., time of day, day of week, holidays, etc.), demographic information, number of guests within a group(s), and so forth) in combination with the ride schedule data inputs360and/or guest throughput inputs358when determining wait times. For example, the processor356amay account for historically slower crowds or colder seasons conditions when providing wait times. As a further example, in certain embodiments, the processor356amay utilize various characteristics of the guests (e.g., type, gender, age, number, etc.) within the queue, in combination with the ride schedule data inputs360and guest throughput inputs358, in order to determine wait times. While the guest throughput inputs358, ride schedule data inputs360, and historical queue condition data inputs362are depicted as being received via an operator interface332, it should be understood that the various inputs to the virtual queue controller330may be received from other components of the system314. In one embodiment, the guest throughput inputs358comprise real-time throughput information that is transmitted to the virtual queue controller330based on guest-associated device320interaction with a check-in or tap-in device or by passing through a gate at each attraction112. For example, as each guest enters the attraction112, the associated guest identification information from the guest-associated device320is read by a reader comprising communication circuitry and associated with the attraction. In an embodiment, each individual ride118of the attraction112is configured to provide guest identification from a reader positioned at a top or start of each ride118. The guest identification information, associated attraction112information and/or ride118information, and timestamp may be provided to the virtual queue controller330as inputs to determine dynamic real-time guest throughput (e.g., guests/hour). Further, the attraction112may also include a reader at a ride exit to track total time through the ride118as a variable in determining real-time guest throughput. In another embodiment, the real-time guest throughput may be based on operator information. For example, a ride operator may track a number of guests and provide guest numbers periodically to the operator interface332. Further, the virtual queue controller330may store the guest throughput information to update historical queue condition inputs362using acquired guest throughput data.

The processor356aof the virtual queue controller330may include one or more processing devices, and the memory may include one or more tangible, non-transitory, machine-readable media. By way of example, such machine-readable media can include RAM, ROM, EPROM, EEPROM, or optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by the processor or by other processor-based devices (e.g., mobile devices). For example, the virtual queue controller330may be accessed by an operator interface332(e.g., a computer-based workstation or a mobile device, and/or may include an input/output interface364and a display).

In certain embodiments, the guest-associated device320, having a processor356band a memory354b, may be a personal guest device (e.g., smart phone, tablet, laptop, etc.) or a park queue device assigned to guests (e.g., smart wrist bands, portable communication devices, etc.). Park queue devices include a program for viewing wait times and sending queue requests. Guests using personal guest devices may be given access to the program (e.g., web based program, smart phone app., downloadable program, etc.). For example, an admission ticket to the theme park or a confirmation email may include details for finding the program, as well as a username, a passcode, or a combination thereof, for accessing the program. Personal information associated with a guest (height, weight, age, and other demographics) may be linked to the username and/or passcode, such that the guest identification information may be transmitted with the queue request signal. A guest using park queue devices may have their guest information uploaded to the park queue device when the device is assigned to the guest. The virtual queue controller330may utilize guest identification information determining wait times as provided herein.

In certain embodiments, the system may include a queue station (e.g., guest kiosk121) that includes a processor and a memory, and is configured to provide an additional resource for guests to view times and send queue requests. Guests may access queuing functionality on the queue station using a form of guest identification (e.g., username, passcode, card, RF wristband, personal information, etc.). Queue stations may be disposed at various locations around the theme park110. In some embodiments, at least one queue station is disposed proximate an entrance of each attraction112, such that guests are provided a means to queue for the attraction112at a location proximate the attraction112. In some embodiments, queue stations may only permit guests to queue for the attraction112most proximate the queue station. In other embodiments, general queue stations are located throughout the theme park110, which may be used to queue for attractions112in the theme park110.

In certain embodiments, the display unit326is configured to receive the wait time signal322from the virtual queue controller330and display current wait times for the attractions112. In some embodiments, at least one display unit326is disposed proximate an entrance of each attraction112. The display unit may be configured to display only the current wait time for the attraction112most proximate the display unit. In other embodiments, general display units are disposed in general locations (e.g., eating areas, walking paths, etc.) around the theme park110. General display units may display current wait times for a plurality of attractions112.

FIG.4is a block diagram of the virtual queue system414having a monitoring device466. In the present embodiment, the monitoring device466may have communication circuitry452dto establish communication with the virtual queue controller430. The monitoring device466may also have a processor456cand a memory device454c. The monitoring device466is configured to monitor and/or determine current queue conditions and output a queue condition signal468to the virtual queue controller430. In some embodiments, the attraction112has both a physical queue and a virtual queue. In such embodiments, a guest first enters a virtual queue before entering the physical queue. The physical queue provides a buffer queue or a standby area for the attraction112to increase efficiency of the attraction112. For example, in the event that a guest does not arrive to the attraction112at the time designated by the virtual queue system414, without a physical buffer queue, it is possible that no guest would be present to fill the position of the absent guest. Therefore, at least one ride118of the attraction112may proceed with less than maximum occupancy of the ride, thereby, decreasing efficiency of the attraction112. However, using both a physical queue and a standby area, a plurality of guests may be present at the attraction112to fill the ride to max occupancy, even when a guest does not arrive on time. In certain embodiments, the monitoring device466is configured to monitor current queue conditions of the physical queue. However, the monitoring device466may be configured to monitor current queue conditions of the physical queue, the virtual queue, or a combination thereof. Further, in certain embodiments, the attraction112may be implemented without a physical queue.

In certain embodiments, the monitoring device466may be configured to monitor or determine current queue conditions, including, but not limited to, the length of the queue, number of guests in the queue, flow rate of the guests entering and exiting the queue, particular individuals within the queue (e.g., identify guests in the queue), number of sub-queues within the queue, types of guests within the queue, and so forth. In certain embodiments, the monitoring device466may monitor particular locations (e.g., geographical location, queue zones, etc.) within the queue and output the number of guests in each particular location to the virtual queue controller. In certain embodiments, the monitoring device466may monitor guests not just at the beginning or end of the queue, but may also monitor whether guests leave the queue in the middle of the queue. In certain embodiments, the monitoring device466may determine various characteristics of the guests (e.g., type, gender, age, number, etc.) within the queue and output that data to the virtual queue controller430to track and record historical throughput data associated with the queue as it relates to the attraction112.

In certain embodiments, the monitoring device466includes a counting mechanism470configured to monitor queue conditions. For example, the number of guests within the queue may be monitored with a counting mechanism470, which may be a manual system and/or may include one or more sensors disposed proximate to the queue. In other embodiments, the monitoring device may include at least one sensor472(e.g., optical sensors, mechanical treadles, RF sensing systems, etc.) disposed physically proximate to the queue, and communicatively coupled to the virtual queue controller430. The sensors472may provide continuous feedback to the virtual queue system414associated with current queue conditions. For example, in situations where guests each carry RF identification, RF sensors associated with the monitoring device may be configured to monitor when the particular guest(s) enters and exits the queue and output that data to the virtual controller. As a further example, the sensors472may be configured to recognize individual guests at the entrance and exit of the queue and continuously output that information to the virtual queue controller, such that various conditions of the queue (e.g., wait time, queue length, etc.) may be calculated based on length of time individual guests spend within the queue.

Based on the received feedback, the virtual queue system414may be configured to dynamically respond to current queue conditions. In certain embodiments, the virtual queue system414may include the functionality to automatically remove a guest from the virtual queue based on one or more factors (e.g., been in the queue for an extended period of time past current queue wait time, guest is seen at an unexpected location within the queue, guest enters another queue, guest is recognized outside of the queue, etc.). In certain embodiments, the virtual queue system414may virtually monitor and dynamically adjust a plurality of queues (or sub-queues), and may be configured to correlate the data for a variety of queues when calculating or determining current queue conditions.

In certain embodiments, the virtual queue system414may utilize the feedback received from the monitoring device466to calculate other queue conditions. The virtual queue system414may calculate various factors or variables, such as, but not limited to, length of the virtual queue, current or real-time guest throughput, maximum attraction throughput, historical information related to queue conditions and responses (e.g., historical guest throughput), length of time that the queue is in different states (overfill state, under-fill state, starvation state, overcrowding state, etc.), and so forth. For example, based on the number of guests within the queue and/or the flow rate of the guests entering or exiting the queue, the virtual queue system414may calculate current wait times, guest wait times, current attraction capacity, and so forth. In particular, the virtual queue system414may be configured to determine accurate real-time information related to the queue system and queue conditions, based at least in part on the continuous feedback received from the monitoring device466.

In another embodiment, in response to determined wait times for guests in the virtual queues and/or physical attraction access areas, the virtual queue system414may be configured to output a queue modification signal474. Specifically, the virtual queue system may be configured to dynamically respond to deviations of the calculated wait times for guests from a wait time range by outputting a queue modification signal474.

In certain embodiments, the queue modification signal474is configured to temporarily disable the ability to add a guest to the virtual queue for an attraction112when the wait time for the attraction is longer than a maximum limit of the wait time range. For example, when the virtual queue is deemed too long by the virtual queue controller430, the virtual queue controller is configured to output the queue modification signal474to the guest-associated device420(e.g. smart phone, guest kiosk, etc.). The queue modification signal474is configured to transmit instructions to a queue program, on the guest-associated device420, to disable an option to send a queue request for the attraction112. Additionally, the queue modification signal474may include instructions to display a message in relation to disabling a portion of the queue program. Once wait times of the virtual queue fall back down to a length of time within the wait time range, the virtual queue controller430may be configured to send a resume signal476to enable the option to send queue requests.

In certain embodiments, the queue modification signal474includes instructions to notify guests of a shorter than average queue time for an attraction112when the wait time for the attraction is shorter than the minimum limit of the wait time range. For example, the queue modification signal474may include instructions for the guest-associated device to display a message indicating that the attraction112has a short wait time. In some embodiments, the queue modification signal474may include instructions to activate a quick queue option in the program on the guest-associated device120. For example, the quick queue option may activate a pop up message the screen that indicates that the virtual queue has a short wait time. Additionally, the pop up message may include a button configured to immediately enter the guest into the virtual queue for the attraction112. In certain embodiments, the virtual queue controller430is configured to send the queue modification signal474to guest-associated devices420linked to guests that have experienced fewer attractions112during that day than other guests at the theme park110before sending the queue modification signal to the other guests, thereby giving a first opportunity to enter the virtual queue to individuals who have experienced fewer attractions112. In certain embodiments, the program includes an option to dismiss messages activated in response to the guest-associated device receiving the queue modification signal474. However, once wait times of the virtual queue rise up to a length of time within the wait time range, the virtual queue controller is configured to send the resume signal to automatically dismiss notifications from the queue modification signal.

In certain embodiments, the virtual queue controller is configured to send an attraction modification signal478to an amusement park operator device480in response to the wait times longer than the maximum limit or shorter than the minimum limit of the wait time range. The attraction modification signal is configured to send instructions to an amusement park operator to open and/or close rides of an amusement park ride118to adjust current guest throughput in response to the wait times. In addition to disabling the virtual queue or sending notifications, dynamically opening and closing rides118of an attraction112may further increase amusement park attraction efficiency.

FIG.5is a graph showing the wait times582and a wait time range584for the virtual queue. The wait time range provides a minimum wait time586and a maximum wait time588for acceptable wait times at particular times, e.g., whereby wait times between the minimum wait time586and the maximum wait time588may bound a predetermined desired wait time range. When wait times582as calculated or estimated by the virtual queue controller (e.g., virtual queue controller430) as provided herein fall below the minimum wait time586or rise above the maximum wait time588, the virtual queue controller430is configured to output the queue modification signal474. In certain embodiments, the virtual queue controller430calculates the wait time range584based at least on historical throughput data. The virtual queue controller430may determine an average wait time590for an attraction112for each time slot of a day using the historical throughput data. The virtual queue controller430may determine a plurality of average wait times, wherein an average wait time is calculated for each time slot of each day of a week, month, year, etc. For example, the virtual queue controller430may calculate an average wait time for an attraction112at 10 a.m. by averaging all historical throughput data for the time slot of 10 a.m. However, in other embodiments, the virtual queue controller430calculates an average wait time for Monday at 10 a.m. by averaging all historical throughput data for every Monday at 10 a.m. Additionally or alternatively, the virtual queue controller430may further utilize historical queue condition data (e.g., historical ride schedule data, historical guest throughput, weather data, guest behavior, calendar information, demographic info, number of groups of guests, size of groups of guests, etc.) in determining the plurality of average wait times590.

In certain embodiments, the virtual queue controller430may calculate the wait time range584by adding a wait time buffer to the average wait time590. For example, the virtual queue controller430may calculate average wait times for 9 a.m., 11 a.m., 1 p.m., and 3 p.m. to be five, twenty, forty, and thirty-five minutes respectively. The virtual queue controller430may provide a five minute wait time buffer to the average wait times to calculate the wait time range. Thus, the wait time ranges at 9 a.m., 11 a.m., 1 p.m., and 3 p.m. are 0-10 minutes, 15-25 minutes, 35-45 minutes, and 30-40 minutes respectively. In other embodiments, the virtual queue controller430may calculate the wait time range584using a dynamic wait time buffer. The dynamic wait time buffer may change a length of time of the wait time buffer at different time slots of a day. For example, a wait time buffer at 9 a.m. may be five minutes, while a wait time buffer at 1 p.m. may be fifteen minutes. In other embodiments, the dynamic wait time buffer includes a longer wait time buffer between the average wait time and the maximum limit than the wait time buffer between the average wait time and the minimum limit. In some embodiments, the dynamic wait time buffer may be determined using historical throughput data, operator input, etc.

In certain embodiments, the wait time range may be set based on inputs receive by the virtual queue controller430. In some embodiments, the virtual queue controller430is configured to receive an input from the operator interface332. An operator may transmit instructions for the virtual queue controller430to set specific wait time ranges using the operator interface332. The operator may set static or dynamic wait time ranges. In some embodiments, an operator may set a wait time range independent of historical throughput data. For example, in the event that an attraction112is temporarily under staffed, an operator may adjust the wait time range584of the attraction112to decrease guest throughput of the attraction112until the attraction112is properly staffed. In another example the operator may adjust the wait time ranges584for a plurality of attractions112to encourage guests to queue for the particular attraction112, in order to prevent overcrowding of other attractions112or locations.

In certain embodiments, the virtual queue controller430may determine wait times582for a position in the virtual queue based on variable guest throughput data and ride schedule data. Generally, the virtual queue controller430calculates a variable guest throughput based at least on current guest throughput data, historical throughput data, historical ride schedule data, etc. The variable guest throughput data represents an expected guest throughput for a single ride118of the attraction112for each time slot during park hours. The virtual queue controller430is configured to predict expected guest throughput data at least based on deviations of current guest throughput data with respect to historical throughput data and other queue conditions. To accurately analyze throughput variations and prevent scheduling variations from skewing the calculation, the current guest throughput data and the historical throughput data are first divided respectfully by the number of rides currently open and the number of rides historically open (i.e., to determine current guest throughput data and historical guest throughput data for a single ride). Further, the virtual queue controller430is configured to dynamically multiply the expected guest throughput data for a single ride according to the ride schedule data to determine an expected guest throughput for each time slot during the park hours. The virtual queue controller430is configured to utilize the expected guest throughput, current queue conditions (e.g., number of guests in queue, etc.) in relation to the guest position to determine wait times.

As an exemplary embodiment, in certain situations, an attraction112may include one or more rides118that open and close at different times throughout the day. For example, a first ride118aof an attraction112may open concurrently with the opening of theme park110, and a second ride of the attraction112may open an hour after the theme park110opens. Each ride of the attraction112may have a throughput of 120 guests per hour. Features of the present disclosure enable the virtual queuing system to utilize the scheduled open/close times of each ride during the day to determine wait times for the attraction112. For example, the virtual queuing system accounts for the delayed opening time of the second ride118bwhen determining a wait time for the attraction112. In this manner, the virtual queuing system may provide an accurate wait time for the attraction112, rather than an artificially low wait time that would be associated with the cases of all rides118being open. In other words, when one or more of the rides118are closed, the estimated total guest throughput of the attraction112will be reduced. Further, the virtual queuing system114accounts for the one hour delay in opening the second ride118bduring wait times assigned before the second ride118bis scheduled to open.

For example, in an embodiment, a guest requests a position in the virtual queue such that the guest wait time for the attraction112encompasses or overlaps a first time period in which a subset of the rides118are closed and a second time period in which all of the rides118are open. That is, some or all of the closed rides118are opened while the guest is in the virtual queue. Accordingly, the attraction112has an estimated lower guest throughput during the first time period and an estimated higher guest throughput during the second time period. By using the lower guest throughput and the higher guest throughput, a more accurate guest waiting time may be determined. In this manner, the virtual queuing system may avoid periods of ride starvation (when artificially high wait times are reported), or ride overcrowding (when artificially low wait times are reported).

In one embodiment, for the attraction112, historical guest throughput data may show that, on average at 1 p.m., the attraction112has a guest throughput of 240 guests per hour and a guest throughput at 2:00 p.m. of 220 guests per hour, both with two rides open. The current conditions, as determined by the monitoring device466, indicate that the current guest throughput of the ride at 1 p.m. is 120 guests per hour with one ride118aopen. However, ride schedule data provided to the virtual queue controller430indicate that a second ride118bis scheduled to open at 1:30 p.m. First, the virtual queue controller may determine that the historical guest throughput for one ride vehicle at 1:00 p.m. is 120 guests per hour, and that the ride throughput per vehicle is on par with historical guest throughput data. However, the historical guest throughput data shows a trend indicating that at 2:00 p.m., guest throughput for one ride vehicle historically decreases to 110 guests per hour. The virtual queue controller430may be configured to consider the decreasing guest throughput in calculating wait times. Additionally, although the current guest throughput is only 120 guests per hour, the virtual queue controller is configured to increase the expected guest throughput by a factor of two at 1:30 p.m. to account for the opening of the second ride vehicle. The expected ride throughput should increase to 240 guests per hour minus the anticipated decrease in guest throughput. Thus, the expected ride throughput at 1:30 p.m. may be 230 guests per hour. Using the estimated guest throughput data and current queue conditions in relation to the guest position, the virtual queue controller may dynamically determine wait times582. Additionally, in certain embodiments, the virtual queue controller may continually calculate the variable guest throughput to account for changes in current guest throughput and other queue conditions, in order to provide guests with updated wait times.

In some embodiments, the virtual queue controller430further utilizes other queue conditions to determine wait times582. Specifically, the virtual queue controller430may be configured to consider various factors, such as, but not limited to, previous guest behavior, guests' current activities within and outside of the queue, current location or historical locations of the guest within the park, weather, calendar information (e.g., time of day, day of week, holidays, etc.), demographic information, number of guests within a group(s), and so forth. Further, in certain embodiments, the virtual queue controller430may record real-time queue conditions as historical queue condition information for future use. For example, acquired real-time queue conditions may indicate that one ride118ahas historically slower guest throughput relative to the other rides118b,118c, even if all three rides118are otherwise alike or of a same type. Such slower throughput may be because an entrance in the loading area for the ride118ais farther from the entrances of the other rides118b,118c, because a loading angle involves slower loading, or because show props adjacent the ride118acause guests to linger at the ride entrance. Accordingly, a more accurate estimated guest wait time may take into account which of the rides118is closed and use historical guest throughput information associated with each individual ride118. For example, when the slower ride118ais closed, the estimated guest wait time may use historical guest throughput for the faster rides118b,118cand not from the closed slower ride118ain calculating an estimated guest wait time.

In certain embodiments, the virtual queue controller430may be configured to determine the wait times582for each attraction112based on a coordinated analysis of other queue conditions. For example, in certain embodiments, the virtual queue controller430may receive ride schedule data and guest throughput data for a plurality of attractions112, and may be configured to coordinate the wait times582for the attractions112based on the received data. In certain embodiments, the virtual queue controller430may utilize other types of data to perform a coordination analysis. For example, the virtual queue controller may receive crowd flow data and/or wait times for other rides, and may utilize this data to provide accurate wait times582for each attraction112.

While only certain features of the present disclosure have been illustrated and described herein, many modifications and changes will occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the disclosure.

The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).