Patent Application
20210263484
This disclosure relates to systems and methods for manipulating the shape and behavior of a physical space.
Real world adventure games, such escape rooms or the like, have become popular in many parts of the world. A typical escape room has both physical and mental aspects that require players, or participants, to solve a series of puzzles or riddles using clues, hints, and strategies in a physical space to complete the objectives at hand. Usually, players are given a set time limit to complete the challenges required to “escape.” Escape rooms can be great fun for its participants. Once established, a typical escape room can accommodate one type of adventure game. If other adventure games are desired, a new escape room, and scenario, are devised.
In one aspect, a method includes receiving content at a computer system. The content describes a mission for participants that involves the participants attempting to complete one or more tasks in a physical zone. Completing at least some of the tasks may require an understanding by the participants of training materials. However, in some implementations, there may be no training materials and the mission may be for entertainment purposes only, or primarily. The method also includes providing or constructing the physical zone where one or more missions can take place, and providing one or more physical components that the participants can interact with when undertaking the mission in the physical zone. The method includes receiving parameters about the physical zone at the computer system. The parameters may describe the physical zone itself and/or one or more physical components in the physical zone. The method includes comparing the content of the mission to the parameters that describe the physical zone to determine, with the computer system, whether the mission can be undertaken in the physical zone. If the computer system determines that the mission can be undertaken in the physical zone, then the method includes presenting the mission and the physical zone as an option for the participants. Additionally, the method includes controlling the one or more physical components in the physical zone with the computer while the participants are undertaking the mission in the physical zone.
In some implementations, the method includes providing training materials to the participants to review before and/or during the mission.
In certain implementations, the method includes receiving signals at the computer system from one or more of the physical components in the physical zone as the participants interact with the one or more physical components while undertaking the mission.
Some implementations include causing, with the computer system, one or more of the physical components (e.g., locks) in the physical space to change state (e.g., to open or close) in response to one or more of the received signal (e.g., a signal indicating that a participant has solved a puzzle related to the training materials).
According to certain implementations, the method includes enabling users (e.g., human content creators) to enter content about different missions into the computer system. The content entered by each respective user can describe and be associated with different missions. Each different mission may involve the participants attempting to complete one or more mission-specific tasks in a mission-specific physical zone. For each different mission, completing at least some of the mission-specific tasks may require an understanding by the participants of mission-specific or generic training materials.
In some implementations, the method includes enabling users to enter parameters at the computer system that describe different physical zones and one or more physical components in each respective one of the different physical zones. In this regard, the computer system, in some implementations, is configured to determine which of the different missions can be undertaken in which of the different physical zones by comparing the content about the different missions with the parameters that describe the different physical zones and the physical components in the different physical zones. The computer system also may be configured to identify to mission participants, at a computer-based user access terminal: one or more of the different missions that can be undertaken at a selected one of the different physical zones, and/or one or more of the different physical zones where a selected one of the different missions can be undertaken. Depending on the specific circumstances, of course, any particular one of the different missions may be able to be undertaken at a particular one of the different physical zones, if requirements of that particular mission set by the content entered for that particular mission, can be satisfied by characteristics of that particular physical zone based on the entered parameters for that particular physical zone.
In some instances, multiple groups of participants can undertake different missions at the same time in one single physical zone—more specifically, in different areas or rooms of one single physical zone. In those instances, the computer system may be configured to control the different areas or rooms of the one single physical zone according to the progress of each respective group of participants.
According to certain implementations, the method includes enabling content creators to leverage content created by others or by themselves for other missions.
The training materials can relate to a wide range of topics including, for example, some real-world training goal that is not related to the mission.
In some implementations, the computer system is configured to set up the one or more physical components in the physical zone prior to the mission taking place in accordance with the content received at the computer system that describes the mission.
The content that describes the mission may be organized (hierarchically) and saved into computer-based memory as mission information, objective information, and task information. Each mission may include (and be built upon) one or more objectives, and each objective may include (and be built upon) one or more tasks. In some implementations, the tasks are logically associated in the computer-based memory with one or more physical devices that must be present as a component in a room of the physical zone in order for the physical zone to be able to support a corresponding mission (that includes those tasks). In some implementations, each objective may be logically associated in the computer-based memory with a corresponding room in the physical zone that has every device that is required to support any tasks associated with that objective. The objective information and the task information may be stored such that each objective can be readily associated with a corresponding new mission, and such that each task can be readily associated with a corresponding new objective or mission.
In certain implementations, comparing the content of the mission to the physical zone parameters (for suitability purposes) includes: determining whether a room type associated with the mission content is represented in the physical zone parameters; and, if so, determining if a device associated with a task to be performed in the room type as represented in the mission content is represented in the physical zone parameters.
The system, in some implementations, is configured to coordinate two or more missions being undertaken utilizing different rooms (at the same time) in the same physical zone to accommodate different objectives in the different rooms for the different missions.
In another aspect, a system includes: a physical zone where one or more missions can be undertaken. Each physical zone is defined at least in part, by walls that define rooms or spaces within which participant action can occur. There are one or more physical components in the physical zone that the participants can interact with when undertaking one of the missions in the physical zone. A computer system is configured to receive signals from the one or more physical components as the participants interact with the one or more physical components during the mission being undertaken, and to control the one or more physical components in response to the signals received. The computer system may be further configured to: receive content that describes a mission for participants that involves the participants attempting to complete one or more tasks in the physical zone. Completing at least some of the tasks may require an understanding by the participants of training materials. The computer system also may be configured to receive parameters that describe the physical zone and the one or more physical components in the physical zone. The computer zone also may be configured to compare the content of the mission to the parameters that describe the physical zone to determine whether the mission can be undertaken in the physical zone, and, if the computer system determines that the mission can be undertaken in the physical zone, present the mission and physical zone as an option for the participants at a user access terminal.
In some implementations, one or more of the following advantages are present.
For example, in some implementations, it is possible for a space to change its shape, the way it behaves and the parameters of that space, based on a pre-programmed script and the actions of a person or people in that space. A person or a group of people can elect to enter a space that is governed by a selected program and depending on how they interact with the space and the program. A System reacts to those inputs. That System can unlock doors/portals/passages, change images on a screen, manipulate lights and sounds, move objects, reposition walls, and reshape objects as that person or people move around and interact with data inputs to the program. Manipulating the space, allows a person or people to interact with a computer System for entertainment purposes or to facilitate education through experiential learning concepts. In essence, an adventure is created in theory and then a person or people act it out in the real world space. Further, a single space can be programmed to enable an infinite number of adventures by the way the plot line and space design, are affected on the actual playing space.
Also, immersive experiences are more engaging for people to enjoy the world around them. These have taken many forms. Each experience requires infrastructure and thematic programming. Up until this point most Content and physical environment solutions are not scalable. To enable this kind of bespoke capability to the masses at a cost-affordable price, there needs to be a way to create scalability. The Systems and techniques described herein enable several forms of scalability.
Other features and advantages will be apparent from the description and drawings, and from the claims.
According to one example, a mission may include a fictional story whereby the participants are supposed to try escape from an evil-doer's lair. In this example, the physical zone 102 may be a life-size mock-up of the lair and may include a series of physical obstacles (e.g., components or objects such as locked doors, locked windows, locked containers, or computer terminals that require passwords or codes to open or access, etc.) and information, either hidden, coded, or out in the open in the physical zone 102. Advancing through, or completing, the mission (e.g., escaping from the lair) may require the participants to complete a series of physical and/or mental activities, some of which may involve one or more of the physical obstacles, one or more of the pieces of information, and/or one or more pieces of information from the training materials.
Typically, the training materials will have been given to the participants in advance of the mission to study and learn. The training materials can relate to just about anything. Some examples may include new company policies, materials from high school or college classes, technical training materials, etc. In general, if a particular mission has associated training materials, then the training materials will relate to some real-world training goal that is not necessarily related to the mission.
The physical and mental activities can include virtually any kind of physical and mental activities, such as, solving problems, answering questions, entering codes into electronic or mechanical devices, unlocking locks, and opening doors, climbing in, on, or over objects, crawling under objects, or otherwise interacting with physical and/or electronic/computer-based objects or components at the physical zone 102. The participants in this example can complete a particular mission by completing whatever prescribed set of physical and mental activities in the physical zone 102 may have been associated with the mission.
In various implementations, the participants may voluntarily undertake a mission for fun, learning, team building, or some combination of these reasons.
The physical zone 102 in the illustrated implementation includes a plurality of walls that define a maze, through which the participants can move.
In a typical implementation, there are physical components (e.g., locked doors or other obstacles) in the physical zone 102 that the participants can interact with, mentally or physically, when undertaking a mission in the physical zone 102. At least some of the locked doors or other obstacles may require problem solving (based, in part, on the training materials) or the like to open or traverse.
The system 100 also has a computer system 104 associated with the physical zone 102 and configured to interact with components in the physical zone 102 while a mission is being undertaken. These interactions may include, for example, sending and/or receiving electronic signals to and/or from the components while the mission is being undertaken in the physical zone 102.
The illustrated computer system 104 has creator terminals 106, zone manager terminals 108, player terminals 110, and a computer-based memory and processing system 112, all connected together over a network 114 (e.g., the Internet or any other communications network). The computer-based memory and processing system 112 has a computer-based memory device 115 and a computer-based processor 116.
The creator terminals 106 provide a computer-based interface to the system 100 for content creators (i.e., people who create content—missions—or enter information about the missions into the system 100). In some implementations, the creator terminals 106 enable content creators (e.g., humans) to enter into the system 104 information that specifies and characterizes new missions, physical zone 102 requirements to support or accommodate the new missions, and/or training materials (if any) associated with the new missions. In a typical implementation, the creator terminals 106 may be configured to prompt the content creators to enter specific types of information that is relevant to a created mission, its physical zone requirements and/or the associated training materials.
In some implementations, different content creators may enter different content about different missions, for different physical zones, with different training materials, at different creator terminals. The content may be entered in the computer system 104 by different types of people. In some instances, content may be entered by people who work for the company that operates the system 100. In some implementations, content may entered in the computer system 104 by people that do not work for the company that operates the system 100, but instead, by potential participants of the system. For example, an organization's human resources group may enter content for a mission that the organization's employees will undertake to learn training materials relating to a new human resources policy. In some implementations, the system is configured so as to enable content creators to leverage content created by others or to leverage content created previously by themselves for other missions.
In some implementations, the content entered at the creator terminals 106 is saved in the computer-based memory device 114 of the computer-based memory and processing system 112. However, in some implementations, the content may be saved at one or more other convenient memory storage locations throughout the system 100.
The zone manager terminals 108 provide a computer-based interface for zone managers (i.e., anyone tasked with managing a particular physical zone 102 and the missions associated therewith). In a typical implementation, a zone manager terminal 108 enables a zone manager to initiate a mission for a group of participants at the physical zone 102, monitor the group's progress through the mission, and/or interact with one or more components (e.g., audio speakers or the like) in the physical zone to interact with the participants during a mission and/or otherwise adapt the mission in real time. In some implementations, the zone manager terminals 108 provide other functionalities that might be convenient or helpful to a party whose job it is to manage a particular physical zone 102 and the missions that are undertaken at the zone 102. These functionalities can include, for example, monitoring and storing performance metrics, handling and tracking financial information (e.g., information about costs and payments, etc.), etc.
The player terminals 110 provide a computer-based interface to the system 100 for players (e.g., mission participants, prospective or otherwise). In a typical implementation, the player terminals allow the participants to access information about available missions at one or more physical zones. In some implementations, the player terminals 110 are configured to prompt the players to select missions from a plurality of available missions based on the physical zones that are available where the selected mission will be undertaken. Also, in some implementations, the player terminals 110 enable the players to access performance metrics, photographs, and/or training materials associated with particular missions.
In some implementations, the computer system 104 (e.g., the computer-based memory and processing system 112) is configured to compare the content of each mission to the parameters that describe each available physical zone to determine whether the mission can be undertaken in the physical zone, and, if the computer system 104 determines that the mission can be undertaken in the physical zone, it presents the mission and physical zone as one, of perhaps several, options for a participant at one of the player terminals 110 to consider for selection.
In some implementations, some terminals in a particular system 100 may perform multiple roles. For example, if a prospective player might utilize his or her terminal to create content for the system 100, then that person's terminal might be a creator terminal and a player terminal.
The computer-based memory and processing system 112 in the illustrated system 100 provides at least some of the processing and memory storage required to facilitate and support system performance according to the current disclosure. In this regard, in some implementations, the computer system 104 (e.g., the computer-based memory and processing system 112) is configured to monitor and/or control various components in the physical zone 102 in accordance with electronically stored information about the mission being undertaken and/or in response to actions that the participants take in the physical zone where the mission is being undertaken. In a typical implementation, this monitoring and/or controlling is implemented automatically (i.e., without requiring input from a human outside of the physical zone 102 after the mission is initiated and while the mission is being undertaken).
During a mission, in a typical implementation, the computer system 104 receives signals from the one or more physical components in the physical zone as the participants interact with the one or more physical components during the mission being undertaken. In a typical implementation, the computer system 104 is able to cause one or more of the physical components in the physical zone or space 102 to change state in response to one or more of the received signal. For example, in response to a signal from a computer terminal in the physical zone indicating that a participant has solved a riddle (related to associated training materials), the computer system 104 may cause a lock on a door in the physical zone 102 to unlock.
In a typical implementation, for each physical zone, multiple groups of participants can undertake different missions (or different instances or versions of the same mission) at the same time in different parts of the physical zone.
What follows is a description of certain exemplary implementations. As used herein, terminology should generally be interpreted in accordance with its ordinary meaning. In addition, in some instances, some of the following commentary may be applicable as well.
At a high level, according to the exemplary implementation, the content creators 220 generate content (at 1). The zone managers 222 configure construct and/or maintain the zone (at 2). The players 224 search for missions (at 3). In this regard, the computer system 104 determines (and presents to the players) available options (at 4) for missions to undertake at the physical zone 102. The players 224 sign-up for one of the options (at 5). The computer system 104 provides content and/or other materials (e.g., training materials) for the selected mission to the players 224 (at 6). The players travel to the physical zone 102 (at 7). The computer system 104 interacts with the physical zone—with, e.g., zone instructions and player actions—at 8 and 9 while the mission is being undertaken.
Thus, in some implementations, the system 100 operates according to the following:
These processes can be happening continuously and/or in an overlapping manner. While some are sequential, not all are pre-requisites for others. Further details of examples of each step are provided below.
There are a variety of people that may want to create (and who may create) content for the system. Here are some examples:
There are a variety of ways in which the content created by a creator may be entered into the system. In one exemplary implementation, the system may be configured to present a series of questions to prompt the content creator (at a computer-based content creator user interface) to enter the information necessary to fully define a particular mission. These questions may prompt the content creator to specify one or more of the following (list is not necessarily comprehensive):
This, and potentially other information, may be saved by the computer system in a mission header, an electronic record that summarizes various features of a mission. A graphical representation of an exemplary mission header record is shown in
At the top level is the mission itself. The attributes that provides contextual information about the mission can be included in, and saved as, a mission header. As mentioned above, the mission header is a logical record that summarizes the overall characteristics of the mission.
The second level of hierarchy in the construction of mission content can be referred to as the objective. Each objective generally relates to a single room in the zone. In short, something (an objective) must be achieved in the room before proceeding to the next room. That thing is the objective. In a typical implementation, the system:
There are a variety of ways in which the objective and objective attributes may be entered (e.g., by a creator) into the system. In one exemplary implementation, the system may be configured to a present a series of questions to prompt the content creator (at a computer-based content creator user interface) to enter the information necessary to fully define particular objectives. These questions may prompt the content creator to specify one or more of the following (list is not necessarily comprehensive):
This, and potentially other information, may be saved by the computer system in an objective information record, an electronic record that summarizes various features/attributes of an objective. The objective information record also may have a field identifying an objective number, which is a unique number that the system uses to track objectives and their associated attributes. An exemplary objective number might be (e.g., the unique identifier=62).
The lowest level of the hierarchy can be referred to as the task. In an exemplary implementation, a task is an action or actions that must be performed to yield a result, which can be submitted to the system for evaluation of correctness. Tasks may be performed within, and as part of, an objective, but need not be exclusive to that objective. Generally speaking, a particular task can only be performed if the room associated to that objective has the requisite components. For example, a creator should not configure a task to perform a math problem and enter the results on a keypad, if the objective is linked to the room type where the task is to be performed has no keypad. A player has to have the opportunity to complete the task, and if not, there should be a reason why and alternative path in the mission's programming.
Tasks also have attributes. The task attributes generally enable the system to engage the player with specific things to do. These things that the player must do then become the base level governing step for the system to determine if the player is progressing through the mission. Some examples of task attributes are listed below. Some of these task attributes may be entered into the system by the creator and stored by the system as an electronic record. The task number may be an arbitrary or sequential number, for example, that is assigned by the system to identify the associated task (and its task attributes). This list is not exhaustive.
In a typical implementation, a mission may be created by creating a mission header, which provides an overall theme and story for the mission and then adding objectives and tasks to the mission (e.g., creating logical links between certain objectives and tasks and the mission). The system, in this regard, may provide an interface at a computer-based user interface that is accessible to the creator constructing the mission. The interface can have any one of a variety of different formats and can facilitate creating the logical associations in a graphical environment or textual environment.
Because they are in a hierarchy, objectives and tasks might already exist, or they can be created on-the-fly. The system, in a typical implementation, will make available to the creator (e.g., at the creator's computer-based interface) a listing or identification of previously-created objectives and tasks, if any. In some implementations, these previously-created objectives and tasks may have been created previously by the creator who is currently engaged with the system. In some implementations, these previously-created objectives and tasks may have been created previously by someone other than the creator who is currently engaged with the system.
If a desired objective or task already exists in the system (e.g., it has already been created and saved in the system), the creator may simply select that objective or task (rather than having to recreate it) to add it to the mission being created.
Each of the items in this hierarchy is independent of the other; however components can be reused as often as are needed for creating missions. In one example, the structure of a mission can be represented in hierarchical structures that indicate associations in the system between the associated items (e.g., missions, objectives and tasks).
To produce the indicated hierarchical structure (in
Next, in this exemplary implementation, the creator creates an objective (62). The creator also creates a logical association in the objective to the indicated tasks (101 and 102), which means that the objective (62), in practice, should include the indicated tasks (101 and 102). In the example represented in
Next, in this exemplary implementation, the creator creates a mission (12635) and creates a logical association between the mission (12635) and the objective (62), which is already logically associated with tasks 101 and 102. This means that the mission (12635), in practice, should include the objective (62) and the associated tasks (101 and 102). In the example represented in
The table in
A combination of the base data in
This sort of construction facilitates creators being able to leverage content created by others. For example, a new Mission, #12701, could use objective 62, but instead gather the numeric values for solving the equation from somewhere other than the locked closet. In that case there might be a “task 103—Get second number from ornate chest”, which could be used to generate the following Mission hierarchy.
Nearly infinite amounts of content, and combinations, can be stored in the system, using this architecture.
In order for a physical space to become a zone (that can support a mission) and thus controllable by the system, the characteristics of the space need to be entered (registered) into the system. In a typical implementations, these characteristics use the same words (or attribute qualifiers) to describe the space and the devices (components) therein, as when missions, objectives and/or tasks, are created and entered into the system built. For example, the system may use the same room types and names of devices when entering (or registering) devices in a room as used to specify room types and devices needed when creating a mission.
Thus, in a typical implementation, the zone manager may build a zone that has certain parameters and enter those parameters into the system using words that are the same as (or highly similar to) the words used by the creator in specifying a mission. This enables the system to easily link missions to physical zones, based on common parameters.
In some implementations, a zone will have multiple rooms linked by doors, connectors, tunnels, etc. In general, each zone should be identified in the system (e.g., by a zone manager) with a name. Each zone should be identified in the system (e.g., by the zone manager) as having a certain number of rooms within the Zone. Moreover, each zone should be identified in the system (e.g., by the zone manager) as having a certain number of and type of devices within each room.
In an exemplary implementation, a zone/room/device hierarchy could look as follows. The device in this example could be an item that interacts with the system's program and is controlled in accordance with parameters of the mission.
Each zone may have a series of attributes. These attributes may be used, for example, for administrative purposes. Adding rooms to a zone could change the mission capabilities of that zone. Typically, missions are applied to zones based on operational attributes from lower levels; not zone level attributes. These are some exemplary zone level attributes that a zone manager, for example, may enter into the system for a particular zone.
Each room also has attributes. In some implementations, these attributes, combined with the device registrations, enable the system to determine if a mission can physically execute at a zone that has these rooms. In an exemplary implementation, two algorithms (described later) enable the system to make this determination. The mission specifies a required room type (in the objective). When a zone is configured in the system, each room is categorized by room type. If those two match, the mission can be executed. And further, they provide the communication mapping to the zone. For example, a device's address is a unique way of identifying that device across a network (e.g., the Internet). It can send and receive signals from a system (commonly referred as Internet of Things (IOT)). Because that unique address is associated with a room, and the room to the zone, when the mission begins at a zone, the system knows all of the devices that will be utilized for that mission. It will need to send signals to each of these devices. As an example, to start it will lock the doors, turn on lights, load a page on a tablet, display an image on a TV. The doors, lights, tablet and TV are all devices that have unique addresses and are needed by the mission (in one example) to execute. The tablet is one device that will send a signal (a challenge response) back to the system. Because it has an address registered and associated with the mission, the system knows to receive that message and evaluate as part of the mission. Typically, the room is ‘coded’ or ‘registered’ by the system so that the system knows that once a room is ‘active’ or the player is in that room solving the objective, that all the devices associated with that room, are also active. In one example, if a mission starts at a zone, the zone's rooms may all have coding and devices in them with individual system-wide addresses so that a command instruction can be sent by the system directly to the device. Thus, the system can control the operations of the zone (including the operations of the devices within the zone) based on the parameters of a mission that is being executed. These are some exemplary room level attributes that a zone manager, for example, may enter into the system for a particular room (the room number may be assigned by the system, not by the zone manager).
Step 3) A Player wants to engage with the System
There are several ways that the player might engage with the system; two options are described herein.
Option 1) A player (at a computer-based terminal) can select or identify desirable attributes for a mission. In this regard, the player might, for example, search or scroll through a list of attributes available in the zones of the system to find a mission to undertake. In this regard, the system may present to the player a search box that the player can enter an attribute or key word related to an attribute (e.g., a lesson to be taught, a skill needed, a style of mission, etc.) that the system will search for. Once the search is completed, the system may present a listing of search results—i.e., missions that have attributes, or associated objective attributes, or associated task attributes that match the or are related to the key word.
Alternatively, the player might search for a particular zone, or indicate to the system which of the available zones is most desirable. The most desirable zone might be, for example, the one closest to the player. As an alternative example, if the mission might require a longer preparation time and the gathering of knowledge, the learning of skills and/or the assembling of materials needed for the mission, a location farther away might be acceptable. Each zone might not support a desired mission, so extending the search areas might be warranted.
Option 2) Instead of individually searching, a player may also engage with the system as a result of other channels, where a mission might have been recommended to them directly. For example:
In some implementations, the system facilitates communication between different users (e.g., any of the people identified above) about missions and how they might be utilized.
In a typical implementation, the system is configured to determine suitability of each particular zone to support each particular mission.
In some implementations, the system is configured such that it can identify to users (e.g., potential players (participants), content creators, etc.) which zones can support a desired mission, objective, or task. Moreover, in some implementations, the system is configured such that it can identify to users (e.g., potential players (participants), content creators, etc.) which missions, objectives, or tasks can be performed at a desired zone.
In this regard, the system may present to the user (e.g., at one of the computer-based user access terminals) an interface that provides searching capabilities (for zones can support a desired mission, objective, or task, or for missions, objectives, or tasks can be performed at a desired zone, etc.) or that lists combinations of compatible zones, missions, objectives, tasks, etc. that are available across the system. Of course, a single system may include multiple different zones that have or that can support multiple different missions, objectives, and/or tasks.
Generally speaking, a mission configuration necessitates certain requirements of a zone for it to be operational at that zone. It is possible that a zone might not support the requirements of a mission based on rooms, devices, sizes, shapes, availability, etc.
In a typical implementation, the system includes processing that is intelligent enough to leverage one or more algorithms that can determine, for example, the requirements of the mission and then dynamically derive which zones are capable of executing that mission. This suitability query (algorithm) may happen, for example, in real time as the player researches missions. An example of this algorithm is described below.
1. First a player selects a mission that he or she wants to undertake. The player may do this, for example, by selecting a desired mission from among a listing of missions available on the system.
2. Next, the player selects a desired zone. The player may do this, for example, by selecting the desired zone from among a listing of zones available on the system presented to the player at a computer-based user interface.
3. Each mission has one or more associated objectives. Each objective is tagged in the system (e.g., logically associated) with a room type. In response to the player's mission selection, the system may determine if the player's selected mission has room types that are present in the desired zone. This determination may be made by comparing key words from the stored room descriptions associated with the selected mission to try to find a match (or substantial match) to stored room descriptions associated with the selected zone. If the system determines that the player's selected mission has room types that are present in the desired zone, then the system can make further determinations of feasibility. If not, then the system may inform the player that the selected mission is not available at the selected zone, and allow the player to continue searching for or selecting other mission/zone combinations.
4. If (in step 3) the system determines that it should make further determinations of feasibility, it may proceed as follows. Each objective has one or more associated tasks. If a task requires a value to be submitted to the system for evaluation, for example, that task will also specify a device to facilitate system communications. The system, in that instance, can determine if the zone's rooms have the device(s) required to facilitate the system communications. Note: Not all devices are room specific. Some, like a mobile phone, may travel with the player as he or she travels through the mission. If the system determines that the zone's rooms do not have the device(s) required to facilitate the system communications, then the system may inform the player of this fact, and allow the player to continue searching for or selecting other mission/zone combinations.
5. In some implementations, if both determinations above are met, the system certifies that the request to begin the selected mission at the selected Zone is valid. The system then may allow the player to “sign-up” for the mission, and begin the process of preparing for and scheduling the mission as dictated by the mission's protocols.
The exemplary depiction represents mission configuration information, for one mission (Evolution of Mankind Through DNA) on the left side of the page (with information about the represented mission that would be saved in the system), and zone configuration information, for two different zones (Egyptian Pyramid and Neon Office Park) on the right side of the page (with information about each respective one of these zones that would be saved in the system).
The system, in the illustrated example, would apply the system algorithm (represented centrally between the mission configuration information and the zone configuration information) to determine whether the indicated mission (which may have been selected by a user, for example) is able to be undertaken at either or both of the represented zones.
According to the illustrated implementation, the system applies two algorithms 1 and 2 (or two parts of an algorithm) to make this assessment. According to the first algorithm (algorithm 1), the system checks to see whether each of the room types (AnteChamber and Crypt) are available in either or both of the zones. As can be seen, of the two available zones, only the Egyptian Pyramid has both of the room types. Next, in algorithm 2, the system checks to see whether any devices are required by tasks associated with each room type. In this check, the system determines that the antechamber represented in the mission configuration information requires a keypad, and that the antechamber represented in the zone configuration information has a keypad. In this check, the system also determines that the crypt represented in the mission configuration information requires a spell box, an audio (voice recognition) device, a computer tablet, and a phone, and determines that the crypt represented in the zone configuration information has the requisite spell box, an audio (voice recognition) device, and a computer tablet, and that phones are carried by all players.
Therefore, in the illustrated example, the system concludes that the selected mission (Evolution of Mankind Through DNA) can be supported by the zone (Egyptian Pyramid) represented in the zone configuration information. In a typical implementation, the system would present a message to the player (e.g., at one of the computer-based user interfaces) indicating that the mission could be accomplished at the zone and prompting, or enabling the user to sign up to undertake the mission at that zone.
There are a variety of ways in which players may sign-up for a mission. According to one exemplary implementation, signing-up for a mission could be as simple as just selecting an icon and/or clicking an “accept” button. In a typical implementation, when signing up, the player might be prompted to provide some contact information and a method of paying for the mission.
After signing-up, in some implementations, the mission parameters (e.g., all or several of the attributes associated with the mission . . . name, description, plot, objectives, tasks, etc.) essentially take over. For example, the mission parameters might cause the system to communicate with the player around the need for the player to prepare, train and/or gather material in anticipation of the mission. As another example, the mission parameters might cause the system to start with the timer counting down to when the player will need to enter the zone and begin the mission. In the latter case, the cycle may be abbreviated and steps 6 and 7 in FIG. 2 may happen in very short order if not simultaneously. No matter which structure, the system may begin interacting with the player and controlling the physical space where the zone is located, at least by the time the player(s) enters the zone.
In a typical implementation, the system records this event in a database in the system's computer-based memory storage. In some implementations, the start of a mission is recorded to enable several functions performed by the system. This may trigger a billing event to charge the player for beginning a mission, it may log that transaction to keep track of player progress, it may log the start of the mission, and it may help keep track of leveling or skill points associated to the mission and conveyed to the player upon completion.
Step 6) The System Engages with the Player
A mission is broken down into objectives and tasks (that include some challenges to be completed and responses to be submitted to the system for evaluation). These may require some preparation by the player(s) including, for example, reviewing the mission plan, gathering materials, accumulating knowledge (training), rehearsing, recruiting other platers, etc.
In general, simpler tasks tend to require less preparation, whereas more complex tasks tend to require more preparation. For example, looking for a number in a box (a relatively simple task) may require only reading that the player will need to look for a box. As another example, if a task will require calculating a ratio (a relatively more complex task), the player may need to learn about ratios and perhaps how to use a calculator to calculate a ratio (more significant preparation).
Each mission may include a variety of tasks having varying levels of difficulty and complexity, and, accordingly, requiring different levels of preparation by the player(s) before beginning the mission at the zone. In general, the specific combination of tasks included in a mission will dictate how much lead time and preparation may be needed for a mission. In some implementations, as part of configuring a mission, the creator can stipulate the number of days before mission execution that training materials should be sent to the player.
There are also options for more complex tasks. Consider the Task to “Open the spell box” for example. In this case, there might be an archeological text that contains the passage to be recanted when on the Mission (evaluated by a voice response engine). Research is required to find this text, write it down or memorize it. In that case, the Mission begins before the Player is at the Zone to perform the physical Tasks, they are instructed with emails, links, texts or other communication vehicles on how to find the passage.
There might also be a learning exercise to illustrate an understanding of a mathematical theorem (e.g., the Pythagorean Theorem). In general, this would need to start well before the physical mission activities begin. As an example, an objective for a room might be to get one shot at pressing the ‘security system deactivation button’ on a wall. But the only way to access the room is to enter through a ceiling vent. The lesson for the room would be to use Pythagorean Theorem to create a pendulum to press the button with a ball on the end of a string from the open ceiling vent. This is a multi-step and complex process that would require significant prep work (by the player(s)).
The preparation that might be required in the foregoing example can include in this case, the system presenting to the player(s), before the mission begins, materials on how the Pythagorean Theorem works. The player may also need to research the dimensions of the walls and ceiling to determine the lengths of A and B in Pythagorean Theorem. Then they solve for C. Finally they would prepare a string and ball with properly measured length to carry into the mission.
All of these activities related to preparation, learning, assembly, and coordination are part of the system and its control of the components needed to complete the mission. In a typical implementation, these activities involve and may be facilitated by the system. The mission creator knows each task, and thus knows what materials and knowledge are needed to solve the task. Thus by the creator entering attributes (links, documents and other learning materials) into the mission information, the system can disseminate those materials as a prerequisite of accomplishing the mission.
In a typical implementation, once the player starts receiving preparation details from the system (e.g., via email, text, push notification, etc.) to complete a Mission, he or she can begin preparing. The system, in this regard, will have communicated to the player(s) by executing on any instructions that were configured and entered into the system by the creator.
In a typical implementation, it is the creator's responsibility to design a mission in a comprehensive way, so as to have thought out all processes necessary to facilitate a learning or entertaining experience for the player(s) that is highly engaging. The focus is on real world execution and the behavior of a person or group of people moving through a physical space, engaging with that space as they proceed. In some instances, it will behoove the creator to devote a comparable amount of care to good mission design, as would be accorded to the making of a movie, or at least a good classroom academic lesson.
In a typical implementation, it is the player's responsibility to read, understand, and follow-up on the materials transmitted to them and to do the actual preparatory work for a mission. In a typical implementation, the players should have learned any materials, planned an approach to the mission, and gathered any equipment necessary to complete all mission tasks prior to beginning the mission. This may include, for example, each player coordinating with any others (e.g., other players) that may be necessary for the mission's successful execution. Others may include, for example, partners in the same mission zone, partners operating at another zone simultaneously, partners operating with pre-requisites or follow-up missions, and/or support personnel helping any of these groups from behind the scenes.
There are several circumstances under which a player might coordinate with someone doing a different mission. For example:
After preparation, at the designated mission time, the player goes to the zone.
At the zone, the player starts the mission. In a typical implementation, starting the mission also triggers the start of a timer clock—to track how much time is remaining for the mission. Starting the mission also generally kicks off the next steps of the mission's program within the system.
In a typical implementation, all of the objectives and tasks will be configured with a particular sequential order. Therefore, the system, in a typical implementation, will know which objective and task to queue first, and which results it should expect to receive first.
In a typical implementation, the system is configured to interact with and control various components (e.g., physical components, electrical components, optical components, etc.) within the zone to create a satisfying mission experience within the zone.
As mentioned above, in a typical implementation, all of the objectives and tasks will be configured with a particular sequential order. Therefore, in a typical implementation, the system will know the order in which the objectives and tasks should be executed and can control the various components during mission execution to facilitate and react to the ordered execution of the objectives and tasks. For example, when a mission begins, the system will know the first objective of the mission and the first task of that objective. The objective and task will take place in a particular room within the zone. Therefore, the system configures that space according to preprogrammed parameters (specified by the creator) to make that room ready for the first task of the first objective to happen. The system enables the player to engage with that room, by including devices in the room that are required by the mission to enable interactions by the player.
In exemplary instances, the system may configure a particular room (for a particular task of a particular objective), by causing one or more (or all) of the following to happen (this list is not exhaustive):
In various implementations, a room that can support the system performing these sorts of configurations might include any one or more (or all) of these devices (components): lights, a light dimmer and switch, different color lights, flashing lights, motion sensors (that may be configured to cause a light to react), pressure sensors, laser sensors, audio equipment (e.g., microphones, etc.), sound equipment (e.g., speakers), doors, doors locks, objects in the room (e.g., boxes, furniture, etc.) that can move, walls, movable walls, video screens, holographic image generators, fans, scent dispensers, buttons or other objects that can illuminate, etc.
Moreover, the room (or a space around the room) may include one or more actuators that receive control signals (e.g., from the computer-based processing and memory system) to facilitate control (in accordance with mission information provided by the creator) of and/or to turn on or off any of the lights, light dimmers, switches, colored lights, flashing lights, motion sensors, pressure sensors, laser sensors, audio equipment (e.g., microphones, etc.), sound equipment (e.g., speakers), doors, doors locks, objects in the room (e.g., boxes, furniture, etc.) that can move, movable walls, video screens, holographic image generators, fans, scent dispensers, buttons or other objects that can illuminate, etc.
According to the illustrated example, the room has eight different devices: device 14 (entry door), device 15 (large sacrificial table), device 16 (screen), device 17 (door to crypt), device 18 (door to vault), device 19 (lights), device 20 (screen attached to table), and device 21 (screen). According to the represented configuration, the system provides signals (e.g., to actuators) that cause device 14 (entry door) to unlock, device 15 (large sacrificial table) to move to a center of the room as a focal point, device 16 (screen) to display hieroglyphics with a “first number” value of 376, device 17 (door to crypt) to lock and have its keypad illuminated, device 18 (door to vault) to lock, device 19 (lights) to set a lighting level in the space to 1 (dim), device 20 (screen attached to table) to display images representing a “second number” value of 102456, and device 21 (screen) to off (because, in the selected objective, this device will not be used).
After the system sets up a room to support an objective, and the player starts moving through the room to pursue the objective, the system may interact with the player and/or make changes to the room as the player interacts with the devices. For example, if the player interacts with a configured device in the room, which results in the device submitting a challenge response from the player into the system, then the system may react by causing another action to occur (e.g., through another device in the space). For example, if the player enters a code that he or she figured out into a keypad for a door, then, when the system receives the code and confirms that the code is correct, the system may cause a lock on the door to unlock. There are various other (some much more dramatic) actions that the system may be configured to cause in response to either correct or incorrect action by the player in the zone.
Some actions (e.g., simply gathering the two numbers in the AnteChamber) are not challenge responses to the system through devices. In these cases, the devices may be controlled by the system, but generally only as conveyors of information or to prompt a player's action(s) within the room (e.g., to look at a particular screen).
Some actions, however, (e.g., the entry of a calculated code to open a door), is a challenge response. Upon typing the calculated code value into the keypad at a device (e.g., the keypad of device 17 in
As indicated, the device (device 17, a door to the crypt with a keypad) is operational, which, in this example, means that the door can be opened or closed and can be locked or unlocked (e.g., using the keypad). The starting state of device 17 is locked. Therefore, when the player interacts with the door during a mission, if successful, the player might unlock the door. In particular, the player, in the illustrated example, provides a response to a challenge (e.g., by entering a code into the keypad). The correct value of the code, as shown (and as would have been specified by the creator during mission configuration) is 272.49. According to the logic represented in the figure, if the player provides the correct response, then the system causes the locked door to unlock. According to the logic represented in the figure, if the player provides a response that is not correct, then the system leaves the door locked, but causes other actions in the room to occur—namely, an alarm to sound and red lights to come on, and device 15 to move.
In a typical implementation, processes similar to the one described above continue for each objective/room and task interaction for the entire mission or until the mission ends, by player (e.g., player gives up) or by the system (e.g., time expires). Each mission generally has its own configuration. A mission may be as long and elaborate as the configuration mandates, though cost and player engagement levels may vary in response.
In a typical implementation, the system is operable such that it can reconfigure a physical space (e.g., one or more rooms in a zone) during a mission.
Some advantages associated with having the system being able to control a physical space, are scalability and maximized usage of the physical space. For example, a particular physical space may be carved into multiple smaller spaces. This document uses the terms zone and room, to describe that dynamic. Based on a desired configuration, the system may redefine the usage of the zone to manipulate rooms in the zone so that they support the intent of the mission. Once a room is no longer being used by a particular player undertaking a particular mission, the room is free to be used by another player potentially undertaking another different mission. The system, in a typical implementation, is adapted to accommodate multiple different missions happening in different rooms of the same zone, with one or more of the rooms being used (at different times) by one group of players undertaking one of the missions and then, shortly thereafter, by a second group of players undertaking a second one of the missions.
In this regard, as one player exits a particular room (and enters the next), the system may determine (e.g., based on one or more signals from motion detector component(s)) that the player has moved from one room to the next, and the door, through which the players passed will be closed and locked, thus making the exited room inaccessible by the players who passed to the second room. This also makes the first room available to the system for use in another mission, or for doubling back, if the running Mission so indicates. In a typical implementation, the system will understand the events (e.g., multiple missions) happening in a particular zone and can create an optimized utilization plan for the zone based, for example, on priority, mission status, missions in the queue, and/or the upcoming objectives of each Mission.
In some implementations, after a particular room has been freed, the system may determine the next prioritized use of that room. The system then researches the required configuration for that room based on the mission configuration requirements for utilizing that space. The configuration begins as noted in Step 8 above and the player enters the room. Note that as the Player in the example above exited the first room after submitting a correct challenge response, the system would have configured the player's next room based on the configuration parameters of the player's running mission. Depending on setup time, for example, the system might actually ‘lock’ a space from use and start room manipulation based on what it knows needs to happen next in that mission.
According to the illustrated representation, player 1 is undertaking one mission (12635, evolution of mankind through DNA), whereas player 2 is undertaking another mission (10199, tomb raider). At the point in time indicated by the schematic representation, player 1 is pursuing objective 2 of his or her mission (remove DNA codes) in the crypt, whereas player 2 is just beginning his or her mission by entering the AnteChamber to pursue objective 1 of his or her mission (decipher hieroglyphics riddle). At this point in time, the door between the AnteChamber (where player 2 will be pursuing one objective) and the Crypt (where player 1 is pursuing another objective) is closed and locked.
Under objective 2 (recover DNA codes), player 1 is trying to accomplish task 1 (find the spells box). This involves two devices: a spells box, which is locked, and the door (device 24), which, again, is locked.
Under objective 1 (decipher hieroglyphics riddle), player 2 will try to accomplish two tasks: task 1 (use cipher from email to decrypt a message), and task 2 (use secret code from research to open door to the treasure room). Task 1 of objective 1, in the illustrated example, involves device 21 (a display for the encrypted message). Task 2 of objective 1, in the illustrated example, involves device 18 (a door keypad), which has a correct challenge response (that will open the door to the treasure room) of 11188.
The information represented in the schematic representation of
In a typical implementation, the steps above are components of a single exemplary system that uses thematic instructions from a creator to change the behavior of a physical space. The system controls that space by enabling infinite combinations of instructions. Each grouping of instructions is stored as a mission. When the mission is executed, the system processes each of those instructions on a physical space and solicits inputs from a player working through that mission in that space (zone). The scalability of the system arises from the fact that a mission can be broken down to its base elements and codified with attributes in such a way that the mission can be executed at any zone with space characteristics that match those mission attributes. Nearly infinite distinct zones can also be configured to allow the execution of a single mission at any of those physical places, as long as the place is configured as a zone that has the appropriate rooms and devices.
The illustrated computer-based memory and processing device 112 has a computer-based processor 1202, a computer-based storage device 1204, a computer-based memory 1206 with software 1208 stored therein that, when executed by the processor 1202, causes the processor to provide functionality to support system 100 operations as described herein, input and output (I/O) devices 1210 (or peripherals), and a local bus, or local interface 1212 that allows for internal communication within the computer-based memory and processing device 112. The local interface 1212 can be, for example, one or more buses or other wired or wireless connections. In various implementations, the computer-based memory and processing device 112 may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to facilitate communications and other functionalities. Further, the local interface 1212 may include address, control, and/or data connections to enable appropriate communications among the illustrated components.
The processor 1202, in the illustrated example, is a hardware device for executing software, particularly that stored in the special software in memory 1206. The processor 1202 may be custom made and may be a single core or multi-core processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the present server 102, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions. In addition, the processing function can reside in a cloud-based service accessed over the internet. The processor can include one or more processing devices and may be geographically distributed.
The memory 1206 can include one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and/or nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory 1206 may incorporate electronic, magnetic, optical, and/or other types of storage media. The memory 1206 can have a distributed architecture, with various memory components being situated remotely from one another, but accessible by the processor 1202.
The software 1208 includes one or more computer programs, each of which contains an ordered listing of executable instructions for implementing logical functions associated with the computer-based memory and processing system 112 (or computer system), as described herein. The memory 1206 may contain an operating system (O/S) 1240 that controls the execution of one or more programs within the computer-based memory and processing system 112, including scheduling, input-output control, file and data management, memory management, communication control and related services and functionality.
The I/O devices 1210 may include one or more of different types of input or output device. Examples include a keyboard, mouse, scanner, microphone, printer, display, etc. In some implementations, a person having administrative privileges, for example, may access the computer-based processing device to perform administrative functions through one or more of the I/O devices 1210.
In a typical implementation, the computer-based processing device 1206 also includes a network interface (not shown in
As part of the system's content, a creator might devise the following and configured it into the system with the purpose of teaching the mathematical concepts of Pythagorean Theorem, and multi-variable algebraic equations.
Plot—Mankind is searching to evolve. The secrets to our further evolution were scattered throughout the solar system by an alien life form. On 4 planets there are 4 keys to enhancing our DNA that would let us evolve to a higher state of cognitive thought. The first person to gather these 4 keys and inject them into their DNA will instantly evolve to that higher state. You have been chosen to embark on a Quest to gather these 4 keys.
The first key is on Earth in an Egyptian Pyramid (a zone). The first mission is to move through 2 rooms of an ancient pyramid to recover the key which is in a coffin in the second room.
The objective of the first room is to solve a math problem the components of which are gathered from within the room. Finding each value (task) enables the solving of the math problem. The solution is needed to open the door to the next room. The objective of the second room is to open the coffin and recover the key. Upon solving the math problems, the player submits a challenge response to the system which evaluates for correctness. Players prepare for the Mission, by reviewing training materials (instructional web sites, texts and documents) before beginning the Mission.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention.
For example, missions have been described herein as being associated with training materials, with the aim that the participants in a mission will need to illustrate an understanding of the training materials in order to advance through certain parts of or complete the mission. However, missions are not necessarily associated with training materials. In some implementations, a mission might simply represent a game that does not include any training materials and/or might be solely for entertainment purposes. In those instances, knowing something about how to solve a challenge may be critical, but if the player already knows that information (e.g., without having consulted specific training materials for the mission), then the enjoyment factor of completing the mission may become more focused on the physical aspects of completing the challenge.
Additionally, the computer system associated with a specific physical zone can have any one of a variety of specific configurations. For example, a given system might have any number of creator terminals, any number of player terminals, any number of zone manager terminals, and other terminals or components. The computer-based memory and processing system can have any number of computer-based memory devices and any number of computer-based processors. These can be housed in a single housing and/or at a single location, or can be physically distributed.
The information to specify a mission or a zone can vary significantly—being far more detailed than disclosed herein or far more general.
In various implementations, one or more of the devices disclosed herein may be configured to communicate wirelessly over a wireless communication network via one or more wireless communication protocols including, but not limited to, cellular communication, ZigBee, REDLINK™, Z-Wave, Bluetooth, WiFi, IrDA, dedicated short range communication (DSRC), EnOcean, and/or any other suitable common or proprietary wireless protocol.
In some implementations, certain functionalities described herein may be provided by a downloadable software application (i.e., an app), or be accessed on a website.
In various embodiments, some of the subject matter disclosed herein can be implemented in digital electronic circuitry, or in computer-based software, firmware, or hardware, including the structures disclosed in this specification and/or their structural equivalents, and/or in combinations thereof. In some embodiments, the subject matter disclosed herein can be implemented in one or more computer programs, that is, one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, one or more data processing apparatuses (e.g., processors). Alternatively, or additionally, the program instructions can be encoded on an artificially generated propagated signal, for example, a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or can be included within, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof. While a computer storage medium should not be considered to include a propagated signal, a computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media, for example, multiple CDs, computer disks, and/or other storage devices.
Some of the operations described in this specification can be implemented as operations performed by a specially-programmed data processing apparatus (e.g., a processor) on data stored on one or more computer-readable storage devices or received from other sources. The term “processor” encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.
While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
Similarly, while operations are depicted in the drawings and described herein as occurring in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
Some of the computer-based user-accessible functionalities associated with the system disclosed herein can be accessed from different kinds of electronic computer device, including, for example, cell phones and tablet.
The disclosure herein refers to players and participants. It should be understood that, whether these terms are used in the singular form or plural form, the meaning should be construed broadly to include both or either.
Other implementations are within the scope of the claims.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/694,227, filed Jul. 5, 2018, entitled “SYSTEMS AND METHODS FOR MANIPULATING THE SHAPE AND BEHAVIOR OF A PHYSICAL SPACE,” which is incorporated by reference herein in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2019/039841 | 6/28/2019 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62694227 | Jul 2018 | US |
