DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
Claims 1, 3, 5, and 10-26 are pending and examined herein.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 16-17, and 19-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by CRONIN (US Patent Publication 2018/0240161).
Regarding claim 16 CRONIN discloses,
a tangible, non-transitory, computer-readable medium, comprising instructions for generating a wait time recommendation for an attraction of a plurality of attractions of a theme park that, when executed by a processor ([109], abstract), cause the processor to:
receiving, user context information comprising a set of preferred attractions ([0063] If the user device is determined not to be at the attraction in S402, the method will proceed to S403. In S403, a selection of a category of sites of interest is made. For example, categories for selection may include attractions, shows, restaurants/café, and merchants. [0064] In S404, the expected wait times for the selected category are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for sites of interest according to a category selected by the visitor, sites of interest located within a predetermined distance, sites of interest preselected by the visitor, sites of interest that have not yet been visited by the visitor, and the like.);
receive, from one or more sensors, positions coordinates of an electronic device within the theme park ([0061] Also, in a non-limiting example, the location data of the user terminal may be GPS data, triangulation location data provided by a cell network, or discrete location data provided by scanning or sensing the user device. For example, if the visitor scans the user device to obtain entry to a particular attraction, the user's device's location may be determined.);
determine an active geographic location of the electronic device within the theme park based on the position coordinates from one or more sensors ([0061] Also, in a non-limiting example, the location data of the user terminal may be GPS data, triangulation location data provided by a cell network, or discrete location data provided by scanning or sensing the user device. For example, if the visitor scans the user device to obtain entry to a particular attraction, the user's device's location may be determined. [0062] In S402, a determination is made by a computer in the tip network whether the user device is at an attraction based on the acquired location data.);
determine a set of attractions of the plurality of attractions within a threshold distance of the geographic location of the electronic device ([0064] In S404, the expected wait times for the selected category are received at the user device from the tip network… sites of interest located within a predetermined distance.);
determine a total wait time of the plurality of attractions by combining respective wait times associated with the plurality of attractions with one another such that the total wait time is a cumulative value of the respective wait times for the plurality of attractions ([0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.);
adjust the total wait time based on one or more skew factors associated with the total wait time to provide an adjusted total wait time ([0071] In addition, the expected wait time may be adjusted to account for a potential increase or decrease in the wait time during the travel time of the visitor based on historical data. For example, if it is known that number of visitors getting in line for the target attraction grows at a rate of 3 people per minute, the expected wait time may be adjusted accordingly to provide the visitor a more accurate estimated wait time. Similarly, if an expected arrival time of the visitor to the target attraction from the current attraction is determined to be near dinner time, it may be determined that no additional visitors may be getting in line for the target attraction, such that shorter wait time may be provided at the time the visitor arrives at the target attraction.);
in response to determining that the set of preferred attractions comprises the attraction, of the plurality of attractions, determine or receive a wait time corresponding to the attraction of the plurality of attractions ([0062] In S402, a determination is made by a computer in the tip network whether the user device is at an attraction based on the acquired location data. In a non-limiting example, if the computer determines that the visitor is within a predetermined distance from the attraction, the computer may determine that the user device is at the attraction. For example, if the user device is near an entrance of the attraction, the computer may determine that the user device is at the attraction. Alternatively, the computer may be set to determine that the user is at the attraction when the user device has passed an entrance of the attraction. [0063] If the user device is determined not to be at the attraction in S402, the method will proceed to S403. In S403, a selection of a category of sites of interest is made. For example, categories for selection may include attractions, shows, restaurants/café, and merchants. [0064] In S404, the expected wait times for the selected category are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for sites of interest according to a category selected by the visitor, sites of interest located within a predetermined distance, sites of interest preselected by the visitor, sites of interest that have not yet been visited by the visitor, and the like.); and
send the wait time recommendation based on the wait time for the attraction, the adjusted total wait time for the plurality of attractions, and a wait time threshold ([0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409. [0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.).
Regarding claim 17, CRONIN discloses
wherein the instructions, when executed by the processor, cause the processor to:
determine a wait time ratio for the attraction of the plurality of attractions, wherein the wait time ratio is based on the adjusted total wait time for the plurality of attractions and the wait time of the attraction ([0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407.);
determine an expected wait time ratio for the attraction of the plurality of attractions, wherein the expected wait time ratio is based on a total historical wait time for the plurality of attractions and an expected wait time of the attraction ([0071] In addition, the expected wait time may be adjusted to account for a potential increase or decrease in the wait time during the travel time of the visitor based on historical data. For example, if it is known that number of visitors getting in line for the target attraction grows at a rate of 3 people per minute, the expected wait time may be adjusted accordingly to provide the visitor a more accurate estimated wait time. Similarly, if an expected arrival time of the visitor to the target attraction from the current attraction is determined to be near dinner time, it may be determined that no additional visitors may be getting in line for the target attraction, such that shorter wait time may be provided at the time the visitor arrives at the target attraction.); and
generate the wait time recommendation based on a comparison between the wait time ratio and the wait time threshold, wherein the wait time threshold is determined by adjusting the expected wait time ratio by a threshold period of time. ([0071] In addition, the expected wait time may be adjusted to account for a potential increase or decrease in the wait time during the travel time of the visitor based on historical data. For example, if it is known that number of visitors getting in line for the target attraction grows at a rate of 3 people per minute, the expected wait time may be adjusted accordingly to provide the visitor a more accurate estimated wait time. Similarly, if an expected arrival time of the visitor to the target attraction from the current attraction is determined to be near dinner time, it may be determined that no additional visitors may be getting in line for the target attraction, such that shorter wait time may be provided at the time the visitor arrives at the target attraction. [0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409.).
Regarding claim 19, CRONIN discloses
determine the wait time threshold based at least in part on date, time, or weather ([0082] In S506, a determination of presence of extraneous factors is made. For example, extraneous factors may include, without limitation, certain weather conditions, street shows or parades scheduled during time of travel to the target venues, and incidents (e.g., accidents, maintenance, or etc.) present in the paths of travel during the time of travel to the target venues. [0083] In S507, a determination of expected arrival time or travel time to get to the target venues is calculated for each of the paths of travel. The expected arrival time may be calculated in view of previous information acquired in one or more of S501, S502, S503, S504, S505 and S506. [0084] In S508, a rate of increase or decrease of the discrete wait time acquired in S502 is determined. The rate of increase or decrease of the discrete wait times may be based on historical data. For example, historical data of target venue A may indicate that wait times grows at a rate of 2 persons per minute during the time of travel (e.g., 2:00 PM to 2:14 PM) estimated for the visitor. Accordingly, in this example, the wait time may be longer than the originally indicated discrete wait time acquired in S502 by the time the visitor arrives at the target venue A.).
Regarding claim 20, CRONIN discloses
determine the wait time threshold based on a total historical wait time for the plurality of attractions at times when a historical park attendance correlates to a park attendance of the theme park ([0080] In S504, a determination of amount of foot traffic is made for each of the identified paths. In an example, an amount of foot traffic present in each of the paths is determined based on location information of visitors. Further, the amount of foot traffic present may be determined based on movement detected by various sensors or beacons located throughout the theme park. In another example, the amount of foot traffic present may be determined based on historical data. However, aspects of the present disclosure are not limited thereto, such that the amount of foot traffic may be determined according to other available technologies. [0130] According to yet another aspect of the present disclosure, the discrete wait times are adjusted based on estimated rate of growth of line based on estimated arrival time and historical data.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3, 5, 24-25 is/are rejected under 35 U.S.C. 103 as being unpatentable by CRONIN (US Patent Publication 2018/0240161) further in view of Burrell (US Patent Publication 2012/0143755).
Regarding Claim 1, CRONIN discloses a method for generating a wait time recommendation (see abstract), the method comprising:
receiving, via a processor, park attendance of a theme park ([0060] In FIG. 4, location data of a user terminal is acquired in S401. In an example, when a visitor visits a theme park, a user device of the visitor may be registered to a tip network. In a non-limiting example, the user device registered may include a mobile device, such as a smart phone, a personal electronic device, a wearable device, and any other electronic device having one or more of a processor, a transmitter or a receiver. Further, the visitor may opt to register his or her own device to the tip network or be provided with a device by the theme park.);
receiving, via the processor, a plurality of historical wait times for a plurality of attractions within the theme park ([0044] The server may also store historical data for the target attraction. For example, the server may store information on average number visiting the target attraction, average wait times for certain days and time of the week, and average time for completing a ride at the target attraction (i.e., throughput rate).);
receiving, via the processor, a wait time for an attraction of the plurality of attractions ([0064] In S404, the expected wait times for the selected category are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for sites of interest according to a category selected by the visitor, sites of interest located within a predetermined distance, sites of interest preselected by the visitor, sites of interest that have not yet been visited by the visitor, and the like.);
determining, via the processor, a typical historical wait time for the attraction based on the plurality of historical wait times ([0044] The server may also store historical data for the target attraction. For example, the server may store information on average number visiting the target attraction, average wait times for certain days and time of the week, and average time for completing a ride at the target attraction (i.e., throughput rate).);
receiving, via the processor, user context information, wherein the user context information comprises a set of preferred attractions ([0063] If the user device is determined not to be at the attraction in S402, the method will proceed to S403. In S403, a selection of a category of sites of interest is made. For example, categories for selection may include attractions, shows, restaurants/café, and merchants. [0064] In S404, the expected wait times for the selected category are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for sites of interest according to a category selected by the visitor, sites of interest located within a predetermined distance, sites of interest preselected by the visitor, sites of interest that have not yet been visited by the visitor, and the like.);
receiving, via the processor and from one or more sensors, sensor data indicative of geographic coordinates of an electronic device ([0061] Also, in a non-limiting example, the location data of the user terminal may be GPS data, triangulation location data provided by a cell network, or discrete location data provided by scanning or sensing the user device. For example, if the visitor scans the user device to obtain entry to a particular attraction, the user's device's location may be determined. [0062] In S402, a determination is made by a computer in the tip network whether the user device is at an attraction based on the acquired location data.);
determining, via the processor, an active location of the electronic device within the theme park based on the geographic coordinates of the electronic device ([0061] Also, in a non-limiting example, the location data of the user terminal may be GPS data, triangulation location data provided by a cell network, or discrete location data provided by scanning or sensing the user device. For example, if the visitor scans the user device to obtain entry to a particular attraction, the user's device's location may be determined. [0062] In S402, a determination is made by a computer in the tip network whether the user device is at an attraction based on the acquired location data.);
determining, via the processor, the attraction is within a threshold distance of the active location of the electronic device ([0062] In S402, a determination is made by a computer in the tip network whether the user device is at an attraction based on the acquired location data. In a non-limiting example, if the computer determines that the visitor is within a predetermined distance from the attraction, the computer may determine that the user device is at the attraction. For example, if the user device is near an entrance of the attraction, the computer may determine that the user device is at the attraction. Alternatively, the computer may be set to determine that the user is at the attraction when the user device has passed an entrance of the attraction.);
generating, via the processor, the wait time recommendation for the attraction ([0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409.); and
instructing, via the processor, a display associated with the electronic device to display a wait time recommendation ([0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409.).
CRONIN discloses a queue management system for notifying wait time recommendations to users. However, CRONIN fails to explicitly disclose:
determining, via the processor, a short wait time threshold for the attraction by decreasing the typical historical wait time by a first threshold period of time;
determining, via the processor, a long wait time threshold for the attraction by increasing the typical historical wait time by a second threshold period of time; and
generating, via the processor, the wait time recommendation for the attraction based on a first comparison between the wait time and the short wait time threshold, a second comparison between the wait time and the long wait time threshold, or both.
Burrell which similarly directed to a queue management for monitoring wait times ([034]) further teaches:
determining, via the processor, a short wait time threshold for the attraction by decreasing the typical historical wait time by a first threshold period of time; determining, via the processor, a long wait time threshold for the attraction by increasing the typical historical wait time by a second threshold period of time (See Fig. 7 [0038] As indicated above, after data collection has occurred, data distribution may begin. That is, once the data is in place, when a consumer requests a wait time estimate or forecast, the current or predicted wait time may be provided to the requesting customer. The wait time might be provided in minutes, or in relative time periods (e.g., short, medium, long). "Short" may correspond to a wait time of less than two minutes. "Medium" may correspond to a wait time of 2-5 minutes. "Long" may correspond to a wait time of five or more minutes. Other predetermined intervals may also or alternatively be used. Other time periods may alternatively be used. The wait time information may be provided to the customer via various channels, e.g., via ATM, web, or mobile device, to name a few. [043] and [0048] According to another feature, a user may request that the system send the user an alert when a wait time reaches a user-specified level. That is, the user might determine that current wait times are too long, but the user's schedule is flexible and the user can delay going to the branch until the wait time is shorter. Instead of relying on future predicted wait times, as discussed above, the user might request that the system send the user a message (e.g., email, SMS, push message via iPhone app, etc.) when the current wait time reaches the low threshold or level. The user may also specify one or more branches that are convenient to the user, and the system will send the alert when the wait time at any of the specified branches is low.); and
generating, via the processor, the wait time recommendation for the attraction based on a first comparison between the wait time and the short wait time threshold, a second comparison between the wait time and the long wait time threshold, or both ([0048] Instead of relying on future predicted wait times, as discussed above, the user might request that the system send the user a message (e.g., email, SMS, push message via iPhone app, etc.) when the current wait time reaches the low threshold or level. The user may also specify one or more branches that are convenient to the user, and the system will send the alert when the wait time at any of the specified branches is low.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to determining, via the processor, a long wait time threshold for the attraction by increasing the typical historical wait time by a second threshold period of time or the alternative, determining, via the processor, a short wait time threshold for the attraction by decreasing the typical historical wait time by a first threshold period of time in order to notify the user based on a comparison between the wait time and the thresholds since such modification is merely a combination of prior art elements known in the art that yields to predictable results such as allowing the system to notify users related to changes or modifications to the expected wait time as disclosed by Burrell.
Regarding claim 3, Burrell further teaches:
sending, via the processor, a respective notification that the wait time for the attraction is shorter than expected in response to a determination that the wait time is less than the short wait time threshold; and sending, via the processor, a respective notification that the wait time for the attraction is longer than expected in response to a determination that the wait time is greater than the long wait time threshold (See Fig. 7 [0038] As indicated above, after data collection has occurred, data distribution may begin. That is, once the data is in place, when a consumer requests a wait time estimate or forecast, the current or predicted wait time may be provided to the requesting customer. The wait time might be provided in minutes, or in relative time periods (e.g., short, medium, long). "Short" may correspond to a wait time of less than two minutes. "Medium" may correspond to a wait time of 2-5 minutes. "Long" may correspond to a wait time of five or more minutes. Other predetermined intervals may also or alternatively be used. Other time periods may alternatively be used. The wait time information may be provided to the customer via various channels, e.g., via ATM, web, or mobile device, to name a few. [043] and [0048] According to another feature, a user may request that the system send the user an alert when a wait time reaches a user-specified level. That is, the user might determine that current wait times are too long, but the user's schedule is flexible and the user can delay going to the branch until the wait time is shorter. Instead of relying on future predicted wait times, as discussed above, the user might request that the system send the user a message (e.g., email, SMS, push message via iPhone app, etc.) when the current wait time reaches the low threshold or level. The user may also specify one or more branches that are convenient to the user, and the system will send the alert when the wait time at any of the specified branches is low).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to include the teachings of Burrell since such modification is merely a combination of prior art elements known in the art that yields to predictable results such as allowing the system to notify users related to changes or modifications to the expected wait time as disclosed by Burrell.
Regarding claim 5, CRONIN discloses:
receiving, via the processor, a total wait time for the plurality of attractions ([0069] In S406, expected wait times at other attractions are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for attractions within a predetermined distance from the current attraction. However, aspects of the present disclosure are not limited thereto, such that the visitor may request to receive wait times for restaurants or shows instead.[0070] Further, in S406, the expected wait times received will include both a calculated estimated wait time of a target attraction and an estimated travel time from the location of the user device to the target attraction. For example, if an estimated wait time for the target attraction is determined to be 30 minutes, and an estimated travel time of the visitor from the current attraction to the target attraction is determined to be 15 minutes, an expected wait time of 45 minutes for the target attraction may be presented to the user device. [0077] At S502, discrete wait times are acquired at various venues. In an example, a discrete wait time may be an expected wait time at a particular ride, show, or a ride a visitor may incur if the visitor was present at the venue. Discrete wait times may be acquired for venues located within a reference distance from a location of the visitor or according to a category selected by the visitor. For example, if the visitor sets a filter to receive wait times for roller coasters, only wait times for the roller coasters may be provided. Similarly, if the visitor sets the filter to receive wait times for restaurants within 50 yards of the visitor, wait times for restaurants meeting the specified criteria may be provided. Further, additional filters may be applied to limit an amount of data to be acquired by the user device.);
determining, via the processor, a wait time ratio for the attraction based on the wait time of the attraction relative to the total wait time for the plurality of attractions a wait time ratio between the wait time and the total wait time;
comparing, via the processor, the wait time ratio to an additional wait time threshold, wherein the additional wait time threshold is based on an expected wait time ratio for the attraction ([0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409. [0084] In S508, a rate of increase or decrease of the discrete wait time acquired in S502 is determined. The rate of increase or decrease of the discrete wait times may be based on historical data. For example, historical data of target venue A may indicate that wait times grows at a rate of 2 persons per minute during the time of travel (e.g., 2:00 PM to 2:14 PM) estimated for the visitor. Accordingly, in this example, the wait time may be longer than the originally indicated discrete wait time acquired in S502 by the time the visitor arrives at the target venue A. [0085] In S509, the wait times at the target venues are adjusted according to the determine rate of increase or decrease in the wait times in S508. For example, if the rate of increase for the target venue A is 2 persons per minute and expected time of travel from a current location of the visitor to the target venue A is 14 minutes, it is expected that net 28 additional visitors have been added to the wait line by the time the visitor arrives at the target venue A. Further, if historical data indicates that 1 minute is added for every visitor that is added to the wait line, it may be determined that 28 additional minutes should be added to the discrete wait time to determine an expected wait time at the time of arrival at the target venue A.); and
generating the wait time recommendation for the attraction based on the wait time ratio and the additional wait time threshold ([0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409. [0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.).
Regarding claim 24, Burrell further teaches:
causing, via the processor, the display of the electronic device to display the wait time recommendation indicating that the wait time for the attraction is shorter than expected based on the first comparison indicating that the wait time for the attraction is less than the short wait time threshold (See Fig. 7 [0038] As indicated above, after data collection has occurred, data distribution may begin. That is, once the data is in place, when a consumer requests a wait time estimate or forecast, the current or predicted wait time may be provided to the requesting customer. The wait time might be provided in minutes, or in relative time periods (e.g., short, medium, long). "Short" may correspond to a wait time of less than two minutes. "Medium" may correspond to a wait time of 2-5 minutes. "Long" may correspond to a wait time of five or more minutes. Other predetermined intervals may also or alternatively be used. Other time periods may alternatively be used. The wait time information may be provided to the customer via various channels, e.g., via ATM, web, or mobile device, to name a few. [043] and [0048] According to another feature, a user may request that the system send the user an alert when a wait time reaches a user-specified level. That is, the user might determine that current wait times are too long, but the user's schedule is flexible and the user can delay going to the branch until the wait time is shorter. Instead of relying on future predicted wait times, as discussed above, the user might request that the system send the user a message (e.g., email, SMS, push message via iPhone app, etc.) when the current wait time reaches the low threshold or level. The user may also specify one or more branches that are convenient to the user, and the system will send the alert when the wait time at any of the specified branches is low).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to include the teachings of Burrell since such modification is merely a combination of prior art elements known in the art that yields to predictable results such as allowing the system to notify users related to changes or modifications to the expected wait time as disclosed by Burrell.
Regarding claim 25, CRONIN discloses
determining, via the processor, a total historical wait time for the plurality of attractions based on the plurality of historical wait times; determining, via the processor, the expected wait time ratio based on the typical historical wait time for the attraction relative to the total historical wait time for the plurality of attractions; and determining, via the processor, the additional wait time threshold by adjusting the expected wait time ratio by an additional threshold period of time ([0071] In addition, the expected wait time may be adjusted to account for a potential increase or decrease in the wait time during the travel time of the visitor based on historical data. For example, if it is known that number of visitors getting in line for the target attraction grows at a rate of 3 people per minute, the expected wait time may be adjusted accordingly to provide the visitor a more accurate estimated wait time. Similarly, if an expected arrival time of the visitor to the target attraction from the current attraction is determined to be near dinner time, it may be determined that no additional visitors may be getting in line for the target attraction, such that shorter wait time may be provided at the time the visitor arrives at the target attraction. [0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409.).
Claim(s) 10-14, 18, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over CRONIN (US Patent Publication 2018/0240161) in view of CRONIN (US Patent Publication 2018/0247270), hereinafter CRONIN II.
Regarding claim 10, CRONIN discloses a wait time recommendation system (see abstract) comprising:
a sensor configured to detect position coordinates of an electronic device, wherein the position coordinates are indicative of an active location of the electronic device within a theme park, the theme park comprising a plurality of attractions ([0061] Also, in a non-limiting example, the location data of the user terminal may be GPS data, triangulation location data provided by a cell network, or discrete location data provided by scanning or sensing the user device. [0076] At S501, location information of the user device may be acquired. Location information of the user device may be acquired by a GPS signal, triangulation of cellular signals, or any other location identification technology.);
a processor ([0021] As illustrated in FIG. 1, the computer system 100 includes a processor);
a memory storing instructions that, when executed by the processor ([0022] Moreover, the computer system 100 includes a main memory 120 and a static memory 130 ), cause the processor to:
receive user context information comprising a set of preferred attractions ([056] Generally, if the customer pays more, then their associated class of service also increases, which means that they may receive notifications of short wait times for attractions they are either interested in as indicated by their preferences.);
determine a set of attractions of the plurality of attractions within a threshold distance of the active location of the electronic device ([0062] In S402, a determination is made by a computer in the tip network whether the user device is at an attraction based on the acquired location data. In a non-limiting example, if the computer determines that the visitor is within a predetermined distance from the attraction, the computer may determine that the user device is at the attraction. For example, if the user device is near an entrance of the attraction, the computer may determine that the user device is at the attraction. Alternatively, the computer may be set to determine that the user is at the attraction when the user device has passed an entrance of the attraction. [0063] If the user device is determined not to be at the attraction in S402, the method will proceed to S403. In S403, a selection of a category of sites of interest is made. For example, categories for selection may include attractions, shows, restaurants/café, and merchants.), wherein each attraction of the plurality of attractions is associated with a respective wait time ([0064] In S404, the expected wait times for the selected category are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for sites of interest according to a category selected by the visitor, sites of interest located within a predetermined distance, sites of interest preselected by the visitor, sites of interest that have not yet been visited by the visitor, and the like. [0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407.);
in response to determining that the set of preferred attractions comprises an attraction of the set of attractions and that the attraction is within the threshold distance of the active location of the electronic device, determine the respective wait time corresponding to the attraction ([0064] In S404, the expected wait times for the selected category are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for sites of interest according to a category selected by the visitor, sites of interest located within a predetermined distance, sites of interest preselected by the visitor, sites of interest that have not yet been visited by the visitor, and the like. [0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409.);
generate a total wait time of the plurality of attractions by combining each respective wait time associated with each attraction of the plurality of attractions with one another such that the toral wait time is a cumulative value of the respective wait times for the plurality of attractions ([0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.);
generate a wait time recommendation for the attraction based on the respective wait time corresponding to the attraction and the total wait time of the plurality of attractions ([0069] In S406, expected wait times at other attractions are received at the user device from the tip network. In a non-limiting example, expected wait times may be received for attractions within a predetermined distance from the current attraction. However, aspects of the present disclosure are not limited thereto, such that the visitor may request to receive wait times for restaurants or shows instead. [0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.);
and send a notification of the wait time recommendation ([0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409..
CRONIN does not explicitly disclose:
determine a wait time based on image data from an additional sensor positioned at the attraction.
However, CRONIN II, which similarly is directed to a theme park management system wherein the user is notified regarding attractions in the vicinity of the user, further teaches:
determine a wait time based on image data from an additional sensor positioned at the attraction ([0015] Attraction conditions, attraction traffic and patron activity information is obtained respectively using attraction condition monitors 115, attraction traffic trackers 120, and patron trackers 125. The information can be stored in their respective databases 130, 135 and 140. Examples of patron trackers include, but are not limited to, pagers provided to the patrons, RF-tagged cards provided to the patrons, applications on patrons' mobile devices, etc. Examples of attraction traffic trackers include, but are not limited to, cameras and/or IR sensors in the vicinity of the attractions. [0018] The traffic optimization software 150 may continually poll the monitors and tracking devices 115, 120 and 125 for updated information. As new maintenance is scheduled/expected downtime is coming up and patron activity is received, the traffic optimization software 150 can update wait times and routes for the patrons. [0019] Furthermore, routes can also be calculated using the patron activity information (e.g. schedule) by the traffic optimization software 150. These routes can facilitate how the patron to proceed from one attraction to another in a time-efficient manner. Furthermore, the traffic optimization software 150 can also calculate new routes based on current and predicted wait times for a planned attraction and nearby/similar attractions. For example, if a nearby or similar attraction has a lower wait time, the traffic optimization software 150 may provide a notification to the patron indicating such. In this way, the patron may be able to choose to go to another attraction with a lower wait time instead of waiting at the current attraction. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to determine a wait time based on image data from an additional sensor positioned at the attraction since such modification is merely a combination of prior art elements previously known in the art yielding the predictable result of tracking patrons with attraction traffic trackers such as cameras as disclosed by CRONIN II.
Regarding claim 11, CRONIN discloses
wherein the processor is configured to determine a wait time ratio between the respective wait time corresponding to the attraction and the total wait time of the plurality of attractions, wherein the wait time recommendation is generated based on comparing the wait time ratio and a wait time threshold ([0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407.).
Regarding claim 12, CRONIN discloses
wherein the wait time threshold is determined based on a relationship between historical total wait times of the plurality of attractions and historical wait times of the attraction ([0066] In addition, the expected wait time may be adjusted to account for additional visitors getting in line at the roller coaster ride during the travel time of the visitor based on historical data. For example, if it is known that number of visitors getting in line for the roller coaster ride grows at a rate of 2 people per minute, the expected wait time may be adjusted accordingly to provide the visitor a more accurate estimated wait time. [0067] Further, in a non-limiting example, the expected wait times received may additionally be adjusted with respect to time of arrival according to historical data. For example, if an expected arrival time of the visitor to the roller coaster ride from the attraction is determined to be near dinner time, it may be determined that no additional visitors may be getting in line to ride the roller coaster ride, such that shorter wait time may be provided at the time the visitor arrives at the roller coaster ride. [0084] In S508, a rate of increase or decrease of the discrete wait time acquired in S502 is determined. The rate of increase or decrease of the discrete wait times may be based on historical data. For example, historical data of target venue A may indicate that wait times grows at a rate of 2 persons per minute during the time of travel (e.g., 2:00 PM to 2:14 PM) estimated for the visitor. Accordingly, in this example, the wait time may be longer than the originally indicated discrete wait time acquired in S502 by the time the visitor arrives at the target venue A. [0085] In S509, the wait times at the target venues are adjusted according to the determine rate of increase or decrease in the wait times in S508. For example, if the rate of increase for the target venue A is 2 persons per minute and expected time of travel from a current location of the visitor to the target venue A is 14 minutes, it is expected that net 28 additional visitors have been added to the wait line by the time the visitor arrives at the target venue A. Further, if historical data indicates that 1 minute is added for every visitor that is added to the wait line, it may be determined that 28 additional minutes should be added to the discrete wait time to determine an expected wait time at the time of arrival at the target venue A.).
Regarding claim 13, CRONIN discloses
wherein the wait time threshold is a short wait time threshold, and wherein the wait time recommendation is that the wait time is shorter than expected based on the wait time ratio being less than the short wait time threshold ([0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0073] In S408, if it is determined that shorter wait times are available at the alternative attractions, a list of alternative attractions having shorter wait times are transmitted to the user device for display in S409. ).
Regarding claim 14, CRONIN discloses
wherein the wait time threshold is a long wait time threshold, and wherein the wait time recommendation is that the wait time is longer than expected based on the wait time ratio being greater than the long wait time threshold (See Fig. 4 and [0072] After the expected wait times at other sites of interest are received in S406, a comparison is made between the wait time at the current attraction and received estimated wait times for alternative attractions at S407. [0074] In S410, a list of entertainment options is transmitted to the user device. However, aspects of the present disclosure are not limited thereto, such that other in-line services may be available to the visitor in the wait line. Other in-line services may include procurement of souvenirs, making reservations to shows or restaurants and the like.).
Regarding claim 18, CRONIN discloses
wherein the instructions, when executed by the processor, cause the processor to:
determine the wait time corresponding to the attraction of the plurality of attractions (See Figure 5 and [0077] At S502, discrete wait times are acquired at various venues. In an example, a discrete wait time may be an expected wait time at a particular ride, show, or a ride a visitor may incur if the visitor was present at the venue. Discrete wait times may be acquired for venues located within a reference distance from a location of the visitor or according to a category selected by the visitor. For example, if the visitor sets a filter to receive wait times for roller coasters, only wait times for the roller coasters may be provided. Similarly, if the visitor sets the filter to receive wait times for restaurants within 50 yards of the visitor, wait times for restaurants meeting the specified criteria may be provided. Further, additional filters may be applied to limit an amount of data to be acquired by the user device.);
send the wait time recommendation comprising a long wait time recommendation indicating that the wait time for the attraction is longer than expected in response to a determination that the wait time for the attraction is greater than the wait time threshold ([0084] In S508, a rate of increase or decrease of the discrete wait time acquired in S502 is determined. The rate of increase or decrease of the discrete wait times may be based on historical data. For example, historical data of target venue A may indicate that wait times grows at a rate of 2 persons per minute during the time of travel (e.g., 2:00 PM to 2:14 PM) estimated for the visitor. Accordingly, in this example, the wait time may be longer than the originally indicated discrete wait time acquired in S502 by the time the visitor arrives at the target venue A. [0085] In S509, the wait times at the target venues are adjusted according to the determine rate of increase or decrease in the wait times in S508.); and
send the wait time recommendation comprising a short wait time recommendation indicating that the wait time for the attraction is shorter than expected in response to a determination that the wait time for the attraction is less than an additional wait time threshold ([0067] Further, in a non-limiting example, the expected wait times received may additionally be adjusted with respect to time of arrival according to historical data. For example, if an expected arrival time of the visitor to the roller coaster ride from the attraction is determined to be near dinner time, it may be determined that no additional visitors may be getting in line to ride the roller coaster ride, such that shorter wait time may be provided at the time the visitor arrives at the roller coaster ride.).
CRONIN does not explicitly disclose:
determine a wait time based on image data from an additional sensor positioned at the attraction.
However, CRONIN II, which similarly is directed to a theme park management system wherein the user is notified regarding attractions in the vicinity of the user, further teaches:
determine a wait time based on image data from an additional sensor positioned at the attraction ([0015] Attraction conditions, attraction traffic and patron activity information is obtained respectively using attraction condition monitors 115, attraction traffic trackers 120, and patron trackers 125. The information can be stored in their respective databases 130, 135 and 140. Examples of patron trackers include, but are not limited to, pagers provided to the patrons, RF-tagged cards provided to the patrons, applications on patrons' mobile devices, etc. Examples of attraction traffic trackers include, but are not limited to, cameras and/or IR sensors in the vicinity of the attractions. [0018] The traffic optimization software 150 may continually poll the monitors and tracking devices 115, 120 and 125 for updated information. As new maintenance is scheduled/expected downtime is coming up and patron activity is received, the traffic optimization software 150 can update wait times and routes for the patrons. [0019] Furthermore, routes can also be calculated using the patron activity information (e.g. schedule) by the traffic optimization software 150. These routes can facilitate how the patron to proceed from one attraction to another in a time-efficient manner. Furthermore, the traffic optimization software 150 can also calculate new routes based on current and predicted wait times for a planned attraction and nearby/similar attractions. For example, if a nearby or similar attraction has a lower wait time, the traffic optimization software 150 may provide a notification to the patron indicating such. In this way, the patron may be able to choose to go to another attraction with a lower wait time instead of waiting at the current attraction. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to determine a wait time based on image data from an additional sensor positioned at the attraction since such modification is merely a combination of prior art elements previously known in the art yielding the predictable result of tracking patrons with attraction traffic trackers such as cameras as disclosed by CRONIN II.
Regarding claim 22, CRONIN further discloses
wherein the additional sensor comprises an NFC reader configured to receive, from the electronic device, an indication of the electronic device entering the attraction, the electronic device leaving the attraction, or both ([0042] Although not explicitly illustrated, the user device 310 may be an electronic communication device having a processor, a memory, one or more transmitters, and one or more receivers. The user device 310 may be configured to receive and transmit various forms of communication, including but not limited to Bluetooth®, RFID, GPS, NFC, Wi-Fi, and/or cellular network. The user device may be a smart phone, a mobile computing device, a wearable electronic device (e.g., fitness level monitoring device). Further, the user device may be an electronic device owned by a visitor or patron to the theme park or an electronic device provided by the theme park. [0047] The next generation tip board 330 may be an electronic board that may be positioned throughout the theme park. The next generation tip board 330 may include a display 331, a NFC reader 332, an RFID reader 333, and a network circuit 334. The next generation tip board 330 may receive information from various sources through the cloud network 300 or directly by the user device 310. For example, the next generation tip board 330 may receive its location information by having the user device 310 scanned against the NFC reader 332 or the RFID reader 333. Accordingly, the next generation tip board may not be required to be fixed to a specific location and may be movable according to the needs of the theme park. Further, upon receiving additional information from the user device 310, the next generation tip board 330 may provide a more accurate information by providing a wait time of a target attraction in consideration of required travel time, presence of distractions/obstacles (e.g., parades), and other factors. [0048] Further, if the user device is scanned against the NFC reader 332 or the RFID reader 333, an updated wait time may be displayed on the display 332 according to rate of travel speed of the visitor or slowest accompanying member (e.g., a child). [0076] At S501, location information of the user device may be acquired. Location information of the user device may be acquired by a GPS signal, triangulation of cellular signals, or any other location identification technology. Further, location information of the visitor may be acquired based detection of a radio or NFC signal transmitted by an electronic device provided to the visitor by the theme park. For example, a theme park may issue an electronic band that is capable of transmitting a passive radio or NFC signal to the visitor. When the visitor wearing such an electronic band transmits a signal at various locations to obtain information or access throughout the park, the location information of the visitor may be acquired. For example, the visitor may scan his or her electronic band at one of the tip display boards located throughout the theme park to obtain tip information.).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over CRONIN (US Patent Publication 2018/0240161) in view of CRONIN (US Patent Publication 2018/0247270), herein after CRONIN II and Heaven (US Patent Publication 2017/0169449).
Regarding claim 15, CRONIN does not explicitly disclose:
remove a respective wait time corresponding to a closed attraction from the total wait time of the plurality of attractions.
Heaven further teaches a system for tracking guests in an amusement park in order to provide notifications and recommendations upon wait times.
Heaven specifically teaches:
remove a respective wait time corresponding to a closed attraction from the total wait time of the plurality of attractions ([0085] At step 540, the mobile application 500 determines whether the response option (e.g., attraction sequence) needs to be modified. This may be determined automatically without user intervention, for example by interfacing with a park system that transmits data about the attractions. For example, if a particular attraction breaks down or has a line queue time above a certain threshold, the attraction sequence may be modified to remove or otherwise delay the attraction in the list of rides to visit. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to take into consideration if a ride is closed in order to remove the ride for consideration since such improvement in the system of Boss is just a combination of well-known techniques in the art that provide the known benefit of modifying the attractions taken into consideration if a particular attraction breaks down and remove the attraction from consideration as disclosed by Heaven on [0085].
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over CRONIN (US Patent Publication 2018/0240161) in view of Burrell (US Patent Publication 2012/0143755) and CRONIN (US Patent Publication 2018/0247270), hereinafter CRONIN II.
Regarding claim 21, CRONIN discloses:
determining, via the processor, a line length; and determining, via the processor, the wait time corresponding to the attraction based on the line length (See Figure 7 [0103] Alternatively, if it is determined in S702 that the discrete wait time is above the predetermined threshold, a determination of whether an unusual circumstance has been detected is made in S703. For example, the unusual circumstance may include an accident, unscheduled maintenance, criminal activity, and the like. The determination may be made by inquiring a database within a tip network, which may be a central repository of incidents occurring the in the theme park. [0106] If it is determined that the unusual circumstance has not been detected in S703, a check is made with the affected venue to obtain information to determine cause of the extended wait time in S706. If it is determined that there is a legitimate cause for the extended wait time in S707, the database in the tip network may be updated with the cause for the extended wait time in S708 and corresponding notification may be sent to relevant visitors in S704. Further, the affected visitors may receive coupons or incentives in S705. [0107] If it is determined that there is no legitimate cause for the extended wait time in S707, the wait time is updated to reflect the extended wait time in S709.).
CRONIN does not disclose:
receiving, via the processor, image data from a sensor positioned at the attraction; determining, via the processor, a line length based on the image data
CRONIN II teaches:
receiving, via the processor, image data from a sensor positioned at the attraction; determining, via the processor, a line length based on the image data ([0015] Attraction conditions, attraction traffic and patron activity information is obtained respectively using attraction condition monitors 115, attraction traffic trackers 120, and patron trackers 125. The information can be stored in their respective databases 130, 135 and 140. Examples of patron trackers include, but are not limited to, pagers provided to the patrons, RF-tagged cards provided to the patrons, applications on patrons' mobile devices, etc. Examples of attraction traffic trackers include, but are not limited to, cameras and/or IR sensors in the vicinity of the attractions. [0018] The traffic optimization software 150 may continually poll the monitors and tracking devices 115, 120 and 125 for updated information. As new maintenance is scheduled/expected downtime is coming up and patron activity is received, the traffic optimization software 150 can update wait times and routes for the patrons. [0019] Furthermore, routes can also be calculated using the patron activity information (e.g. schedule) by the traffic optimization software 150. These routes can facilitate how the patron to proceed from one attraction to another in a time-efficient manner. Furthermore, the traffic optimization software 150 can also calculate new routes based on current and predicted wait times for a planned attraction and nearby/similar attractions. For example, if a nearby or similar attraction has a lower wait time, the traffic optimization software 150 may provide a notification to the patron indicating such. In this way, the patron may be able to choose to go to another attraction with a lower wait time instead of waiting at the current attraction. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to include the teachings as disclosed by CRONIN II since such modification is merely a combination of prior art elements previously known in the art yielding the predictable result of tracking patrons with attraction traffic trackers such as cameras as disclosed by CRONIN.
Claim(s) 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over CRONIN (US Patent Publication 2018/0240161) in view of Heaven (US Patent Publication 2017/0169449).
Regarding claim 23, CRONIN does not explicitly disclose:
provide the adjusted total wait time by removing a respective wait time corresponding to a closed attraction from the total wait time.
CRONIN discloses a system that determines wait time of attractions. However, does not explicitly disclose removing a second wait time corresponding to a closed attraction from the total wait time of the plurality of attractions. That is, Boss does not contemplate a closed attraction when determining all the attractions.
Heaven teaches a system for tracking guests in an amusement park in order to provide notifications and recommendations upon wait times.
Heaven specifically teaches:
provide the adjusted total wait time by removing a respective wait time corresponding to a closed attraction from the total wait time. ([0085] At step 540, the mobile application 500 determines whether the response option (e.g., attraction sequence) needs to be modified. This may be determined automatically without user intervention, for example by interfacing with a park system that transmits data about the attractions. For example, if a particular attraction breaks down or has a line queue time above a certain threshold, the attraction sequence may be modified to remove or otherwise delay the attraction in the list of rides to visit. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to take into consideration if a ride is closed in order to remove the ride for consideration since such improvement in the system of Boss is just a combination of well-known techniques in the art that provide the known benefit of modifying the attractions taken into consideration if a particular attraction breaks down and remove the attraction from consideration as disclosed by Heaven on [0085].
Claim(s) 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over CRONIN (US Patent Publication 2018/0240161) in view of Burrell (US Patent Publication 2012/0143755) and Mbekeani (US Patent Publication 2017/0169449).
Regarding claim 26, CRONIN does not explicitly disclose:
adjusting, via the processor, the typical historical wait time for the attraction by excluding one or more historical wait times of the plurality of historical wait times that are associated with skewed historical park attendance.
CRONIN discloses taking into account historical data to determine the attendance (i.e. amount of patrons in a park) of a theme park. CRONIN does not disclose adjusting the historical wait time for the attraction by excluding one or more historical wait times that are associated with skewed historical park attendance.
However, Mbekeani which is directed to determining the amount of traffic based on historical data further teaches:
adjusting, via the processor, the typical historical wait time for the attraction by excluding one or more historical wait times of the plurality of historical wait times that are associated with skewed historical attendance ((48) Turning now to FIG. 8, a block diagram of the historic traffic data 504(3) depicted in FIG. 7 is shown. In this embodiment shown, the historic traffic data 504(3) include an identifier 504(3)(1) for identifying the historic traffic data record 504. Since traffic conditions depend upon the time of day, a time stamp 504(3)(2) is included. Several embodiments are contemplated with the time stamp 504(3)(2), one embodiment is to include all the various time stamps defined by a predetermined factor of the location reference code in the historic traffic record 504. For example, the historic traffic record 504 that is associated with the location reference number may include a traffic condition every 5 minutes. Aside from the time stamp, other information, such as minimum speed 504(3)(3), maximum speed 504(3)(4), and/or average speed 504(3)(5), can also be included. Depending upon the implementation, some statistical information may also be helpful. For example, a median 504(3)(6) or a variance 504(3)(7) may be included in the historic traffic data record 504 to assist in the determination when the current traffic conditions from the traffic suppliers had sufficiently deviated from the historic traffic pattern. (49) Furthermore, a predefined threshold 504(3)(8) may also be included as a tolerance factor for the deviation between the current traffic conditions and the historic traffic conditions. In an alternative embodiment, the threshold 504(3)(8) may also be dynamically generated by an algorithm in the central facility 200 or the navigation system 202. In this case, a threshold 504(3)(2) may be excluded from the historic traffic data record 504. In the various embodiments, the threshold 504(3)(8) may be a predefined constant value, a minimum value, a maximum value, an average value, a median value, a variance, and an auto covariance. These and other embodiments are again contemplated and readily appreciated by a skilled artisan, and thus, they are within the scope of the various embodiments shown.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to adjust, the typical historical wait time for the attraction by excluding one or more historical wait times of the plurality of historical wait times that are associated with skewed historical park attendance since such modification is a well-known method known in the art of queue and traffic management that provides the known benefit of removing or exclude data points that deviate from historic patterns as disclosed by Mbekeani at (48).
Response to Arguments
Applicant's arguments filed 07/17/2026 have been fully considered.
Regarding the previously presented 35 USC 101:
Examiner agrees that the amendments are enough to overcome the 35 USC 101 by providing significantly more than the abstract idea.
Regarding the previously presented 35 USC 102 and 103:
Applicant’s arguments with respect to “"determining, via the processor, a short wait time threshold for the attraction by decreasing the typical historical wait time by a first threshold period of time; determining, via the processor, a long wait time threshold for the attraction by increasing the typical historical wait time by a second threshold period of time: in response to determining that the set of preferred attractions comprises the attraction and that the attraction is within the threshold distance of the active location of the electronic device, generating, via the processor, the wait time recommendation for the attraction based on a first comparison between the wait time and the short wait time threshold, a second comparison between the wait time and the long wait time threshold, or both." are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argues “Independent claim 16 has been amended to recite, inter alia, "determine a total wait time of the plurality of attractions by combining respective wait times associated with the plurality of attractions with one another such that the total wait time is a cumulative value of the respective wait times for the plurality of attractions; adjust the total wait time based on one or more skew factors associated with the total wait time to provide an adjusted total wait time;. and send the wait time recommendation based on the wait time for the attraction, the adjusted total wait time for the plurality of attractions, and a wait time threshold."” Examiner respectfully disagrees. CRONIN clearly disclose on paragraph [0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.” It is clear from this paragraph that CRONIN does determine a total wait time of the plurality of attractions by combining respective wait times associated with the plurality of attractions.
The argument above applies to independent claim 10 wherein CRONIN discloses “"generate a total wait time of the plurality of attractions by combining each respective wait time associated with each attraction of the plurality of attractions with one another such that the total wait time is a cumulative value of the respective wait times for the plurality of attractions; generate a wait time recommendation for the attraction based on the respective wait time corresponding to the attraction and the total wait time of the plurality of attractions," as recited by amended independent claim 10.” By disclosing on paragraph [0086] In S509, the adjusted wait times determined in S508 is added with the estimated travel time determined in S507 to provide a total expected wait time at the target venues. Accordingly, the visitor may be provided with more accurate wait times at various venues from a location of the visitor. Visitors having access to such information may plan their trip through the park with increased efficiency with reduced wait times.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Joshi, US 10026099, Computerized Waiting List Tracking System. (73) Block 610 illustrates accessing a deal 130. The deal selection module 120 may receive waitlist data 212 associated with one or more alternative merchants 204. As described above, the waitlist data 212 may indicate that at least one of the one or more alternative merchants 204 has no waiting list, has a waiting list that is shorter than the waiting list for the merchant 202, or has an estimated wait time below a predetermined threshold. Based at least in part on receiving the waitlist data 212, the deal selection module 120 may select one or more deals 130 offered by an alternative merchant 204 and may send the one or more deals 130 offered by the alternative merchant 204 to the presentation module 126, as described above.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARIA C SANTOS-DIAZ whose telephone number is (571)272-6532. The examiner can normally be reached Monday-Friday 8:00AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah Monfeldt can be reached at 571-270-1833. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARIA C SANTOS-DIAZ/ Primary Examiner, Art Unit 3629
