WO2017222774A1 - System and method for disrupting expected group performance in digital environments - Google Patents

Abstract

To change anticipated outcomes for users within digital environments, a systematic approach may dynamically disrupt progress or create an augmented or diminished degree of challenge for the users. A trigger may be identified which indicates a disruption or augmentation of the users' probability of success in the environment is currently desirable. A current state of the digital environment may be determined, and a plan may be generated to, upon execution, modify a user-group's probability of success by altering the current state of the environment through disruptions, augmentations, or both. In some cases, a plurality of users may be partitioned into subgroups, where a plan for each subgroup may be distinct from other subgroups. In some cases, a plan may "teleport" a user from a first session in the digital environment to a second session, in order to affect a probability of success in one or both sessions.

Description

SYSTEM AND METHOD FOR DISRUPTING EXPECTED GROUP

PERFORMANCE IN DIGITAL ENVIRONMENTS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C. §119(c) from, U.S. Provisional Patent Application Serial No. 62/353,257, filed June 22, 2016, entitled "SYSTEM AND METHOD TO AFFECT EXPECTED GROUP PERFORMANCE IN DIGITAL ENVIRONMENTS THROUGH PLANNED DISRUPTION, AUGMENTATION AND TELEPORTATION", which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] This disclosure relates to systems and methods for digital environments. More specifically, this disclosure relates to systems and methods for improving user engagement with digital environments.

BACKGROUND

[0003] Digital environments (DEs) - e.g., multiplayer games, massively multiplayer online role playing games (MMORPG), immersive video games such as those experienced through stereoscopic head-mounted displays, team based learning applications, and others - strive to provide players with satisfying experiences. For example, challenge-level (or difficulty) should be "just right". When only a single player is involved, the DE can be fairly easily adapted to pose a suitable challenge.

[0004] Designing DEs that engage users is a significant concern of almost every application (referred to as an "app" henceforth) in a managed app ecosystem (e.g., Google Play,

Amazon Store, etc.) (see, e.g., M.D. Dickey, "Engaging By Design: How Engagement

Strategies in Popular Computer and Video Games Can Inform Instructional Design",

Educational Technology, Research and Development; 2005; 53, 2; Academic Research

Library, pg. 67, 2005; R. Koster, Theory of Fun for Game Design (2nd Ed.), O'Reilly Media,

New York, 2013; T. Fields, Mobile & Social Game Design, Monetization methods and mechanics, CRC Press, New York, 2014). Engaging users refers to the act of holding both their interest and focus for the purposes of:

entertaining them (e.g., gameplay that meets expectations) challenging them and/or promoting learning (e.g., improving their standing or understanding)

monetizing them (e.g., in-app sales) and/or

increased social networking (e.g., shares and mentions in social media; this is also, ultimately, monetization)

[0005] Without sufficient engagement, players are less likely to use the DE for long periods (for example, on mobile platforms this is characterized by quick uninstall times, sometimes referred to as "churn") which undermines the advertising model (in which longer in-game sessions comprise valuable "eyeball time" for in-app advertisers), undermines opportunity for in-app purchases, and so on. Negative or neutral views of the DE, such as those fostered by unengaging sessions, will not result in positive social media shares either. It is clear that engaging users just up to - but not too much beyond - their capabilities is important, relevant, and difficult (see P. Sweetser et al., "Revisiting the Gameflow model with detailed heuristics", Journal: Creative Technologies, 2012(3)).

[0006] Prior work exists relating to "A|B testing". A|B testing is an established way to test two variants of an app vis-a-vis a particular outcome. Current mobile analytics tools generally enable developers to fairly easily instrument and deploy multiple app-variants for subsequent study.

[0007] Mobile analytics services such as those offered by Taplytics, Flurry, Facebook, and Google, provide a means to gather and analyze in-app events at a fine-grained level. Analytics based on gender, age, demographics, location can be combined into filters. For example, Flurry can segment users into Personas (movie-lover, dreamers, sports-fanatics, etc.) based on their app history; subsequent campaigns can then target each such segment using a different strategy.

[0008] Some past work has attempted to classify users by their behaviors through machine learning and other techniques (see, e.g., A. Drachen et al., "Guns, Swords and Data: Clustering of Player Behavior in Computer Games in the Wild", Proc. IEEE CIG' 12, 2012; Bartle, Richard (1996) "Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs" The Journal of Virtual Environments, 1(1)).

[0009] In the context of multiplayer video gaming, a line of research attempts to detect and anticipate "toxic" behavior of players in DEs and mitigate their negative effects (see B. Maher, "Can a video game company tame toxic behavior?" Nature, 531, 568-571, 31 March 2016). This has come to the fore as virtual worlds become larger, contain more and more players, and become more "open" through enabling many types of behaviors. Case studies have shown that "toxic" behaviors by only a few participants can have a negative effect on the experience of others. Similarly, a player who differs greatly in in-app skills from other in-app group participants can have a negative, disruptive, or distracting effect on the experiences of others.

[0010] The present disclosure addresses these and other issues.

SUMMARY

[0011] Embodiments disclosed herein provide a systematic approach to adjusting the challenge level in a DE in which a group of players is playing simultaneously. The approach goes beyond simply examining the median level of capabilities and skills. By better taking into account the group outliers (e.g., the "strongest" individual player), one can introduce new DE entities that, taken together and experienced by the group, will affect the group's probability of succeeding in the level. The system may then attempt to ensure that the aforementioned probability remains neither too high nor too low. This disclosure relates to concepts involving real-time in-app event processing (see S. Loeb et al., "Just-in- time Reconnaissance and Assistance for Video Game Streams and Players", Proc. IEEE Consumer Communications and Networking Conference (CCNC' 16), Work-in- Progress Track, Las Vegas, 2016), systematic analysis and comparison of user profiles, and systematic estimation and disruption of in-app performance by leveraging same.

[0012] In this disclosure the terms participant, user, player, and gamer are used to stand for the notion of the in-app representation of a human player. An in-app player controlled by an algorithm can be referred to as an enemy, adversary, or bot. More broadly, the terms in-app entity and element can refer to any human or algorithmically driven in-app player, object, or challenge. The term group is used describe a coalition of players playing with or against in-app entities who are all simultaneously in the same DE session trying to succeed. Success can include finishing the level by defeating all adversaries, solving all challenges, or might hinge upon some other end conditions. The term Order is used to mean the probability of success in a DE. Order may be a probability value in the range 0 to 1.0, so that if a group stage of a DE has Order equal to 0.9 then there is a high probability that the group will eventually succeed (with 1.0 being certainty), however if the Order of the group level is near 0 then there is a much lower probability of eventual success.

[0013] The systems and methods disclosed herein enable DEs to be systematically adjusted so as to offer a different level of challenge (or other attribute) to participants within it. In one embodiment, the method partitions users who are in a group and creates an asymmetric attack plan that is expected to reduce the group's probability of success by some degree. The current art may simply create an adversary plan that considers only the average level of competence of the group. As disclosed herein, a method for considering - and targeting - the nature of individual players may achieve superior, more targeted performance, as well as increased player satisfaction. The so-called attack plan is a series of steps taken by the framework, each affecting the DE and one or more players in it in some way, with the total goal to affect a group's Order in the DE level. In other embodiments, the systems and methods have applicability to different realms beyond multi-player gaming. Multi-user video conferencing applications are one such realm.

[0014] In an embodiment, there is a method comprising: identifying at least a first trigger for disrupting a group order associated with a plurality of users in a digital environment; determining a current state of the digital environment; generating a disruption plan to modify the group order by altering the determined current state of the digital environment; and executing the generated disruption plan to modify the group order in the digital environment.

[0015] In some embodiments, there may be a system comprising a processor and a non- transitory storage medium storing instructions operative, when executed on the processor, to perform functions including the methods set forth above and herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, wherein:

[0017] FIG. 1A illustrates an exemplary timing diagram for one embodiment of an augment-disrupt plan deployment.

[0018] FIG. IB illustrates an embodiment of an augment-disrupt plan deployment.

[0019] FIG. 2 illustrates a flowchart for one embodiment of implementing an augment- disrupt plan.

[0020] FIG. 3A illustrates a timing diagram for one embodiment of a teleportation plan sequence.

[0021] FIG. 3B illustrates an embodiment of a teleportation plan sequence.

[0022] FIGS. 4 A and 4B illustrate exemplary GUI for user interaction during a teleportation sequence.

[0023] FIG. 5 illustrates a flowchart for one embodiment of implementing a teleportation sequence, including GUI interfaces. [0024] FIG. 6 illustrates an exemplary embodiment of the present disclosure in relation to JumpStart.

[0025] FIG. 7 illustrates an exemplary embodiment of relationships between actors in the present disclosure.

[0026] FIG. 8 illustrates another exemplary embodiment of relationships between actors in the present disclosure.

[0027] FIG. 9 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed in some embodiments.

[0028] FIG. 10 illustrates an exemplary network entity that may be employed in some embodiments.

DETAILED DESCRIPTION

[0029] A detailed description of illustrative embodiments will now be provided with reference to the various Figures. Although this description provides detailed examples of possible implementations, it should be noted that the provided details are intended to be by way of example and in no way limit the scope of the application.

[0030] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non- transitory computer-readable medium or media, such as commonly referred to as RAM, ROM, etc.

[0031] Some terms that will be used throughout the disclosure, particularly in relation to game based embodiments, are set forth here.

[0032] Digital environment (DE) - a session involving a computer-based information or entertainment system such as an online video game, a massively multiplayer online role playing game (MMPORG), an immersive app experienced through stereoscopic headset and virtual reality, an app on a mobile device, a video sharing/conferencing application, or the like. Some types of environments, notably single-player ones, are not good candidates to benefit from the systems and methods of this disclosure. These include single player apps (e.g., chess) and completely offline apps such as photo editing.

[0033] Event Pattern Detection Engine (EPDE) - a system that implements complex event processing. Complex event processing combines data from multiple sources (see Schmerken, Ivy (May 15, 2008), Deciphering the Myths Around Complex Event Processing, Wall Street & Technology) to infer events or patterns that suggest more complicated circumstances. Complex event processing operates to identify meaningful events (see John Bates, "Secrets Revealed: Trading Tools Uncover Hidden Opportunities", Fix Global Trading, June 15, 2011) so as to allow a rapid response to such events.

[0034] Profile Management Framework (PMF) - a system that creates and manages multidimensional models of users (human or possibly non-human), and offers its data as a software service through an Application Program Interface.

[0035] Order - Estimation of the probability of success of a given group in a given DE. In one embodiment Order is represented as a floating point numerical value in the range [0-1] where 1.0 is "almost certain to succeed" and 0.1 is "unlikely to succeed". For example, in a multiplayer combat game, the Order of a group containing several highly armed players in a relatively simple combat level would likely be near 1.0, whereas the Order of a group of inexperienced players in a level containing enemies with very strong protective shields would likely be near 0. Order may be computed in any number of ways that are immaterial to this invention. For example, in some multiplayer role playing game each character may have a "skill" or "points" count (in one or more category such as strength, endurance, speed, etc.). Given 4 players and a level L, an admin may compute the order of the players in L by mapping the sum of the point count of the players to a table of probabilities of successes (e.g., total of 400 or more points might map to 80-100% probability, while 200-400 count may map to 70- 80%, and so on).

[0036] Challenge level - a representation of the degree of difficulty posed by a DE.

[0037] Disruption - a set of new elements and/or new behaviors transmitted into a DE that when played out can modify the present Order. An example of an element (also referred to as entity) could be a new monster character in a battle game. An example of a behavior could be a new sequence that performs a particular task well, such as an accurate shot of a bow-and- arrow.

[0038] Augmentation - a set of usually increased (but in some instances decreased) capabilities provided to adversaries or increased difficulty given to riddles or levels or other entities in the DE. An augmentation affects the present Order within the DE.

[0039] Teleportation - the act of moving one or more players from a particular game and level (source) to a different game and level (destination). Teleportation may be preceded by a series of GUIs allowing the player some input and/or control (e.g., Ok', 'cancel') over the subsequent operations. Typically, since the presence of players, combined with their skills, has an impact on the probability of success, a goal of teleportation may be to change the Order of the source and/or destination levels in some desired direction (e.g., increase or decrease).

[0040] GameSpace - a descriptor that uniquely points to a particular live instance of a particular game, or other digital environment (and optionally the set of players or users presently involved). A GameSpace identifier might take one of various forms including (not limited to): a) Session ID - some globally unique session id, or b) a tuple: <game-id, game- served - a live session of a game-id G on game-server S.

[0041] Asymmetric proactive disruption-augmentation calibration. One embodiment disclosed herein revolves around the idea of sensing the need to change the Order of the level (e.g., probability of success), creating and implementing a disrupt-augment calibration plan, and verifying the results. For example, an explanation of this method in practice may be as follows.

[0042] A trigger initiates the need for a new plan within the DE to proactively calibrate the Order. Next, the current state of the DE is examined, which may include examining and quantifying the current set of game players, player-profiles, and other in-game entities such as non-player characters (NPCs), and the like. Further, the analysis of player profiles may allow players to be partitioned into groups (group size can be 1) according to skill (or some other factor) such as: (high-skilled(strong), average-skilled, weakly-skilled(weak)}. In some embodiments, user-skill may represent a user's calculated capability to affect the digital environment and/or to succeed in the face of a given challenge. Next, an augment-disrupt plan PL is created, and a unique ID (UID) is associated with the plan. All subsequent in-game events in the game may be tagged with these identifiers to allow for analysis. A PMF may be consulted during plan creation. Within the devised plan PL, augmentation actions may include those that introduce new slightly stronger enemies into a DE that will "occupy" only the strong players in group G (or in some instances a negative augmentation to weaken an enemy to occupy one or more players). Within the plan PL, disruption actions may include those that introduce an additional problem-solving challenge to a weaker player (WP) that requires the player to coordinate with several others. The overall goal of the plan PL is to decrease the Order, thereby delaying (or possibly stifling) success, increasing challenge, and increasing in-app time. Next, the plan PL is executed over a period of time during which all in-app events are tagged with UTD and sent to the EPDE. As it is executed, the plan PL may occupy strong and weak players with new Elements designed to decrease local Order, and may encourage certain players to take actions that they rarely take, or that they find difficult or unfamiliar (these aspects may be discovered by referencing the players' gameplay histories and profiles in a PMF). At some later time the plan PL terminates, such as for example at some threshold of event counts, at some specific time of day, or after some specific set of in-app events are seen, or the like. If executed effectively, the plan PL may have an effect on the Order of the game, in some cases a decrease in the Order such that the group is less likely to achieve success, delayed from achieving success, and/or the like. The post-conditions of the plan PL should be a DE that is different than it was before the plan (the individual elements of the plan should be in concert with the overall goal of the plan whether it is to, for example, increase or decrease the Order).

[0043] Generally, such methods may create and execute a calibration that affects the Order. An asymmetric approach which sometimes addresses individual players with separate affronts may be most effective due to the varying skills of the individuals in the DE.

[0044] It is assumed that there exists some trigger for initiation of the flow described above (which results in the creation and execution of a plan to affect the Order). It is not material to the method herein exactly what that trigger is, but it may be one of (but is not limited to) the following:

an event resulting algorithmically from ongoing analysis of game state by a realtime back-end system such as JumpStart (see FIG. 6);

an output of an ongoing real-time analysis of a state of the DE;

an event generated at random times designed to occasionally affect game Order; an event generated manually by a system administrator or 'super user' player; an event sequence that matches a pre-defined pattern in terms of either all/some of the events present in the sequence, a time interval between the first and last events in the sequence, event attribute values, or any combination thereof. [0045] The trigger may use a syntax such as XML or JSON, and may carry a semantic that encodes meaningful information such as an imminent need to start the method described above. Triggers may be exchanged between software system components, and interpreted correctly at each step. A trigger's source may be on the same physical system or may originate on a remove system accessible via a network.

[0046] The lifecycle of a trigger may be as follows. A DE system may identify a trigger indicating a need to disrupt a group order associated with a plurality of users in a given DE. The system may determine a current state of the DE. Based on the determined current state of the DE, the system may generate a disruption plan to modify the group order by altering the determined current state of the DE. Once the disruption plan is generated, it may be executed to modify the group order in the DE.

[0047] In some embodiments, determining the current state of the DE may comprise examining DE elements and the users of the DE, including user profiles, such as with a PMF.

[0048] For example, as illustrated in FIG. IB, there may be DE in which there are four players (150a, 150b, 150c, 150d) in a level (155). The system may estimate that - given the individual and group skill sets in this specific set of four players - the Order of this group (probability of success in this level) is, for example, very high. To mitigate this the system may devise a disrupt-augment plan by first partitioning (160) the players into sub-groups (162a, 162b, 162c) corresponding to profile attributes (such as skill, accuracy, sociability, etc.) and then creating asymmetric challenges for each sub-group (166, 167a and 167b, and 168) (such as asymmetrically introducing new DE elements). Typically, the partitioning (160) may use a single classification attribute to partition players into logical sub-groups, such as user-skill (e.g., high, medium, low, etc.). However, any method resulting in a useful set of player subgroups (based on one or more attributes) may be valid. In some embodiments, user-skill may represent a user's calculated capability to affect the digital environment and/or to succeed in the face of a given challenge.

[0049] In one case (step 165), the players of strongest skill in the group (e.g., partition 162a with player 150c) may be given augmented enemies 168 to battle, the players of medium skill (partition 162c with players 150a and 150d) may be given enemies 167a and 167b with tricky or possibly unforeseen skillsets of their own to battle, while a player whose profile indicates, for example based on a historical average, that she is a "quiet" non-interactive player (partition 162b with player 150b) (e.g., rarely uses real-time player chat capabilities) may be given a challenge 166 that requires her to use such chat interactions to complete. In another embodiment, the challenge 166 may comprise a riddle or other challenge type that disrupts the player's usual style, such as by requiring interaction with other players. During the time-period of this asymmetric challenge the system may re-estimate the Order of the level and finds that it has decreased, thus the level plays out as per the Plan.

[0050] In some embodiments, a disruption action may comprise posing to a partitioned group a new challenge that requires the partitioned group to perform an action, wherein the action is selected as falling below a threshold number of occurrences for the partitioned group based at least in part on historical user profiles (such as those evaluated by a PMF). In some embodiments, the disruption action may comprise posing to a partitioned group a new challenge that requires that the partitioned group perform an action, wherein the action is selected as exceeding a threshold degree of difficulty for users in the partitioned group. In still other embodiments, a disruption action may comprise posing a new challenge to a partitioned group that requires the partitioned group to coordinate a response with at least one other user (for example, another user not in the partitioned group, or in some embodiments another user in the partitioned group).

[0051] FIG. 1A illustrates a timing diagram for a successful Plan deployment in one embodiment. In FIG. 1A, a Service S may implement an embodiment of a method described herein. A Game G may interact with the Service S via events and triggers. Events describing specific player actions may be sent by G to S (via integration with a software development kit or some other mechanism). S may send (e.g., as a response to events sent by G to S) triggers corresponding to augmentation and disruption activities to G once a plan is generated after analyzing received events. Once the plan is executing, Service S may monitor the session, and Game G may send further in-game events or status updates to Service S. Service S may evaluate the effect of the augmentation and disruption activities which have been put in place under the plan, and Service S may update or terminate the plan as needed. For example, Service S may determine that a monster introduced in an augmentation step did not pose as difficult a challenge as previously predicted, and so under an updated plan, Service S may instruct Game G to increase the strength and hit points of the monster.

[0052] In the embodiment shown in FIG. 1A, players A, B, and C may join the Game G. The Game G may then send session info to the Service S. Players A, B, and C may experience gameplay interaction for a period of time, after which the Game G may communicate in-game events and/or current game state to the Service S. At some point, the Game G may determine or receive a trigger for a new augmentation or disruption plan, which is communicated to the Service S. The Service S may then generate a new plan, and in accordance with the new plan may communicate disruption events and/or augmentation events to the Game G. For example, responsive to augmentation and disruption events received from the Service S, the Game G may present a disruption challenge to Player B and introduce an augmented enemy to Player A. With these augmentation and/or disruption events in place, the players may continue their gameplay interaction, and the Game G may continue to update the Service S as to in-game events and/or the in-game state. The Service S may responsively evaluate the effectiveness of the plan that was implemented, and in some instances may update the plan as necessary (e.g., introduce additional augmentation / disruption events into the Game G).

[0053] FIG. 2 illustrates the methodology as a flowchart showing the main steps and sub- processes. Creating a plan for augment-disrupt may involve additional steps including, but not limited to: taking inventory of the salient entities or elements (e.g., players, non-player entities, etc.) presently in the DE; partitioning users into sub-groups according to one or more criteria (such as skill level as determined and specified in a PMF); selected targeting of some of the partitions for asymmetric disruption-augmentation; and/or the like.

[0054] Taking inventory of the salient entities or elements presently in the DE can be achieved by analyzing received events and any additional information that may be available about the DE. In practice, a game engine (e.g., the software driving and managing the DE) is- instrumented so as to support queries over regions of the underlying game state. Plan creation can utilize past information associated with previous plans for similar DE state, current Order, and user profiles, and/or the like. Tagging of events associated with a specific plan can be done by the game or the service prior to performing any analysis or processing by EPDE. Tagging may involve the addition of a specific event attribute containing a value that uniquely identifies the plan (e.g., unique plan ID). A series of similar-tagged events may then be examined post- hoc together with a historical state of the DE in order to understand the effectiveness of the Plan indicated by the tag, from a quantitative perspective.

[0055] Maintain Challenge level via Systematic Teleportation. Another embodiment of the present disclosure for maintaining challenge is achieved via systematic "teleportation." In these embodiments, the system chooses the right moment and the right set of players to "teleport" in and out of various groups so as to affect the Order in a particular way. Such player "teleportation" may happen only at amenable times, to amenable target GameSpaces, etc., and may optionally in some embodiments be accompanied by a set of GUI screens for providing a streamlined and informative user experience to the affected groups and players (e.g., the player may choose not to be transported). Additionally, part of the server/system/infrastructure may be used to track the state of each game in near real-time as to its amenability to accept or perform teleportation. For example, the triple below could point to game state information needed as a basis for teleportation:

<GameSpaceID, ArrayOf<PlayerProfiles>, amenability-flag> where: GameSpacelD describes a unique endpoint in game-space such as a particular session of a particular game (in the case of multiple hosted games and multiple hosted sessions - see "Game Session" in FIG. 7), ArrayOf<PlayerProfiles> describes the current set of players in the game in terms of their profiles, and amenability-flag (true/false) describes whether it is appropriate at this time for this game to accept teleportation. In one embodiment, such a flag may be determined at least in part by examining the current Order in the GameSpacelD, and if, for example, it falls into some numeric range (e.g., between 0.85 and 1.0) then the flag may be set to true - indicating a GameSpace in which the probability of group success is presently too high.

[0056] A triple may be saved in a DE and can be the basis for determining teleportation at various times. In an exemplary case, a teleportation action could then be described as:

Teleport <PlayerProfile, Source GameSpacelD, Destination GameSpaceID>

[0057] In one embodiment of the teleportation method there may be two separate GameSpaces, and the process may result in two (or more) players being exchanged between them via teleportation, with each player ending up in the others' original GameSpace. FIG. 3 A illustrates one embodiment of a timing diagram for a successful teleportation sequence. In an embodiment, Players 1 and 2 may join a game session in GameSpace G (305a). At the same time, using the same Service S, Players 3 and 4 may join a game session in GameSpace H (305b).

[0058] At some point, the system (Service S) may monitor (310a) the game state of a first DE (GameSpace G) and determine if it is amenable to teleport (315). If so, the system may derive the requirements for an inbound player. The system may also monitor the game state of the second DE (GameSpace H) (310b), and determine if it is amenable to teleport (315). If so, the system may derive the requirements for an inbound player to the second DE. In some embodiments, player requirements may be represented with a keyword value mechanism in JSON or XML syntax (or the like) using a catalog of terms from a datastore.

[0059] If both GameSpaces are amenable to teleport (315), the system may search for players to teleport between them. The system may also estimate the effects of teleportation(s) on group capabilities in one or both of the DEs. For example, the system may estimate whether the Order of a group in one DE or another DE will increase or decrease as a result of the teleportation, and by how much. In some embodiments, if the anticipated effects on the Order of the two GameSpaces does not meet some criteria or threshold, a planned teleportation may be suppressed or otherwise canceled. The system may identify players which, if teleported, will have a desired effect on the capabilities of the groups or on the Orders of the groups in one or both DEs (320). Once appropriate players are identified, the system may finalize a teleportation plan which may then be implemented. For example, the system may send a request (325) to teleport Player 2 out of GameSpace G, and a request (330) to teleport Player 3 out of GameSpace H. In some embodiments, during implementation, the human user(s) may see and/or interact with a control GUI, such as to enable the user(s) to accept or decline the planned teleportation. In some embodiments, if one of the players declines the teleportation, it is canceled for both players.

[0060] In some embodiments, one or both DEs may be paused or suspended during - or from moments before - the teleportation process. In some embodiments, such pause or suspension may be to ensure session consistency.

[0061] The players are either teleported between DEs, or both accept the teleportation and are then teleported between DEs. This results in "teleporting" Player 2 from GameSpace G to GameSpace H (335), and "teleporting" Player 3 from GameSpace H to GameSpace G (340). In some instances, such as where the DE is paused or suspended during teleportation, the DE may then resume.

[0062] The system may then receive metadata updates from both GameSpaces (345a, 345b), and gameplay may continue for both GameSpaces, with the newly arranged players (350a, 350b). At some point, the service may continue monitoring the sessions in both GameSpaces (355a, 355b).

[0063] In some embodiments, after some period of time and/or gameplay, the teleportation(s) may be un-done whereby one or more teleported players are returned to their pre-teleportation GameSpaces. In some embodiments, this reversal of the teleportation may occur with a GUI interface for the involved players, as in the initial teleportation.

[0064] FIG. 3B illustrates another embodiment of a successful teleportation plan execution. There may be players 365, 366, and 367 in a first GameSpace, and players 368, 369, and 370 in a second GameSpace. If the first GameSpace is amendable to transport, the system may derive the requirements for an inbound player to the first GameSpace. After finding the second GameSpace which is amenable to teleport, the system may derive requirements for an inbound player to the second GameSpace. The system may then search the two GameSpaces for appropriate or suitable players, and estimate the effects of one or more teleportations on group capabilities in each GameSpace. After suitable determinations, the system may negotiate and finalize a plan for the GameSpaces. The teleportation plan may then be enacted. In an embodiment, the teleportation plan may result in a player 366 from the first GameSpace teleporting with a player 370 in the second GameSpace. In some embodiments, the players may be presented with or otherwise interact with a control GUI for the teleportation, such as to confirm the teleportation. Once the players have teleported, the system may resume the gameplay in each GameSpace, in embodiments where gameplay was paused during the teleportation. In some embodiments, after some period of time and/or gameplay (or the like), the system may undo the teleportation, such as with an optional GUI.

[0065] FIGS. 4 A and 4B illustrate an embodiment of an optional GUI that allows a teleportation to be undone or prevented. FIG. 4A illustrates the essence of such a GUI allowing the player teleported to first allow or not allow the teleportation and then after teleportation, as in FIG. 4B, to choose whether to remain in the new GameSpace or to return to his original GameSpace.

[0066] FIG. 5 is a flowchart for one embodiment of a teleportation method. The flow starts when a particular GameSpace X is ready to be involved in a teleportation (505) - for example, an analysis of X has determined that the Order (e.g., probability of success) is too high and an increased challenge would be beneficial. The System may initiate a process for metadata to evaluate teleportation conditions (510), such as deriving the requirements describing the type of player desired for the inbound teleportation (511) (e.g., this might be described in terms defined by the PMF) as well as similarly describing the set of player profiles corresponding to candidates for outbound teleportation from X (512). Such elements may then be written as metadata (513). The system may then try to identify a set of other GameSpaces to query (515) that satisfy basic requirements for the teleportation(s). If no other GameSpaces are satisfactory, then the process may end (560). If there is at least one potentially satisfactory GameSpace, the GameSpace(s) may be further analyzed. If a player within a GameSpace N meets the inbound requirements for X (520) and a player in X meets the inbound requirements of that GameSpace N (525), then a 2-player teleportation may be made (520) and play may resume (e.g., GameSpaces are "unpaused"). If players between the two GameSpaces fail to satisfy the respective inbound requirements, a next GameSpace may be considered (535), if available. [0067] After the teleportation, the relevant metadata may be update or otherwise written to reflect the teleportation (540).

[0068] After some threshold of time, events, or any other appropriate condition, a GUI may optionally be presented allowing the teleportation to be un-done (545). In some embodiments, any subset of the teleported players may be provided with the option to undo (550) their teleportation although the most natural use case would be if two players are teleported (or exchanged) and then both subsequently want to 'un-do' this step. Such a step may put some control back into the players' hands. If at least one player selects to undo, then the teleportation may be undone (555), otherwise the teleportation may be left in place and the teleportation process may conclude (560).

[0069] The disclosed systems and methods may have the two main arcs as described above. Note that in practicality the system may be embodied as a software module running in a centralized (and/or replicated) server, or running on the client-side in the case of a client-server deployment. Favorably, the module has network connectivity but it is possible that it could be run in a limited sense without such connectivity. Optimally, the module connects and communicates with PMF, EPDE which - in most architectures today - are likely to be offered as network services. The disclosed systems and methods can be deployed as a capability of (and making use of) the JumpStart components (see S. Loeb et al.). FIG. 6 shows one embodiment of JumpStart and how functions described in this disclosure map to it. The functionality that enables the systems and methods is shown as components grouped logically in the dashed 'box'. These functions might reside on the end user device (mobile, desktop or other) or on a server such as the JumpStart server (see S. Loeb et al.).

[0070] The above systems and methods are likely to be preceded by a business and technical agreement between the business entities participating in the ecosystem. These might include, but are not limited to, game portal operator, game developer, mobile handset operator, etc. FIG. 7 illustrates an embodiment of likely relationships between the actors in the systems and methods. Note that a particular augmentation/disruption plan affects a single Game Session entity and at least one player. In contrast, a teleportation plan affects at least two Game Sessions and at least two players.

[0071] To seed the interactions enumerated in this disclosure the following exchanges may occur:

- Developer D implements hooks to enable teleportation; - Developer D instruments G to emit in-app events to System, including a syntax and semantic for the information;

System is reachable over the network (or is local to Game G).

[0072] The following describes the simple steps in setting up and realizing the benefits of the systems and methods in this disclosure, with reference to FIG. 8.

[0073] In one exemplary use case, a developer Dl may instrument their multiplayer game Gl to work with the disclosed systems and methods which are offered by service S (running on one or more servers in an enterprise network or cloud infrastructure), which is owned and run by company C.

[0074] For example, a process flow may be as follows:

- Dl and C communicate and agree that C's technology may help improve engagement of players (A, B, C, D) within Gl;

C informs Dl how to instrument Gl so that the necessary information will flow to S. Optionally, some or all of C's technology is incorporated directly into the logic of Gl . The mechanism allowing the logic to Gl to interwork with S is likely encapsulated within a Software Development Kit (SDK) which exposes the methods required for interworking (see S. Loeb et al.);

- Dl decides how and under what circumstances within Gl it will employ C's technology;

Gl is deployed and distributed users play the game;

C's technology is invoked to improve player-engagement during gameplay of Gl, which Dl comes to understand via reports, statistics, or other metadata provided by C.

[0075] In some embodiments, a second developer D2 may work with C to help improve the engagement of players (D, E, F, G) within multiplayer game G2. As with Dl, G2 may be instrumented by D2 for information flow to S. G2 is deployed and distributed to users who play the game. C's technology is invoked to improve player-engagement during gameplay of G2, which D2 comes to understand via reports, statistics, or other metadata provided by C.

[0076] In some instances, a player, such as Player D, may interact with more than one game, such as Gl and G2.

[0077] The systems and methods of the present disclosure can be applied in domains other than gaming; indeed, several domains wherein multiple participants interwork in collaboration over a network are good candidates to benefit from the systems and methods. In particular, the present disclosure may be beneficial to video sharing applications such as: Google Hangouts, Slack video, Tango, Viber, Airtime, Houseparty, and others. In today's video hangout apps multiple participants use their mobile phones (or laptops, tablets, or the like) to engage in ad hoc meetups in which live video of all participants is captured via the device camera, all participants see all others, send messages, talk, and use in-app features such as broadcasting emoji, pictures, or others. Therefore, there is a notion of engagement that is a function of all possible interactive features of the app and how they are used by participants (for example, low engagement might be indicated by infrequent usage of features beyond the video stream itself).

[0078] In a video sharing realm, the general methodology holds, however some of the terminologies in the above figures and flowcharts may change so that they reflect this new realm. The "digital environment" (DE) would instead be a video sharing session, and these other notes apply:

- Engagement - this becomes the attribute that the system could affect by disrupting or augmenting. Engagement in video sharing can be thought of as a function of the cumulative events occurring within the app such as (but not limited to): inserting an emoji into the session, making a side textual comment, moving the camera, gesturing, and so on.

Order - this becomes the probability of engagement, where high order implies better (e.g., deeper or more frequent) engagement and low order implies low (e.g., shallower or less frequent) engagement.

- Plan - the notions of Augment and Disrupt may apply in video sharing as "amplify" and "mute" (this is just one possible way they apply), meaning that a plan can attempt to, for example, amplify a participant (e.g., by giving her more tools to be heard and seen in the video session) or to "mute" a participant (e.g., by taking away or diminishing tools that allow her to be seen in the video session). A simple example of a "mute" of a player would be to remove the feature in the player's console that allows him to attach emoji to the session.

[0079] The high level flow of the disclosed systems and methods implemented in video sharing may then be as follows. A trigger may initiate the use of a new plan within the DE to proactively calibrate the Order. The current state of the DE is examined, including all of the participant profiles, current and past interactions, and the like. The participants in the DE may then be partitioned, such as into groups by the "style" of the participant. An augment-disrupt plan PL may be created, a unique ID for the plan is saved, and all subsequent events in the session are tagged with it for EPDE. As part of creating the plan, a PMF may be consulted. Within the plan PL, augmentation actions may include those that "amplify" or "mute" participants that are identified as having particular personalities, with the goal of increasing the Order of the session. The plan PL is executed over a course of time, and events are tagged with the plan and sent to the EPDE. Notably, the plan may mute overlying active participants while empowering (or "amplifying") "quieter" participants. At some time, the plan PL reaches an end, such as at some threshold, at some time, after some specific actions, and/or the like. If executed effectively, the plan PL will achieve an increase in the Order of the session, in some cases resulting in a more engaging DE than before the plan (e.g., within increased involvement by the various participants).

[0080] Additionally, a further aspect of this disclosure relating to teleportation also applies in the video sharing realm. In a video sharing scenario, teleportation may be used to send a video sharing participant from one live session to another. The GameSpace would describe these sessions uniquely. Therefore, the flow in FIG. 5 generally holds for teleportation in video sharing (taking GameSpace as analogous to video session ID). In the prior art, it is noted that the at-one-time very popular Chatroulette system "teleported" users into video chats with random people. While the notion of random grouping for chat is therefore viable, a semi- random approach is also viable in which a participant P can only be teleported into a chat session S if S already has a minimum percentage of participants who are "socially connected" to P. A chat session might be characterized by a nominal title, by the occurrence of a number of keywords appearing in text chats, by the cumulative attributes of its participants, or some other means. A practical use case for such teleportation may be as follows:

- User U is in a chat session with friends but over the span of a few moments becomes disengaged, tuning out of using any extra tools such as emoji;

The system detects disengagement and finds another live chat session X, more than half of whose participants are socially connected to U;

The system teleports U to chat session X.

[0081] Additional embodiments. In an embodiment, there is a method comprising augmenting the individual experience in a digital environment for each of a plurality of users that exist in the digital environment and are interacting with the digital environment simultaneously. The method may comprise wherein augmenting the individual experience comprises asymmetrically introducing new digital environment elements. The method may comprise wherein the digital environment comprises a multiplayer gaming environment. The method may comprise wherein the digital environment comprises a video-sharing session. The method may comprise wherein augmenting the individual experience comprises teleporting at least one of the plurality of users from a first session in the digital environment to a second session in the digital environment.

[0082] In an embodiment, there is a method comprising: detecting a need to change an Order of a digital environment; creating a disrupt-augment Order-calibration plan; implementing the disrupt-augment Order-calibration plan; and verifying the results.

[0083] In an embodiment, there is a method comprising: detecting a trigger to initiate a new plan within a digital environment to proactively calibrate an Order of the digital environment; examining a current state of the digital environment; creating an augment-disrupt Order-calibration plan PL; executing augment-disrupt Order-calibration plan PL over a course of time; and reaching an end of augment-disrupt plan PL. The method may comprise wherein examining the current state of the digital environment further comprises examining game elements and players therein, including player profiles. The method may comprise wherein examining the current state of the digital environment further comprises partitioning players into groups of at least one player. The method may comprise wherein groups may correspond to at least one of: player skill high, player skill average, player skill weak. The method may comprise wherein the augment-disrupt plan includes at least one of an augmentation action or a disruption action for each partitioned group. The method may comprise wherein an augmentation action comprises introducing at least one new stronger enemy into the digital environment that will occupy at least one partitioned group. The method may comprise wherein an augmentation action comprises introducing at least one new weaker enemy into the digital environment that will occupy at least one partitioned group. The method may comprise wherein a disruption action comprises posing a new challenge to at least one partitioned group that requires that the at least one partitioned group perform an action that such group rarely performs. The method may comprise wherein a disruption action comprises posing a new challenge to at least one partitioned group that requires that the at least one partitioned group perform an action that such group finds difficult. The method may comprise wherein a disruption action comprises posing a new challenge to at least one partitioned group that requires that the at least one partitioned group coordinate a response using in-game chat with a plurality of peers. The method may comprise wherein a goal of the augment-disrupt plan PL is to decrease the Order. The method may comprise wherein creating an augment-disrupt plan further comprises saving a unique ID for the plan, and tagging all subsequent events in game with said unique ID for an event pattern detection engine. The method may comprise wherein creating an augment-disrupt plan further comprises communicating with a profile management framework. The method may comprise wherein reaching the end of PL comprises satisfaction of at least one of: a threshold, a time period, a specific action. The method may comprise wherein upon reaching the end of PL, the Order of the environment should be disrupted such that the Order is decreased so that a group of players is further from achieving success. The method may comprise wherein upon reaching the end of PL, the Order of the environment should be disrupted such that the Order is increased so that a group of players is more likely to achieve success. The method may comprise wherein the augment-disrupt plan comprises teleporting at least one user of a plurality of users from a first session in the digital environment to a second session in the digital environment. The method may further comprise displaying a GUI to the at least one user prompting said user to accept or decline the teleport. The method may further comprise undoing an executed teleport upon satisfaction of at least one of: a threshold, a time period, a specific action. The method may comprise wherein the trigger comprises an event resulting algorithmically from an ongoing analysis of a state of the digital environment by a real-time back-end system.

[0084] In an embodiment, there is a method comprising: determining that a first session of a digital environment is amenable to a teleport; deriving requirements describing a type of user desired for an inbound teleportation; describing a set of user profiles corresponding to candidate users for an outbound teleportation from the first session; querying at least a second session in a suitable state for teleportation to identify at least a second user in the second session who meets the inbound requirements for the first session; identifying at least a first user in the first session who meets inbound requirements of the second session; and performing a two user teleportation. The method may further comprise displaying a GUI to at least one of the first and second users, the GUI prompting said user to accept or decline the teleport. The method may further comprise undoing the teleport for at least one of the first and second users upon satisfaction of at least one of: a threshold, a time period, a specific action. The method may comprise wherein the first and second sessions are paused just before and during the performance of the teleportation so as to ensure session consistency. The method may comprise wherein the first and second sessions are unpaused after the completion of the teleportation so as to ensure session consistency. The method may comprise wherein requirements for users to be teleported are generated in terms defined by a profile management framework. [0085] In an embodiment, there is a method comprising: determining that a first session of a digital environment is amenable to a teleport; describing a set of user profiles corresponding to candidate users for an outbound teleportation from the first session; identifying at least a second session in a suitable state for teleportation; identifying at least a first user in the first session who meets inbound requirements of the second session; and performing a teleport of at least the first user from the first session to the second session. The method may further comprise displaying a GUI to the at least one user prompting said user to accept or decline the teleport. The method may further comprise undoing the teleport upon satisfaction of at least one of: a threshold, a time period, a specific action.

[0086] In an embodiment, there is a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: augmenting the individual experience in a digital environment for each of a plurality of users that exist in the digital environment and are interacting with the digital environment simultaneously.

[0087] In an embodiment, there is a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: detecting a need to change an Order of a digital environment; creating a disrupt-augment Order-calibration plan; implementing the disrupt-augment Order-calibration plan; and verifying the results.

[0088] In an embodiment, there is a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: detecting a trigger to initiate a new plan within a digital environment to proactively calibrate an Order of the digital environment; examining a current state of the digital environment; creating an augment-disrupt Order-calibration plan PL; executing augment-disrupt Order-calibration plan PL over a course of time; and reaching an end of augment-disrupt plan PL.

[0089] In an embodiment, there is a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: determining that a first session of a digital environment is amenable to a teleport; deriving requirements describing a type of user desired for an inbound teleportation; describing a set of user profiles corresponding to candidate users for an outbound teleportation from the first session; querying at least a second session in a suitable state for teleportation to identify at least a second user in the second session who meets the inbound requirements for the first session; identifying at least a first user in the first session who meets inbound requirements of the second session; and performing a two user teleportation.

[0090] In an embodiment, there is a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: determining that a first session of a digital environment is amenable to a teleport; describing a set of user profiles corresponding to candidate users for an outbound teleportation from the first session; identifying at least a second session in a suitable state for teleportation; identifying at least a first user in the first session who meets inbound requirements of the second session; and performing a teleport of at least the first user from the first session to the second session.

[0091] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity.

[0092] FIG. 9 is a system diagram of an exemplary WTRU 902, which may be employed in embodiments described herein. As shown in FIG. 9, the WTRU 902 may include a processor 918, a communication interface 919 including a transceiver 920, a transmit/receive element 922, a speaker/microphone 924, a keypad 926, a display/touchpad 928, a non-removable memory 930, a removable memory 932, a power source 934, a global positioning system (GPS) chipset 936, and sensors 938. It will be appreciated that the WTRU 902 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0093] The processor 918 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 918 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 902 to operate in a wireless environment. The processor 918 may be coupled to the transceiver 920, which may be coupled to the transmit/receive element 922. While FIG. 9 depicts the processor 918 and the transceiver 920 as separate components, it will be appreciated that the processor 918 and the transceiver 920 may be integrated together in an electronic package or chip.

[0094] The transmit/receive element 922 may be configured to transmit signals to, or receive signals from, a base station over the air interface 916. For example, in one embodiment, the transmit/receive element 922 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 922 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 922 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 922 may be configured to transmit and/or receive any combination of wireless signals.

[0095] In addition, although the transmit/receive element 922 is depicted in FIG. 9 as a single element, the WTRU 902 may include any number of transmit/receive elements 922. More specifically, the WTRU 902 may employ MTMO technology. Thus, in one embodiment, the WTRU 902 may include two or more transmit/receive elements 922 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 916.

[0096] The transceiver 920 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 922 and to demodulate the signals that are received by the transmit/receive element 922. As noted above, the WTRU 902 may have multi-mode capabilities. Thus, the transceiver 920 may include multiple transceivers for enabling the WTRU 902 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0097] The processor 918 of the WTRU 902 may be coupled to, and may receive user input data from, the speaker/microphone 924, the keypad 926, and/or the display/touchpad 928 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 918 may also output user data to the speaker/microphone 924, the keypad 926, and/or the display/touchpad 928. In addition, the processor 918 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 930 and/or the removable memory 932. The non-removable memory 930 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 932 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 918 may access information from, and store data in, memory that is not physically located on the WTRU 902, such as on a server or a home computer (not shown).

[0098] The processor 918 may receive power from the power source 934, and may be configured to distribute and/or control the power to the other components in the WTRU 902. The power source 934 may be any suitable device for powering the WTRU 902. As examples, the power source 934 may include one or more dry cell batteries (e.g., nickel -cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like.

[0099] The processor 918 may also be coupled to the GPS chipset 936, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 902. In addition to, or in lieu of, the information from the GPS chipset 936, the WTRU 902 may receive location information over the air interface 916 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 902 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0100] The processor 918 may further be coupled to other peripherals 938, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 938 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0101] FIG. 10 depicts an exemplary network entity 990 that may be used in embodiments of the present disclosure. As depicted in FIG. 10, network entity 990 includes a communication interface 992, a processor 994, and non-transitory data storage 996, all of which are communicatively linked by a bus, network, or other communication path 998.

[0102] Communication interface 992 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 992 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 992 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 992 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 992 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[0103] Processor 994 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.

[0104] Data storage 996 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non-transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 10, data storage 996 contains program instructions 997 executable by processor 994 for carrying out various combinations of the various network-entity functions described herein.

[0105] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS We claim:

1. A method comprising:

identifying at least a first trigger for disrupting a group order associated with a plurality of users in a digital environment;

determining a current state of the digital environment;

generating a disruption plan to modify the group order by altering the determined current state of the digital environment; and

executing the generated disruption plan to modify the group order in the digital environment.

2. The method of claim 1, wherein the first trigger comprises an output of an ongoing real-time analysis of the state of the digital environment.

3. The method of any of claims 1-2, wherein the digital environment comprises a

multiplayer gaming environment.

4. The method of any of claims 1-2, wherein the digital environment comprises a video- sharing session.

5. The method of any of claims 1-4, wherein executing the disruption plan comprises augmenting an individual experience for each of the plurality of users by

asymmetrically introducing new digital environment elements.

6. The method of any of claims 1-5, wherein executing the disruption plan comprises teleporting at least one of the plurality of users from a first session in the digital environment to a second session in the digital environment.

7. The method of any of claims 1-6, wherein determining the current state of the digital environment comprises examining digital environment elements and users of the digital environment, including user profiles.

8. The method of any of claims 1-7, further comprising partitioning the plurality of users into groups of at least one user.

9. The method of claim 8, wherein partitioning the plurality of users into groups comprises partitioning the plurality of users into groups based on user-skill levels.

10. The method of any of claims 8-9, wherein the disruption plan includes at least one of an augmentation action or a disruption action for each partitioned group.

11. The method of claim 10, wherein at least one augmentation action comprises

introducing into the digital environment at least one new digital environment element associated with at least one partitioned group.

12. The method of any of claims 10-11, wherein at least one disruption action comprises posing to at least one partitioned group a new challenge that requires that the at least one partitioned group perform an action, wherein said action is selected as falling below a threshold number of occurrences for the at least one partitioned group based at least in part on historical user profiles.

13. The method of any of claims 10-12, wherein at least one disruption action comprises posing to at least one partitioned group a new challenge that requires that the at least one partitioned group perform an action, wherein said action is selected as exceeding a threshold degree of difficulty for users in said at least one partitioned group.

14. The method of any of claims 10-13, wherein a disruption action comprises posing to at least one partitioned group a new challenge that requires that the at least one partitioned group coordinate a response with at least one other user.

15. A system comprising a processor and a non-transitory storage medium storing

instructions operative, when executed on the processor, to perform functions including:

identifying at least a first trigger for disrupting a group order associated with a plurality of users in a digital environment;

determining a current state of the digital environment;

generating a disruption plan to modify the group order by altering the determined current state of the digital environment; and

executing the generated disruption plan to modify the group order in the digital environment.