Virtual queue methods

Abstract

To provide a virtual queue system.SOLUTION: The virtual queue system includes a virtual queue controller comprising a processor and a memory, where the memory stores instructions executable by the processor and is configured to receive a request, the request being associated with an individual amusement park guest, for a position in a virtual queue of an attraction, assign the individual guest to the position in the virtual queue in response to the request, receive ride schedule data for the attraction comprising information about a change in status of individual rides of the attraction, and determine a wait time for the guest for the attraction based at least on the position of the individual guest in the virtual queue, the ride schedule data, and historical guest throughput at the attraction. The virtual queue system is further configured to output a signal to a guest-associated device indicating the wait time for the attraction.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] (Related Applications) This application claims priority to U.S. Provisional Patent Application No. 62 / 419,837, filed November 9, 2016, entitled "Systems and Methods for Pre-Scheduling In Virtual Queuing Systems," and U.S. Provisional Patent Application No. 62 / 419,833, filed November 9, 2016, entitled "Systems and Methods for Automatically Monitoring and Dynamically Adjusting A Queue," which are hereby incorporated by reference in their entireties for all purposes.

[0002] (Technical field) FIELD OF THE DISCLOSURE The present disclosure relates generally to the field of amusement parks. Specifically, embodiments of the disclosure relate to a method of managing an amusement park, including queuing for attractions. [Background technology]

[0003] Since the early 20th century, amusement parks have grown significantly in popularity. To accommodate this increased demand, amusement parks have expanded by adding attractions and space. The addition of attractions (e.g., rides, restaurants, stores, and shows) generally provides an amusement park with additional capacity to handle more visitors. However, the addition of attractions also typically provides potential visitors with an incentive to visit the amusement park. Thus, while a particular amusement park may add additional capacity, this additional capacity does not necessarily result in an increase in the ability of visitors to participate in the amusement park's entertainment (e.g., shopping, viewing a show, riding a ride) or a reduction in wait times for attractions. This is often due to the presence of a corresponding increase in attendance. Furthermore, for operational efficiency, it is often desirable to limit attraction occupancy rates during times of low attendance. Thus, queuing for attractions is a persistent challenge for amusement parks, as it can limit participation in amusement park activities.

[0004] Guests are demanding bigger, better and more elaborate attractions, while at the same time demanding and expecting an overall positive experience. Providing an overall positive experience for guests at an amusement park requires addressing certain challenges associated with queuing for attractions. It is recognized that, in fact, guests at an amusement park may be deterred from returning to a particular amusement park due to undesirable experiences associated with waiting in line. Furthermore, guests may be prevented from using establishments (e.g., stores) at the amusement park due to time spent waiting in line. In fact, traditionally, guests have waited in line for hours to experience some of the more popular attractions at an amusement park. In addition, it is recognized that the capacity of an amusement park may not result in efficient guest utilization of that capacity due to individual guest preferences for certain attractions over others. Thus, it is now appreciated that improved amusement park queuing systems and methods are desirable. Summary of the Invention [Problem to be solved by the invention]

[0005] Certain embodiments falling within the scope of the initially claimed invention are summarized below. These embodiments are not intended to limit the scope of the disclosure, but rather, the embodiments are intended only to provide a brief summary of certain disclosed embodiments. Indeed, the disclosure may include a variety of forms that may be similar to or different from the embodiments set forth below. [Means for solving the problem]

[0006] According to one embodiment, a virtual queue system is provided. The virtual queue system includes a virtual queue controller having a processor and a memory. The memory stores instructions executable by the processor and is configured to receive a request. The request is for a position in a virtual queue of an attraction associated with an individual guest and having a plurality of rides. The virtual queue allows the individual guest to access one of the plurality of rides of the attraction, and guests in the virtual queue are distributed among the plurality of rides via the virtual queue. The memory is further configured to assign the individual guest to a position in the virtual queue in response to the request, receive ride schedule data for the ride including information regarding changes in status of the individual rides of the plurality of rides, and determine a guest wait time for the attraction based at least on the individual guest's position in the virtual queue, the ride schedule data, and historical guest throughput at the attraction. The virtual queue system further includes a communication circuit configured to output a signal indicative of the wait time for the attraction to a guest associated device.

[0007] According to another embodiment, a virtual queue system is provided. The virtual queue system comprises at least one monitoring device configured to monitor a current queue status of an attraction and output a queue status. The virtual queue system also comprises a virtual queue controller including a controller and a communication circuit. The virtual queue controller is configured to receive the queue status signal. The virtual queue controller is also configured to determine a current wait time for the attraction based at least on the queue status signal and preset ride schedule data for the attraction, the preset ride schedule data indicating closure of a subset of a plurality of rides for the attraction. The virtual queue controller is further configured to output a queue modification signal in response to the determined current wait time being outside of a preset wait time range.

[0008] According to another embodiment, a method is provided that includes providing ride schedule data for an attraction including a plurality of rides to a virtual queue controller, the ride schedule data including scheduling times associated with closures of the plurality of rides, calculating variable guest throughput data for the attraction, the variable guest throughput data being calculated based at least on current guest throughput data, the ride schedule data, and historical guest throughput data for the attraction, determining a current wait time for a next available position in the virtual queue for the attraction based at least on a next available position in the virtual queue and the variable guest throughput data, the current wait time overlapping a scheduling time such that a subset of the plurality of rides experiences a closure during the current wait time, the current wait time being calculated based on first variable guest throughput data indicative of a first guest throughput during the closure and second variable guest throughput data indicative of a second guest throughput during a time outside of the closure, and outputting a current wait time signal indicative of a current wait time to queue for the attraction to a display device, a guest associated device, or a combination thereof.

[0009] These and other features, aspects, and advantages of the present disclosure will become better understood when read in conjunction with the accompanying drawings, in which like characters represent like parts throughout the drawings, in which: [Brief description of the drawings]

[0010] [Figure 1] 1 is a schematic diagram of a theme park including a virtual queuing system in accordance with the present technology; [Diagram 2] FIG. 2 is a flow diagram of a method for using a virtual queuing system in accordance with the present technique. [Diagram 3] 1 is a block diagram of a virtual queuing system in accordance with the techniques of the present invention; [Figure 4]1 is a block diagram of a virtual queuing system including a monitoring device in accordance with the present technique; [Diagram 5] 4 is a graph illustrating waiting time ranges in a virtual queuing system in accordance with the techniques of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Theme park or amusement park attractions are becoming increasingly popular, and various amusement park attractions are being produced that provide passengers with unique motion and visual experiences. Guests entering various amusement park attractions may utilize a virtual queuing system that places the guest in a virtual queue rather than a physical queue, thereby allowing them to enjoy other amenities 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., the length of time it will take for the queue to be able to enter the attraction) and provide reminders to guests that it is approaching time to enter the attraction. However, in determining guest wait times for each attraction, a particular virtual queuing system may assume an average wait time or an average guest return rate, or may utilize pre-set or pre-configured wait times for a fixed number of rides within a particular attraction (e.g., the attraction's guest-acceptable amenities, such as individual ride cars, individual lanes of a multi-lane slide, individual tracks of a multi-track attraction, etc.). Determining wait times using data based on a fixed number of rides may not dynamically respond to queue conditions (e.g., the closing and opening of rides at an attraction.) In fact, such virtual queuing systems may provide inaccurate wait times to guests, which may lead to excessive or insufficient wait times and inefficient operation of amusement park attractions.

[0012] With this in mind, certain embodiments of the present disclosure relate to a virtual queuing system that determines wait times by monitoring and / or dynamically evaluating virtual queues based on at least queue status and scheduling information for attractions in an amusement park. The embodiments of the present disclosure allow for dynamic modification of queue operations in response to feedback received related to wait times. In particular, certain embodiments of the present disclosure relate to determining wait times by monitoring and evaluating dynamic variations in open / close times for various attractions in addition to queues in determining wait times for attractions. In particular, the virtual queuing system can be configured to utilize scheduled times for each attraction, current or real-time guest throughput of the attractions, future estimated guest throughput, historical throughput of each attraction, and / or historical queue wait time information to determine accurate wait times for particular attractions and avoid communicating inaccurate wait times to guests. In this manner, the virtual queuing system can help prevent underutilization of rides, overcrowding of rides, 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 operation or the current virtual queue in response to insufficient or excessive wait times to further avoid inefficient operation, underutilization of rides, overcrowding of rides, and / or wasteful consumption of ride resources over a period of time. Additionally, the virtual queuing system can be configured to monitor and track how guests transition or move throughout the queues, providing more granular control of the virtual queues. Thus, based on the more granular control of the virtual queues, the virtual queuing system can be configured to automatically and dynamically control access to attractions, thereby preventing ride starvation, overcrowding, or other wasteful consumption of ride resources.

[0013] FIG. 1 is a schematic diagram of a theme park 110 with at least one amusement park attraction 112 that can be accessed via a virtual queue controlled by a virtual queuing system 114. A particular attraction 112 can feature multiple rides 118. For example, in the illustrated embodiment, the water slide attraction 112 can include multiple lanes or slides (e.g., shown as rides 118a, 118b, 118c) that are accessed via a single virtual queue that allows guests access to a boarding area 116. That is, a guest will have a position in the virtual queue for the attraction 112a to enter the boarding area 116. Upon entering the boarding area 116, the guest will be distributed among the separate slides (i.e., rides 118a, 118b, 118c) to experience the attraction 112. Thus, in the illustrative embodiment shown, the attraction 112a can accommodate multiple guests (e.g., two, three, or more) at one time. However, guests may enter their assigned rides 118 at different rates, resulting in dynamic changes in real-time guest throughput rates for each ride 118 of the multi-ride attraction 112. For example, certain guests may be more hesitant than other guests, leading to temporarily slower real-time guest throughput rates at some rides 118 compared to others. Additionally, ride operators may have different efficiencies in distributing guests to and boarding their respective rides 118. Thus, determining the overall guest throughput of a multi-ride attraction 112 can be complex and may require considering real-time guest throughput rates at each individual ride 118 of the attraction 112 to determine the overall guest throughput of the attraction 112.

[0014] It should be understood that while the illustrated embodiment is shown in the context of a water attraction, such as a water slide, other multiple ride attractions 112 are contemplated. Further, the rides 118 of an individual attraction 112 may include any suitable number of rides 118 (slides, tracks, path rides, etc.) that still accommodate any suitable number of guests accessed via a single virtual queue for the attraction 112. In addition, theme park 110 may also feature other attractions 112 that do not include multiple rides 118, for example, single ride attractions 112.

[0015] In one embodiment, through the virtual queuing system 114, guests are assigned a position in the queue status for an amusement park attraction 112 after submitting a request from a guest associated device 120 (e.g., a smart phone, guest wristband) or guest kiosk 121 and are not required to physically stand in line to enter the attraction 112 until a designated time. Thus, guests using the virtual queue may spend less time waiting in line while visiting the theme park 110. Additionally, data from the virtual queue provides guidance to the theme park to schedule ride openings and closings and optimize guest throughput and amusement park attraction efficiency.

[0016] In some embodiments, the virtual queuing system includes multiple virtual queues, each corresponding to a separate amusement park attraction (112a, 112b). To assist guests in determining which virtual queue to enter, the virtual queuing system 114 is configured to output a wait time signal 122 indicating the current wait time for each amusement park attraction 112. A display device 126 can be configured to receive the wait time signal 122 and display the current wait time to guests within the theme park 110. The display device 126 can be a central display configured to display the current wait times corresponding to multiple amusement park attractions. However, in some embodiments, the display device 126 can be a local display configured to display the current wait time for a single amusement park attraction. In another embodiment, a guest associated device 120 (e.g., a smartphone, a guest wristband, a guest tracker, etc.) receives the wait time signal 122 and displays the current wait time to the guest (e.g., a text message, a smartphone app notification, etc.).

[0017] In certain embodiments, the wait time signal 122 transmits a current wait time, a guest wait time (i.e., the wait time for an individual guest in the virtual queue), or a combination thereof. The current wait time indicates the amount of time that a guest who is not in the queue would expect to wait before being admitted to the amusement park attraction 112 if he or she were to join the virtual queue at that time. In contrast, the guest wait time indicates the amount of time that an individual guest who already has a position in the virtual queue still must wait before being admitted to the amusement park attraction 112. Thus, the guest wait time corresponds to a particular position of an individual guest who is already in the virtual queue, while the current wait time corresponds to the next available position in the virtual queue (i.e., an unassigned position).

[0018] In one embodiment, the virtual queuing system 114 determines wait times based at least on scheduling information or ride schedule data for the attraction 112. The ride schedule data includes planned ride openings and closings for the attraction 112 at designated times during theme park operating hours, as well as dynamic openings and closings in response to desired guest group flows. In the illustrated embodiment, the attraction 112a includes three rides 118a, 118b, 118c accessed by a single virtual queue. To increase attraction efficiency, one or more of the three rides 118 may close at designated times during theme park operating hours, such as those determined by or included in the ride schedule. For example, each of the three rides 118 may have an average historical guest throughput potential of 120 guests per hour. Thus, in the illustrated embodiment, the second ride 118b and the third ride 118c may be closed during times of day when guest throughput is historically low. When guest throughput is low, opening only the first ride 118a may reduce the number of employees required to operate the attraction 112a while still allowing the attraction to maintain sufficient guest throughput to keep wait times short. In contrast, when guest throughput is historically high, the attraction may open the second ride 118b and the third ride 118c to increase guest throughput to minimize wait times. Because opening and closing rides 118 of the attraction 112 dynamically changes real-time guest throughput as well as future guest throughput during closure times, having the virtual queuing system 114 determine wait times based at least on the scheduling information may provide more accurate wait times for guests. Thus, scheduling information regarding dates, times, and other details about ride closures and openings is sent to the virtual queue controller 130 of the virtual queuing system 114.In certain embodiments, the scheduling information is automatically transmitted from the theme park database to the virtual queue controller 130. In other embodiments, a user can manually input or modify the scheduling information for the virtual queue controller using the operator interface 132.

[0019] 2 is a flow diagram of a method 234 for determining a current wait time (e.g., for guests not yet in the queue) and a guest wait time for a guest in a virtual queue for an attraction 112 using a virtual queuing system 114 according to an embodiment of the present invention. The method includes providing ride schedule data for the attraction 112 to a virtual queue controller 114 (block 236), the ride schedule data including designated times for one or more rides to open and close, where the opening and closing of the one or more rides increases or decreases an estimated guest throughput for the attraction, the method further includes calculating variable guest throughput data based at least on the ride schedule data and historical guest throughput data for the attraction (block 238), and determining a next available position in the virtual queue for the attraction 112 based at least on the variable guest throughput data. The method includes determining a current wait time for a location available for a given attraction (block 240), outputting a wait time signal to a display device, guest associated device, or combination thereof indicative of the current wait time for a guest in queue for the next attraction 112 (block 242), assigning the guest to a location in the virtual queue for the attraction in response to the guest queuing request (block 244), determining a guest wait time for the guest based at least on the location in the virtual queue and the variable guest throughput data (block 246), and outputting a wait time signal indicative of the guest wait time to a guest associated device (block 248). Further details of aspects of method 234 are discussed in more detail herein with respect to related system features.

[0020] In certain embodiments, the method 234 further includes calculating the variable throughput data based on current or real-time guest throughput data. In some embodiments, the method 234 includes providing queue status data for the attractions 112 to the virtual queue controller 114, the queue status data including at least current guest throughput data for the amusement park attractions.

[0021] In certain embodiments, the virtual queue controller 130 is configured to continuously or periodically determine the guest wait time and continuously output a wait time signal indicative of the updated guest wait time. In other embodiments, the virtual queue controller 130 is configured to determine the guest wait time in response to an update request from the guest. The virtual queue controller 130 may limit the number of update requests a guest may issue. In other embodiments, the rate at which a guest may issue update requests may be limited. In some embodiments, the virtual queue controller 130 is configured to output a wait time signal when the virtual queue controller determines that the guest wait time has changed by more than a preset amount of time. For example, the virtual queue controller 130 may output a new wait time signal when the guest wait time has changed by more than two minutes.

[0022] 3 is a block diagram of a virtual queue system 314. The virtual queue system includes a virtual queue controller 330 (e.g., virtual queue controller 130) in communication with a guest associated device 320, a display 326, or a combination thereof. To enter the virtual queue of the attraction 112, the guest associated device 320, in response to an input from the guest, sends a queue request signal 350 to the virtual queue controller 330. The virtual queue controller 330 receives the wait time request signal 350, determines a wait time for the guest, and outputs a wait time signal 322 to the guest associated device 320, the display 326, or a combination thereof. The guest associated device 320 and the display 326 are configured to receive the wait time signal 322 and display the wait time for the guest. To enable these communications, the guest-associated devices 320, displays 326, and virtual queue controller 330 may include communications circuitry 352, such as antennas, radio transceiver circuitry, signal processing hardware and / or software (e.g., hardware or software filters, A / D converters, multiplexer amplifiers), or combinations thereof. The communications circuitry 352 may be configured to communicate over wired or wireless communications paths via IR wireless communications, satellite communications, broadcast radio, microwave radio, Bluetooth, Zigbee, Wifi, UHF, NFC, and the like. Such communications may also include intermediate communications devices, such as radio towers, cell towers, and the like.

[0023] In certain embodiments, the virtual queue controller 330 can include a memory device 354a storing instructions executable by the processor 356a to implement the methods and control operations described herein. For example, the processor 356a can execute instructions to dynamically evaluate virtual queue conditions and determine guest queuing based on guest throughput inputs 358 and ride schedule data inputs 360 received by the virtual queue controller 330. The ride schedule data inputs can be received through user input, from memory storage, and / or through cloud services. The virtual queue controller 330 can receive scheduling (or changed schedule) information in real time and can be configured to update wait times based on the updated schedule. In certain embodiments, the virtual queue controller 330 can receive and utilize additional inputs in combination with the ride schedule data inputs 360 and guest throughput inputs 358 in determining wait times.

[0024] Additionally, in certain embodiments, processor 356 may utilize historical queue condition data input 362 (e.g., historical weather information, previous guest behavior in a particular ride / attraction, calendar information (e.g., time of day, day of week, holidays, etc.), demographic information, number of guests in a group, etc.) in combination with ride schedule data input 360 and / or guest throughput input 358 in determining wait times. For example, processor 356 may take into account historically slow groups or cold weather conditions when providing wait times. As another example, in certain embodiments, processor 356 may utilize various characteristics of guests in queue (e.g., type, gender, age, number, etc.) in combination with ride schedule data input 360 and guest throughput input 358 to determine wait times 3. While guest throughput input 358, ride schedule data input 360, and historical queue status data input 362 are depicted as being received via operator interface 332, it is understood that the various inputs to virtual queue controller 330 may be received from other components of system 314. In one embodiment, guest throughput input 358 includes real-time throughput information transmitted to virtual queue controller 330 based on interaction of a check-in or tap-in device with a guest associated device 320, or by passing through a gate at each attraction 112. For example, as each guest enters an attraction 112, associated guest identification information is retrieved from a guest associated device 320 having communication circuitry and associated with the attraction. In one embodiment, each individual ride 118 of the attraction 112 is configured to provide guest identification from a reader located at the top or start of each ride 118. The guest identification information, associated attraction 112 and / or ride 118 information, and time stamps can be provided to the virtual queue controller 330 as inputs for determining real-time dynamic guest throughput (e.g., guests / hour).Additionally, the attraction 112 may also include readers at the ride exits to track total usage time through the ride 118 as 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 the number of guests and provide the guest count periodically to the operator interface 332. Additionally, the virtual queue controller 330 may store guest throughput information in order to update the historical queue status input 362 with collected guest throughput data.

[0025] The processor 356 of the virtual queue controller 330 may 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 may include RAM, ROM, EPROM, EEPROM, or optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to hold or store desired program code in the form of machine-executable instructions or data structures and that may be accessed by a processor or other processor-based device (e.g., a mobile device). For example, the virtual queue controller 330 may be accessed by an operator interface 332 (which may include, for example, a computer-based workstation or a mobile device, and / or an input / output interface 364 and a display).

[0026] In certain embodiments, guest associated device 320 having processor 356b and memory 3545b may be a personal guest device (e.g., a smart phone, tablet, laptop, etc.) or a theme park queue device (e.g., a smart wristband, portable communication device, etc.) assigned to the guest. The theme park queue device includes a program for viewing wait times and sending queue requests. Guests using a personal guest device may access the program (e.g., a web-based program, a smart phone app, a downloadable program, etc.). For example, an admission ticket or confirmation email to a theme park may include details for locating the program, as well as a username, passcode, or combination thereof for accessing the program. Personal information associated with the guest (height, weight, age, and other demographic data) may be linked to the username and / or passcode, and guest identification information may be transmitted along with the queue request signal. Guests using a theme park queue device may have guest information uploaded to the theme park queue device when the theme park queue device is assigned to the guest. The virtual queue controller 330 can utilize guest identification information to determine wait times as provided herein.

[0027] In certain embodiments, the system may include a virtual queuing station (e.g., a guest kiosk 121) including a processor and / or memory configured to provide an additional resource for guests to view time and submit virtual queue requests. Guests may access queuing functionality with the queuing station using some form of guest identification (e.g., username, passcode, card, RF wristband, personal information, etc.). The queuing stations may be located at various locations around the theme park 110. In some embodiments, at least one virtual queuing station is located proximate to the entrance of each attraction 112 to provide guests with a means to queue for the attraction 112 in a location proximate to the attraction 112. In some embodiments, the queuing station may only allow guests to queue for the attraction 112 closest to the queuing station. In other embodiments, general queuing stations are located throughout the theme park 110 and may be used to queue for attractions 112 within the theme park 110.

[0028] In certain embodiments, the display devices 326 are configured to receive the wait time signal 322 from the virtual queue controller 330 and display the current wait times for the attractions 112. In some embodiments, at least one display device 326 is located proximate to the entrance of each attraction 112. The display devices may be configured to display only the current wait times for the attractions 112 closest to the display device. In other embodiments, a general display device is located in general locations around the theme park 110 (e.g., food and beverage areas, sidewalks, etc.). The general display device may display the current wait times for multiple attractions 112.

[0029] FIG. 4 is a block diagram of the virtual queue system 414 having a monitoring device 466. In this embodiment, the monitoring device 466 may include a communication circuit 452d that establishes communication with the virtual queue controller 430. The monitoring device 466 may also include a processor 456c and a memory device 454c. The monitoring device 466 is configured to monitor and / or determine a current queue status and output a queue status signal 468 to the virtual queue controller 430. In some embodiments, the attraction 112 has both a physical queue and a virtual queue. In such an embodiment, a guest first enters the virtual queue before entering the physical queue. The physical queue provides a buffer queue or standby area for the attraction 112 to increase the efficiency of the attraction 112. For example, if a guest does not arrive at the attraction 112 at the time specified by the virtual queue system 414, there may be no guest present in the physical queue to fill the position of the absent guest. Thus, at least one ride 118 of the attraction 112 may proceed at less than the ride's maximum capacity, which reduces the efficiency of the attraction 112. However, with both physical and virtual queues, there may be multiple guests at the attraction 112 to fill the ride to capacity even if the guest does not arrive at the scheduled time. In certain embodiments, the monitoring device 466 is configured to monitor the current queue status of the physical queue. However, the monitoring device 466 may be configured to monitor the current queue status of the physical queue, the virtual queue, or a combination thereof. Additionally, in certain embodiments, the attraction 112 may be implemented without a physical queue.

[0030] In certain embodiments, the monitoring device 466 may be configured to monitor or determine current queue conditions, including, but not limited to, queue length, number of guests in the queue, flow rate of guests entering and leaving the queue, particularly individuals in the queue (e.g., identifying guests in the queue), number of sub-queues in the queue, types of guests in the queue, and others. In certain embodiments, the monitoring device 466 may monitor specific locations in the queue (e.g., geographic locations, queuing zones, etc.) and output the number of guests at each specific location to the virtual queue controller. In certain embodiments, the monitoring device 466 may not only monitor guests at the beginning and end of the queue, but may also monitor whether guests are leaving the queue in the middle of the queue. In certain embodiments, the monitoring device 466 can determine various characteristics of guests in the queue (e.g., type, gender, age, number, etc.) and output that data to the virtual queue controller 430 to track and record historical throughput data associated with the queue for the attraction 112.

[0031] In certain embodiments, the monitoring device 466 includes a counting mechanism 470 configured to monitor queue status. For example, the number of guests in the queue can be monitored using the counting mechanism 470, which can be a manual system and / or can include one or more sensors located proximate to the queue. In other embodiments, the monitoring device can include at least one sensor 472 (e.g., optical sensor, mechanical pedal, RF sensing system, etc.) located physically proximate to the queue and communicatively coupled to the virtual queue controller 430. The sensor 472 can provide continuous feedback to the virtual queue system 414 related to the current queue status. For example, in situations where each guest holds an RF identification, an RF sensor associated with the monitoring device can be configured to monitor when a particular guest enters and exits the queue and output that data to the virtual controller. As another example, the sensors 472 may be configured to recognize individual guests at the entrance and exit of the queue and continuously output that information to the virtual queue controller, so that various states of the queue (e.g., wait time, queue length, etc.) can be calculated based on the amount of time each guest spends in the queue.

[0032] Based on the feedback received, the virtual queuing system 414 can be configured to dynamically respond to the current queue status. In certain embodiments, the virtual queuing system 414 can include the ability to automatically remove guests from the virtual queue based on one or more factors (e.g., waiting in queue for an extended period of time past the current queue wait time, the guest being seen in an unexpected location in the queue, the guest entering another queue, the guest being recognized outside of the queue, etc.). In certain embodiments, the virtual queuing system 414 can virtually monitor and dynamically adjust multiple queues (or sub-queues) and can be configured to correlate data for the various queues when calculating and determining the current queue status.

[0033] In certain embodiments, the virtual queuing system 414 may utilize feedback received from the monitoring device 466 to calculate other queue conditions. The virtual queuing system 414 may calculate various factors or variables, such as, but not limited to, virtual queue length, current or real-time guest throughput, maximum attraction throughput, historical information related to queue conditions and responses (e.g., historical guest throughput), the amount of time the queue has been in different states (overflow, underflow, starvation, overcrowding, etc.), and others. For example, based on the number of guests in the queue and / or the flow rate of guests entering and leaving the queue, the virtual queuing system 414 may calculate the current wait time, guest wait time, current attraction capacity, and others. In particular, the virtual queuing system 414 may be configured to determine accurate real-time information related to the queuing system and queue conditions based at least in part on the continuous feedback received from the monitoring device 466.

[0034] In another embodiment, in response to a guest's determined wait time in the virtual queue and / or the physical attraction access area, the virtual queuing system 414 can be configured to output a queue modification signal 474. In particular, the virtual queuing system can be configured to dynamically respond to deviations of a guest's calculated wait time from a wait time range by outputting a queue modification signal 474.

[0035] In certain embodiments, the queue modification signal 474 is configured to temporarily disable the ability to add guests to the virtual queue of the attraction 112 when the wait time for the attraction is longer than the maximum limit of the wait time range. For example, when the virtual queue is deemed too long by the virtual queue controller 430, the virtual queue controller is configured to output the queue modification signal 474 to a guest associated device 420 (e.g., a smart phone, a guest kiosk, etc.). The queue modification signal 474 is configured to send instructions to a queue program on the guest associated device 420 to disable an option to submit a queue request for the attraction 112. Additionally, the queue modification signal 474 can include instructions to display a message regarding disabling a portion of the queue program. When the wait time for the virtual queue returns to an amount of time within the wait time range, the virtual queue controller 430 can be configured to send a return signal 476 to enable the option to submit a queue request.

[0036] In certain embodiments, the queue modification signal 474 includes instructions to notify a guest that the queue time for the attraction 112 is shorter than average when the wait time for the attraction is shorter than the minimum of the wait time range. For example, the queue modification signal 474 can include instructions to a guest associated device to display a message indicating that the wait time for the attraction 112 is short. In some embodiments, the queue modification signal 474 can include instructions to activate a quick queue option in a program on the guest associated device 120. For example, the quick queue option can activate a pop-up message on a screen indicating that the wait time for the virtual queue is short. Additionally, the pop-up message can include a button configured to immediately admit the guest into the virtual queue for the attraction 112. In certain embodiments, the virtual queue controller 430 is configured to send the queue modification signal 474 to guest associated devices 420 linked to guests who have experienced fewer attractions 112 during the day at the theme park 110 than other guests before sending the queue modification signal to other guests, thereby giving those who have experienced fewer attractions 112 a first opportunity to enter the virtual queue. In certain embodiments, the program includes an option to disable the message that is activated in response to the guest associated device receiving the queue modification signal 474. However, when the wait time for the virtual queue rises to a length of time that is within the wait time range, the virtual queue controller is configured to send a return signal to automatically disable notifications from the queue modification signal.

[0037] In certain embodiments, the virtual queue controller is configured to send an attraction modification signal 478 to an amusement park operator in response to a wait time that is greater than the maximum limit or less than the minimum limit of the wait time range. The attraction modification signal is configured to send instructions to the amusement park operator to open and / or close rides of the amusement park rides 118 to adjust the current guest throughput according to the wait time. In addition to disabling the virtual queue or sending notifications, dynamically opening and closing rides 118 of the attraction 112 can further improve the efficiency of the amusement park attraction.

[0038] 5 is a graph illustrating a virtual queue wait time 582 and a wait time range 584. The wait time range provides a minimum wait time 586 and a maximum wait time 588 of an acceptable wait time at a particular time, for example, whereby the wait time between the minimum wait time 586 and the maximum wait time 588 can bound a preset desired wait time range. If the wait time 582 calculated or estimated by a virtual queue controller provided herein (e.g., virtual queue controller 430) falls below the minimum wait time 586 or exceeds the maximum wait time 588, the virtual queue controller 430 is configured to output a queue modification signal 474. In certain embodiments, the virtual queue controller 430 calculates the wait time range 584 based at least on historical throughput data. The virtual queue controller 430 can use the historical throughput data to determine an average wait time 590 for the attraction 112 during each time of day. The virtual queue controller 430 may determine a plurality of average wait times, where the average wait times are calculated for each time period of each day of a week, month, year, etc. For example, the virtual queue controller 430 may calculate the average wait time 590 for the attraction 112 at 10:00 AM by averaging all historical throughput data for the 10:00 AM time period. However, in other embodiments, the virtual queue controller 430 calculates the average wait time 590 for Mondays at 10:00 AM by averaging all historical throughput data for every Monday at 10:00 AM. Additionally or alternatively, the virtual queue controller 430 may further utilize historical queue condition data (e.g., ride schedule data, historical guest throughput, weather data, guest behavior, calendar information, demographic information, number of guest groups, guest group size, etc.) in calculating the plurality of average wait times 590.

[0039] In certain embodiments, the virtual queue controller 430 can calculate the wait time ranges 584 by adding a wait time buffer to the average wait time 590. For example, the virtual queue controller 430 can calculate the average wait times for 9:00 AM, 11:00 AM, 1:00 PM, and 3:00 PM as 5 minutes, 20 minutes, 40 minutes, and 35 minutes, respectively. The virtual queue controller 430 can calculate the wait time ranges by providing a wait time buffer of 5 minutes to the average wait time. Thus, the wait time ranges for 9:00 AM, 11:00 AM, 1:00 PM, and 3:00 PM are 0-10 minutes, 15-25 minutes, 35-45 minutes, and 30-40 minutes, respectively. In other embodiments, the virtual queue controller 430 can calculate the wait time ranges 584 using a dynamic wait time buffer. A dynamic wait time buffer can vary the length of time of the wait time buffer at different times of the day. For example, the wait time buffer for 9:00 AM can be 5 minutes, while the wait time buffer for 1:00 PM can be 15 minutes. In other embodiments, the dynamic wait time buffer comprises a wait time buffer between the average wait time and a maximum limit that is longer than a wait time buffer between the average wait time and a minimum limit, hi some embodiments, the dynamic wait time buffer may be determined using historical throughput data, operator input, or the like.

[0040] In certain embodiments, the wait time ranges can be set based on input received by the virtual queue controller 430. In some embodiments, the virtual queue controller 430 is configured to receive input from the operator interface 332. The operator can send instructions to the virtual queue controller 430 to set a particular wait time range using the operator interface 332. The operator can set static or dynamic wait time ranges. In some embodiments, the operator can set wait time ranges independent of historical throughput data. For example, if an attraction 112 is temporarily understaffed, the operator can adjust the wait time range 584 of the attraction 112 to reduce guest throughput for the attraction 112 until the attraction 112 is adequately staffed. In another example, the operator can adjust the wait time ranges 564 for multiple attractions 112 to encourage guests to queue for a particular attraction 112 and prevent overcrowding of other attractions 112 or locations.

[0041] In certain embodiments, the virtual queue controller 430 can determine a wait time 582 for a position in the virtual queue based on the variable guest throughput data and the ride schedule data. In general, the virtual queue controller 430 calculates the variable guest throughput based at least on the current guest throughput data, the historical throughput data, the historical ride schedule data, and the like. The variable guest throughput data represents an expected guest throughput of a single ride 118 of the attraction 112 during each time period during the theme park's operating hours. The virtual queue controller 430 is configured to predict the expected guest throughput based at least on the historical throughput data and deviations of the current guest throughput data relative to other queue conditions. To accurately analyze throughput variations and prevent scheduling variations from distorting the calculation, the guest throughput data and the historical throughput data are first divided by the number of currently open rides and the number of previously open rides, respectively (i.e., the current guest throughput data and the historical guest throughput data for a single ride). Additionally, the virtual queue controller 430 is configured to dynamically multiply the expected guest throughput data for a single ride according to the ride schedule data to determine the expected guest throughput for each time period during operating hours. The virtual queue controller 430 is configured to determine wait times utilizing the expected guest throughput associated with a guest location, the current queue conditions (e.g., number of guests in queue, etc.).

[0042] In some exemplary embodiments, in certain circumstances, the attraction 112 may include one or more rides 118 that open and close at different times throughout the day. For example, a first ride 118a of the attraction 112 may open at the same time as the theme park 110 opens, and a second ride of the attraction 112 may open one hour after the theme park 110 opens. Each ride of the attraction 112 may have a throughput of 120 guests per hour. Features of the present disclosure enable the virtual queuing system to utilize the scheduled opening / closing times of each ride during the day to determine the wait time of the attraction 112. For example, the virtual queuing system may take into account the delayed opening time of the second ride 118b when determining the wait time of the attraction 112. In this manner, the virtual queuing system may provide an accurate wait time for the attraction 112, rather than an artificially low wait time that would be associated with all rides 118 being open. In other words, when one or more of the rides are closed, the estimated total guest throughput of the attraction 112 is reduced. Additionally, the virtual queuing system 114 allows for a one hour delay in opening the second ride 118b during the assigned wait time before the second ride 118b is scheduled to open.

[0043] For example, in one embodiment, a guest requests a virtual queue position such that the guest wait time for the attraction 112 includes or overlaps a first time period during which a subset of the rides 118 are closed and a second time period during which all of the rides 118 are open. That is, some or all of the closed rides 118 are opened while the guest is in the virtual queue. Thus, the attraction 112 has an estimated low guest throughput during the first time period and an estimated high guest throughput during the second time period. By using the low and high guest throughputs, a more accurate guest wait time can be determined. In this manner, the virtual queuing system can eliminate periods of ride starvation (when artificially high wait times are reported) or ride overcrowding (when artificially low wait times are reported).

[0044] In one embodiment, for an attraction 112, historical guest throughput data may indicate that at 1:00 PM, on average, the attraction 112 has a guest throughput of 240 guests per hour and at 2:00 PM, a guest throughput of 220 guests per hour. The current conditions determined by the monitoring device 466 indicate that the current guest throughput of the rides at 1:00 PM is 120 guests with one ride 118 open. However, the ride schedule data provided to the virtual queue controller 430 indicates that a second ride 118b is scheduled to open at 1:30 PM. Initially, the virtual queue controller may determine that the historical guest throughput of one ride vehicle at 1:00 PM is 120 guests per hour and that the ride throughput per vehicle is comparable to the historical guest throughput data. However, historical guest throughput data indicates that guest throughput for one ride car at 2:00 PM has historically trended downward to 110 guests per hour. The virtual queue controller 430 can be configured to account for the decrease in guest throughput when calculating the wait time. Additionally, although the current guest throughput is only 120 guests per hour, the virtual queue controller is configured to increase the expected guest throughput at 1:30 PM by a factor of two to account for the opening of the second ride car. The expected ride throughput would increase to 240 guests per hour minus the expected decrease in guest throughput. Thus, the expected guest throughput at 1:30 PM may be 230 guests per hour. Using the estimated guest throughput data and current queue conditions associated with guest locations, the virtual queue controller can dynamically determine the wait time 582. Additionally, in certain embodiments, the virtual queue controller may continuously calculate a variable guest throughput and provide guests with updated wait times, taking into account the current guest throughput and changes in other queue conditions.

[0045] In some embodiments, the virtual queue controller 430 may further utilize other queue conditions to determine the wait time 582. Specifically, the virtual queue controller 430 may be configured to consider various factors, such as, but not limited to, previous guest behavior, the guest's current activity in and out of the queue, the guest's current or historical location within the theme park, weather, calendar information (e.g., time of day, day of the week, holidays, etc.), demographic information, the number of guests in a group, and others. Additionally, in certain embodiments, the virtual queue controller 430 may record the real-time queue conditions as historical queue condition information for future use. For example, the collected real-time queue conditions may indicate that one ride 118a has historically had a lower guest throughput relative to the other rides 118b, 111c, even if all three rides 118 are of a similar or the same type. Reasons for such low throughput may include the entrance to the boarding area of ​​the ride 118a being farther away from the entrances of the other rides 118b, 118c, or involving a lower boarding angle, or show props adjacent to the ride 118a causing guests to linger at the entrance to the ride. Thus, a more accurate estimated guest wait time may take into account which of the rides 118 are closed and use historical guest throughput information associated with each individual ride 118. For example, if the slower ride 118a is closed, the estimated guest wait time may use the historical guest throughput of the faster rides 118b, 118c and not from the closed slower ride 118a when calculating the estimated guest wait time.

[0046] In certain embodiments, the virtual queue controller 430 can be configured to determine wait times 582 for each attraction 112 based on a coordinated analysis of other queue conditions. For example, in certain embodiments, the virtual queue controller 430 can receive ride schedule data and guest throughput data for multiple attractions 112 and can be configured to coordinate wait times 582 for the attractions 112 based on the received data. In certain embodiments, the virtual queue controller 430 can utilize other types of data to perform the coordinated analysis. For example, the virtual queue controller can receive guest group flow data and / or wait times for other rides and can utilize this data to provide accurate wait times 582 for each attraction 112.

[0047] 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, and 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 invention.

[0048] The technology presented and claimed herein is applied with reference to specific examples of a tangible and practical nature that clearly improve the art, and is therefore not abstract, intangible, or purely theoretical. Moreover, when any claim appended hereto includes one or more elements designated as "means for performing a function" or "step for performing a function," such elements are intended to be construed under 35 U.S.C. 112, paragraph 6. However, for any claim that includes an element designated in any other manner, such elements shall not be construed under 35 U.S.C. 112(f).

Claims

1. 1. A virtual queuing system comprising: a virtual queue controller including a processor and a memory; The memory stores instructions executable by the processor, and the virtual queue controller comprises: receiving requests associated with individual guests for a position in a virtual queue of an attraction having a plurality of rides, the virtual queue enabling the individual guests access to one of the plurality of rides of the attraction, guests in the virtual queue being distributed among the plurality of rides of the attraction via the virtual queue; assigning the individual guest a position in the virtual queue for the attraction in response to the request; receiving ride schedule data for the attraction, the ride schedule data including information regarding changes in status of individual rides of the plurality of rides; determining a wait time for the guest for the attraction based at least on a position of the individual guest in the virtual queue, the ride schedule data, and historical guest throughput at the attraction; It is configured as follows: The virtual queuing system further comprises: a communication circuit configured to output a signal to a guest associated device indicative of a wait time for the attraction.

2. 2. The virtual queuing system of claim 1, further comprising at least one monitoring device disposed at the attraction, the at least one monitoring device configured to generate a guest throughput signal indicative of real-time guest throughput of the attraction and output the guest throughput signal.

3. The virtual queuing system of claim 2 , wherein a virtual queue controller is configured to receive said guest throughput signal from said at least one monitoring device.

4. 3. The virtual queuing system of claim 2, wherein the at least one monitoring device includes at least one sensor, and the virtual queue controller is configured to receive one or more signals from the at least one sensor indicative of a number of guests entering the attraction, a number of guests exiting the attraction, a flow rate of the guests entering the attraction, an identity of the guests entering the attraction, or a combination thereof.

5. The virtual queuing system of claim 1 , wherein the virtual queue controller is further configured to determine a next available wait time for the attraction based at least on a next available position in the virtual queue.

6. 6. The virtual queuing system of claim 5, wherein the virtual queue controller is configured to output a queue correction signal when the next available waiting time deviates from a historical waiting time by more than a set amount.

7. 2. The virtual queuing system of claim 1, wherein the virtual queue controller is configured to dynamically update wait times for the individual guests based on receiving changes in the ride schedule data and output updated wait time signals to the guest associated devices.

8. 10. The virtual queuing system of claim 1, wherein multiple rides of the attraction are accessed through a single boarding area of ​​the attraction.

9. 9. The virtual queuing system of claim 8, wherein access to the single boarding area is based on the individual guest's position in the virtual queue.

10. 10. The virtual queuing system of claim 1, wherein the rides of the attraction are of the same type.

11. The virtual queuing system of claim 1 , wherein said vehicle schedule data indicates closures of a subset of said individual vehicles over a range of times.

12. 12. The virtual queuing system of claim 11, wherein the determined wait times during the time range are longer for later times during which the subset of individual rides are open.

13. 12. The virtual queuing system of claim 11, wherein the ride schedule data indicates a closure of the subset at the time of the request and a subsequent opening of the subset during the wait time, the wait time being determined based on an estimated increase in guest throughput of the attraction during a portion of the wait time after the opening.

14. 12. The virtual queuing system of claim 11, wherein the ride schedule data indicates the closure of the subset after the request is received, and the wait time is determined based on an estimated decrease in guest throughput of the attraction during a portion of the wait time after the closure.

15. 1. A virtual queuing system comprising: at least one monitoring device configured to monitor current queue conditions for the attraction and output a queue condition signal; a virtual queue controller including a controller and a communication circuit; Equipped with The virtual queue controller: Receive a queue status signal; determining a current wait time for the attraction based at least on the queue status signal and preset ride schedule data for the attraction indicating a closure of a subset of a plurality of rides for the attraction; outputting a queue modification signal in response to the determined current latency being outside a preset latency range. A virtual queuing system configured to:

16. 16. The virtual queuing system of claim 15, wherein the queue modification signal is configured to temporarily disable the ability to add guests to a virtual queue when the current wait time exceeds a maximum wait time in the wait time range.

17. 17. The virtual queuing system of claim 16, further comprising a guest kiosk configured to receive the queue modification signal and to override user input in response to receiving the queue modification signal, the guest kiosk configured to transmit a request for a position in the virtual queue for the attraction based on the user input.

18. 17. The virtual queuing system of claim 16, wherein the virtual queue controller is configured to output the queue modification signal to a guest associated device such that the guest associated device overrides user input, and the guest associated device is configured to transmit a request for a position in the virtual queue for the attraction based on the user input.

19. providing ride schedule data to a virtual queue controller for an attraction that includes a plurality of rides, the ride schedule data including scheduling times associated with closures of the plurality of rides; calculating variable guest throughput data for the attraction, the variable guest throughput data being calculated based at least on current guest throughput data, the ride schedule data, and historical guest throughput data for the attraction; determining a current wait time for a next available position in the virtual queue for the attraction based at least on a next available position in a virtual queue and the variable guest throughput data, wherein the current wait time overlaps the scheduling time such that a subset of the plurality of rides experiences a closure during the current wait time, and the current wait time is calculated based on first variable guest throughput data indicative of a first guest throughput during a closure and second variable guest throughput data indicative of a second guest throughput during a time outside of the closure; outputting a current wait time signal to a display device, a guest associated device, or a combination thereof, indicative of a current wait time in the queue for the attraction; A method comprising:

20. 20. The method of claim 19, wherein the historical guest throughput data includes historical guest throughput data for the one or more attractions in relation to the number of rides open, weather data, guest behavior, calendar information, demographic information, number of guests in a group, guest group size, or any combination thereof.

21. 20. The method of claim 19, further comprising the step of updating said vehicle schedule data signal when said vehicle schedule data changes.

Images