U.S. Pat. No. 8,328,640

DETAILED DESCRIPTION

The present invention is a system for displaying objects within an interactive game program that are updated dynamically while the game is being played. In addition, the system includes the capability to add additional objects after the game is published and released. One embodiment of the invention is a client/server system providing dynamically changing advertisements within interactive video games, with corresponding development suites for game developers, game publishers and advertisers. The embodiment is shown with a single client interacting with a single server, but it is understood that the system applies to multiple clients interfacing with multiple servers, depending on the needs of the particular implementation.

FIG. 1illustrates the present invention10and how it relates to game developers, game publishers, and advertisers. The game developers, game publishers and advertisers use a group of support servers12, to deliver dynamic ad object information to a number of game consoles14,16,18,20each containing an Ad Engine22,24,26,28. The invention creates the ability to expose a number of game players to the dynamic advertisements.

FIG. 2illustrates a block diagram of the embodiment's system architecture10. It includes the fundamental components involved in the process of creating and updating integrated game advertisements, during both game development and game operation. One component of the invention is an Ad Engine30integrated within the interactive game32using a game developer ad object Management Studio and Software Development Kit (SDK)34.

The game developer uses the ad object Management Studio34to define new advertising objects within the game and set their properties. The object properties are saved in local files within the interactive game program platform. Examples of possible properties include: timing, (when the ad could change and what frequency), appearance characteristics, and medium characteristics, such as file format, resolution, and default ad information. During runtime, the Ad Engine30loads the properties file, prepares the data for the game application, and generates an ad objects, which is the actual advertisement displayed to the game player. The Ad Engine30controls the ad object based on the ad type and the control parameters set by the developer using the object Management Studio34. In addition to the objects, the game developer also creates native objects in the game engine to act as placeholders. The Ad Engine registers these objects; which are linked to the ad objects defined in the Studio using a unique (per game) object ID provided by the developer or created automatically. The object ID is used to identify particular ad objects for later updates.

In addition, to including ad objects during the interactive game's creation, the present embodiment also includes the ability to add ad objects after the interactive game publication and release. One can add new objects to the game environment or change the location, orientation, or shape of already existing objects. For example, a game developer or advertiser may choose to create a new billboard near a road where no billboard was placed before or move an already existing billboard to a place with higher audience exposure. Another example is changing the game environment to reflect special holidays like Christmas or Halloween.

FIG. 3illustrates a possible high-level abstract architecture of the Ad Engine. At the core of the Ad Engine30is an engine controller36. The engine controller interacts with the game engine38of the particular interactive game platform via a facade40. A facade is a programming technique in which a simplified interface is created between two components, in this case the engine controller and the interactive game's game engine.

In addition to communicating with the game engine38, the engine controller36interacts with an object cache manager42to receive the current content as needed. The cache manager42maintains and manages the content data for each object so that it is available on demand. To do so, the cache manager42interacts with support servers to determine the correct content for each ad object at every instance of time, and retrieves the content from the local cache, if available. If the content is not available, the cache manager42downloads the data from the support servers. To obtain the desired data, the ad object cache manager42uses an IO manager44, which acts as a standard platform independent IO interface. The IO manager44in turn uses two interface modules, a file system interface46to interact with the local file system, and a network interface48to interact with the server via the Internet. These two interfaces are platform dependent and act as the interface to the specific operating system50of the interactive game platform.

As noted, the engine controller is at the heart of the Ad Engine and has other responsibilities, including the handling of game engine events. These events are events related to the ad objects, and include for example, object visibility, proximity to the object, and actions on the object (e.g. contact, shooting, etc.). The game reports these events to the Ad Engine, who passes the events to the engine controller for handling. This process allows the support of interactive ads.

Another responsibility of the engine controller is to synchronize with the game engine's clock. The game maintains its own clock, which is typically dependent on the specific host computer's frame rate. On the other hand, the ad display in many cases, such as video, depends on real time. The engine controller, therefore, needs to maintain synchronization with the game engine's clock to correctly display the ad objects.

An additional responsibility of the engine controller is to update all ad objects in game as needed. The engine controller may update static objects once at the start of the game or at the beginning of a game level. On the other hand, other objects handle content that may change on a per frame basis. For example, a billboard showing a video requires updating with the correct data at every frame.

The engine controller may also decode Video & Flash content. Due to the huge size of a typical video or Flash data, it is usually not feasible to hold the content in its raw frame format required by the game. For example, a video with typical resolution of 640×480 with 32-bit color requires 1.2 mega bytes per frame. At standard rates of 30 frames per second, even a short 5-second video will require more than 180 mega bytes of data. Holding this amount of data within the game's memory is not practical, so clearly, the video must be stored in a compressed form. Therefore, the engine controller is required to decode the compressed and symbolic information to produce frames suitable for the game engine on the fly, in an efficient manner without affecting game play.

In a similar manner, the engine controller synchronizes animations with current game frame rate. Typically, the frame rate of a game changes according to the performance of the specific host computer, and the game attempts to maximize its frame rate. Video and other animations on the other hand require a predefined frame rate determined by their creators. Usually, this frame rate is 30 frames per second. Thus, the engine controller has to synchronize between the desired frame rate and the actual one by skipping frames and interpolating between frames as needed.

Finally, the engine controller supports for Level-Of-Detail and other graphic engine features. A typical object in a 3D game may contain tens of thousands of polygons with many of these objects appearing on the screen at any given time. Rendering such scenes in an interactive frame rate is a hard task even for today's most advanced Graphical Processing Units (GPUs). In order to solve this problem, the game engine often uses Automatic Level-Of Detail (LOD). The basic idea of LOD is to use simpler versions of the same object as it makes less contribution to the rendered image (i.e. when it is far away). For example, when the object is close to the camera (viewer), it requires the full number of polygons displayed. As the viewer gets further away, the area it covers on the screen reduces. Instead of using the full resolution model, a simplified model is used with less polygons needed. Due to the distance from the camera, the simplified model looks approximately the same as the detailed one. Since the renderer has much fewer polygons to process, a significant processing benefit occurs. The Ad Engine supports LOD with respect to the ad objects by providing the object to the game engine at the appropriate level of detail. In alternative embodiments, the Ad Engine and engine controller can support other advanced graphic algorithms used by the graphics engine.

FIG. 4illustrates the typical processing of the Ad Engine. At the start of the game, the Ad Engine constructs the ad objects from the property files (step52). Next the Ad Engine retrieves the static information contained within the ad object (step54). An example of static information is the local file name for current ad creative assigned to the object. This can be a default value for the ad's content. Then, the Ad Engine updates the time elapsed between the last update (step56). At defined intervals depending on the type of the ad, the Ad Engine will then retrieve the dynamic information from the ad objects (step58). Animated ads may update upon every frame, while other ads update upon certain game events. In the next step (step60), the Ad Engine passes the current game events to the ad objects for processing. This process repeats until the game ends and the Ad Engine destroys the current ad objects (step62).

The embodiment supports various types of ads, ranging in complexity and in the level of integration in the game. The supported ad types can be broken down into three groups: non-immersive, immersive, and a group of non-visual ads. Non-immersive ads are ads presented in the plane of the display in front of the user. These include but not limited to overlays, ads in the game menus, and commercial breaks. The content types supported for non-immersive ads are textures and animation, including for example animated textures, Video, 2D vector graphics (Flash).

The second type of ads supported by the embodiment is ads that are immersed in the (3D) environment of the game. The game displays the immersive ads according to the shape of the objects they are on and according to the viewing transformation of the game, such as an advertisement placed upon a wall in a car racing video game. The content types supported for immersive ads include for example: textures, 3D objects, animated textures, Video, 2D vector graphics (Flash). These objects can be interactive, responding to events in the game, such as, an object that was touched or shot at.

The final category of possible ad types included in the embodiment is non-visual ads. Non-visual ads are elements that do not have a visual presentation. These elements may appear stand-alone, tied to visual ads, or tied to events. Examples of non-visual ads include audio effects, music, or a call for action, such as coupons or Uniform Resource Locators (URLs) presented to user because of various game events.

It is important to note that the in-game objects and the system are not limited to advertising only. Passing advertising media is one obvious application with clear business potential; hence, it is used as one example. The objects are a communication channel from a server into the game and vice versa, and can transfer many types of media content for different purposes. Other possible applications could include for example, instant messaging, music streaming, game updates, etc.

Back toFIG. 2, in addition to loading ad files and preparing the data for the application, the Ad Engine30communicates with the support servers12to manage and control the ad content. Its responsibilities include: requesting campaign information for the support servers12whenever possible, download and cache ad content according to defined ad campaigns, update ad objects integrated within the game, and track ad impressions and deliver statistic reports to the support servers12. The following sections discuss each of these responsibilities in more detail.

In the embodiment the support servers12consist of three components: a Management Server64, an Ad Server66and a File Server68. Note that when using the term “server” we refer to software components. As such, different servers may reside on different actual physical computers or on the same ones. Furthermore, a given server may be distributed across multiple computers and networks, as depicted above for the case of the Ad Servers supporting the games. The distribution of servers to physical computers and networks is determined according to various considerations such as cost, geographical location of clients, and bandwidth limitations.

The Ad Server66is responsible for communication with the integrated Ad Engine30of each interactive game. It delivers ad information, including ad campaign information and ad creative URLs used to update the integrated ad objects. In addition, the Ad Engine30sends ad tracking information to the Ad Server66, which the Management Server64uses and stores.

In the embodiment, the Ad Engine30communicates with the support servers12using HTTP protocol, which occurs in the following cases: the engine needs to retrieve ad campaign information for the game objects, the engine needs to download creative data from the server, and the engine needs to send tracking information. Furthermore, the communication between the Ad Engine30and the Ad Server66can be done in two modes: background mode and blocking mode. In background mode, the Ad Engine sends/receives data from the server in the background at specific game events such as game start and level change. This is the default mode and is preferred because it limits the influence of the system upon game play. In blocking mode, the game engine waits for X seconds until the Ad Engine sends/receives data from the server. The game developer sets this mode explicitly defining the interval of communication. Once successful, the embodiment does not repeat both operations within a certain amount of time (e.g. once a day).

FIG. 5illustrates the typical process of communication from the perspective of the Ad Engine. First, the Ad Engine connects to the Ad Server with a web service that uses the HTTP protocol (step70). If the Ad Engine cannot connect with the Ad Server through the web service, it uses the local ad information in the local cache (step72) to display the ads within the game (step74). If it can connect with the Ad Server, it will request an update for the dynamic data for the Ad object (step76). When it receives the updated dynamic data (step78), it will update the local ad space with the updated Ad Object information (step80). It will then display the ads in the game (step82). If there is ad creative information missing (step84), it will download the missing information from the File Server (step86), which stores the ad creative information.

In an alternative embodiment of the present invention, the communication protocol could include security measures to assure that the support servers and Ad Engine can authenticate each other and to prevent tampering of data. Standard encryption methods such as but not limited to RSA Security methods can be used.

Back toFIG. 1, the Management Server64provides services to the game developers, game publishers, and advertisers. This interface includes three components: a game developer's object Management Studio and SDK34, a game publisher's object Management Suite88, and an advertiser ad campaign Management Suite90. As stated before, the developer's object Management Studio and SDK34allow game developers to define Ad Objects within the game. In addition, developers will use the Object Management Studio34to pass game technical information to the Management Server64to control various parameters, such as Ad Object information, and Object ID information.

In addition, the game publisher's object Management Suite88also interfaces with the Management Server64to control the objects within the game. The game publisher is the “owner” of the game and controls all business related issues of the game, which includes the advertising content. Once the Ad objects are integrated within the game by the developer, the publisher uses the Object Management Suite88to control various characteristics of these objects and of the game as a whole. Game and ad object information to be controlled include but not limited to the following: timing, (when the ad could change and what frequency), player demographic information, and appearance characteristics. In addition, a game publisher may want to exercise domain control over the ad content by selecting preferred domains or excluding others based upon the available ad campaign information. For example, a publisher may want to exclude alcohol related ads from appearing within their game. In addition, the publisher may also incorporate an advertiser filter to include or exclude certain advertisers from appearing also. The incorporation of these features within the preferred embodiment allow the game publisher create a business around the advertising content shown in the interactive games.

Finally, advertisers use the ad campaign Management Suite90to interface with the Management Server64to create and upload the content of the ads. The Suite90defines and manages the ad campaigns, and tracks the progress of the campaign using tracking tools. Note that for simplicity reasons we use the term “advertiser” as an abstract concept. In reality the “advertiser” role are several entities such as the brand owner (the advertiser), the ad agency, or the ad creative agency.

As stated before, one objective of the present invention is to allow advertises use their existing creative tools (Flash, 3D Studio, Photoshop) and data formats when creating ad campaigns. Thus, after creating the content using their commercial tools, the advertiser uploads the ad creative content to the system using the ad campaign Management Suite90. The system then converts the content produced by advertisers in their commonly used formats to the native data types required by specific game engines as needed. The Management Server64receives the data who then passes it along to the File Servers68for storage. For example, the system converts an image in jpg format created and uploaded by the advertiser into the local format required by a target game.

Furthermore, the ad campaign Management Suite90allows the advertisers to control various aspects of an ad campaign. Through communication with the Management Server64, the Suite can update campaign information based upon the available game and ad object information. An example of controlled campaign parameters include but not limited to: timing, (control display by date and time, maximum exposure time, frequency), target demographics, and appearance. In addition, advertisers may develop ad campaigns based upon target game rating, (such as Everyone, Teen, Mature), genre, or content depending upon how the interactive games are classified within the system. These features also facilitate a business around interactive game advertising by allowing the advertisers develop specific ad campaign directed toward game play.

Furthermore, in the embodiment the ad campaign Management Suite90incorporates tracking tools allow the advertisers to track ad delivery, and get immediate feedback and statistical reports, enabling them to gauge the success of their campaigns in real time. As discussed above the Ad Engine30accumulates display statistics for each object and for each campaign. The Ad Engine30sends this information to the Ad Server66who forwards it to the Management Server64. The Management Server64then analyzes this data and produces reports to the advertisers as needed. These reports include number of unique users viewing the ad, number of ad impressions, impressions per user, time ad was viewed, etc. This allows advertisers to update current ad campaign data to maximize advertising potential and to better prepare future campaigns.

Finally, as stated before, another important functionality of the invention is to allow users create additional advertising objects within the interactive game program after publication and release. All three management suites incorporate this functionality. The process for adding new advertising object is shown inFIG. 6. This process can apply to an interactive game program created with or without existing ad objects. First, the ad object is created and is defined on the Management Server with either the game developer's object Management Studio, game publisher's object Management Suite or the advertisers' ad campaign Management Suite (step92). The created object contains the following information in order to display the new advertisement, which may include all information necessary in order to render and display the object correctly. The data include geometric data (vertices), texture coordinates, texture data, normals, and shaders. Additional included information is the advertisement location and orientation information: For example, in a 3D environment, a 3D vector determines the location, defining the X, Y, Z coordinates of the pivot point of the object, and a rotation axis and an angle of rotation around that axis determines the object's orientation. Other included information may include collision volumes used by the game engine physics code for collision detection calculations.

Next, the Management Server downloads the object to the Ad Engine in the game players machine (step94). Once the object information is received, the Ad Engine passes the information to the game console's game engine for display at the appropriate time (step96). At this point, the Ad Engine processes the new object as if the ad object was included in the interactive game program, as described previously. As a result, game developers, game publishers, and advertisers can dynamically change advertising campaigns within interactive game programs to meet current demands.

Therefore, while the present invention has been shown and described herein in what is believed to be the most practical and preferred embodiments, it is recognized that departures can be made therefrom within the scope of the invention, which is not to be limited to the details disclosed herein but is to be accorded to the full scope of the claims so as to embrace any and all equivalent apparatus and processes.