HK40056945A - Virtual queuing techniques - Google Patents

Description

Virtual queuing techniques

The application is a divisional application, the invention name of the parent case is 'virtual queuing technology', the application date is 11, 9 and 2017, and the application number is 201780069272.9.

Cross Reference to Related Applications

This application is a divisional application of U.S. application No.15/807,411 filed on 8.11.2017, claiming priority from U.S. provisional patent application No.62/419,837 entitled "Systems and Methods for Pre-Scheduling In visual Queuing Systems" filed on 9.11.2016, and U.S. provisional patent application No.62/419,833 filed on 9.11.2016, entitled "Systems and Methods for automatic Monitoring and dynamic adjustment A Queuing" which are incorporated herein by reference In their entirety for all purposes.

Background

The present disclosure relates generally to the field of amusement parks. In particular, embodiments of the present disclosure relate to techniques for managing amusement park experiences, including queuing for attractions.

Amusement parks have increased significantly in popularity since the beginning of the twentieth century. To address this increased demand, amusement parks have been enlarged by adding attractions and space. The addition of attractions (e.g., rides, restaurants, stores, and shows) generally provides amusement parks with additional capacity to handle larger numbers of guests. However, additional attractions typically also provide potential guests with an incentive to visit the amusement park. Thus, while a particular amusement park may add additional capacity, the additional capacity does not always result in increased ability for guests to participate in park entertainment (e.g., shopping, watching shows, riding rides) or reduced waiting times for attractions. This is because there will typically be a corresponding increase in the number of participants (attenance). Further, it is often desirable to limit the availability of attractions during times of low attended availability due to operational efficiency. Thus, queuing for attractions (which may limit participation in park activities) is a perennial issue in amusement parks.

While guests have requested larger, better, more elaborate attractions, they also need and expect a positive overall experience. Providing a positive overall experience for amusement park guests requires addressing certain issues related to queuing for attractions. Indeed, it is now recognized that park guests may be prevented from returning to a particular amusement park due to the negative experience in the event of queue wait times. Further, guests may be prevented from visiting an amusement park establishment (e.g., a store) due to the time spent waiting in the queue. In fact, in the past, guests have been waiting in line for several hours to experience some of the more popular attractions at the amusement park. Additionally, it is now recognized that park capacity does not always result in efficient guest utilization of that capacity due to individual guest preferences for certain attractions rather than other attractions. Accordingly, it is now recognized that improved amusement park queuing systems and methods are desirable.

Disclosure of Invention

The following summarizes certain embodiments commensurate in scope with the originally claimed subject matter. These embodiments are not intended to limit the scope of the present disclosure, but rather these embodiments are intended only to provide a brief summary of certain disclosed embodiments. Indeed, the present disclosure may encompass a variety of forms that may be similar to or different from the embodiments set forth below.

According to one embodiment, a virtual queue system is provided. The virtual queue system includes a virtual queue controller including a processor and a memory. The memory stores instructions executable by the processor and is configured to receive a request. The request is associated with an individual guest and is for a position in a virtual queue of attractions comprising a plurality of rides. The virtual queue allows an individual guest access to one of the plurality of rides of the attraction, and guests in the virtual queue are distributed among the plurality of rides of the attraction via the virtual queue. The memory is further configured to: assigning individual guests to locations in a virtual queue in response to the request; receiving ride schedule data for the attraction, the ride schedule data including information about changes in status of individual rides of the plurality of rides; and determining a latency of the individual guest for the attraction based at least on the location of the individual guest in the virtual queue, the ride schedule data, and the historical guest throughput at the attraction. The virtual queue system further comprises a communication circuit configured to output a signal to the guest associated device indicating a latency for the attraction.

According to another embodiment, a virtual queue system is provided. The virtual queue system includes at least one monitoring device configured to monitor a current queue condition of the attraction and output the queue condition. The virtual queue system also includes a virtual queue controller that includes a controller and communication circuitry. The virtual queue controller is configured to receive a queue status signal. The virtual queue controller is further configured to determine a current wait time for the attraction based on at least the queue status signal and preset ride schedule data for the attraction, wherein the preset ride schedule data indicates a closure of a subset of the plurality of rides of the attraction. The virtual queue controller is further configured to output a queue modification signal in response to the determined current latency being outside of a predetermined latency range.

According to another embodiment, a method is provided. The method comprises the following steps: providing ride schedule data including attractions of a plurality of rides to a virtual queue controller, wherein the ride schedule data includes scheduled times associated with closure of a subset of the plurality of rides; calculating variable guest throughput data for the attraction, wherein the variable guest throughput data is calculated based at least on current guest throughput data, ride schedule data, and historical guest throughput data for the attraction; determining a current wait time for a next available position in a virtual queue of the attraction based on at least the next available position and the variable guest throughput data, wherein the current wait time overlaps with the scheduled time such that a subset of the plurality of rides experience a shutdown during the current wait time, and wherein the current wait time is calculated based on first variable guest throughput data indicating a first guest throughput during the shutdown period and second variable guest throughput data indicating a second guest throughput during a time other than the shutdown; and outputting a current latency signal to the display unit, the guest associated device, or a combination thereof, the current latency signal indicating a current latency for queuing for the attraction.

Drawings

These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

FIG. 1 is a schematic illustration of a theme park including a virtual queue system in accordance with the present technology;

FIG. 2 is a flow diagram of using a virtual queue system in accordance with the present technique;

FIG. 3 is a block diagram of a virtual queue system in accordance with the present technique;

FIG. 4 is a block diagram of a virtual queue system including a monitoring device in accordance with the present technique; and

FIG. 5 is a graph illustrating latency ranges for a virtual queue in accordance with the present technology.

Detailed Description

Theme parks or amusement park attractions have become increasingly popular and various amusement park attractions have been created to provide unique sports and visual experiences to guests. Guests entering 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 guests to enjoy other features of the amusement park as their position in the virtual queue advances. To help guests plan their day, the virtual queuing system may estimate the wait time (e.g., the length of time before a guest may enter an attraction) and provide an alert to the guest that the time to enter the attraction is upcoming. However, in determining the waiting time for a guest for each attraction, some virtual queuing systems assume an average waiting time or an average guest return rate, or may utilize a predetermined or preconfigured waiting time for a static number of rides within a particular attraction (e.g., features accepted by guests of the attraction, such as individual ride vehicles, individual channels of a multi-lane slide, individual tracks of a multi-track attraction, etc.). Using data based on a static number of rides to determine the wait time may not be able to react dynamically to queue conditions (e.g., rides closing and opening at a scene point). In fact, such virtual queuing systems may provide guests with inaccurate latencies, which may result in excessive or insufficient latencies and result in inefficient operation of the amusement park attraction.

In this regard, certain embodiments of the present disclosure are directed to a virtual queuing system that determines latency by monitoring and/or dynamically evaluating virtual queues based at least on queue conditions and scheduling information for amusement park attractions. Embodiments of the present disclosure facilitate dynamically modifying queue operations in response to received feedback associated with latency. In particular, certain embodiments of the present disclosure relate to: in determining the wait time for attractions, the wait time is determined by monitoring and evaluating the dynamic changes in the open/closed times of various attractions (or various rides within a particular attraction) in addition to queue conditions. In particular, the virtual queue system may be configured to utilize the scheduled time for each attraction, the current or real-time guest throughput of the attraction, the estimated future guest throughput, the historical throughput of each attraction, and/or historical queue latency information to accurately determine the latency for a particular attraction to avoid transmitting inaccurate latencies to guests. In this manner, the virtual queuing system may help prevent under-utilization of rides, overcrowding of rides, and/or inefficient use of ride resources for a period of time. Additionally, certain embodiments of the present disclosure relate to automatically or dynamically modifying a queue operation or virtual queue in response to insufficient or excessive latency to further prevent inefficient operation over a period of time, ride under-utilization, ride overcrowding, and/or waste of ride resources. Further, the virtual queuing system may be configured to monitor and track how guests are transferred or moved throughout the queue to provide finer control of the virtual queue. Accordingly, based on finer control of the virtual queue, the virtual queuing system can be configured with automatic and dynamic control of attraction access, thereby preventing ride starvation (starvation), overcrowding, or wasting other ride resources.

FIG. 1 is a schematic diagram of a theme park 110 having at least one amusement park attraction 112, the attraction 112 accessible via a virtual queue controlled by a virtual queue system 114. Some attractions 112 may feature multiple rides 118. For example, in the depicted embodiment, the water slide attraction 112a may include multiple channels or slides (e.g., shown as rides 118a, 118b, and 118 c) accessed via a single virtual queue that allows access to the loading area 116 for guests. That is, the guest assumes a position in the virtual queue of the attraction 112a to enter the loading area 116. Once in the loading area 116, guests are distributed among the separate slides (i.e., rides 118a, 118b, and 118 c) to experience the attraction 112. Accordingly, in the depicted embodiment, as an example, the attraction 112a can accommodate multiple guests (e.g., two, three, or more) at a time. However, guests may enter their assigned rides 118 at different rates, resulting in dynamically changing the real-time guest throughput rate for each ride 118 of the multi-ride attraction 112. For example, some guests may be hesitant to other guests, resulting in a temporarily slower real-time guest throughput rate in one ride 118 relative to another. Further, the ride operators may have different efficiencies in distributing and loading guests into their respective rides 118. Accordingly, determining the total guest throughput of a multi-ride attraction 112 may be complex and may involve considering different real-time guest throughput rates at each individual ride 118 of the attraction 112 to determine the total guest throughput of the attraction 112.

While the depicted embodiment is shown in the context of a water attraction (such as a water slide), it should be understood that other multi-ride attractions 112 are contemplated. Further, the rides 118 of individual attractions 112 may include any suitable number of rides 118 (slides, tracks, road vehicles, etc.) housing any suitable number of guests, although these rides 118 are nevertheless to be accessed via a single virtual queue of attractions 112. Additionally, the theme park 110 may also feature other attractions 112 that do not include multiple rides 118 (e.g., a single ride attraction 112).

In one embodiment, via the virtual queue system 114, after submitting a request from a guest association device 120 (e.g., a smartphone, a guest wristband) or a guest kiosk (kiosk) 121, the guest is assigned a position in the virtual queue for the amusement park attraction 112 and does not need to physically queue to enter the attraction 112 until a specified time. Accordingly, guests using the virtual queue may spend less time waiting in line during their visit to theme park 110. Additionally, data from the virtual queue provides guidance for theme parks for scheduling the opening and closing of rides to optimize guest throughput and amusement park attraction efficiency.

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

In some embodiments, the latency signal 122 communicates the current latency, the guest latency (i.e., the latency for an individual guest in the virtual queue), or some combination thereof. The current wait time indicates the following time: that is, an ungrouped guest, if joined the virtual queue at that time, should expect a time to wait before entering the amusement park attraction 112. In contrast, guest latency indicates the following times: that is, an individual guest that already has a position in the virtual queue still must wait until the time of entering the amusement park attraction 112. Thus, the guest latency corresponds to a specific location of an individual guest already queued in the virtual queue, while the current latency corresponds to the next available location (i.e., unassigned location) in the virtual queue.

In one embodiment, the virtual queue system 114 determines the wait time based at least on the scheduling information or ride schedule data of the attractions 112. The ride schedule data includes planned ride openings and closings for attractions 112 at specified times during the theme park hours, as well as dynamic openings or closings in response to desired crowd flows. In the depicted embodiment, the attraction 112a includes three rides 118a, 118b, and 118c (e.g., slides, ride vehicles, seats, etc.) that are accessed by a single virtual queue. For the purpose of increasing attraction efficiency, one or more of the three rides 118 may be turned off during park hours (e.g., at a specified time) as 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 one hundred twenty guests per hour. Thus, in the depicted embodiment, the second ride 118b and the third ride 118c may be turned off during the time of day when guest throughput is historically low. When guest throughput is low, opening only the first ride 118a may allow the attraction to maintain sufficient guest throughput to keep latency low while requiring fewer employees to operate the attraction 112 a. 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 in order to minimize latency. Because opening and closing the rides 118 of the attractions 112 dynamically changes the real-time guest throughput and the future guest throughput during the closing time, having the virtual queue system 114 determine the wait time based at least on the scheduling information may provide the guest with a more accurate wait time. Thus, scheduling information relating to date, time, and other details regarding the closing and opening of the ride is sent to the virtual queue controller 130 of the virtual queue 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 may use operator interface 132 to manually enter or modify scheduling information for the virtual queue controller.

Figure 2 is a flow diagram of a method 234 for determining a current wait time (e.g., for guests not already queued) and a guest wait time for a guest in a virtual queue of an attraction 112 using the virtual queue system 114 according to the present embodiment. The method comprises the following steps: providing ride schedule data for the attraction 112 to the virtual queue controller 114, wherein the ride schedule data includes specified times for one or more rides to open and close (block 236), and wherein opening and closing one or more rides increases or decreases estimated guest throughput for the attraction accordingly; calculating variable guest throughput data, wherein the variable guest throughput data is calculated based at least on ride schedule data and historical guest throughput data for the attraction (block 238); determining a current wait time for a next available location in a virtual queue of the attraction 112 based on the at least next available location and the variable guest throughput data (block 240); outputting a latency signal to the display unit, the guest associated device, or a combination thereof, the latency signal indicating a current latency for a next guest to queue for the attraction 112 (block 242); in response to the guest queue request, assigning the guest to a location in a virtual queue of the attraction (block 244); determining a guest latency for the guest based on at least the location in the virtual queue and the variable guest throughput data (block 246); and outputting a latency signal indicative of the guest latency to the guest associated device (block 248). Details of aspects of method 234 will be discussed in further detail herein with respect to related system features.

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

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

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

In certain embodiments, virtual queue controller 330 may include a memory device 354a, memory device 354a storing instructions executable by processor 356a for performing the methods and control actions described herein. For example, processor 356a may execute the following instructions: the instructions are for dynamically evaluating virtual queue conditions and determining a wait time for a guest based on guest throughput input 358 and ride schedule data input 360 received by the virtual queue controller 330. The ride schedule data input may be received from the memory storage via user input, and/or via a cloud service. Virtual queue controller 330 may receive scheduling (or rescheduling) information in real-time and may be configured to update the latency based on the updated schedule. In certain embodiments, the virtual queue controller 330 may receive and utilize additional inputs in conjunction with the ride schedule data input 360 and the guest throughput input 358 in determining the wait time.

Further, in certain embodiments, the processor 356a may utilize historical queue condition data input 362 (e.g., historical weather information, previous guest behavior within a particular ride/attraction, calendar information (e.g., time of day, day of week, vacation, etc.), demographic information, number of guests within group(s), etc.) in conjunction with the ride schedule data input 360 and/or guest throughput input 358 in determining wait time. For example, the processor 356a may consider historically slower people or colder seasonal conditions when providing latency. As a further example, in certain embodiments, the processor 356a may utilize various characteristics of guests within the queue (e.g., type, gender, age, number, etc.) in conjunction with the ride schedule data input 360 and the guest throughput input 358 in order to determine the wait time. While the guest throughput input 358, the ride schedule data input 360, and the historical queue condition data input 362 are depicted as being received via the operator interface 332, it should be understood that various inputs to the virtual queue controller 330 may be received from other components of the system 314. In one embodiment, the guest throughput input 358 includes real-time throughput information that is communicated to the virtual queue controller 330 based on the interaction of the guest associated device 320 with a sign-on device or a tap-in device or by passing through a gate at each attraction 112. For example, as each guest enters the attraction 112, the associated guest identification information from the guest association device 320 is read by a reader that includes communication circuitry and is associated with the attraction. In an embodiment, each individual ride 118 of the attraction 112 is configured to provide guest identification from a reader located at the top or beginning of each ride 118. The guest identification information, associated attraction 112 information, and/or ride 118 information, and a timestamp may be provided as input to the virtual queue controller 330 to determine dynamic real-time guest throughput (e.g., guest/hour). Further, the attraction 112 may also include a reader at the ride exit to track the total 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, the ride operator may track multiple guests and periodically provide the number of guests to the operator interface 332. Further, the virtual queue controller 330 may store guest throughput information to update the historical queue status input 362 with the obtained guest throughput data.

Processor 356a of virtual queue controller 330 may include one or more processing devices, and memory may include one or more tangible, non-transitory, machine-readable media. By way of example, such machine-readable media can comprise 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 a processor or other processor-based device (e.g., a mobile device). For example, virtual queue controller 330 may be accessed by an operator interface 332 (e.g., a computer-based workstation or mobile device, and/or may include an input/output interface 364 and a display).

In some embodiments, the guest associated device 320 having the processor 356b and the memory 354b may be a personal guest device (e.g., a smart phone, tablet, laptop, etc.) or a park queue device (e.g., a smart wristband, portable communication device, etc.) assigned to the guest. The park queue device includes a program for viewing the wait time and sending a queue request. Guests using the personal guest device may be authorized to access the program (e.g., web-based programs, smartphone app, downloadable programs, etc.). For example, a ticket or confirmation email to a theme park may include details for finding the program, and a username, password, or combination thereof for accessing the program. Personal information associated with the guest (height, weight, age, and other demographic characteristics) may be linked with the username and/or password so that guest identification information may be transmitted with the queue request signal. When a park queue apparatus is assigned to a guest, guests using the park queue apparatus may have their guest information uploaded to the apparatus. The virtual queue controller 330 may utilize guest identification information to determine latency, as provided herein.

In some embodiments, the system may include a queue station (e.g., guest kiosk 121) that includes a processor and memory and is configured to provide additional resources for guests to view time and send queue requests. The guest may use a form of guest identification (e.g., username, password, card, RF wristband, personal information, etc.) to access the queuing function at the queuing station. Queue stations may be located at various locations around theme park 110. In some embodiments, at least one queue station is provided adjacent the entrance of each attraction 112, such that guests are provided with means for queuing for the attractions 112 at locations adjacent the attractions 112. In some embodiments, the queue station may only allow guests to queue for attractions 112 that are closest to the queue station. In other embodiments, general queuing stations are located throughout the theme park 110 that may be used to queue attractions 112 in the theme park 110.

In certain embodiments, the display unit 326 is configured to receive the latency signal 322 from the virtual queue controller 330 and display the current latency for the attraction 112. In some embodiments, at least one display unit 326 is disposed adjacent to the entrance of each attraction 112. The display unit may be configured to display only the current waiting time for the sights 112 of the nearest display unit. In other embodiments, general display units are disposed in general locations (e.g., dining areas, walking roads, etc.) around theme park 110. A general display unit may display the current waiting times for a plurality of sights 112.

FIG. 4 is a block diagram of virtual queue system 414 with monitoring device 466. In this embodiment, the monitoring device 466 may have a communication circuit 452d to establish communication with the virtual queue controller 430. The monitoring device 466 may also have a processor 456c and a memory device 454 c. The monitoring device 466 is configured to monitor and/or determine the current queue condition and output a queue condition signal 468 to the virtual queue controller 430. In some embodiments, attractions 112 have both physical and virtual queues. In such an embodiment, the guest first enters the virtual queue before entering the physical queue. The physical queue provides a buffer queue or spare area for the attractions 112 to increase the efficiency of the attractions 112. For example, without a physical buffer queue, if a guest does not arrive at the attraction 112 at the time specified by the virtual queue system 414, there may not be a guest to fill in the location of the absent guest. Thus, at least one ride 118 of the attraction 112 may continue to operate at less than the maximum occupancy of that ride, thereby reducing the efficiency of the attraction 112. However, using both the physical queue and the spare area, there may be multiple guests at the attraction 112 to fill the ride to maximum occupancy even when the guests do not arrive on time. In certain embodiments, the monitoring device 466 is configured to monitor the current queue condition 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. Further, in some embodiments, the attractions 112 may be implemented without a physical queue.

In some embodiments, the monitoring device 466 may be configured to monitor or determine current queue conditions, including, but not limited to, the length of the queue, the number of guests in the queue, the flow rate of guests into and out of the queue, the particular individual within the queue (e.g., identifying a guest in the queue), the number of sub-queues within the queue, the type of guest within the queue, and so forth. In some embodiments, the monitoring device 466 may monitor particular locations within the queue (e.g., geographic locations, queue areas, etc.) and output the number of guests in each particular location to the virtual queue controller. In some embodiments, the monitoring device 466 may monitor the guest not only at the beginning or end of the queue, but also whether the guest leaves the queue in the middle of the queue. In certain embodiments, the monitoring device 466 may determine various characteristics of guests within the queue (e.g., type, gender, age, number, etc.) and output this data to the virtual queue controller 430 to track and record historical throughput data associated with the queue as it relates to the attraction 112.

In certain embodiments, the monitoring device 466 includes a counting mechanism 470 configured to monitor queue conditions. For example, the number of guests within the queue may be monitored using a counting mechanism 470, which counting mechanism 470 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 sensor 472 (e.g., an optical sensor, a mechanical pedal (tread), an RF sensing system, etc.) disposed in physical proximity to the queue and communicatively coupled to the virtual queue controller 430. Sensor 472 can provide continuous feedback associated with current queue conditions to virtual queue system 414. For example, in the case where guests each carry an RF identification, an RF sensor associated with the monitoring device may be configured to monitor when a particular guest(s) enters and leaves the queue, and output that data to the virtual controller. As a further example, the sensor 472 may be configured to identify individual guests at the entry and exit of the queue and continuously output this information to the virtual queue controller so that various conditions of the queue (e.g., latency, queue length, etc.) may be calculated based on the length of time the individual guests spend within the queue.

Based on the received feedback, virtual queue system 414 may be configured to dynamically respond to current queue conditions. In some embodiments, virtual queue system 414 may include functionality to automatically remove a guest from a virtual queue based on one or more factors (e.g., being in the queue for an extended period of time that exceeds a current queue latency, the guest being seen at an unexpected location within the queue, the guest entering another queue, the guest being identified as being out of the queue, etc.). In certain embodiments, virtual queue system 414 may virtually monitor and dynamically adjust multiple queues (or sub-queues) and may be configured to correlate data for various queues when calculating or determining current queue conditions.

In some embodiments, virtual queue system 414 may utilize feedback received from monitoring device 466 to calculate other queue conditions. The virtual queue system 414 may calculate various factors or variables such as, but not limited to, the 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), the length of time the queue is in different states (over-filled state, under-filled state, starved state, overcrowded state, etc.), and so forth. For example, based on the number of guests within the queue and/or the flow rate of guests entering or leaving the queue, the virtual queue system 414 may calculate a current wait time, guest wait time, current attraction capacity, and so forth. In particular, virtual queue system 414 may be configured to determine accurate real-time information related to the queue system and queue condition based at least in part on continuous feedback received from monitoring device 466.

In another embodiment, in response to a determined latency for guests in the virtual queue and/or physical attraction access area, the virtual queue system 414 may be configured to output a queue modification signal 474. In particular, the virtual queue system may be configured to dynamically respond to deviations of the calculated wait time for the guest from the range of wait times by outputting the queue modification signal 474.

In some embodiments, the queue modification signal 474 is configured to temporarily disable the ability to add guests to the virtual queue of an attraction when the latency for that attraction 112 is longer than the maximum limit of the latency range. For example, when the virtual queue controller 430 considers the virtual queue to be too long, the virtual queue controller is configured to output a queue modification signal 474 to the guest associated device 420 (e.g., a smart phone, a guest kiosk, etc.). The queue modification signal 474 is configured to transmit an instruction to a queue program on the guest association device 420 to disable the option for sending a queue request for the attraction 112. Additionally, queue modification signal 474 may include instructions to: a message is displayed relating to the portion of the queue program that is disabled. Once the latency of the virtual queue falls back to a length of time within the latency range, the virtual queue controller 430 may be configured to send a resume signal 476 to enable an option for sending a queue request.

In some embodiments, queue modification signal 474 includes instructions to: when the wait time for an attraction 112 is shorter than the minimum limit of the wait time range, the guest is notified of a shorter queue time than the average queue time for that attraction. For example, queue modification signal 474 may include instructions to: the instructions are for the guest associated device to display a message indicating that the attraction 112 has a short latency. In some embodiments, queue modification signal 474 may include instructions to: a fast queue option in the program on the guest associated device 120 is activated. For example, the fast queue option may activate an on-screen pop-up message indicating that the virtual queue has a short latency. Additionally, the pop-up message may include a button configured to establish that the guest entered into the virtual queue of the attraction 112. In certain embodiments, virtual queue controller 430 is configured to: before sending the queue modification signal 474 to other guests, it is sent to the guest association device 420 linked to: the guest has experienced fewer attractions 112 at the theme park 110 than other guests during that day, giving individuals who have experienced fewer attractions 112 the first opportunity to enter the virtual queue. In some embodiments, the program includes an option for dismissing messages activated in response to the guest associated device receiving the queue modification signal 474. However, once the latency of the virtual queue rises to a length of time within the latency range, the virtual queue controller is configured to send a resume signal to automatically dismiss notifications from the queue modification signal.

In certain embodiments, the virtual queue controller is configured to send the attraction modification signal 478 to the amusement park operator device 480 in response to a wait time that is longer than a maximum limit or shorter than a 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 the ride of the amusement park ride 118 to adjust the current guest throughput in response to the wait time. In addition to disabling the virtual queue or sending notifications, dynamically opening and closing the rides 118 of the attractions 112 may further increase amusement park attraction efficiency.

FIG. 5 is a graph illustrating latency 582 and latency range 584 for a virtual queue. The latency range provides a minimum latency 586 and a maximum latency 588 for an acceptable latency at a particular time, e.g., whereby the latency between the minimum latency 586 and the maximum latency 588 may form the boundary of a predetermined desired latency range. When the latency 582, as calculated or estimated by a virtual queue controller (e.g., virtual queue controller 430), as provided herein, falls below the minimum latency 586 or rises above the maximum latency 588, the virtual queue controller 430 is configured to output a queue modification signal 474. In certain embodiments, virtual queue controller 430 calculates latency bounds 584 based at least on historical throughput data. The virtual queue controller 430 may use the historical throughput data to determine an average latency 590 of the attraction 112 within each time slot of the day. The virtual queue controller 430 may determine a plurality of average wait times, where the average wait time is calculated for each time slot of each day of the week, month, year, etc. For example, the virtual queue controller 430 may calculate the average wait time of the attraction 112 at 10 am by averaging all historical throughput data within a time slot of 10 am. However, in other embodiments, virtual queue controller 430 calculates the average wait time at 10 am on monday by averaging all historical throughput data at 10 am on monday. Additionally or alternatively, in determining the plurality of average wait times 590, the virtual queue controller 430 may further utilize historical queue condition data (e.g., historical ride schedule data, historical guest throughput, weather data, guest behavior, calendar information, demographic information, number of groups of guests, and size of groups of guests, etc.).

In some embodiments, virtual queue controller 430 may calculate latency bound 584 by adding a latency buffer to average latency 590. For example, virtual queue controller 430 may calculate average wait times for 9 am, 11 am, 1 pm, and 3 pm as five minutes, twenty minutes, forty minutes, and thirty-five minutes, respectively. The virtual queue controller 430 may provide a five minute latency buffer to the average latency to calculate the latency range. Thus, the wait times at 9 am, 11 am, 1 pm, and 3 pm range from 0-10 minutes, 15-25 minutes, 35-45 minutes, and 30-40 minutes, respectively. In other embodiments, the virtual queue controller 430 may use dynamic latency buffering to calculate the latency bound 584. Dynamic latency buffering may vary the length of time of the latency buffering at different time slots of the day. For example, the latency buffer at 9 am may be five minutes, while the latency buffer at 1 pm may be fifteen minutes. In other embodiments, the dynamic latency buffering comprises: a longer latency buffer between the average latency and the maximum limit than between the average latency and the minimum limit. In some embodiments, historical throughput data, operator input, etc. may be used to determine dynamic latency buffering.

In some embodiments, the latency range may be set based on input received by virtual queue controller 430. In some embodiments, virtual queue controller 430 is configured to receive input from operator interface 332. The operator may use the operator interface 332 to communicate instructions as follows: this instruction is used by virtual queue controller 430 to set a specific latency range. The operator may set a static or dynamic latency range. In some embodiments, the operator may set a range of latencies that is independent of historical throughput data. For example, in the case where the attraction 112 is temporarily at a low staffing (under staffed), the operator may adjust the wait time range 584 of the attraction 112 to reduce guest throughput of the attraction 112 until the attraction 112 is properly staffed. In another example, the operator may adjust the latency ranges 584 for multiple attractions 112 to encourage guests to queue for a particular attraction 112 in order to prevent overcrowding of other attractions 112 or locations.

In certain embodiments, the virtual queue controller 430 may determine the 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 current guest throughput data, historical ride schedule data, and the like. The variable guest throughput data represents an expected guest throughput for a single ride 118 of an attraction 112 in each time slot during a park hour. The virtual queue controller 430 is configured to predict expected guest throughput data based at least on deviations of current guest throughput data from historical throughput data and other queue conditions. To accurately analyze throughput changes and prevent scheduling changes from skewing the calculations, first, the current guest throughput data and the historical throughput data are divided by the number of currently open rides and the number of historically open rides, respectively (i.e., to determine the current guest throughput data and the historical guest throughput data for a single ride). Further, 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 within each time slot during the park hours. The virtual queue controller 430 is configured to utilize the expected guest throughput associated with the guest location, the current queue conditions (e.g., number of guests in the queue, etc.) to determine the latency.

As an exemplary embodiment, in some cases, the attractions 112 may include one or more rides 118 that are open and closed at different times throughout the day. For example, a first ride 118a of an attraction 112 may be open at the same time as the opening of the theme park 110, and a second ride of the attraction 112 may be open one hour after the opening of the theme park 110. 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 open/close times of each ride during the day to determine the wait times for the attractions 112. For example, the virtual queuing system takes into account the delayed open time of the second ride 118b when determining the wait time for the attraction 112. In this manner, the virtual queuing system may provide accurate waiting times for attractions 112, rather than artificially low waiting times associated with situations where all rides 118 are open. In other words, the estimated total guest throughput of the attraction 112 will decrease when one or more rides 118 are closed. Further, the virtual queuing system 114 accounts for the one hour delay in opening the second ride 118b during the assigned wait time before the second ride 118b is scheduled to open.

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

In one embodiment, for the attraction 112, the historical guest throughput data may show: typically, at 1 PM, the attraction 112 has a guest throughput of 240 guests per hour, and at 2:00 PM has a guest throughput of 220 guests per hour, both times with two ride openings. The current condition, as determined by the monitoring device 466, indicates: the ride's current guest throughput at 1 PM is 120 guests per hour with one ride 118a open. However, the ride schedule data provided to the virtual queue controller 430 indicates that the second ride 118b is scheduled to be open at 1:30 PM. First, the virtual queue controller may determine that the historic guest throughput for one ride vehicle at 1:00 pm is 120 guests per hour, and that the ride throughput for each vehicle is comparable to the historic guest throughput data. However, historical guest throughput data shows the following trends: it indicates that at 2:00 PM, the guest throughput for one ride vehicle historically decreased to 110 guests per hour. The virtual queue controller 430 may be configured to account for reduced guest throughput in computing latency. Additionally, while 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 vehicle. The expected ride throughput should be increased to 240 guests per hour minus the expected drop in guest throughput. Thus, the expected ride throughput at 1:30 pm may be 230 guests per hour. Using the estimated guest throughput data related to the guest location and the current queue conditions, the virtual queue controller may dynamically determine the wait time 582. Additionally, in some embodiments, the virtual queue controller may continuously calculate a variable guest throughput to account for changes in current guest throughput and other queue conditions in order to provide updated latency for the guest.

In some embodiments, virtual queue controller 430 further utilizes other queue conditions to determine latency 582. In particular, the virtual queue controller 430 may be configured to consider various factors, such as, but not limited to, previous guest behavior, current activities of guests both inside and outside the queue, current or historical locations of guests inside the park, weather, calendar information (e.g., time of day, day of week, holidays, etc.), demographic information, number of guests within the group(s), and so forth. Further, in some embodiments, virtual queue controller 430 may record real-time queue conditions as historical queue condition information for future use. For example, the obtained real-time queue conditions may indicate that one ride 118a has historically slower guest throughput relative to the other rides 118b, 118c, even though all three rides 118 are otherwise quite similar or of the same type. This slower throughput may be due to the entrance in the loading area of the ride 118a being farther from the entrances of the other rides 118b, 118c, due to the loading angle causing slower loading, or due to display props near the ride 118a causing guests to wander at the ride entrance. Accordingly, a more accurate estimated guest latency may take into account which of the rides 118 was shut down and use historical guest throughput information associated with each individual ride 118. For example, when the slower ride 118a is shut down, the estimated guest wait time may use the historical guest throughput of the faster ride 118b, 118c in calculating the estimated guest wait time instead of the historical guest throughput from the shut down slower ride 118 a.

In certain embodiments, the virtual queue controller 430 may be configured to determine the wait time 582 for each attraction 112 based on a coordinated analysis of other queue conditions. For example, in certain embodiments, the virtual queue controller 430 may receive ride schedule data and guest throughput data for a plurality of attractions 112 and may be configured to coordinate the wait times 582 for the attractions 112 based on the received data. In some embodiments, virtual queue controller 430 may utilize other types of data to perform the 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 an accurate wait time 582 for each attraction 112.

While only certain features of the 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 cited and applied to material objects and concrete examples of a practical nature, which arguably improve the technical field and are thus not abstract, intangible or purely theoretical. Further, if any claim appended to the end of this specification contains one or more elements designated as "means for [ performing ] [ function ]," or "step for [ performing ] [ function ]," it is intended that such elements will be interpreted at 35 u.s.c.112 (f). However, for any claim that contains an element specified in any other way, it is intended that such element will not be interpreted at 35 u.s.c.112 (f).

Claims (20)

1. A virtual queue system, comprising:

a virtual queue controller comprising a processor and a memory, wherein the memory stores instructions executable by the processor and is configured to cause the virtual queue controller to:

receiving a request for a location in a virtual queue of an attraction, the request associated with an individual guest, the attraction including a plurality of rides, wherein the virtual queue allows the individual guest to access one of the plurality of rides of the attraction, and wherein guests in the virtual queue are distributed among the plurality of rides of the attraction via the virtual queue;

assigning an individual guest to a location in a virtual queue of an attraction in response to the request;

receiving ride schedule data for an attraction, wherein the ride schedule data includes information about changes in status of individual rides of the plurality of rides; and

determining a wait time for an individual guest for an attraction based at least on a location of the individual guest in a virtual queue, the ride schedule data, and a historical guest throughput at the attraction; and

a communication circuit configured to output a signal to the guest associated device indicating a latency for the attraction.

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

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

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

5. The 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 of the virtual queue.

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

7. The system of claim 1, wherein the virtual queue controller is configured to dynamically update a latency for an individual guest based on receiving a change in the ride schedule data and output an updated latency signal to the guest associated device.

8. The system of claim 1, wherein the plurality of rides of an attraction are accessed via a single loading area of the attraction.

9. The system of claim 8, wherein access to the single loading area is based on a location of individual guests in a virtual queue.

10. The system of claim 1, wherein the plurality of rides of an attraction are of the same type.

11. The system of claim 1, wherein the ride schedule data indicates a shutdown of a subset of individual rides over a time range.

12. The system of claim 11, wherein the determined wait time during the time frame is longer relative to a later time when a subset of individual rides is open.

13. The system of claim 11, wherein the ride schedule data indicates a closing of the subset at the requested time and a subsequent opening of the subset during the wait time, wherein the wait time is determined based on an increase in estimated guest throughput for an attraction within a portion of the wait time after the opening.

14. The system of claim 11, wherein the ride schedule data indicates a shutdown of the subset after receiving the request, wherein the wait time is determined based on a reduction in estimated guest throughput for attractions for a portion of the wait time after the shutdown.

15. A virtual queue system, comprising:

at least one monitoring device configured to monitor a current queue condition of the attraction and output a queue condition signal; and

a virtual queue controller comprising a controller and communication circuitry, wherein the virtual queue controller is configured to:

receiving the queue status signal;

determining a current wait time for the attraction based on at least the queue status signal and preset ride schedule data for the attraction, wherein the preset ride schedule data indicates a closure of a subset of a plurality of rides of the attraction; and

outputting a queue modification signal in response to the determined current latency being outside of a predetermined latency range.

16. The system of claim 15, wherein the queue modification signal is configured to: temporarily disabling the ability to add guests to the virtual queue of the attraction when the current wait time is above the maximum wait time of the wait time range.

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

18. The system of claim 16, wherein the virtual queue controller is configured to output the queue modification signal to a guest associated device to cause the guest associated device to disable user input, wherein the guest associated device is configured to transmit a request for a location in a virtual queue for an attraction based on user input.

19. A method, comprising:

providing ride schedule data including attractions of a plurality of rides to a virtual queue controller, wherein the ride schedule data includes scheduled times associated with closure of a subset of the plurality of rides;

calculating variable guest throughput data for the attraction, wherein the variable guest throughput data is 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 a virtual queue of an attraction based on at least the next available position and the variable guest throughput data, wherein the current wait time overlaps the scheduled time such that a subset of the plurality of rides experience a shutdown during the current wait time, and wherein the current wait time is calculated based on first variable guest throughput data and second variable guest throughput data, the first variable guest throughput data indicating a first guest throughput during the shutdown period, the second variable guest throughput data indicating a second guest throughput during a time other than the shutdown; and

outputting a current latency signal to a display unit, a guest associated device, or a combination thereof, the current latency signal indicating the current latency in queuing for the attraction.

20. The method of claim 19, wherein the historical throughput data comprises historical guest throughput data for one or more attractions relating to: the number of rides opened, weather data, guest behavior, calendar information, demographic information, the number of guests in the group, the size of the group of guests, or some combination thereof.