Internet Scavenger Game

- STOR NETWORKS, INC.

A system, method, and computer readable medium for playing a scavenger hunt game via an electronic network, such as the Internet. Players are enabled to search and find clues distributed amongst multiple electronic locations, such as Web pages, in order to reach a final objective. Clues lead each player from a starting uniform resource locator (URL) to a final URL.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application No. 61/361,475, filed Jul. 5, 2010, which is incorporated herein by reference, in its entirety for all purposes.

FIELD

The present invention generally pertains to advertising, entertainment, and games on the Internet.

BACKGROUND

In the physical world, people often play a game called “scavenger hunt.” In a scavenger hunt, an organizer sets out objectives for players to discover. The objectives are placed in secret locations in a designated game environment (e.g., a house, a garden, a neighborhood, a city, etc.). Often, each objective provides a clue as to the location of the next objective, with the final clue leading the players to the end of the hunt. The first player to reach the final objective is the winner. A scavenger hunt is often played by groups in order to build camaraderie, such as a team-building exercise for co-workers. While scavenger hunts are enjoyable and provide an opportunity for social interaction, they are cumbersome to organize and run. It is difficult to have a scavenger hunt at the spur of the moment as a person must find and prepare the hunt location, prepare clues and objectives, hide the clues and objectives, find a group of available players, and coordinate the hunt. Due to these factors and others, scavenger hunts are typically played only in conjunction with special events, such as birthdays, company gatherings, etc., and are not an activity that a person can participate in on a casual basis.

Conversely, video games are very accessible and are immensely popular with a broad audience. In addition to traditional video game platforms, such as consoles and personal computers, the popularity of smart-phones, tablet computers, and other portable devices has made access to video games nearly ubiquitous. Individuals have convenient access to video games via the Internet and/or a mobile network. Instead of buying a cartridge or disk, a growing number of video games are available via Web sites or as smart-phone applications (i.e., “apps”).

What is needed is a mechanism that combines the convenience and accessibility of video games with the unique fun and social interaction of a scavenger hunt.

SUMMARY

The present invention pertains to a system, method, and computer readable medium for playing a scavenger hunt game via an electronic network, such as the Internet. Players are enabled to search and find clues distributed amongst multiple electronic locations, such as Web pages, in order to reach a final objective. Clues lead each player from a starting uniform resource locator (URL) to a final URL.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features of the invention may be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 depicts a general architecture overview of an exemplary an Internet scavenger hunt network including an Internet scavenger hunt system according to an embodiment;

FIG. 2 depicts a flowchart of an exemplary process for creating an Internet scavenger hunt via an Internet scavenger hunt system according to an embodiment;

FIG. 3A and FIG. 3B depict a flowchart of an exemplary process for participating in an Internet scavenger hunt according to an embodiment; and

FIG. 4 depicts an overview of an exemplary interface enabled to facilitate an Internet scavenger hunt according to an embodiment.

DESCRIPTION OF EMBODIMENTS

Various embodiments of the invention are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person with ordinary skill in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention.

The present invention is described herein mainly in terms of an individual accessing the Internet, such as via an access mechanism, such as a personal computer (e.g., a desktop computer, a laptop computer, a tablet computer, etc.), a mobile phone, a multipurpose mobile device (e.g., a smartphone, an iPod, a personal electronic assistant, etc.), or a video game system (e.g., a Nintendo Wii, a Microsoft XBox360, a Sony PlayStation 3, etc.). This is not to be construed as limiting as the present invention may be applicable to any electronic network accessible to a user via a network-appropriate device. For example, the present invention may be applied to broadcast networks (e.g., cable, satellite, etc.), mobile networks, interactive television systems, kiosk systems, and any technologies that enable the electronic rendering of Web pages.

Internet Scavenger Hunt Network and System

FIG. 1 depicts a general architecture overview of an exemplary Internet scavenger hunt network (ISHN) 100 including an Internet scavenger hunt system (ISHS) 104 according to an embodiment. The amount of representations of each component depicted is for illustrative purposes only and is not to be construed as limiting, as ISHN 100 may include more or less instances of each component as determined by implementation. Furthermore, although some components are depicted and described herein as separate, this is not to be construed as limiting, and components may be combined per implementation. The components are herein referenced as “systems” and “mechanisms.” This is not to be construed as limiting and it is to be understood that each component may include the necessary hardware, firmware, and/or software to enable the processing, storing, communicating and/or receiving of data. For example, a component may include one or more computer processors, computer servers, data stores, electronic components, storage mediums, memory, etc.

The components of ISHN 100 may interact with one another via network 102. Although network 102 is typically described herein to be the Internet, this is not to be construed as limiting. Network 102 may be any applicable electronic network, such as the Internet, a mobile network, an intranet, a broadcast network, a private or proprietary network, etc., or a combination thereof, and may include local area networks (LANs), wireless local area networks (WLANs), wide area networks (WANs), wireless personal area networks (WPANs), etc.

ISHN 100 may include ISHS 104, which may be a system configured to enable the storage of scavenger hunt data, the creation of scavenger hunts, and the distribution of scavenger hunts to access mechanisms 108. ISHS 104 may include data store 106 which may maintain hunt data 130, hunt creator account data 132, and user data 134 (including user account data 136). A user identifier may be used to reference the user data 134 of a particular user. For example, a user identifier may be a user's email address, a username, an identification code, a telephone number, other alphanumeric data, etc. A user identifier may reference a user account. User account data 136 may be user data 134 specific to a user, such as credential information (e.g., username and password, social network credentials, etc.), personal information, contact information (email address, phone number, etc.), demographic data (e.g., sex, age, etc.), financial account data (e.g., credit card information, checking account information, stored value account information, etc.), user preferences (e.g., hunt preferences, privacy preferences, etc.), etc. A user may create an ISHS user account by accessing an ISHS Web page, by employing an ISHS-specific application (e.g., ISHS software, a smartphone app, hunt utility mechanism 112, etc.), etc. In one embodiment, a user account may be generated, accessed, and/or modified via a third party service, such as social network system 138.

Hunt data 130 may include data associated with one or more Internet scavenger hunts. Hunt data 130 for a particular hunt may be referenced by a hunt identifier and may include URLs of Web pages, hunt name data, hunt description data, hunt step data, hunt clue data, hunt objective data, reward data, team-play data, etc. A hunt identifier may be a URL, an alphanumeric code, or any other data that may be used to reference a hunt. Hunt data 130 also may include a hunt creator identifier referencing a hunt creator account. Hunt creator account data 132 may include data specific to a hunt creator, such as credential information, contact information, Web site information, financial account data, hunt creator preferences, social network data, etc. A hunt creator may create a hunt creator account by accessing an ISHS Web page, by employing an ISHS-specific application, via a social network system, etc. or may contact an ISHS service provider to have a hunt creator account established. In one embodiment, ISHS 104 may be accessible by a variety of hunt creators and data store 106 may maintain hunt data 130 and/or hunt creator account data 132 for each hunt created by each hunt creator. In another embodiment, ISHS 104 may be associated with a limited amount of hunt creators, such as a particular sponsor or a particular group of affiliated sponsors, and data store 106 may only contain hunt data 130 and/or hunt creator account data 132 for the particular creator or group of creators.

A hunt creator may be an individual or an organization and may be a commercial or non-commercial entity authorized by an ISHN service provider to create one or more Internet scavenger hunts. For example, a hunt creator may be an entity such as a retailer, a vendor, a reseller, a manufacturer, and/or an advertising or marketing organization. For example, such an entity may sponsor a hunt in order to advertise a good or service (herein collectively referred to as a “product”) and offer a related reward (e.g., a discount coupon, a gift card, etc.). Although a hunt creator may be a sponsor (e.g. a commercial entity), a sponsor may utilize a separate hunt creator to generate and/or manage an Internet scavenger hunt on its behalf. As another example, a hunt creator may be an individual who may create a hunt for recreational purposes. As yet another example, a hunt creator may be an employer or an academic organization and such an entity may create a hunt to be used for training and/or educational purposes.

ISHS 104 may include hunt creation interface mechanism 114 which may enable a hunt creator to generate a scavenger hunt and may enable a hunt creator to perform any hunt creation-related procedure described herein. ISHS 104 may include hunt distribution mechanism 116 which may enable user participation by communicating hunt data 130 to access mechanism 108 and may enable any scavenger hunt distribution procedure described herein. In one embodiment, hunt creation interface mechanism 114 and/or hunt distribution mechanism 116 may work in conjunction with other services, such as social networking system 138, and Internet search systems (e.g., Google, Yahoo, etc.), etc. For example, an application programming interface (API) may facilitate interaction between hunt creation interface mechanism 114 and/or hunt distribution mechanism 116 and social networking system 138.

ISHN 100 may include one or more social network systems 138, such as Facebook, Twitter, Google+, an online forum or message board, etc. ISHN 100 components, such as ISHS 104 or a Web site publisher system, may interact with social network system 138 via an API or other functionality. In one embodiment, a user and/or hunt creator may employ ISHS 104 via social network system 138.

A user may interact with one or more components of ISHN 100 via access mechanism 108. Access mechanism 108 may include hardware, software, and/or firmware configured to enable the viewing and the inputting of information by the user. For example, a user may interact with components of ISHN 100 by loading a Web page on a personal computer via a Web browser, or through a smartphone via its browsing application or via an another app. Additionally, access mechanism 108 may be another properly equipped device, such as a television, kiosk, or other presentation system. Furthermore, ISHN 100 may be accessible via various embodiments of access mechanism 108 and a user may employ any combination of these. For example, a user may access ISHN 100 via his mobile phone at one point and later access it via his television.

Access mechanism 108 may include browser mechanism 110 which may enable the viewing, receipt, and transmission of data via network 102. For example, browser mechanism 110 may be a Web browser, such as, for example, Microsoft Internet Explorer, Mozilla Firefox, or Google Chrome. If access mechanism 108 is a multipurpose mobile device (e.g., a smartphone), browser mechanism 110 may be a browsing application or an app configured to access and/or display Web pages and/or participate in Internet scavenger hunts.

Browser mechanism 110 may enable a user to participate in an Internet scavenger hunt. In one embodiment, browser mechanism 110 may be enabled with hunt utility mechanism 112 to facilitate hunt participation. An exemplary embodiment of hunt utility mechanism 112 is described in relation to FIG. 4 below. Hunt utility mechanism 112 may be a browser extension (sometimes called an “add-on”), a toolbar added to browser mechanism 110, etc. In one embodiment, hunt utility mechanism 112 may be an application that works independently from or in conjunction with browser mechanism 110. For example, if the user's access mechanism 108 is a multipurpose mobile device (e.g., a smartphone), hunt utility mechanism 112 may be an app. Once installed, the user may activate hunt utility mechanism 112 whenever he wishes to play. For example, hunt utility mechanism 112 may be a browser extension the user clicks on or an app he selects from his smartphone menu.

The user may obtain hunt utility mechanism 112 from a hunt service provider Web page associated with ISHS 104 or a Web page associated with a particular hunt creator or sponsor. The Web page's may offer hunt utility mechanism 112 in order to enable the user to participate in hunts from various hunt creators. Alternatively, the Web page may be specific to one hunt creator or sponsor and hunt utility mechanism 112 may only provide access to that creator's or sponsor's hunts. In the latter case, the hunts offered may be related to a particular sponsor's products. The scavenger hunt Web page may also serve to explain the scavenger hunt process to those interested, to provide prizes to participants, to enable hunt creation, to display available hunts, to enable a user to create or join a teams, etc.

Hunt data 130, such as clues, objectives, URLs, etc., may be communicated to hunt utility mechanism 112, which may instruct browser mechanism 110 and/or access mechanism 108 appropriately. For example, browser mechanism 110 may access an appropriate Web page, such as Web page 118, Web page 120, or Web page 122, maintained by Web site publisher system 124, Web site publisher system 126, or Web site publisher system 128 (respectively).

A Web site publisher system may be any system that enables the distribution of electronic content via a Web page. For example, a Web site publisher system may include a Web server and may enable a user to view a Web page via access mechanism 108. Three Web pages and three Web site publisher systems are depicted in FIG. 1 for illustration purposes only and this is not to be construed to as limiting. ISHN 100 may include any number of Web pages and/or Web site publisher systems.

Internet Scavenger Hunt Creation

A hunt creator may access ISHS 104 via a browser mechanism 110. For example, a hunt creator may log into a Web page associated with ISHS 104. Alternatively, a hunt creator may access ISHS 104 via a specialized application. A hunt may be designed to advertise an entity's products by requiring the participants visit Web pages pertaining to the entity's products (e.g., product pages, reviews, etc.). Additionally, or alternatively, a user may be required to supply one or more objective answers pertaining to the entity's products (e.g. “Toyota has the best cars.”). A hunt may be designed to include multiple sponsors, with each sponsor having one or more of its Web pages included in the hunt. A scavenger hunt may be based upon any topic, may be as complicated or as simple as the hunt creator desires, and may be targeted toward a variety of audiences. For example, scavenger hunts may be designed to test participants' knowledge; may be aimed at women, teenagers, gardening enthusiasts, etc.; and/or may deal with beers of the world, supermodels, fashion, food, or anything else the hunt creator wishes.

Once a hunt creator has accessed ISHS 104, he may create an Internet scavenger hunt. FIG. 2 depicts a flowchart of an exemplary process for creating an Internet scavenger hunt via ISHS 104 according to an embodiment. The hunt creation process described herein is related in a particular sequence for explanation purposes only and it is not to be construed as limiting. Other sequences producing the same result may also be employed. From the hunt creator via access mechanism 108, ISHS 104 may receive a hunt name (step 202) and a hunt description (step 204). For example, the creator may name a sports-related hunt “Sports Seek” and may enter a description detailing the hunt (e.g., “Search the Web for major league sports teams!”). The description explain the particulars of the hunt, the particulars of the reward to be provided, the hunt requirements, etc. If the hunt creator wishes to enable team play, ISHS 104 may receive team play data in order to establish the maximum and/or minimum number of teams allowed to participate (step 206) and the maximum and/or minimum number of players allowed on each team (step 208). Alternatively, if the hunt is only for individual players, ISHS 104 need not receive team play data and these steps may be omitted or skipped.

ISHS 104 may receive instruction from the hunt creator to add a hunt step (step 210). ISHS 104 may enable a hunt creator to indicate the sequential position of the added hunt step or, alternatively, hunt steps may be ordered in the sequence they are added. ISHS 104 may enable the creator to revise a hunt's step order during or after the hunt creation process. ISHS 104 may receive the objective for the added hunt step (step 212). For example, for a hunt step for an American football-related hunt, the objective may be “Green Bay Packers.” ISHS 104 may receive one or more clues to be provided for the objective for the added hunt step (step 214). For example, a clue for the “Green Bay Packers” objective may be “Their fans are rather cheesy.” The hunt creator may enter multiple clues if he wishes to offer users additional help. ISHS 104 may receive the URL associated with the added hunt step (step 216). For example, the URL may be “http://www.NFL.com.” Once the hunt step has been added, ISHS 104 may determine whether the added hunt step is the final step of the hunt (step 218). If not, he may continue to add steps until he reaches the final step (i.e., repeat steps 210-216). For example, the hunt creator may indicate if the added step is the final step or ISHS 104 may determine whether the creator has reached a hunt step limit.

Once all the steps have been completed, the user may be allowed to revise the order and make any of adjustments in the hunt steps as needed. In an alternative embodiment, the hunt steps may be randomized or a participant may be allowed to complete the steps non-consecutively. For example, the hunt creator may designate that a participant may skip steps and return to them later. ISHS 104 may receive or more rules from the creator and establish these for the hunt (step 220), such as how quickly the hunt must be completed, how many clues are allowed per objective, reward parameters (e.g., how the value of the reward may fluctuate based how fast the hunt was completed, the number of clues used, etc.), etc. When the hunt creator has entered all the necessary information and is satisfied with the hunt, he may indicate this and ISHS 104 may enable the hunt for user participation (step 222). The hunt may be assigned a hunt identifier.

A hunt creator need not complete hunt creation in one session. He may be enabled to may save his progress and provided hunt data in order to resume hunt creation at a later time. A hunt creator may also access ISHS 104 to modify, activate, deactivate, or delete an existing hunt.

Internet Scavenger Hunt Participation

FIG. 3A and FIG. 3B depict a flowchart of an exemplary process for participating in an Internet scavenger hunt according to an embodiment. The scavenger hunt described herein describes the ISHS 104 as enabling the scavenger hunt via hunt utility mechanism 112. This is not to be construed as limiting and it is to be understood that other embodiments are possible. In one embodiment, browser mechanism 110 may interact with ISHS 104 directly without the use of hunt utility mechanism 112. Additionally, the description herein explain one or more procedures as being handled by ISHS 104 and/or hunt utility mechanism 112. This is not to be construed as limiting as the necessary data processing, management, and storage may be accomplished via ISHS 104, hunt utility mechanism 112, browser mechanism 110, and/or access mechanism 108, as would be appropriate per implementation.

When a user wishes to initiate a scavenger hunt, ISHS 104 may receive a request to access a user account from the user via access mechanism 108 (step 302). A user may access his user account via hunt utility mechanism 112, by accessing an ISHS Web page, via social network system 138, etc. ISHS 104 may determine whether the user has a user account (step 304). For example, the user may be prompted to provide login credentials, ISHS 104 may receive credential data maintained by browser mechanism 110 or hunt utility mechanism 112 (e.g., tracking cookie information), etc. and ISHS 104 may determine whether there is a corresponding user account. If ISHS 104 does not have a corresponding user account, the user may be prompted to create one and, after ISHS 104 has received sufficient user data, ISHS 104 may create a user account for the user (step 306). Once a user account has been created, the user may opt to have hunt utility mechanism 112 store his credential information so that hunt utility mechanism 112 may log him in automatically upon subsequent accesses. In one scenario, hunt utility mechanism 112 may interface with one or more social networking systems 138, and the user may access his user account via his credentials for such a system. If the user logs in and/or creates a user account via a social networking system 138, he may not need to provide registration information as ISHS 104 may access such data from social networking system 138.

Once ISHS 104 has accessed the user's user account (step 308), it may receive from the user one or more account option selections (step 310). For example, the user may choose whether to share reports of his scavenger hunt process via social network system 138, such as by having his progress automatically reported as updates to his Twitter, Facebook, and/or Google+ accounts. A user may indicate the types of scavenger hunts in which he wishes to participate. For example, his account option selections may indicate whether he wishes to participate in sponsored hunts, group hunts, hunts with or without rewards, the maximum or minimum steps involved, etc. The user may only need to establish these options upon his initial use of ISHS 104, although he may adjust an option at a later time, and this step may be omitted once account options have been established

ISHS 104 may communicate available hunt data to hunt utility mechanism 112 (step 310) and may receive the user's scavenger hunt selection (step 312). Hunt utility mechanism 112 may present a listing of scavenger hunts available to the user and enable access to descriptions, details, instructions, requirements, rewards, etc. for each of the available hunts. The user may select a hunt he has previously started or select a new one. For a hunt the user has already started, hunt utility mechanism 112 may indicate the user's progress in the hunt (e.g., 55% complete). In one scenario, a user may select more than one hunt and may participate in multiple hunts in succession or concurrently. A user may choose one hunt for one session and choose a different hunt at the next session, etc. Hunt utility mechanism 112 may track and store his progress (either locally or at ISHS 104), allowing the user to resume where he left off when he next accesses his user account. In one scenario, a user may be enticed to complete a hunt sooner rather than later by the promise of a greater reward for a more timely completion. Before choosing the hunt, the user may review the particulars and requirements and, if he has previously started the hunt, review his progress.

After the user has selected a particular hunt and ISHS 104 receives the selection (step 314), ISHS 104 may activate the hunt for the user (step 316) and the user may participate via hunt utility mechanism 112. As detailed below, in one embodiment, ISHS 104 may not activate the selected hunt if it is a team hunt and insufficient users have selected it. When displaying available hunts, hunt utility mechanism 112 may indicate the number of players needed and number of players that have selected a particular hunt.

Once the selected hunt has been activated, ISHS 104 may communicate the initial Web page data, including a URL, for the selected scavenger hunt to hunt utility mechanism 112 (step 318) and hunt utility mechanism 112 may instruct browser mechanism 110 to access the associated Web page. If the user has chosen to resume a hunt he had previously begun, the initial Web page data communicated to hunt utility mechanism 112 may be associated with the last Web page he accessed for the hunt.

ISHS 104 may communicate a clue about the initial objective for the hunt to the user via hunt utility mechanism 112 (step 320). A user may request a clue via hunt utility mechanism 112 or it may be presented automatically. The current Web page may be associated with the clue in some fashion and the clue may be presented in a display included in hunt utility mechanism 112, as a pop-up message, etc. For example, the first clue may be “the Big O,” the answer may be “Oprah,” and the current Web page may include an article about Oprah, a link to a book from Oprah's Book Club, etc.

Via hunt utility mechanism 112, ISHS 104 may receive the user's objective answer once he has entered it via an objective input interface included with hunt utility mechanism 112 (step 322) and ISHS 104 or hunt utility mechanism 112 may determine if it is the correct answer (step 324). For example, hunt utility mechanism 112 may access hunt data 130 to determine if the received objective answer is correct or hunt utility mechanism 112 may communicate the objective answer to ISHS 104 so that it may analyze the received objective answer. The current hunt's hunt data 130 may be referenced by the current Web page's URL or another hunt identifier. If the user has entered a wrong objective answer, hunt utility mechanism 112 (or ISHS 104 via hunt utility mechanism 112) may communicate an alert message (e.g., “try again”) (step 326) and, in one embodiment, may communicate an additional clue for the current objective (step 328). In another embodiment, the user may not be able to receive an additional clue or may only receive an additional clue after repeated failures. If the user has entered the correct objective, hunt utility mechanism 112 or ISHS 104 may determine if the current Web page was the final page in the scavenger hunt (step 330). If not, Web page data, including a URL, for the next Web page in the hunt and next objective clue may be communicated to hunt utility mechanism 112 (steps 332 and 334), which may instruct browser mechanism 110 to access the corresponding page and may provide the next objective clue. As aforementioned, hunt steps may be presented in a randomized sequence. Additionally, a participant may be allowed to complete the steps non-consecutively, such as by skipping a step and returning to it later.

In an alternate embodiment, rather than hunt utility mechanism 112 accessing the next Web page in the hunt for the user, the user may be required to determine which URL is next by himself. Part of the challenge of the scavenger hunt may be locating the one or more of the particular URLs that the hunt creator has included as hunt steps, rather than the user being automatically led to each one. For example, the user may use browser mechanism 110 to navigate from one Web page to the next and hunt utility mechanism 112 may indicate when he has reached an appropriate URL. The user may then analyze the Web page for the objective. Alternatively, finding the appropriate Web page may be the objective in itself and the user may not need to enter a particular objective answer. Clues provided to the user may pertain to a particular Web page in addition to, or rather than, a particular objective answer.

The user may continue with the hunt until he provides the final objective for the final page. In one embodiment, if the user stops the hunt before reaching the final objective, ISHS 104 may store his progress and enable the user to resume the hunt at his subsequent access. When it has been determined that the user has completed the final objective, ISHS 104 and/or hunt utility mechanism 112 may communicate a message indicating that the hunt has been completed (step 336) and may determine if the user is eligible for a reward per the hunt's reward parameters (step 338).

The reward may be based upon a score reflective of the user's effectiveness. The score may be based upon the number of objectives found, the length of time needed to complete the hunt, the number of clues needed, etc. If the hunt was a team hunt, as detailed below, ISHS 104 may determine if the team's performance makes them eligible for a reward. In one scenario, a user may be eligible for a reward simply by completing the selected hunt. If the user is eligible for a reward, a reward message may be communicated (step 340). In one scenario, the reward message may simply be a congratulatory message. In another scenario, the reward message may enable the user to receive a monetary reward, such as credit to registered financial account, a credit to a stored value account associated with ISHS 104 or a hunt sponsor, a gift certificate (delivered electronically or via traditional means), etc. If permitted per the user's established account options, a congratulatory message may be presented via social network system 138 (e.g., a wall post on Facebook or a Twitter tweet). If the user is not eligible for a reward, ISHS 104, via hunt utility mechanism 112, may communicate a failure message (step 342).

Team Internet Scavenger Hunts

As mentioned, in addition to allowing for a solitary user to participate in a hunt, a hunt may be designed as a group hunt to allow, and possibly require, multiple users to participate. For example, a group hunt may require that a particular number of users participate. This group may be considered a team. In one scenario, a team may include a leadership hierarchy, with one or more members having authority over other team members. A leader member may be allowed to remove other team members (e.g., because a member has ceased to participate, is ineffective, is voted out by other team members, etc.). In one scenario, a team may need to maintain a minimum or maximum number of members in order to be eligible for the hunt and/or the associated reward.

A hunt may be designed to mandate a particular number of teams in order for the hunt to be active. In order for the hunt to be considered a success and, therefore, for the reward to be provided, a certain quota of objectives may be required to be met. For example, the team may need to complete all of the steps or, for example, 75% of them. As another example, every member of the team may be required to complete a hunt before it is considered finished. This scenario may provide team members with an incentive to ensure each team member participates. If multiple teams are involved in the same hunt, the first team to finish may be the only one to be rewarded or rewards may be provided to various teams in the relation to how successful each team was (e.g., first prize, second prize, etc.).

An Internet scavenger hunts may be held as competition and the competition may include multiple hunts. An individual or team may not be allowed to proceed to the next hunt until the current hunt has been finished. Alternatively, a hunt may be skipped, with the player possibly given the option to return to the hunt later.

INTERNET SCAVENGER HUNT EXAMPLES

An Internet scavenger hunt may be implemented for various reason. For example, an

Internet scavenger hunt may be implemented as a team-building exercise (e.g., for co-workers), a knowledge test (e.g., an accreditation process, a quiz, etc.), a competition, a social network game, a knowledge building exercise (e.g., sale team training, school work, learning a language, etc.), a way to meet people (e.g., a singles party hunt, etc.) etc. Furthermore, a team scavenger hunt may interact with a group-based service, such a Groupon. A scavenger hunt may be scheduled to start at a particular date and/or time. This may be used as a way to market the hunt (e.g., “The Horror Hunt starts on October 31st at Midnight!”). These examples are for illustrative purposes only and it is to be understood that the present invention may be applied to other scenarios as well.

AN EXAMPLE OF AN INTERNET SCAVENGER HUNT UTILITY

FIG. 4 depicts an overview of an exemplary of hunt utility mechanism 112 according to an embodiment. Hunt utility mechanism 112 may provide the user with a convenient interface to select and participate in hunts, communicate with other hunt participants, view hunt statistics, etc. The hunt utility mechanism 112 depicted in FIG. 4 is an example of a hunt utility configuration and is not to be construed as limiting. It is to be understood that other configurations may be possible with more, less, or the same elements as those depicted and those described herein. Furthermore, although hunt utility mechanism 112 is depicted as a Web browser extension, this is not to be construed as limiting, and hunt utility mechanism 112 may be alternatively implemented as an independent application.

Hunt utility mechanism 112 may include hunt selection interface 402 that may enable a user to select a particular hunt to in which to participate. For example, the hunt selection interface 402 may provide a list of available scavenger hunts via a drop-down menu. If the user is part of a team, he may use hunt selection interface 402 to toggle between all available hunts or only hunts in which his team is participating. Hunt selection interface 402 may indicate in which scavenger hunts his team is active, such as via an icon. If a particular scavenger hunt allows for either solo or team play, a user may be required to participate in the hunt in only one fashion (i.e., solo or on a team) to prevent him from receiving double points for the same hunt. Hunt information display 432 may provide the user with information regarding his current hunt, such as the name of the hunt, the total number of steps in the hunt, which step he is currently on, the number of steps his team has completed, etc.

Hunt status interface 404 may enable a user to toggle between participating in the hunt and ceasing or pausing his participation. Hunt utility mechanism 112 may only be active when a user is explicitly participating in a scavenger hunt. When a user is participating in a scavenger hunt, hunt utility mechanism 112 may track the URLs visited and may alert the user when he has found a hunt Web page (even if accidentally). If the user is not participating in a hunt, hunt utility mechanism 112 may still function, such as by providing data regarding his team's progress, enabling the user to interact with team members, etc., but, per a user's preferences, it may not be able to track or monitor the user's Web browsing behavior.

A user may use team creation interface 406 to create a team. The user may stipulate who may join the team (e.g., public, invitation-only, per team leader approval, etc.), may invite participants (e.g., by providing their email addresses, phone numbers, etc.), set a hunt ranking requirement, etc. The user may be prompted to provide an avatar image, such as a photograph of himself, to represent himself to other team members or other hunt participants in general. The avatar image may be stored in association with his hunt account. In one embodiment, a user may allow his avatar image and/or that of the entire team to be provided to a third party service, such as abillionfaces.com. Team joining interface 408 may enable a user to find and join an existing team. For example, team joining interface 408 may provide a list of available teams via, for example, a drop-down menu, or the user may enter the name of a known team or team member. Once the user has selected a team, he may readily join if membership is open to all or he may request to join if access is restricted. Team members may communicate with one another via messaging interface 418. Messaging interface 418 may enable communication via typed messages, audio communication, video communication, or a combination thereof. Location display 420 may indicate the location of other team members. In one embodiment, location display 420 may be a map-like display that allows a user to zoom in on particular locations. In order to preserve player privacy, location display 420 may only display a general location, such as a participant's city. A participant may also stipulate in his user account the level of location information he wants available and to whom he wants it available.

Hunt voting interface 422 may enable team members to vote on the hunt in which to participate. For example, hunt voting interface 422 may display five available scavenger hunts and allow each member to cast a vote for his desired hunt. The displayed hunts may be the next ones available, randomly selected, or may include the hunt each team member selected via hunt selection interface 402. Once the majority of the team has selected a particular scavenger hunt, it may begin or each team member may be prompted to start.

In one embodiment, in addition to, or instead of, hunt creators providing ISHS 104 with clues, users may provide ISHS 104 with the clues. A user may use clue providing interface 410 to leave one or more clues regarding a hunt objective. The user may be restricted to leaving a clue only for the Web page he is currently viewing or may be enabled to specify the appropriate Web page for the clue. A user may use clue providing interface 410 during solo play and leave public clues for other participants and/or may use it during a team hunt to leave clues for other team members. Hunt utility mechanism 112 and/or ISHS 104 may scan a clue before publishing it in order to prevent a user from explicitly providing the hunt objective answer via the interface. Alternatively, a human operator may monitor user-provided clues in order to prevent this. A user may also request a clue for the current Web page by selecting clue request interface 412. Once selected, clue request interface 412 may display one or more clues provided by other users or by the hunt creator. A user may provide feedback regarding a received clue via clue feedback interface 414. For example, if the user feels a clue is particularly useful, he may select “Good Clue!” while he may select “Bad Clue!” for a clue that was not helpful. As with user-provided clues, hunt utility mechanism 112 and/or a human operator may monitor user feedback to determine whether a user is abusing the system. For example, hunt utility mechanism 112, ISHS 104, or a human operator may determine if an individual is purposefully providing inaccurate clue feedback or whether a particular user-provided clue is being repeatedly marked as bad (thereby indicating abuse by the participant that provided the clue). A user that abuses clue providing interface 410 or clue feedback interface 414 may lose points, be blocked from participating in the hunt (and possible future hunts), etc. Information entered into messaging interface 418 may be similarly monitored.

A user may enter what he believes is the correct objective answer into objective input interface 430. Hunt utility mechanism 112 may then interact with ISHS 104 to determine whether it is correct. A participant may receive a score for completing hunt objectives. The score may be represented in various fashions, such as a grade, a percentage, a point total, etc. A user may view his current hunt score via score display 416. The amount of a score may be based upon how long it took the user to find objectives, how many clues he needed, a minimum and/or maximum point reward, etc. A user's score may also be increased for providing good clues and/or for providing accurate clue feedback, and, as mentioned, may be penalized for providing bad clues and/or inaccurate user feedback.

Current page information display 424 may provide the user with various data, such as how many players have been on the current Web page before the user, the number and names of team members that have been to the Web page, the number and names of team members currently there, etc. Timer display 426 may display the time elapsed since the user started the scavenger hunt, the time left remaining before the hunt ends, etc. Ad display 428 may display electronic advertisements, such as those provided by a hunt sponsor.

These and other aspects of the present invention will become apparent to those skilled in the art by a review of the preceding detailed description. Although a number of salient features of the present invention have been described above, the invention is capable of other embodiments and of being practiced and carried out in various ways that would be apparent to one of ordinary skill in the art after reading the disclosed invention. Therefore, the description should not be considered to be exclusive of these other embodiments. Also, it is to be understood that the phraseology and terminology employed herein are for the purposes of description and should not be regarded as limiting.

Claims

1. A method for playing a game via the Internet, the method comprising:

receiving, by a scavenger hunt system from a Web browser, a request from a user to activate a scavenger hunt;
activating the requested scavenger hunt;
transmitting to the Web browser, a first uniform resource locator (URL), wherein the URL pertains to a Web page associated with a hunt objective;
receiving, by the scavenger hunt system from the Web browser, hunt objective answer data; and
making a first determination whether the received hunt objective answer data is correct by comparing the received hunt objective answer data to stored objective answer data, wherein: if the received hunt objective answer data is determined to be incorrect, transmitting to the Web browser an alert message; and if the received hunt objective answer data is determined to be correct, making a second determination whether the final hunt objective has been reached, wherein: if the final hunt objective has not been reached, transmitting to the Web browse a subsequent URL, wherein the subsequent URL pertains to a Web page associated with a subsequent hunt objective; and if the final hunt objective has been reached, transmitting to the Web browser a completion message.

2. The method of claim 1, wherein the Web browser is enabled to interact with the scavenger hunt system via a hunt utility mechanism included with the Web browser.

3. The method of claim 1, further comprising transmitting to the Web browser a hunt objective clue.

4. The method of claim 1, wherein the scavenger hunt is a team-building exercise.

5. The method of claim 1, wherein the scavenger hunt is a test of knowledge.

6. The method of claim 1, wherein if the final hunt object has been reached, making a third determination whether the user is eligible for a reward per a reward parameter.

7. The method of claim 6, wherein if the user is determined to be eligible for the reward per the reward parameter, transmitting to the Web browser a reward message.

8. A method for creating a scavenger hunt, the method comprising:

receiving, at a scavenger hunt system, a request to create a scavenger hunt;
receiving scavenger hunt data, wherein scavenger hunt data comprises hunt description data;
receiving scavenger hunt step data, wherein the scavenger hunt step data comprises: a hunt step objective; a hunt objective clue; and a uniform resource locator (URL) pertaining to a Web page associated with the hunt step objective;
requesting instruction whether the scavenger hunt is complete, wherein: if a received instruction indicates that the scavenger hunt is incomplete,
transmitting a request for subsequent scavenger hunt step data; if a received instruction indicates that the scavenger hunt is complete, transmitting a request for scavenger hunt rule data;
receiving the scavenger hunt rule data; and
activating the scavenger hunt in compliance with the scavenger hunt rule data.

9. The method of claim 8, further comprising receiving a player quantity requirement.

10. The method of claim 8, further comprising receiving a team quantity requirement.

11. The method of claim 8, wherein the scavenger hunt pertains to one or more of the goods and services of a commercial entity.

12. The method of claim 8, further comprising receiving scavenger hunt reward data.

13. A system for enabling an electronic network scavenger hunt, the system comprising:

a scavenger hunt system accessible via an electronic network, wherein the scavenger hunt system comprises: a data store mechanism configured to maintain scavenger hunt data for one or more scavenger hunts, wherein the scavenger hunt data includes a plurality of uniform resource locators (URLs) associated with the steps of a scavenger hunt; a hunt creation interface mechanism configured to receive the scavenger hunt data, to enable the creation of a scavenger hunt based on the received scavenger hunt data, and to activate the created scavenger hunt; and a hunt distribution mechanism configured to distribute one or more steps of the created scavenger hunt to an access mechanism via an electronic network in order to enable an individual to participate in the scavenger hunt.

14. The system of claim 13, wherein the access mechanism is one or more of the following: a personal computer, a mobile phone, a multipurpose mobile device, an interactive television, a kiosk, or a video game system.

15. The system of claim 13, wherein the electronic network is one of the following: the Internet, a mobile network, an intranet, and a broadcast network.

16. The system of claim 13, wherein the hunt distribution mechanism is configured to distribute the one or more steps of the created scavenger hunt to the access mechanism by distributing the one or more steps of the created scavenger hunt to a hunt utility mechanism included in the access mechanism.

17. The system of claim 16, wherein the hunt utility mechanism is configured to interact with a Web browser included in the access mechanism.

18. The system of claim 13, wherein the data store mechanism is further configured to store user data.

19. The system of claim 13, wherein the scavenger hunt data further includes reward data.

20. The system of claim 13, wherein the scavenger hunt system is configured to interact with a social network system.

Patent History
Publication number: 20120202600
Type: Application
Filed: Feb 8, 2012
Publication Date: Aug 9, 2012
Applicant: STOR NETWORKS, INC. (Sandy, UT)
Inventor: Reza Jalili (Sandy, UT)
Application Number: 13/369,291
Classifications
Current U.S. Class: Network Type (e.g., Computer Network, Etc.) (463/42)
International Classification: A63F 9/24 (20060101);