U.S. Pat. No. 12,179,113

DETAILED DESCRIPTION

The present specification relates to dynamic placement of digital assets in a virtual environment, based on location, timing and player actions to maximize the visibility and impact on the users.

The present specification is directed towards multiple embodiments. The following disclosure is provided in order to enable a person having ordinary skill in the art to practice the invention. Language used in this specification should not be interpreted as a general disavowal of any one specific embodiment or used to limit the claims beyond the meaning of the terms used therein. The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Also, the terminology and phraseology used is for the purpose of describing exemplary embodiments and should not be considered limiting. Thus, the present specification is to be accorded the widest scope encompassing numerous alternatives, modifications and equivalents consistent with the principles and features disclosed. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

In the description and claims of the application, each of the words “comprise” “include” and “have”, and forms thereof, are not necessarily limited to members in a list with which the words may be associated.

It should be noted herein that any feature or component described in association with a specific embodiment may be used and implemented with any other embodiment unless clearly indicated otherwise.

It should be appreciated that the programmatic methods described herein may be performed on any computing device, including a laptop, desktop, smartphone, tablet computer, specialized gaming console, or virtual reality system. The computing device comprises at least one processor and a nonvolatile memory that stores the programmatic instructions which, when executed by the processor, perform the methods or steps disclosed herein, including the generation of a graphical user interface that is communicated to a local or remote display. The computing device is in communication with at least one remotely located server through a network of any type.

The embodiments disclosed herein are directed to an improvement in computer-related technology (enabling computers to enable improved gaming experiences in an online multiplayer gaming environment), and thus do not recite abstract ideas or concepts. The improved computing gaming experiences are achieved through the use of specific rules to collect and evaluate player data within the gaming environment which, when executed, enable the automation of specific content generation, and other gaming experiences that previously were not available or could not be automated. These new computer gaming rules improve existing technological processes in gaming and product placement and, therefore, are not abstract or conceptual in nature. This specification therefore teaches how the disclosed inventions improve a gaming technology using a specific set of rules, and particular solutions to the aforementioned failures in conventional gaming systems to achieve the desired outcomes.

While aspects of the present specification may be described herein with reference to various game levels or modes, characters, roles, game items, and any other characteristic associated with a particular genre of video game, it should be appreciated that any such examples are for illustrative purposes only, and are not intended to be limiting. The dynamic asset placement system and method described in detail herein may be used in any genre of video game or any kind of a virtual environment, without limitation.

The terminology used within this specification and detailed description of the various embodiments is for the purpose of describing particular embodiments only and is not intended to limit the invention.

As used herein, the term “a multiplayer game environment” or “massively multiplayer online game” may be construed to mean a specific hardware architecture in which one or more servers electronically communicate with, and concurrently support game interactions with, a plurality of client devices, thereby enabling each of the client devices to simultaneously play in the same instance of the same game. Preferably the plurality of client devices number in the dozens, preferably hundreds, preferably thousands. In one embodiment, the number of concurrently supported client devices ranges from 10 to 5,000,000 and every whole number increment or range therein. Accordingly, a multiplayer game environment or massively multiplayer online game is a computer-related technology, a non-generic technological environment, and should not be abstractly considered a generic method of organizing human activity divorced from its specific technology environment.

The term “dynamic assets”, “dynamic digital asset”, “digital asset” and “message” may be used interchangeably and is construed to mean an object, an image, a graphical, textual or video message, or an animated graphic, including and not limited to a message of public interest issued by an authority, a message issued by the developer of the game, a message relating to a third party or a third party's products or services, or any other type of digital asset including at least one or several of text, graphics, audio and video that is displayed in particular locations and at particular times in a virtual environment of a game to be seen by human players and/or human spectators of the virtual game.

In some embodiments, a “third party digital asset owner” is external to the publisher of the video game and dynamically provides the digital asset via servers that are separate and distinct from the servers of the video game publisher or the servers that host the video game.

The term “game space” refers to the virtual landscape of a video game, including all interactive and non-interactive objects within the virtual landscape, that the virtual character, or avatar, of a human player may engage with or otherwise view while actually playing a game. It does not include the images, video, or text that may be shown in a graphical user interface of a video game before a game, after a game, while a game is paused, or around the borders of the game and outside the actual virtual environment of the game.

The term “dynamically place” refers to the automated placement of a digital asset into a scene without requiring a manual action by a human to select the location or specifically cause the asset to be associated with the selected location.

Exemplary System Architecture

FIGS.1A and1Billustrate systems for providing multiplayer video games, according to some implementations of the present specification, referred to as a multiplayer game environment or multiplayer gaming environment.FIG.1Aillustrates an implementation in which server(s)150function as a host computer that hosts gameplay between other devices, such as computer system(s)110.FIG.1Billustrates an implementation in which a given computer system110functions as a host computer that hosts gameplay between (or with) other devices, such as other computer system(s)110. Server(s)170function as an interface between server(s)150and third party providers or owners to digital assets. Unless specifically stated otherwise, the description of various system components may refer to either or both ofFIGS.1A and1B.

System100may be used to implement various embodiments described in subsequent sections of the present specification. For example, system100may implement various programs that result in more optimal placement of a digital asset in a virtual environment or greater outreach of a message to the participants of a virtual environment, including but not limited to players and spectators in a virtual gaming environment. In one implementation, system100may include one or more computer systems110, one or more servers150, one or more servers170, one or more databases160, and/or other components.

Computer system110may be configured as a gaming console, a handheld gaming device, a personal computer (e.g., a desktop computer, a laptop computer, etc.), a smartphone, a tablet computing device, a smart television, and/or other device that can be used to interact with an instance of a video game.

Referring toFIG.1B, computer system110may include one or more processors112(also interchangeably referred to herein as processors112, processor(s)112, or processor112for convenience), one or more storage devices114(which may store one or more applications120), one or more peripherals140, and/or other components. Processors112may be programmed by one or more computer program instructions. For example, processors112may be programmed by application120and/or other instructions (such as gaming instructions used to instantiate the game).

Depending on the system configuration, application120(or portions thereof) may be part of a game application, which creates a game instance to facilitate gameplay. Alternatively or additionally, application120may run on a device such as a server150to perform its designated function(s) for users in an “online” game hosted by server150.

Application120may include instructions that program computer system110, each of which are described in greater detail herein. As used herein, for convenience, the various instructions will be described as performing an operation, when, in fact, the various instructions program the processors112(and therefore computer system110) to perform the operation.

Peripherals140may be used to obtain an input (e.g., direct input, measured input, etc.) from a player. Peripherals140may include, without limitation, a game controller, a gamepad, a keyboard, a mouse, an imaging device such as a camera, a motion sensing device, a light sensor, a biometric sensor, and/or other peripheral device that can obtain an input from and/or relating to a player. Peripherals140may be coupled to a corresponding computer system110via a wired and/or wireless connection.

Server150may include one or more computing devices. Referring back toFIG.1A, Server150may include one or more physical processors152(also interchangeably referred to herein as processors152, processor(s)152, or processor152for convenience) programmed by computer program instructions, one or more storage devices154(which may store an application120), and/or other components. Processors152may be programmed by one or more computer program instructions. For example, processors152may be programmed by gaming instructions used to instantiate the game. Server170may include one or more computing devices. Server170may include one or more physical processors programmed by computer program instructions, one or more storage devices, and/or other components. The processors of server170may be programmed by one or more computer program instructions.

Depending on the system configuration, application120(or portions thereof) may be part of a game application, which creates a game instance to facilitate gameplay. Alternatively, or additionally, portions or all of application120may run on computer system110or server150. Application120may include instructions that program server150to perform various operations, each of which are described in greater detail herein. As used herein, for convenience, the various instructions will be described as performing an operation, when, in fact, the various instructions program the processors152(and therefore server150) to perform the operation.

Depending on the system configuration, an application180(or portions thereof) may be part of a game application, or may be separate from the game application but in communication with the game application, which creates and positions dynamic assets within the game space. Alternatively, or additionally, portions or all of application180may run on a computer system in communication with server170. Application180may include instructions that program server170to perform various operations, each of which are described in greater detail herein. As used herein, for convenience, the various instructions will be described as performing an operation, when, in fact, the various instructions program the processors (and therefore server170) to perform the operation.

Although illustrated inFIGS.1A and1Bas a single component, computer system110and servers150,170may each include a plurality of individual components (e.g., computer devices) each programmed with at least some of the functions described herein. In this manner, some components of computer system110and/or servers150,170may perform some functions while other components may perform other functions, as would be appreciated. The one or more processors (112,152) may each include one or more physical processors that are programmed by computer program instructions. Thus, either or both server150and computer system110may function as a host computer programmed by application120. The various instructions described herein are exemplary only. Other configurations and numbers of instructions may be used, so long as the processor(s) (112,152) are programmed to perform the functions described herein.

Furthermore, it should be appreciated that although the various instructions are illustrated inFIGS.1A and1Bas being co-located within a single processing unit, in implementations in which processor(s) (112,152) includes multiple processing units, one or more instructions may be executed remotely from the other instructions.

The description of the functionality provided by the different instructions described herein is for illustrative purposes, and is not intended to be limiting, as any of instructions may provide more or less functionality than is described. For example, one or more of the instructions may be eliminated, and some or all of its functionality may be provided by other ones of the instructions. As another example, processor(s) (112,152) may be programmed by one or more additional instructions that may perform some or all of the functionality attributed herein to one of the instructions.

The various instructions described herein may be stored in a storage device (114,154) which may comprise random access memory (RAM), read only memory (ROM), and/or other memory. The storage device may store the computer program instructions (e.g., the aforementioned instructions) to be executed by processor (112,152) as well as data that may be manipulated by processor (112,152). The storage device may comprise floppy disks, hard disks, optical disks, tapes, or other storage media for storing computer-executable instructions and/or data.

The various components illustrated inFIG.1may be coupled to at least one other component via a network, which may include any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network. InFIG.1, as well as in other drawing Figures, different numbers of entities than those depicted may be used. Furthermore, according to various implementations, the components described herein may be implemented in hardware and/or software that configure hardware.

The various databases160described herein may be, include, or interface to, for example, an Oracle™ relational database sold commercially by Oracle Corporation. Other databases, such as Informix™, DB2 (Database 2) or other data storage, including file-based, or query formats, platforms, or resources such as OLAP (On Line Analytical Processing), SQL (Structured Query Language), a SAN (storage area network), Microsoft Access™ or others may also be used, incorporated, or accessed. The database may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations. The database may store a plurality of types of data and/or files and associated data or file descriptions, administrative information, or any other data.

FIG.2Aillustrates an exemplary system configuration200A in which a server hosts a plurality of computer devices to facilitate a multiplayer game, according to an implementation of the present specification. In one implementation, one or more servers150/170(illustrated inFIGS.1A and1B) may host a number of computer systems110(illustrated as computer systems110A,110B, . . . ,110N) via a network102. Each computer system110may include one or more peripherals (illustrated as peripherals140A,140B, . . . ,140N). In this manner, one or more servers150may facilitate the gameplay of different players using different computer systems110and/or otherwise provide one or more operations of applications120/180(illustrated inFIGS.1A and1B).

In some instances, a given server150may be associated with a proprietary gameplay network system, such as, without limitation, the Sony PlayStation® Network, Microsoft Xbox Live®, and/or any other gameplay network system. In this implementation, a given computer system110may be associated with a particular type of gaming console. Other types of computer systems110using other types of gameplay networks may be used as well.

FIG.2Billustrates an exemplary system configuration200B in which a plurality of computer systems110are networked together to facilitate a multiplayer game, according to an implementation of the present specification. Any one or more of the computer devices110may serve as a host and/or otherwise provide one or more operations of applications120/180(illustrated inFIGS.1A and1B).

FIG.2Cillustrates an exemplary system configuration200C in which a computer system110is used by a plurality of users to facilitate a multiplayer game, according to an implementation of the present specification. In an implementation, computer system110may be considered to host the multiplayer game and/or otherwise provide one or more operations of applications120/180(illustrated inFIGS.1A and1B).

Referring toFIGS.2A-2C, simultaneously, in an implementation, a host may facilitate the multiplayer game by sending invitations to one or more contacts through social groups, to play the game and/or performing other operations described herein. In an implementation, at least some of these operations may also or instead be performed by one or more individual computer systems110. Furthermore, the illustrated system configurations are exemplary only and should not be viewed as limiting in any way. Other system configurations may be used as well, as would be appreciated by those having skill in the art.

Selecting and Modifying Messaging Within Game Elements

In some embodiments, a “third party digital asset owner” is external to the publisher of the video game and dynamically provides the digital asset via servers170that are separate and distinct from the servers150of the video game publisher or the servers150that host the video game. However, servers150and170may communicate with each other over network102, as discussed inFIGS.1A and1B. Application180is a part of digital assets server170and may be in communication with server150. Application180implements a scoring system and method for determining value of placing a dynamic asset in a game space, such as the gaming environment hosted by server150or computer system110. Application180scores value of the message for a particular location and a particular time based on a potential or a determined set of parameters relating to visibility, exposure, impressions, attributes of the product, and other attributes of the game space itself. As further discussed below, the set of parameters are determined using multiple tools including but not limited to, analysis of historic data for a particular area of the game space, analysis of post-match event data, and/or advanced or real-time analysis of in-game action. The scores are dynamic, and are based on updates to game data during and after a gaming session.

Locations of the dynamic assets are ranked or classified in multiple tiers based on the determined scores. A Graphical User Interface (GUI) is presented to an owner of the digital asset through a computer system110. The digital asset owner, interfacing through the GUI, may specify one or more tiers that they want for placing their digital assets. In some embodiments, the GUI enables the digital asset owners to view and filter different digital asset placement locations from a perspective of a match or a gaming level or the game. In some embodiments, the digital asset owners may place a request for the selected tiers in advance, before the game begins.

As further discussed below, application180is also configured to filter or evaluate messages for chosen locations in the game space, before adding them to the game space. In some embodiments, application180is programmed to modify a message provided by the digital asset owner, so as to suit the digital asset's display to a particular time, location, or event in the game space. In an example, a digital asset pertaining to a car is rendered to be light and bright if placed on a billboard game element during the daytime but that same digital asset would be modified to be dark and textured if integrated into a mountainside, within the game space. Application180could also make recommendations to the digital asset owner based on the nature and content of a digital asset for suitable locations in the game space. One example of a recommendation is a match based on the nature of the digital asset and the nature of the location. In an example, a digital asset, such as a message, pertaining to a movie is recommended to be placed on the marquee of a theatre in the game space, or a digital asset pertaining to or recommending a snack food may be placed in the window of a convenience store in the game space. Other recommendations would be based on the game action at the virtual location in the game space. Therefore, if the virtual location is a high traffic choke point with a lot of fast action, it may be recommended that a digital asset relating to an action sport brand, product or service be placed, but if the virtual location is typically associated with slower action, digital assets for other, more relevant brands, products, or services may be recommended. The digital asset owner may choose to accept the recommendations.

Application Architecture

FIG.3illustrates an exemplary set of modules implemented by application180described in the context of and with reference toFIGS.1A and1B, in accordance with some embodiments of the present specification. In some embodiments, application180provides or implements a plurality of modules, such as, but not limited to a scoring module302comprising a module304that calculates scores based on historic data and a module306that calculates scores in real time or based on estimations for future data, a digital asset placement module308, and a payment or billing module310. It should be appreciated that the term ‘module’ refers to computer logic utilized to provide a desired functionality, service or operation. In various embodiments, a module can be implemented in hardware, firmware and/or software controlling a general purpose processor. In one embodiment, the modules are programmatic codes or computer executable instructions stored on a storage system, such as the game and business database system160, and executed by a processor. It should be appreciated that one of ordinary skill in the art would understand that the term “real-time”, relative to the term “historical data”, means that the data is being generated substantially concurrently, e.g. within an hour or less, of the scoring module calculations.

In some embodiments, module302is configured to access information pertaining to a game space. The information includes, and is not limited to a map showing multiple locations within the game space, game-data of the game(s) that was played within the game space, and data pertaining to the action or events that take place during the game played in the game space. The accessed information provides a specialized and organized format for presenting, processing, retrieving, and storing data associated with each game space so as to determine one or more scores.

Module304uses historic data including post-match event data and historic data for a map of the virtual environment. In embodiments, the historical data is constantly updated with new game data.

Module306may use real-time analysis of in-game action to predict scores. In embodiments, machine learning techniques are used to improve predictions. In an example, various weighted factors are used for predicting high traffic areas of a given map. New game data is used to “learn” and refine what weight should be given to these various factors.

The factors, used by modules304and306, may include historical traffic patterns that indicate locations in the map that witness action. The data may include traffic patterns that also indicate areas within the map where players have stayed or are likely to stay for a prolonged period of time. Additional factors may include places and times with high visibility to the players and/or spectators. The identification of such places and times may be based on obstructions encountered by players, camera angle, lighting, depth in a scene, size of the location in which the digital asset can be displayed, among other parameters. Areas where obstructions are encountered by the players are likely to witness relatively higher traffic as compared to areas without obstructions where the players move ahead with speed. Similarly, a camera angle that focuses on a certain area within the map is likely to offer greater visibility to a digital asset, relative to an area that is not central to the camera's viewing field. The other factors are similarly applied to establish and predict the scores of places and times with high visibility to the players and/or spectators. Some additional examples of the factors used by modules304and306may include team composition, map layout, player profiles indicating tendencies and gaming patterns for each player.

In another case, a scene is analyzed for optimal camera angle and the scene is further analyzed for optimal digital asset placement within the scene based on relevance to an action in the scene, and discreet and seamless placement within the scene so as not to detract from the visual integrity of the gameplay.

Module302may combine the scores analyzed by modules304and306, to determine an overall score for digital asset placement for display within the virtual environment of the game space. In an embodiment, the score is analyzed based entirely on the amount of time a virtual location is within the field of view of players. In another embodiment, the score is analyzed by combining the amount of time the virtual location is within the field of view of the players with an offset/reduction for the time the player is moving quickly or engaged in action that would detract from their ability to perceive the digital asset. In another embodiment, the score is analyzed by increasing a placement (of the digital asset) score based on the game action experienced by the player. In this embodiment, if the virtual location is a spawn point, it could receive a higher score. If the virtual location is a key goal in the game, such as but not limited to an enemy base or a flag, it could receive a higher score.

In some embodiments, scores are additionally based on timing in the game and how close the game is near the end of the game session. For a time that is closer to the end of the game session, the score may be higher.

A higher score may indicate a higher value for placing a digital asset at a particular location and at a particular time within the game space, whereas a low score may indicate a lower value of placing the digital asset at a particular location and at a particular time, within the game space. Here, the value may be associated with a monetary value that is paid by the digital asset owner for placing their digital asset in the game space. In embodiments, module302determines the scores for the digital asset for a particular location and a particular time based on potential (i.e., predicted) or determined (i.e., actual) metrics used respectively by modules306and304.

The scores provided by module302are used by a digital asset placement module308to determine a suitability of a message for placing the message into a scene. The scene is defined by, among other properties, a location or an area within the game space and a time at which the scene is executed. Location is used to specify an area/volume of the in-game world (world coordinates) in the game space. For example, locations can include 2D areas on a wall, billboard, sign, storefront, television, or other flat surface in the game space. Locations can also include 3D areas/volumes such as a space on a table, in a store or mall, in a restaurant, or any other space in the game space. The location can be defined by the world coordinates so that placing a message would be similar to placing a 2D texture or a 3D object in the game space. Module308classifies each scene that may be appropriate for placement of a digital asset, in to one or more tiers or ranks, based on the scores. The scores are dynamic and may be based on the determined and estimated features of a game taking place within the game space. As a result, the tiers or ranks for each scene may change over time. Each tier corresponds to a different value for digital asset placement in the given game space. The tiers and their associated values are made available to digital asset owners through a graphical user interface.

The digital asset owners may specify in advance which tiers they want for placing their digital assets in the game space. Additionally, the digital asset owners may request specific placements using a GUI that allows for viewing and filtering different digital asset placement locations from a match/level/game within the game space. The digital asset placement module308is configured to receive one or more digital assets from digital asset owners through the GUI. The digital asset is characterized by its size, nature of product being showcased, combination of colors, combination of text and images, among other characteristics.

In embodiments, the scores provided by module302may be modified further by module308, based on an analysis of compatibility of a received digital asset with a particular scene. In one example, the score and therefore the value of a scene for a digital asset that is relatively more suited to that scene, is high, and vice-versa for a digital asset that is relatively less suited to the same scene. The analysis for determining the suitability of the received digital asset to a scene is based on at least one or more of the following:

In one embodiment, the suitability of the digital asset for the scene is rated based on a size of the digital asset and the location. For example, a digital asset may be constrained to some size or range of sizes to be ideally viewed on screen, while a location for placing the digital asset may have specific size or ideal range of sizes as well. Module308rates a given digital asset's suitability for the scene based on a comparison of these parameters.

In another embodiment, the suitability of the digital asset for the scene is rated based on the color palettes use in the digital asset and the scene. In an example, certain colors may not be visually pleasing for a certain scene, whereas other colors may blend in better. In another example, a visually noisy or colorful message is determined to be a poor fit to put on a wall in a plain grey room in a scene.

Therefore, the above two parameters are examples of comparing visual aspects of the digital asset to the visual parameters of the scene to determine whether the digital asset is suitable for that scene.

In another embodiment, a rating for the suitability of the digital asset for a scene is based on the subject matter of the digital asset and the scene. In an example, a food-related digital asset for product placement may be highly rated for a scene relating to food. Such a scene may include locations such as a restaurant, a grocery store, a food court, among other food-related locations in the game space. The same food related digital asset, however, may be rated as lower in a scene unrelated to food, including scenes at locations of a military base, an outdoor/underwater scene, and the like.

In another embodiment, a rating for the suitability of the digital asset for the scene is based on the duration of the scene. In one example, if a determination is made that players are typically sprinting through a location then it may generally be ranked lower in terms of suitability for digital assets compared to a location where players are spending more time or not moving as quickly through the scene. In another embodiment, the suitability of the digital asset for the scene is rated based on the visibility of the scene. The visibility of the scene may be based on a combination of features such as, camera angle, obstructions, lighting, and anything else that may affect the player's viewing of the location.

In yet another embodiment, the suitability of the digital asset for the scene is rated based on the nature and type of activity taking place (currently or historically) in the virtual location of the scene, either for an individual player or for a set of players. For example, displaying a digital asset representing athletic gear in a sports game may be rated as highly compatible or the same digital asset may also be rated as highly compatible in another game genre, but for specific players who have a demonstrated preference for sports gear.

In some embodiments, module308is configured to use the rating of compatibility of the digital asset for a scene to make recommendations of the most suitable scenes to the advertisers. In some embodiments, module308is configured to modify visual aspects of the digital asset to increase its rating of suitability to certain scenes. The digital assets may be customized by module308, or custom digital assets may be provided by digital asset owners for a scene, where the customization is based on the profiles of each player and spectators. The ability to customize the digital assets indicates dynamic characteristics of the digital assets.

A module310is configured to determine the values of various choices of dynamic asset placement available to digital asset owners and enable the owners to perform transactions associated with their choices. The value of a scene is modified based on the dynamics of actual game play in the game space, so that a scene which may start with an initial default value (high) may actually decrease because, in actual game play, the game element associated with that digital asset placement location is not frequently encountered, and vice-versa. Similarly, the value is modified based on the player or group of players, since the knowledge of game play style of specific players enables the knowledge of which game elements associated with a given dynamic asset placement location would receive greater or fewer impressions from those players. The dynamic nature of the value of a scene is specifically applicable to the scenes for which the values are based on estimated scores, predicted by module306. In embodiments where a digital asset owner has paid for a scene based on a projected value of the scene and there is a discrepancy with the actual value, module310is configured to credit or refund the digital asset owner after the discrepancy has occurred. In some embodiments, the digital asset owner only gets a refund if the value goes down, and is not charged more if the value goes up. Alternatively, module310is configured such that the digital asset owner pays for the scene after the game so the actual value is used. Alternatively, the digital asset owner can pay based on the projected value and assume some risk that the actual value might change (for better or worse). Different types of transactional models may be adopted by module310. Additionally, the payment models may be based on cost of each click or impression for a dynamic asset, or based on a flat rate, or based on a cost only if the numbers of clicks or impressions are above a predefined threshold, or any other.

The GUI provided to the digital asset owners enables them to conduct the transactions with the server170. The GUI may enable a digital asset owner to visualize the game elements (billboards, sides of buildings, sides of vehicles, terrain, others) and how their digital asset would visually change based on camera angles, time of day, weather, among other factors discussed above.

FIG.4is a flow chart illustrating a process for dynamically placing digital assets (such as selecting and modifying messaging) within a game space, in accordance with some embodiments of the present specification. In embodiments, the process is configured to be implemented by a combination of modules implemented by application180, for a multiplayer video game. At step402, a scene is analyzed to generate a dynamic score for the scene. The dynamic score is based on at least one of a historic data, a real time data, and an estimated data related to the scene. The historic data is continuously updated with new game data and machine learning techniques are used to improve estimations. The updates are provided in real time and/or after a game event. The scores are generated based on multiple factors that may be weighted for predicting high traffic areas of a given map such as historical traffic patterns, team composition, map layout, player profiles/tendencies/patterns, visibility of a scene, obstructions, camera angle, lighting, depth of scene, among others. The system can use new data to “learn” and refine what weight should be given to these factors, while determining a score. Each score may be classified or ranked in one of pre-defined tiers. Each tier may be associated with a monetary value for placing a digital asset in the scene. The term data related only to a first scene means that the referenced data does not include data specific to scenes other than the first scene but may include data common to the first scene and the other scenes.

At step406, a graphical user interface (GUI) is generated for display to a digital asset owner. The owner may specify in advance which tier is preferred for placing a digital asset in the game space. Additionally, the digital asset owner may request specific placements using the GUI that allows for viewing and filtering different digital asset placement locations from a match/level/game within the game space. The digital asset placement module308is configured to receive one or more digital assets from the digital asset owner through the GUI. The digital asset is characterized by its size, nature of product being showcased, combination of colors, and combination of text and images, among other characteristics.

At step408, a suitability of the digital asset for placing it within the scene is determined. Module308is configured to use a rating of suitability or compatibility of the digital asset for a scene to make recommendations of the most suitable scenes to the digital asset owner for the digital asset. In some embodiments, module308is configured to modify visual aspects of the digital asset to increase its rating of suitability to the scene. The digital asset is rendered dynamic through customizing by module308, or a customized digital asset may be provided by the digital asset owner for the scene, where the customization is based on the profiles of players and spectators of the game.

At step410, either or both of the digital asset and the score are modified based on the determined suitability. The score and therefore the value of the scene for the digital asset that is relatively more suited to that scene, is high, and vice-versa for a digital asset that is relatively less suited to the same scene. The value of placing the digital asset within the scene is presented to the digital asset owners and is used to perform a transaction associated with it. The value of the scene is modified based on the dynamics of actual game play in the game space, so that a scene which may start with an initial default value (high) may actually decrease because, in actual game play, the game element associated with that digital asset placement location is not frequently encountered, and vice-versa. Similarly, the value is modified based on the player or group of players, since the knowledge of game play style of specific players enables the knowledge of which game elements associated with a given digital asset placement location would receive greater or fewer impressions from those players. The dynamic nature of the value of a scene is specifically applicable to the scenes for which the values are based on estimated scores, predicted by module306. In embodiments where a digital asset owner has paid for a scene based on a projected value of the scene and there is a discrepancy with the actual value, module310is configured to credit or refund the advertiser after the discrepancy has occurred. In some embodiments, the digital asset owner only gets a refund if the value goes down, and is not charged more if the value goes up. Alternatively, module310is configured such that the digital asset owner pays for the scene after the game so the actual value is used. Alternatively, the digital asset owner can pay based on the projected value and assume some risk that the actual value might change (for better or worse). Different types of transactional models may be adopted. Additionally, the payment models may be based on cost of each click or impression for a digital asset, or based on a flat rate, or based on a cost only if the numbers of clicks or impressions are above a predefined threshold, or any other. At step412, the digital asset is placed for display in the scene of the virtual environment. The digital asset is available for display to players and spectators of the game. In some embodiments, different digital assets are displayed to players and to spectators, based on the customizations implemented at steps406and408.

The above examples are merely illustrative of the many applications of the system of present invention. Although only a few embodiments of the present invention have been described herein, it should be understood that the present invention might be embodied in many other specific forms without departing from the spirit or scope of the invention. Therefore, the present examples and embodiments are to be considered as illustrative and not restrictive, and the invention may be modified within the scope of the appended claims.