Guest-facing game information management system and method

Abstract

The check-in system includes an amusement park attraction associated with the check-in process. The check-in system also includes a database and a controller. The database stores data indicating availability of the amusement park attraction. The controller receives a request from a guest to participate in the amusement park attraction. In response to the request, the controller transmits one or more forms, one or more waivers, or both to the guest. The controller also receives the one or more forms, one or more waivers, or both after completion. The controller further verifies that the one or more forms, one or more waivers, or both are compatible with the amusement park attraction. In response to determining compatibility, the controller further transmits an entry code indicating a verified status to the guest.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates generally to the field of amusement parks. In particular, embodiments of the present disclosure relate to techniques for efficiently checking in guests to participate in an amusement park experience. [Background technology]

[0002] In some entertainment environments, such as amusement parks, guests may participate in an amusement experience. For example, the experience may include special events (e.g., seasonal events), rides, festivals, and the like. Often, the experience may be accompanied by paperwork, such as a pre-check document, to be completed prior to participating in the experience. The pre-check document may include one or more waivers, consent forms, informative forms, and the like. The guest may receive these documents, such as at the entrance to the experience, and may complete the pre-check document prior to participating in the experience. In some instances, the pre-check document may be customized based on a particular guest. Additionally, amusement park personnel may verify that the pre-check document is completed correctly. In some instances, amusement park personnel may take subsequent actions based on information provided by the guest in the pre-check document. For example, if the pre-check document indicates that the guest requires assistance to enter or exit the experience, amusement park personnel may call another personnel to be tasked with escorting the guest. However, completing the pre-screening process (e.g., the guest completing paperwork, park personnel verifying that the paperwork is properly completed and responding to the guest's requests, and receiving indication that the guest has passed the check to participate in the experience) can take time and may take up time that could otherwise be spent enjoying the experience. Summary of the Invention

[0003] The following summarizes certain embodiments common in scope to the subject matter of the original claims. These embodiments are not intended to limit the scope of the disclosure, but rather to provide merely a brief summary of some disclosed embodiments. Indeed, the disclosure may include a variety of forms that may be similar to or different from the embodiments set forth below.

[0004] In one embodiment, the check-in system includes an amusement park attraction associated with the check-in process. The check-in system also includes a database and a controller. The database stores data indicating availability of the amusement park attraction. The controller receives a request from a guest to participate in the amusement park attraction. In response to the request, the controller transmits one or more forms, one or more waivers, or both to the guest. The controller also receives the one or more forms, one or more waivers, or both after completion. Further, the controller verifies that the one or more forms, one or more waivers, or both are compatible with the amusement park attraction. Further, in response to determining compatibility, the controller transmits an entry code to the guest indicating a verified status.

[0005] In one embodiment, a method of operating a check-in system includes receiving a request to reserve a feature of an attraction. The method further includes determining availability of one or more features of the attraction as a feature. The method also includes transmitting one or more documents to be completed in response to determining that the features are available. The method further includes receiving the one or more documents after completion and validating the one or more documents after completion. The method includes providing a code indicative of a validated status of the one or more documents after completion. The method further includes reserving the feature of the attraction in response to validating the one or more documents after completion.

[0006] In one embodiment, another method of operating a check-in system includes transmitting, via an amusement park application, a request for one or more guests to reserve a feature of an amusement park attraction. The method includes receiving, via the amusement park application, a request for each of the one or more guests to complete a waiver prior to attending the amusement park attraction. The method also includes transmitting, via the amusement park application, the waiver as completed. Further, the method includes receiving, via the amusement park application, a message for admission to the amusement park attraction without a verification process at the amusement park attraction.

[0007] These and other features, aspects, and advantages of the present disclosure will be better understood from the following detailed description when read in conjunction with the accompanying drawings, in which like parts are designated with like numerals throughout. [Brief description of the drawings]

[0008] [Figure 1] 1 is a schematic diagram of an amusement park application on a display according to an embodiment of the present disclosure. [Diagram 2] 2 is a schematic diagram of questions in a form displayed based on selection of an amusement park experience in the amusement park application of FIG. 1 according to an embodiment of the present disclosure. [Diagram 3] FIG. 3 is a schematic diagram of a waiver that may be displayed based on the selection of an amusement park experience and information provided in response to the questions in FIG. 2, in accordance with an embodiment of the present disclosure. [Figure 4] FIG. 1 is a block diagram of a check-in system for checking guests into an amusement park experience according to an embodiment of the present disclosure. [Diagram 5] FIG. 1 illustrates a process flow diagram of a guest face-to-face check-in process according to an embodiment of the present disclosure. [Figure 6] FIG. 13 is a process flow diagram of a non-guest face-to-face check-in process according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] One or more specific embodiments of the present disclosure will be described below. In order to concisely describe these embodiments, not all of the features of the implementations may be described herein. It should be understood that in the development of any such implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developer's particular objectives, such as compliance with system-related and business-related constraints that may vary from implementation to implementation. Moreover, it should be understood that such development efforts may be complex and time-consuming, but are nevertheless a routine undertaking of design, fabrication, and manufacture for those of ordinary skill in the art having the benefit of this disclosure.

[0010] When introducing elements of various embodiments of the present disclosure, the articles "a," "an," and "the" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements. It is also to be understood that references to "an embodiment," "an embodiment," or "some embodiments" of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also contain the recited features. The use of the terms "approximately" or "near" is to be understood to mean to include close to a target (e.g., a design, value, amount), such as within any suitable or expected margin of error (e.g., within 0.1% of a target, within 1% of a target, within 5% of a target, within 10% of a target, and within 25% of a target).

[0011] As used herein, an "amusement park application" may refer to a platform for accessing one or more amusement park applications (e.g., games), tickets, documents, and notices related to rides and special events such as festivals. Additionally, as used herein, a "precheck document" may refer to any one or more physical or electronic documents related to an amusement park experience that must be completed prior to participating in the amusement park experience. The precheck document may include one or more waivers, consents, information forms, and the like. Additionally, the precheck document may facilitate a precheck process to approve a guest or guest group to participate in the amusement park experience prior to arrival at the amusement park experience. Additionally, as used herein, a "guest" or a "user" may synonymously refer to a person accessing an entertainment environment, such as an amusement park experience, at an amusement park.

[0012] As described above, a guest may participate in an amusement park experience, such as an event at an amusement park. The amusement park experience may have the guest complete pre-check forms prior to participating in the amusement park experience. These forms may include information to efficiently place the guest and / or other guests in the guest party within the amusement park experience. For example, the amusement park experience may be a holiday parade float, and the forms may include questions related to party size, the number of adults and / or children in the party, the height of individuals in the party, and any special assistance requirements related to boarding or exiting the float, etc. Additionally or alternatively, the forms may include a waiver for participating in the parade. Once the forms are completed, they may be checked for validity. In particular, amusement park personnel may verify that the pre-check forms are completed correctly (e.g., completely completed, with no blank or illegible fields, etc.). The park personnel may also verify that the guests meet float thresholds such that the information in the documentation meets one or more thresholds for riding a float (e.g., the age of each guest in the group is above a minimum age threshold). Finally, the park personnel may reserve an appropriate float for the guest group (e.g., assign a float that can accommodate the guests based on the information in the documentation). Manually validating and checking in guests (e.g., making a reservation for the guest upon approval of the documentation) at the amusement park experience (e.g., at the gate to the ride) may be time consuming. As described herein, the check-in system may validate and check in guests before they arrive at the amusement park experience for an efficient park experience. That is, the check-in system may approve the guest and reserve the amusement park experience for the guest, effectively checking the guest into the amusement park experience.

[0013] It should be noted that while the examples provided herein may relate specifically to certain aspects of an amusement park check-in system, such as facilitating guest check-in for an amusement park experience, the techniques of the present disclosure may be applied in other conditions and / or contexts. As such, the examples should be understood to reflect illustrative examples of a check-in system and / or amusement park to provide an illustrative context, and should not be considered as limiting further applicability of the present approach. For example, it should be understood that the present disclosure is applicable to additional situations in which pre-event information compatibility validation and / or checking may be utilized.

[0014] With this in mind, FIG. 1 is a schematic diagram of an amusement park application 10 for an amusement park. The amusement park application 10 may include or provide access to one or more portals (e.g., related to the amusement park) accessible through a display interface 11, such as a web page or mobile application displayed on a device. As described in detail herein, the display interface 11 may include visual and / or selectable components (e.g., buttons, editable fields, etc.) that allow a guest (e.g., a user) to interact with the amusement park application 10. The display interface 11 may display information related to the amusement park, guests, or both. For example, the amusement park application 10 may include in-park announcements (e.g., closure information, new ride opening dates, and ride wait times, etc.), purchased tickets, indicators or reminders of special events at the amusement park (e.g., performances, plays, shows, parades, etc.), a list of games offered on a gaming platform associated with the amusement park, etc. As shown, the amusement park application 10 may include one or more points of interest 12, which may include guest-accessible indicators (e.g., names or symbols) that identify areas associated with the amusement park (e.g., physical amusement park experiences or in-game virtual experiences). Although the points of interest 12 are described below as referring to parades (e.g., special events), the points of interest 12 may refer to any guest-accessible area, such as, but not limited to, attractions, rides, restaurants, events, restrooms, and games. It is noted that, as used herein, points of interest 12 may refer to indicators of areas or to the areas themselves, depending on the context.

[0015] As an example, in FIG. 1, the selected point of interest 12 (point of interest 1) refers to a holiday parade. The amusement park application 10 displays information about the point of interest 12, such as location, duration, description, and reservation options for the actual event corresponding to the point of interest 12. Here, the amusement park application 10 may include information about the holiday parade as the point of interest 12, such as one or more event periods 14 (e.g., a week of a holiday month), one or more reservation timings 16 (e.g., one or more available time slots on one or more dates of the week), and any other parade-related information (as indicated by ellipses). The amusement park application 10 includes a first period 14A (week of January 3, 2021 to January 9, 2021) and a second period 14B (week of January 10, 2021 to January 16, 2021) as periods of the holiday parade. In the illustrated embodiment, a guest desires to participate in a parade during a first time period 14A. The first time period 14A includes four reservation timings 16 available for reservation to participate in the parade (e.g., Sunday, January 3 at 11:00 AM and 6:00 PM, Monday, January 4 at 6:00 PM, and Tuesday, January 5 at 6:00 PM). However, each of the time periods 14 may include one or more reservation timings 16. In some embodiments, the amusement park application 10 may provide real-time updates such that if a previously unavailable reservation becomes available at the time of cancellation, the corresponding reservation timing 16 is shown as available for reservation. In the illustrated embodiment, the user has selected a reservation timing 16 for Sunday, January 3, 2021 at 11:00 AM, as indicated by the dashed box.

[0016] In some embodiments, the amusement park application 10 may include an account associated with the guest such that the guest has a unique user identification (ID) 17 and associated guest data. In the illustrated embodiment, a user ID 17 is presented on the display interface 11. The user ID 17 (e.g., 10359) may include a unique combination of phonograms, numbers, and / or letters that identify a guest profile associated with the guest. The guest may select the user ID 17 and / or the amusement park application 10 may assign the user ID 17 as long as the user ID 17 is available (e.g., not currently being used by another guest). The amusement park application 10 (e.g., via a check-in system) may store the guest data (e.g., in one or more databases) and tag the guest data with the user ID 17 such that the amusement park application 10 and / or the amusement park may search the guest data using the unique user ID 17. By way of example, the guest data may include an email address, a guest name or screen name, age, height, family members, and their respective ages and heights, language used, preferred language, etc. The guest data may also include an annual pass associated with the guest, the duration of the visit, rides used, zones used, activity on a gaming portal associated with the park, and other tracked guest activity associated with or within the park. As an example, an annual pass may be unique to a guest, and thus an annual pass ID may be used as the user ID 17 to search for guest data for an annual pass holder.

[0017] Additionally, in some instances, the amusement park application 10 may pull data from third-party applications related to the guest (e.g., medical information indicative of a high likelihood of assistance being sought in the case of a ride) and store it as guest data after tagging it with the user ID 17. Specifically, as described in more detail with respect to FIG. 4, the check-in system may communicate with third-party application programming interfaces (APIs) that enable communication between the check-in system and the third-party applications. Specifically, these APIs may act as intermediaries that send requests from the amusement park application 10 to the third-party applications (e.g., third-party systems), receive information from the third-party applications, and send information back to the check-in system. In this manner, the check-in system may have access to third-party information that would not otherwise be available through the check-in system. As an example, the check-in system via the amusement park application 10 on a mobile device may have access to third-party applications on the mobile device, such as social media applications, medical applications, and banking applications, if the guest allows access. The check-in system may use such information to learn about the guest. The third party data may indicate preferences including, but not limited to, preferred float in a holiday parade (e.g., as indicated on social media), number of family members, medical conditions, disabilities, and / or information about the guest's family. In some embodiments, the check-in system may use user ID 17 to look up the guest data, use the guest data to pre-check the guest, provide appropriate pre-check paperwork, automatically fill in portions of the pre-check paperwork for the guest to confirm, and / or validate the guest for the point of interest 12 (e.g., a parade). In this manner, the check-in system may use the guest data to efficiently verify and check the guest into a reservation before the guest arrives at the point of interest 12.

[0018] FIG. 2 is a schematic diagram of a form question presented based on selection of an amusement park experience (e.g., point of interest 12) in the amusement park application of FIG. 1. Specifically, as described above, the guest selects a reservation timing 16 for the parade on Sunday, January 3, 2021 at 11:00 AM. As described above, the amusement park application 10 includes input fields, selectable buttons, and the like that facilitate receiving input from the guest. Upon selection of the reservation timing 16, one or more sub-questions 18 regarding the point of interest 12 may appear. Here, the sub-questions 18 include a first sub-question 18A that asks for the number of guests in the group. The guest may enter the number of guests (e.g., 1, 2, 4, etc.) that will ride on a float in the parade. A second sub-question 18B asks for the number of adults (e.g., 18 years or older) in the group, and a third sub-question 18C asks for the number of children (e.g., under 18) in the group. The second additional question 18B and the third additional question 18C are additional questions to the first additional question 18A. In some embodiments, the additional questions 18 from the previous questions may be presented within the amusement park application 10 (e.g., causing subsequent questions to appear) upon answering the previous questions. Additionally or alternatively, the additional questions 18 may be removed from the display based on the answer to the previous question. Thus, the additional questions 18 may be dynamic, appearing or disappearing based on the previous answer. Furthermore, subsequent additional questions 18 may be tailored to the answer provided for the previous additional question 18.

[0019] The supplemental questions 18 also include a fourth supplemental question 18D that asks whether there are guests in the party who require special assistance, such as to accommodate a condition (e.g., wheelchair accessibility or language translation). A fifth supplemental question 18E, which is a supplemental question of the fourth supplemental question 18D, can ask for an indication as to how many guests require special assistance. As described above, the fifth supplemental question 18E can appear based on a particular response to the supplemental question prior to triggering the fifth supplemental question 18E. For example, if the guest answers "yes" to the fourth supplemental question 18D, the check-in system can cause the fifth supplemental question 18E to appear. Alternatively, if the guest answers "no" to the fourth supplemental question 18D, the check-in system can indicate that the information required by the form is complete, cause a different supplemental question 18 to appear, and / or delete the fifth supplemental question 18E. As described above, the user ID 17 can be used to pre-populate editable answers to the supplemental questions 18, as well as to tailor the questions associated with the user ID 17. For example, if guest data associated with user ID 17 indicates that the guest purchased an adult parade ticket and a child parade ticket, the check-in system can prompt for information about both the adult and child and pre-populate answer fields based on the ticket purchase and other guest data. In some embodiments, the information requested about points of interest 12 can be static (e.g., the same format) for each guest, for example, based on the protocol for the particular point of interest (e.g., questions to be answered about the ride protocol for the ride of interest).

[0020] 3 is a schematic diagram of waivers presented based on selection of an amusement park experience (e.g., point of interest 12) in FIG. 1, information provided for the questions in FIG. 2, or both. That is, upon selection of a parade as point of interest 12, the amusement park application 10 may provide the guest with a waiver 20 for participating in the parade. Additionally or alternatively, the waiver 20 provided may be based on information provided for additional questions 18. As shown, the waiver 20 includes a waiver for adults in the group, a waiver for children in the group, and other event-related documentation (as indicated by the ellipsis). Thus, the amusement park application 10 may request information, such as via a form, completion of a waiver, etc., prior to the guest and group's arrival at the parade. In some embodiments, if the waiver 20 is not completed correctly (e.g., guest initials are not present on each page, digital signature is illegible, etc.), the amusement park application 10 may prompt the user to correct the identified issues while validating the pre-check documents (e.g., forms including additional questions 18, the waiver 20, and other event related documents). As described in more detail with respect to FIGS. 5 and 6, the guest may receive an indication that the check-in process is complete and the group has been approved for the point of interest 12. In this manner, the amusement park application 10 may provide an interface for pre-checking (e.g., a guest facing check-in process) and validation (e.g., a non-guest facing check-in process) for the point of interest 12 prior to the guest's arrival at the point of interest 12. A pre-check process that solicits information via pre-check documents, validates the guest and provides approval instructions prior to arrival provides an efficient process for participating in a ride.Additionally, pre-checking can eliminate bottlenecks in guest queues that would otherwise occur due to distributing forms, requesting information via forms, requesting signatures on waivers 20, checking forms and waivers for conformity, verifying correct completion, approving or disapproving guests, and reserving time slots at points of interest 12.

[0021] To illustrate a system for interfacing with and validating guests via an amusement park application, FIG. 4 illustrates a check-in system 50 that checks in guests prior to their arrival at a point of interest 12. As illustrated, the check-in system 50 includes park sensors 52, a controller 54, points of interest 12, the amusement park application 10, a guest mobile device 60, and a third party application 62. In some embodiments, the check-in system 50 may also include a monitoring system 56, a service desk 58, or both. It should be understood that the illustrated system is intended to be illustrative only, and that certain features and components may be omitted and various other features and components may be added for ease of implementation in accordance with the disclosed embodiments.

[0022] The controller 54 can include an input device 70, a processor 72, a memory 74, and communication circuitry 76. The input device 70 can receive input data from the park sensors 52, the amusement park application 10, the third party application 62, and the guest mobile devices 60. In the following description, the amusement park application 10, the third party application 62, and the guest mobile devices 60 are described as separate components of the check-in system 50 that provide data to the input device 70, although these components can alternatively be integrated into or in communication with the amusement park application 10 (as indicated by dashed lines). Based on the input data received at the input device 70, the controller 54 can check in and validate guests to attend the points of interest 12 as described above.

[0023] The controller 54 may check in the guest based on the information provided for check-in and / or verify compliance with procedures for the point of interest 12 (e.g., approve or validate the guest). As described above, the points of interest 12 may include attractions throughout the park, such as rides, virtual game rooms, picnic areas, restaurants, and special events, such as parades or shows. In some cases, as described above, the guest may complete pre-check paperwork at the point of interest 12 in order to participate in the point of interest 12. Completing such paperwork after arrival at the point of interest 12 may take time and cause delays in participating in the point of interest (e.g., riding a float in a parade). Thus, the controller 54 may communicate with the points of interest 12 (e.g., another system and / or park personnel) and the park application 10 to pre-check the guest prior to arrival at the point of interest 12.

[0024] The amusement park application 10 may include an account application 78 and a notification application 80. The account application may include a user ID 17 and any information related to the guest's user ID 17. In some embodiments, as described above, the guest data may be associated with a particular user ID 17 such that pre-check paperwork may be adjusted and / or pre-populated for verification based on the guest data. The notification application 80 may provide a message to the guest. The message may include communications related to the amusement park, such as information related to the points of interest 12. The notification application 80 may inform the guest of pre-check paperwork to be completed prior to arrival at the points of interest 12. In some embodiments, the notification application 80 may also send a message to the guest suggesting points of interest 12 that may be used based on the guest's location (e.g., based on the location of the guest running the amusement park application 10). Additionally, the notification application 80 may notify the guest that the guest has been approved to attend the points of interest 12 (e.g., pre-check paperwork has been verified). As described herein, the amusement park application 10 may provide a quick response (QR) code for entry into the amusement park application 10, where the QR code indicates that the guest has been checked in and approved for a reservation to attend the point of interest 12. The guest may receive the QR code via the amusement park application 10, email, text message, and the like.

[0025] In some embodiments, the controller 54 can initiate the check-in process based on data from the park sensors 52. Specifically, the park sensors 52 can indicate a selection or intent to attend the point of interest 12. The park sensors 52 can include inputs within the amusement park application 10 and physical sensors at the amusement park. For example, the park sensors 52 can include touch sensors on the mobile device 60 that indicate the selection and reservation timing 16 of the point of interest 12. The park sensors 52 can include one or more radio frequency identification (RFID) tags, one or more cameras, one or more weight sensors, one or more electronic readers, and / or one or more proximity sensors. The park sensors 52 can be placed or positioned in areas where a guest presence is expected, such as near the point of interest 12. For example, a park sensor 52 placed in a guest row of the point of interest 12 can detect a guest and determine that the guest is likely to attend the point of interest 12 that includes that row. The RFID tag can communicate with the electronic reader to indicate the presence of the guest. Thus, the electronic reader can be positioned in a manner that allows for scanning of the RFID tags along, such as a specific path to the point of interest 12. In some embodiments, the RFID tag may include a guest wearable RFID tag associated with a particular user ID 17. Thus, input data from the electronic reader may indicate the presence of a guest associated with the user ID 17 at the time the guest scans the wearable RFID tag. The controller 54 may then look up the guest data based on the user ID 17 to fill out a form provided to the guest to participate in the point of interest 12. In some embodiments, the amusement park application 10 may communicate with the amusement park sensors 52 such that a guest detected near a particular point of interest 12 (e.g., within a threshold distance of the point of interest 12) may receive prompts suggesting an interest in nearby points of interest 12 and / or a prompt to complete a check-in process prior to arriving at the point of interest 12.

[0026] The third party application 62 may provide input data to the input device 70. That is, if the guest permits, the third party application 62 may share data with the check-in system 50. The third party application 62 may include systems associated with third parties, including entities that do not have a direct relationship with the amusement park. The third party application 62 may provide third party data from one or more third parties collected through the third party's website, mobile application, and / or other platform. As discussed above, the third party application 62 may include, but is not limited to, a social media application, a medical application, and / or a banking application. Thus, the third party data from the third party application 62 may include data related to a social media application, a medical application, and / or a banking application.

[0027] The guest mobile device 60 may also provide input data to the input device 70. The guest mobile device 60 may be able to share device data with the check-in system 50 upon permission from the guest. Device data may include, but is not limited to, images and videos stored on or accessible to the guest mobile device 60 (e.g., images of the parade or other points of interest), a GPS location of the guest mobile device 60 (indicating, for example, that the guest is walking toward or within a threshold distance of the point of interest 12 and therefore likely wishes to participate in the point of interest 12), tracking data determined by the guest mobile device 60, and / or setting preferences (e.g., that a particular accessibility feature is enabled, etc.).

[0028] The check-in system 50 includes a monitoring system 56 and a service desk 58. In the following description, the monitoring system 56 and the service desk 58 are described as separate components of the check-in system 50, but these components may communicate with each other (e.g., as indicated by dashed lines) or may be integrated into a single system (e.g., the service desk 58 is part of the monitoring system 56). The monitoring system 56 may be a management system that monitors the park sensors 52, the points of interest 12, and the amusement park application 10. For example, the monitoring system 56 may monitor data used in the check-in process and guest validation, as well as control signals that control features of the points of interest, such as floats. In particular, the monitoring system 56 may ensure that the park sensors 52, the points of interest 12, and the amusement park application 10 function as expected. In some embodiments, the monitoring system 56 may also track ride wait times or queues to maintain expected throughput while performing a pre-check process.

[0029] The monitoring system 56 may also control or reconfigure the controller 54 if the controller 54 is not functioning as expected (e.g., the control signals are erroneous). Thus, the monitoring system 56 may reset or recalibrate the park sensors 52, points of interest 12 and the amusement park application 10, and / or disable the display or organization of pre-check documents on the amusement park application 10 for a particular guest (as originally determined by the controller 54). The monitoring system 56 may reset algorithms related to pre-check documents. In some embodiments, the monitoring system 56 and the controller 54 may be implemented as a single controller.

[0030] In some embodiments, if the service desk 58, which may include a human or virtual service agent, notices any issues with the point of interest 12, it can manually disable the features of the point of interest 12 via a stop mechanism (e.g., a button) to override the control signal from the controller 54. Also, since guests can be tracked as described above (e.g., via guest-wearable RFID tags), the service desk 58 can monitor guest activity and use this to address unexpected delays or unexpected functionality at the amusement park. As an example, tracked activity can indicate that a guest is unlikely to be able to join the parade at their reserved reservation timing 16, indicating to the controller 54 that the float can be reassigned upon confirmation from the late guest.

[0031] The controller 54 may enable the communications circuitry 76 to interface with various electronic devices, such as the monitoring system 56, the service desk 58, the amusement park application 10, and / or the points of interest 12. The monitoring system 56 and / or the service desk 58 may communicate with the controller 54 to receive and / or transmit information (as indicated by the double-headed arrows) to ensure that the amusement park application 10 and / or the points of interest 12 are operating as expected. Additionally or alternatively, the controller 54 may also enable the communications circuitry 76 to interface with components of the points of interest 12. For example, the communications circuitry 76 may enable the controller 54 to be communicatively coupled to a network, such as a personal area network (PAN), a local area network (LAN), and / or a wide area network (WAN). Thus, in some embodiments, the controller 54 may process data from the input device 70, determine the points of interest 12, determine guest data associated with the guest from the respective user ID 17, determine pre-check documentation to provide to the guest, pre-fill portions of the pre-check documentation, communicate the documentation to the amusement park application 10, receive input from the amusement park application 10, approve the guest to participate in the points of interest 12, and the like, via the communications circuitry 76. For example, the processor 72, after processing sensor data from the input device 70, may determine control signals that enable the communications circuitry 76 to wirelessly transmit control data to the amusement park application 10 and / or the points of interest 12 to facilitate inviting the guest to participate in the points of interest 12. In other embodiments, the communications circuitry 76 may be connected to the amusement park application 10 and / or the points of interest 12 via a wired connection.

[0032] The processor 72 may include one or more processing devices that receive input signals from the input device 70 regarding guest data that can be used to check in and validate guests prior to booking a point of interest 12 using the techniques described herein. The memory 74 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 can be used to hold or store desired algorithms (e.g., program code) in the form of machine-executable instructions or data structures and that can be accessed by the processor 72 or other processor-based devices. In particular, the processor 72 may include a processing core that executes the machine-executable instruction algorithms stored in the memory 74. The processor 72 may include a processor-side interface for software applications running on the processing core to interact with hardware components of the point of interest 12 associated with the processor 72, such as the hard components of the float or other features of the parade. The memory 74 can store guest data and algorithms for validating a guest for a particular point of interest 12, validating and proceeding to participate in the point of interest 12, etc. The memory 74 can store the guest data for subsequent retrieval after tagging it with a corresponding user ID 17. That is, the check-in system 50 can look up data related to a guest by looking up the user ID 17 and using the associated guest data.As an example in an amusement park setting, the stored algorithms may include, but are not limited to, algorithms for determining the presence of a guest based on sensor data from the amusement park sensors 52, algorithms for identifying a particular guest, algorithms for identifying points of interest 12, algorithms for retrieving guest data for a user ID 17 if available, algorithms for determining appropriate pre-check documentation (e.g., forms and waivers, etc.) to provide to the points of interest 12, algorithms for determining and / or completing portions of the pre-check documentation based on the guest data, and the like.

[0033] FIG. 5 is a flow diagram of a method 100 in which a guest undergoes a check-in process on the amusement park application 10. That is, the method 100 includes a guest-facing interface and a check-in process of the check-in system 50. Although the method 100 of FIG. 5 and the method 130 of FIG. 6 are described using a particular order of acts, it should be understood that the described acts may be performed in an order different from the order shown, and some described acts may be skipped or not performed entirely. In general, at least some of the steps of the method 100 and the method 130 may be at least partially implemented by the check-in system 50 of FIG. 4. In particular, the steps may be at least partially performed by the controller 54 and / or the processor 72 of the controller 54 executing instructions stored in a tangible, non-transitory computer-readable medium, such as the memory 74. Additionally or alternatively, at least some of the steps of the method 100 and the method 130 may be performed by any other suitable component, control logic, or the like.

[0034] As discussed above, the guest may be interested in attending a point of interest 12 (e.g., an amusement park attraction). Thus, the processor 72 may request attendance at the point of interest 12 (process block 104) based on input received at the amusement park application 10 (e.g., the guest selects a point of interest 12) executing on an electronic device (e.g., the guest device, the mobile device 60) associated with the guest. As discussed above, the points of interest 12 may include rides, special events such as parades or shows, and the like. The processor 72 may select a time to attend the point of interest 12 (process block 106) based on input received at the amusement park application 10 (e.g., the guest selects a reservation timing 16). That is, the guest may review various time slots for the points of interest 12 on one or more days of the week, as described with respect to FIG. 2, and the processor 72 may select the guest's reservation time based on the selection from the guest. This selection may cause the amusement park application 10 to display one or more questions (e.g., additional questions 18) regarding the guest and / or guest group, as described with respect to FIG. 2. The processor 72 may receive answers to one or more questions regarding the guest and / or guest group based on input received at the amusement park application 10 (e.g., the guest inputs information for additional questions 18) (process block 108). That is, the guest may input (e.g., select, type, etc.) answers to one or more general questions or questions related to points of interest for a selected time, and the processor 72 may process the answers.

[0035] Additionally or alternatively, the processor 72 may receive and display on the amusement park application 10 one or more waivers 20 for the guest and / or guest group to receive on the display (process block 110). Specifically, the processor 72 may obtain or receive general, specific, or both waivers 20 for subsequent provision to the guest and / or guest group within the amusement park application 10. Thus, as described with respect to FIGURE 3, the amusement park application 10 may request information via pre-check documentation, including a form or the like (e.g., one or more questions), or request completion of a waiver 20 prior to the guest's arrival at the point of interest 12.

[0036] The processor 72 may submit the waiver 20 for review (process block 112) after the waiver is indicated to be completed based on the received guest input (e.g., the guest submits the completed waiver 20). Specifically, the guest may receive the waiver 20 within the amusement park application 10 as part of the check-in process, complete the waiver 20, and submit the waiver 20 for review. The guest may receive an indication via the processor 72 as to whether the waiver 20 has been approved (decision block 114). Specifically, the guest may receive an indication as to whether the guest and / or guest group has been approved or verified to participate in the point of interest 12. The processor 72 may provide the indication based on the entered information from the waiver 20.

[0037] If the waiver 20 is approved, the processor 72 receives information regarding entry to the point of interest 12 (process block 115) and correspondingly may display this information within the amusement park application 10 for receipt by the guest. That is, the guest may receive a notification (e.g., a message) indicating that the waiver 20 has been granted, along with a QR code that can be verified or scanned for admission to entry to the point of interest 12. The QR code may indicate that the guest and / or guest group's entry to the point of interest 12 has been verified. On the other hand, if the waiver 20 is not approved, the processor 72 receives instructions to amend the waiver 20 (processor block 116) and correspondingly may display the instructions on the amusement park application 10 for receipt by the guest. In particular, processor 72 may provide (e.g., the guest may receive) instructions such as that waiver 20 was not granted, the reason why waiver 20 was not granted, recommendations to modify waiver 20 (e.g., indications of which fields need to be modified within waiver 20), and any other reasons for the failed or unapproved check-in. Processor 72 may thus update waiver 20 based on revised or new information entered by the guest in amusement park application 10.

[0038] FIG. 6 is a flow diagram of a method 130 for a non-guest facing check-in process. That is, the method 130 includes a backside verification of the guest based on input received at a guest facing interface as described with respect to FIG. 5. Behind the verification process of checking in the guest, the processor 72 may receive a request from the guest to participate in a point of interest 12, such as a parade, at a particular time and location (process block 132). The processor 72 may receive the input and perform point of interest related checks, such as determining whether the point of interest 12 is available at the selected time. In terms of a parade, the processor 72 may determine whether a float is available for a particular guest at the selected time. Specifically, the processor 72 may reference a database that stores the number of floats in the parade and present the reservation to determine the availability of a suitable float. The database may generally store any information regarding the characteristics available for reservation of the point of interest 12. With respect to floats, the database may store the type of float (e.g., two-seater, four-seater, etc.), daily float reservation or availability times, and special accessory features on the float. In some instances, availability may change based on answers provided to questions and / or information provided in waiver 20. That is, the particular float reserved for a guest during a particular available time slot may change based on new information, such as the number of guests in a party and special accessories that will participate in the parade with the guest.

[0039] In some embodiments, the processor 72 may identify the guest (process block 134). Specifically, as described with respect to FIG. 1, the processor 72 may use a user ID 17 associated with the guest within the amusement park application. As described above, the user ID 17 may include age, height, family members and their respective ages and heights, language spoken, preferred language, special assistance preferences, and the like. The processor 72 may send the guest one or more questions (e.g., as additional questions 18) regarding the selected time slot for attending the point of interest 12 (process block 136). For example, in the case of a parade, the processor 72 may request information regarding the number of adults, children, or both, who will be riding the same float. The processor 72 may receive answers to the one or more questions from the amusement park application 10 based on the guest's input to the questions (process block 138). For example, the guest may respond to a question indicating that the party includes the guest (e.g., an adult) and three children.

[0040] The processor 72 may retrieve and send one or more waivers to the guest based on the responses received based on the information provided by the guest (process block 140). For example, if the guest responds that the group includes a certain number of adults and children, the processor 72 may retrieve and send waivers for the specific number of adults and children. In some embodiments, the point of interest 12 may require each guest to complete a specific waiver 20, and thus may send several waivers 20 to the guest at any one time. The processor 72 may receive the completed waivers 20 (process block 142). After the guest and / or group completes and submits the waivers 20, such as by signing the waivers (e.g., using a finger or a stylus in the amusement park application 10), the processor 72 may receive the submitted waivers 20 to verify compliance with the point of interest 12's procedure for completing the waivers 20.

[0041] After receiving the completed waiver, the processor 72 may determine whether the waiver meets the suitability for participating in the point of interest (decision block 144). In some embodiments, suitability may be based on one or more factors, such as the point of interest 12, the particular guest, and legibility. As an example, suitability for the point of interest may be related to a minimum weight and / or age for riding a float. If the completed waiver 20 is in place, the processor 72 may approve the guest and send a message indicating that the request to participate in the point of interest 12 was successfully approved (process block 145). The check-in system 50 may also check in the guest at the point of interest 12 (e.g., pre-approve the guest's participation). Additionally, the check-in system may reserve a requested date and time for the guest to participate in the point of interest 12. In some embodiments, the approval message may include a QR code or another unique identifier, as described above. In some instances, the unique identifier may be secure, such that it is not easily copied or susceptible to tampering (e.g., being used by another guest). On the other hand, if the processor 72 does not match, the processor 72 may not approve the guest (process block 146). Thus, the guest may not be able to attend the point of interest 12. As described above, the processor may send a request to the guest (e.g., via the amusement park application 10) to amend the waiver 20 within a predetermined time period (e.g., to hold the reservation) so that the guest may be approved to attend the point of interest 12. In some embodiments, the processor 72 may request payment within the amusement park application 10. For example, some points of interest 12 may require payment for reservations (e.g., holiday shows, restaurant reservations, etc.). In such instances, the processor 72 may refund the payment if the pre-clearance paperwork associated with the reservation was not completed correctly.In this manner, the check-in system 50 can validate and check-in guests before they arrive at a point of interest 12 (e.g., an amusement park experience) for an efficient park experience.

[0042] Specifically, some of the benefits and efficiencies provided by the check-in system 50 include improved computational operations. The improved computational operations can include a check-in process that reduces the number of, often irrelevant documents that are reviewed when validating a guest. Rather than processing multiple redundant documents for each guest, which can be time-consuming and use relatively large amounts of processing power, the check-in system 50 described herein utilizes data to provide appropriate, tailored documents for computational processing when checking in a guest. Additionally, performing computational processing of documents in one location (e.g., back-end or non-guest interface) can expedite the time- and power-intensive process that would otherwise be associated with multiple check-in processes at various locations (e.g., park applications, point of interest entrances, point of interest queues, etc.).

[0043] Although 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 that comply with the true spirit of the disclosure. It is to be understood that any of the features illustrated or described with respect to the above figures may be combined in any suitable manner.

[0044] The technology presented and claimed herein refers to and applies to tangible objects and specific examples of a practical nature that positively improve the art and are therefore not abstract, intangible, or purely theoretical. Moreover, if any claim appended at the end of this specification contains one or more elements designated as "means for [performing] ... [function]" or "step for [performing] ... [function]," such elements are to be construed pursuant to 35 U.S.C. 112(f). On the other hand, for any claim containing an element designated in any other manner, such elements are not to be construed pursuant to 35 U.S.C. 112(f). [Explanation of symbols]

[0045] 10 Amusement Park Applications 12 Points of Interest 50 Check-in System 52 Park Sensor 54 Controller 56 Monitoring System 58 Service Desk 60 Mobile Devices 62 Third Party Applications 70 Input Device 72 processors 74 Memory 76 Communication Circuits 78 Accounts 80 notifications

Claims

1. A check-in system, Amusement park attractions related to the check-in process, a database storing data indicative of the availability of the amusement park attractions; A controller; The controller comprises: receiving a request from a guest to participate in the amusement park attraction; Responding to the request, transmitting one or more forms, one or more waivers, or a combination thereof to the guest; receiving said form(s), said waiver(s), or a combination thereof, after completion; verifying that the one or more forms, the one or more waivers, or the combination thereof are compatible with the amusement park attraction; In response to determining a match, transmitting an entry code to the guest indicating a verified status. It is configured as follows: Check-in system.

2. 2. The check-in system of claim 1, wherein the controller is configured to check in the guest at the amusement park attraction using the admission code without a verification process at the amusement park attraction.

3. The check-in system of claim 1 , wherein the entry code comprises a Quick Response (QR) code.

4. 2. The check-in system of claim 1, wherein the controller is configured to, in response to determining that the one or more forms, the one or more waivers, or the combination thereof are not in compliance, send a request to the guest to modify the one or more forms, the one or more waivers, or the combination thereof.

5. The controller is Identifying the guest; retrieving information related to said guest; transmit the one or more forms, the one or more waivers, or any combination thereof based at least in part on the information; The check-in system according to claim 1 , configured as follows:

6. The check-in system of claim 5 , wherein the controller is configured to pre-populate at least a portion of the one or more forms, the one or more waivers, or the combination thereof based on the information.

7. The check-in system of claim 1 , wherein the request includes a time slot of a plurality of time slots for attending the amusement park attraction.

8. 8. The check-in system of claim 7, wherein the controller is configured to determine availability of the amusement park attraction during the time period prior to transmitting the one or more forms, the one or more waivers, or the combination thereof based on obtaining sensor data from the amusement park attraction.

9. The check-in system of claim 1 , wherein the controller is configured to determine the availability based on pending reservations for the amusement park attraction.

10. 1. A method of operating a check-in system, comprising: receiving a request to reserve a feature of the attraction; determining availability of one or more features of the attraction as the feature; in response to determining that the feature is available, transmitting one or more forms to be completed; Receiving said one or more documents after completion; validating said one or more documents after completion; providing a code indicating the validated status of said one or more documents upon completion; reserving the feature of the attraction in response to validating the one or more documents after completion; A method comprising:

11. The method of claim 10 , wherein the request includes an indication of a number of people to participate in the feature.

12. 12. The method of claim 11, wherein determining availability of the feature includes determining current reservations, future availability of the one or more features based at least in part on the number of people and a current state determined by at least one sensor of the one or more features.

13. The method of claim 11 , wherein the one or more documents are based at least in part on the number of people.

14. The method of claim 10 , wherein the request indicates a number of adults, a number of children, or a combination thereof.

15. 15. The method of claim 14, wherein determining feature availability includes determining current reservations, future availability of the one or more features based at least in part on the number of adults, the number of children, or a combination thereof.

16. The method of claim 10 , wherein the request includes an indication of special assistance requirements for participating in the feature.

17. The method of claim 16 , wherein the one or more documents are based at least in part on the specific assistance request.

18. 1. A method of operating a check-in system, comprising: submitting, via the amusement park application, a request for one or more guests to reserve a feature of the amusement park attraction; receiving, via the amusement park application, a request for each of the one or more guests to complete a waiver prior to participating in the amusement park attraction; submitting said waiver upon completion via said amusement park application; receiving, via the amusement park application, a message for admission to the amusement park attraction without a verification process at the amusement park attraction; A method comprising:

19. 20. The method of claim 18, comprising receiving, via the amusement park application, a request to make payment for the amusement park application prior to participating in the amusement park application.

20. The method of claim 18 , wherein the message includes a unique code associated with the reservation of the feature.

Images