US20070010330A1

US20070010330A1 - System and method forming interactive gaming over a TV network

Info

Publication number: US20070010330A1
Application number: US11/326,101
Authority: US
Inventors: Justin Cooper; Jamie Cristini; Todd Federman; Daniel Fellars; Pat Ruble; Darren Schueller
Original assignee: Individual
Current assignee: Eterna Therapeutics Inc
Priority date: 2005-01-04
Filing date: 2006-01-04
Publication date: 2007-01-11

Abstract

A play along television system includes a plurality of questions and answers to be used as part of an interactive game to be played over a network. A main server stores a plurality of questions and answers, the questions are displayed to the users who answer the questions. The users are scored based on whether they answer the questions correctly, and how fast the ester the questions. The users may also receive hence about claim I mean answering the question and those hence are displayed when the user takes longer than a certain time to answer the question. After answering the question, the correct answer is displayed along with a fun fact about the question. All users playing everywhere are globally scored according to the scoring criteria.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Application Ser. No. 60/641,247 filed Jan. 4, 2005 and entitled, “Play Along TV Technology (P.A.T.T.)”. The disclosure of the prior application is considered part of (and is incorporated by reference in) the disclosure of this application.

BACKGROUND

NTN Buzztime Inc., the assignee of the present application, has a number of products which relate to trivia games that can be played in various ways. The interactive trivia games may be multiplayer trivia games allowing players to play against each other and having different kinds of scoring schema.
Games of this type have typically been run on dedicated networks.

SUMMARY

The present application defines techniques, including hardware, an architecture and a game module, which allows interactive and competitive play from individual television sets. In an embodiment, the play can be carried out over a cable platform, or other broadband platform.
Aspects describe the operation of the game, as well as housekeeping issues of the game operation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of the overall system;
FIG. 2 illustrates the overall architecture of the system;
FIG. 3 shows the hookup of the system;
FIG. 4A illustrates the messaging architecture;
FIG. 4 illustrates the question sequence;
FIGS. 5A-5D illustrates screenshots of the game;
FIG. 6 illustrates the process diagram of forming game skin;
FIGS. 7 & 8 show a screenshot of the template;
FIGS. 9-10 show screenshots of additional rules;
FIGS. 11A-11H show screenshots enabling advertising;
FIG. 12 shows a flowchart of spot (advertisement) management); and
FIG. 13 shows a screenshot of creating those questions.

DETAILED DESCRIPTION

The general structure and techniques, and more specific embodiments which can be used to effect different ways of carrying out the more general goals, are described herein.
An embodiment describes a special game which is played on a computer network. The game may be a trivia game in the specific embodiment, but may alternatively be other kinds of games. The embodiment describes the game as being played over a special channel, but it should be understood that different aspects may be played in different ways. This also describes using a television as the game playing terminal, but it should be understood that any other terminal can alternatively be used, including a dedicated terminal, a PDA type device such as a PDA, blackberry™ or Ipod™, or a computer.
A special architecture is defined based on the number of modules that can be integrated with existing interactive television systems. One aspect of the application may allow operation based on different scientific Atlanta boxes including STB models 2000, 2000 HD, 3000, 2100/3100, 20200/32XX, 30100HD, 3250 HD and 8000. Another aspect may allow drivers or interfaces for other cable “set top” boxes.
One desirable aspect of the architecture is to enable it to allow for future growth.
FIG. 1 illustrates a block diagram of the architecture. The playing engine 100 forms the main portion of the games, which operates according to stored data in a data storage unit 110. A registration and login module 120 allows users to interact with the playing engine 110. The playing engine also includes reporting module 130 which may also interact with the stored data. A security module protects all of the aspects and specifically the data storage. An advertisement server 150 provides advertising which may be incorporated as part of the game. In addition, a user-interface 160 provides an interface to the channel, e.g., the network or directly to the player. While FIG. 1 illustrates the user interface as connected only to the registration and login module, it should be understood that the user interface may connect directly to other parts including the game engine, and the like. The different modules described herein may be distributed between different locations as described in the embodiment.
In the embodiment, the trivia channel provides a continually-running multiplayer trivia game. The game engine may simultaneously run six, 2-way, multiplayer trivia games. Each game is formed of 15 trivia questions. Players compete with other players in their specific areas. The players are scored based on how quickly they can answer each question.
The welcome screen includes an entry point that allows players to enter their home page, or to find out more information about the game. The players can reach a player registration area that captures player specific information from different points in both the home and information screens. The entry of this information is required before the player can enter any games. A prize form may also be required to capture the detailed player information.
In the embodiment, two different levels of registration may be used. A first level of registration is necessary to simply play the game. This level of registration simply provides name, and other similar information. Basically, the lowest level provides a minimal amount of information. A second level of registration is a prize form. This form requires that the player provide more information, but is not required to play the game—it is only required to enter the player for contest and prize giveaway, if such is desired by the player.
The game information may include a trivia guide that lists the countdown formats of the different games. Each countdown format relates to a specific way that the game is played, e.g., by times and the like. Different dynamic game slots are also provided. The games typically run every 15 minutes, but may run staggered so that different players can enter different games at different times.
The games also include advertising content. Scrolling text may run across the trivia guide, for local promotional information. Different users at different locations may receive different advertisements, related to their specific locations.
A special remote for the game, or for the game and for certain TV functions, may also be provided which has consolidated global navigation. Many of these different aspects may be reached from the remote directly.
A help screen may provide information about account help and game help.
The information area lists contests, winners and different information about the game.
Finally, backend management tools are provided, which enables ad placement, monitoring, text and graphic information, random name generation and account management.
The game also includes specified sounds which are used for specified information. When the correct answer is entered, the user receives a correct answer sound, as compared with a different, incorrect answer sound for incorrect answers. Other sounds are provided for “be right back with the game-winner”, timer bar ticking, cursor movement, click, select, out of time, and game winner display.
FIG. 2 illustrates a detailed architectural diagram of the game. The architecture is built on an interactive TV architecture forming the backbone for the trivia channel. One aspect is that the server structure can integrate the game server and session server with many different middleware provider servers and cable operator head ends. Administrative tools are also described allowing access to data pertaining to player accounts, registration, content delivery, usage, and scheduling and ad tracking. The player usage information is captured and stored in the backend, and allows administrators to obtain certain reports.
In operation, the game is initially set up from the main server, which uploads all the information necessary to run a broadcast, over channel connection, to a session server 200, running in the customers head end 205, for example, in the set-top box. The session server includes storage 202 which stores the uploaded information, which may include game and locale specific advertising, as well as question sets and answers, as well as fun facts that may be eventually displayed to the players. The session server 200 divides the question content into smaller intervals, and makes the question content available on a game per game basis for the clients.
The session server 200 also communicates with a number of subscriber home locations 210, each one including a set-top box shown as 212. The communication sends questions to the set-top box, and receives answers from the set-top box. The data including player scores may be stored in the local memory 202. The session server computes scores at the end of each game. Note that the session server is in the cable head end, and hence is regional. A game server device 220, is located in the colocation facility 222, and may be less regional, or national. The engines 206 within the game server may compute the local top 10 players. These are sent back to the clients such as 212 after each question. At the end of each game, the engines push the scores to the game server 220, which provides an engine to determine a national top 10 score. The national top 10 scorers sent back to each of the game servers, which sends those national rankings, in turn, to the clients.
In operation, each of the session servers host at least 96 hours of advanced content at any time within the content storage 206. In this way, Internet outages between the game server 220 and the session server 200 will not affect the session server's ability to provide content to the users.
The game server 220 acts as the main server. This may reside at the main company headquarters, or in, as shown, a colocation facility 222. The game server, in the embodiment, builds XML files which contain questions, names of the images needed for the questions and/or the games, and uses these as the content to be sent to the local session servers. A certain amount of content is cached at any time, for example seven days worth of files may be cached on the file system 224 that is associated with the game server 220. In addition, the game server includes certain ranking engines, which produce national ranking statistics at the end of each game, and sends these statistics to the session server. This enables displaying leader boards to the different players.
The game server 220 uses a number of different interconnecting servers and services. The content server 226 creates content for each game. As described above, this content may be produced in the form of XML questions. The information may be created and cached on the server, in a local cache memory shown as 228. The information for producing the questions comes from the database 224 which in an embodiment may be an Oracle database. A content server also includes a content redistribution service, which is initiated by the session server when the session server reaches a certain point of cache fill. When initiated, the session server receives question content over the channel. In the embodiment, encryption modules may be provided at both ends to avoid surreptitious interception of the data. Another advantage of the caching of information is that the information is not sent in real time, enabling intercepted information to be discarded.
The media server 240 also stores the different content for the games including the game graphics, advertisements, and sound. Any media being used by the game can be stored in this way.
A ranking service may also be provided as 228 on the game server, which provides for different kinds of ranking of the players. The ranking may include leader boards, player ranking, player rewards, top scores, leagues, and tournament information. The game server, for example by using stay awake messages or other techniques of determining down time of the game server. Problems or errors are reported to the administrators.
In addition, the player data from the registration is stored within the database 224. Once a player has properly registered in the database, the player can log into any set-top box, that runs the system and enter a game.
Different tests against the player registration are carried out. Player registrations are automatically validated against a dirty word database, and immediately rejected if they include those keywords. Registrations are also manually validated at least once a day, to manually make sure that the words used are appropriate.
The session server stays within the cable operators head end. The session server also includes an external monitoring service within the game engine, shown as 208. This service allows the game server to communicate at any time, and check for problems or errors.
FIG. 3 illustrates a high level architecture, showing the different servers including the game server 220, the session server 200, and the set-top box 212.
The messages between the servers are sent as XML files, encrypted using DES encryption. Different kinds of messages are sent between the servers.
Registration messages represent the user registering for certain services. The registration information is typically sent from a cable box to the main game server, and may be sent between servers. The registration messages are sent at variable time intervals, and therefore, the timing of the registration messages cannot be predicted. The intervals exist whenever a player logs in, changes their PIN, or changes some other aspect of their account. The messages are relatively small, most less than 1 kB, all less than 2 kB. A similar size response is sent from the game server to the session server, after the registration has been completed.
External monitoring messages allows the game server to monitor the game server.
A content build message session is carried out whenever question content is received from the game server to be stored to file on the session server. In the embodiment, this will happen once a day, at a configurable time during off-peak hours. In operation, the session server sends a small request to the game server, asking for a 15 minute block of time. The response from the game server to the session server contains six games of content, to be simultaneously provided during that 15 minute period. The response message is roughly 70 to 80 kB in size. This session server stores the response message, associated with the specific 15 minute block of time. Media related files, which are stored on the media server, may also be retrieved from the media server and stored on the session server. Media related files may include images, text, and other files that are associated with a game. The content build may provide a full day's worth of question content, 15 minutes at a time. The entire process may take between 10 and 15 minutes to complete.
National ranking messages provide information about the ranking of all users relative to all other users. At the end of each game, a national ranking is shown for that game. The national ranking is carried out, however, by the game server. Each game initially sends a small message to the game server to initialize and subscribe to the national ranking server. The message may be less than 1 kB in size. A response, of comparable size, is sent back to confirm or deny the initialization. After the game has been completed, and the final question has been ranked, each game since its top 10 players to the game server.
The top 10 message is 1 to 2 kb in size. The game server performs a national ranking of all the incoming session servers for each game, and sends the national top 10 players back to the session servers. This message may be 2-3 kB in size, a little larger since it includes each player's city and state to be displayed.
Database synchronization messages are also carried out preferably once a day and again preferably during off-peak hours. These synchronization messages compare the data to ensure that all databases hold the same information. The information to be synchronized may include the following. Player data information includes a list of all the players that logged in that day. The list only includes the player's ID and the date that the last logged in. The size of this message may be variable depending on the number of players that logged in during the specific day. It may be configurable to determine how many players get sent per message in order to load balance the message size.
As an example, if 100 players logged in during a day, and the setting is 10 players per message, then 10 messages will get sent for this synchronization, each message referring to 10 players.
The game server responds by comparing the player last logged in with what was stored in the main database. If the database has any data more recent than what was sent, then the game server sends back any player information that needs to be updated on the session server. The game server may also send the list of any players that need to be deleted from the session server's database, for example players whose membership have expired or players who have requested to removed from registration. Game data may also be synchronized.
The player scores are saved to the session server database after every game. One time per day, those scores are sent to the game server, and stored in the database. The game server may also send back global score information for those players. The number of scores per message may also be configured in a similar way to the number of players per message noted above.
The messaging architecture is illustrated in FIG. 4. During registration and game play, messages are transferred between the game server, the session server, and the eventual client. The embodiment illustrates both upstream communication 400 and downstream communication 410 between the set-top box 212 and the session server 200. Upstream communication 400 may include user registration and login as well as individual scores. The TCP channel is used only for specialized content unique to each set-top box. Downstream information may include responses to registration and login, personalized ranking, as well as individual content.
The registration module supports eight player accounts per set-top box, as well as the ability to add, and delete, player information. The registration module has a virtual keyboard which can be controlled through the remote control using arrow keys. The user can log in from this keyboard, and also enter and delete their information. Different kinds of operations are possible using the registration module. A short registration component requests player information from each player, in order to play legacy games. The players need to provide a player name, a pin number, and valid birth date. The information is captured and used to map play patterns.
The log in component verifies that the players who are entering the games have valid player accounts. It also stores login information to determine which players are logging into use the messages noted above. Frequency of login and time of login is also monitored. This information may be used for various statistics including whether game use is increasing or decreasing.
Certain games may include prizes for the highest scoring users. The prize eligibility form captures certain additional information from the user, and makes those users eligible for prizes. It is a voluntary form, and players who do not fill out that form are not eligible for prize giveaways. However, the form may be used to capture additional demographic information.
Another aspect is the random name generator. The system may provide a random name to provide players with unused name options at registration. The generator may include a number of different components, a first random name generator that provides an entirely random player name, and another local name. Each local area has a pool of names that can be assigned to players in their area, in addition to the random name. Each random name includes actual words concatenated together with a series of random numbers, for example, busybee 901.
Another random name generator combines unique player name options, based on the player's entered name. This may include a piece of the player's entered name, along with three valid options.
Another aspect allows the user to indicate that they have forgotten their pin number, which causes them to receive a “pin forgotten” screen. This includes the player name pre-populated with the name that was chosen, and prompts for entry of the date of birth. The client validates that the date of birth matches the name on the player account, and if so provides a new screen with the players information. The player is considered logged in at that point.
The player may log in to the middle of the game in progress. If this happens, then a “tuning in” page remains on the screen until the game moves to a new sequence. The player may be allowed to enter at the beginning of certain sequences, for example big question, little question, hint, answer options, fun fact, or during a top 10 list. However the player can not enter once an ad has begun downloading because of the time it takes to download the ad from the server. This causes the player to wait for the next sequence.
Another aspect determines whether a player with the same account is already playing. If a second player logs in with the same account on a different set-top box, the first logged in player is removed from the game. An error message is displayed to the earlier-login-player, indicating that someone else has logged in with the same username.
Login is automatically timed out after 30 minutes of inactivity. Moreover, if a logged in player logs in with a new account, the old one is also automatically logged off.
Player names are recycled after 30 days. Once a player deletes their name, the player can register the same name on another box, or the name will be recycled.
In the embodiment, players must be added both to the set-top box and also must have a national account. In operation, the easy registration is all that is required: a player name, pin and date of birth. The client checks certain aspects of the message, and sends it to the session server which in turn sends that message to the game server. The game server verifies the information, and if verified, instructs the session server to add the player to the set-top box. A login timestamp is also added at this time. Conversely, if the game server does not find the proper information, an error message is sent back.
A specific messaging protocol is defined allowing communication between the game server, the session server, and the client. The communication can support both UDP and TCP transfer. Communication which is sent over TCP between the session server and client is encrypted.
When a player can choose to exit at any time during the game. When the player exits, the specific file indicative of the players current operations is deleted from the set-top box. In contrast, the player can request a different channel. When this happens, the specific file indicative of the player's operation remains on the set-top box.
Another way of timing out an inactive player is based on zero scores. When a player scores zero, it means that the player is typically not answering any questions. After a certain number of zeros are sent, for example 10 consecutive zeros, the player is automatically considered to be inactive and logged out.
Another error is an out of sync. The head ends are in sync with the game server, and an error is established when any server is out of sync with the game server by seven seconds or more.
A fun fact may be displayed after each question. The fun fact may be displayed for 10 seconds, or enough time to allow specific scores to be communicated back to the game server, and leader boards to be updated with top 10 local and national players in each game. The connection is open for the client to receive messages from the session server and for the session server to receive messages from the game server. The amount of time is limited, however, and if the local leader board does not load in time, then filler pages are displayed. These filler pages look similar to the leader board, but may include promotional text, or other information indicating that the value is not available.
The question sequence proceeds as shown in FIG. 4. FIG. 4 illustrates the different screens of the sequence. In the screen 400, the player is given an option to either play normally, or play a sample game. This leads to the login screen at 402, allowing the user to either login or register. The user selects the game at 404, which can be for example the trivia guide. The game intro screen is displayed at 406. Different screens are provided, either a big question screen at 408 or a little question screen at 410. If the user does not answer fast enough, the user is given a hint screen at 412. Finally, an answer screen, showing the correct answer is displayed at 414. This is followed by a fun fact screen 416 which provides the fun fact, associated with the question and answer. At certain points in the question answering sequence, the local top 10 may be displayed at 418.
In the embodiment, this is done after question six at 417 or after question 10 at 415. At the end of the game, after question 16, at 422, an end game sequence is executed. The system displays a screen at 424 saying ‘be right back with the winner’. An advertisement may be displayed at 426 while the winner is being tabulated. A game-winner screen is provided at 428 indicating who won the specific game. This is followed by the local top 10 at 430, and possibly another advertisement at 432. At 434, the national top 10 is displayed. This is followed by a screen at 436 which begins a countdown to the next game beginning. Each question may take between 45 seconds and one minute, taking a total time for each game of approximately 15 minutes.
Certain user options are available for each game. Each question sequence uses the same answer option treatments for the graphics. During the questions and hints, all of the answer buttons are in a non-select color, but the player can scroll through the options and select one of the answers, changing its color to the selected color. Once the answer is selected, it turns to the selected state. After answer cutoff, the hints remain on the screen and the answers remain on the screen, but the bar behind the selected answer is removed. The correct answer screen is displayed with the correct answer being the only thing that appears on the screen. The correct answer button turns to the select state, and remains in the select state, but hints are no longer displayed. The correct answer button remains in the select state while the fun fact is being displayed.
A special countdown timer is also displayed during the play. At the beginning of a question, the bar appears with a point value to the left of the bar. For example, FIG. 5 a shows a screenshot with the bar at its initial position, having a maximum height and showing a point value of 1000. As the time counts down, the point value decreases, and the image moves towards the bottom of the screen shown in FIG. 5B. When the player selects an answer option, a score value appears to the right of the bar, and remains there until either the time runs out or until the player selects a new answer. If the player answers incorrectly, the correct answer screen shows the timer bar with a value of −250 indicating the lowest score. The game content and graphics can be refreshed while the player is within a game. For example, if the player is in again in game slot 1 at 7:50 p.m., and the new promotion is about to start in game slot 1 at 8:00, then a sequence of events will occur. At the end of the last question (question 15) the final ad 432 appears before the national leader board at 434. The previous game's graphics are unloaded, on the upcoming games graphics are instead loaded. This may be done based on memory constraints in the hardware. A countdown to the next game then starts, as shown in FIG. 5C. If the loading process takes longer than the allotted time, then a pop-up menu appears as shown in FIG. 5D and the game begins. The user will see the game graphics as soon as they are finished loading.
The information screen provides help and trivia information that can be accessed using the remote control. The player can select menu, obtaining a choice from
player home,
trivia guide, (if logged in),
the buzz,
help, and cancel.
Any of these categories may help the user to understand how to play the game.
In addition, the would-be player can play a sample game. The sample game is intended to allow user to get a feeling for the way the game works. The sample game has a sample question from each of the different trivia game categories. For example, the current sample game may include countdown games, and sample trivia questions about everything. Other questions may be about other kinds of trivia. At the end of the sample game, the system asks “now that you have previewed the buzztime trivia games, which you like to create a player name and start playing?”
If so, the new user is guided through the process.
Data capture is important in this system and has been described above. The data tracks player patterns, tracks advertising statistics, demographic information, and game score data. Registration and score data is stored at the session server, and is periodically synchronized with the game server, for example every night. In operation, all the messages are sent from the set top box to the game server. Either the game server, or the session server, however, may be malfunctioning. If the game server is malfunctioning, this will prevent the client from being able to perform certain specified actions. The client may be able to login to an existing game on the list and play. However, actions which must be umpired by the game server will not be able to be followed. When the game server is down, the session server continues to update its last login field for the each set-top user. Other actions may return an error.
Conversely, when the session server's database is inoperative, messages are forwarded to the channel, and responses are sent back to the client. This bypasses the session server's database completely. Synchronization occurs when either database becomes operational.
The main database stores a number of different data tables. A player registration table maintains all of the properly registered users. Different variables including a user table and ITV user, and the set-top user are set. The ITV user is the player's individual information, while the set-top user associates that specific player with a specific set-top box. As discussed above, the ITV user information may include the pin, date of birth, certain kinds of eligibility, and the activity. If a long registration has been carried out, then the player name includes first and last name, address, city, State, ZIP, e-mail, phone number, and possibly other information.
The set-top user table may be stored within the game server, and when an existing player comes to a set-top box, that table gets a new entry for the new client ID. In addition, the game server updates the “last login” parameter for that user. When a user deletes a player account from the set-top box, the activity bit gets set to zero, and the player account does not actually get deleted. When the player logs in again to play, only those users were active is one are returned to the player as options.
A game tracking table maintains relatives scoring and game play information such as game scores and questions answered by each player. Capturing of this data enables determination of who is playing what games, how long they are playing, and other information about the questions which have been asked. The next table refers to question tracking, and may be maintained on the game server. Question tracking information indicates which players are playing which games, and the way the questions are answered. This can be used to evaluate question difficulty in the event that the questions are re-used at another time.
Each of the different tables may be maintained in a SQL database at the head end, and a nightly synchronization process may synchronize data between the game server and the session servers. This maintains and ensures that all data is mirrored on each database.
An important feature is that the architecture includes the tools that can be used for administration. These may be web-based or more generally remotely accessible tools, and can be used to schedule a scan, track player data, create game templates, monitor player account information, and monitor the service processes. Each tool is described separately.
An ad scheduling component allows scheduling, rotating and serving of advertisements throughout the game. The ad scheduling component uses specific codes within the question content file. Those codes dictate which ads are displayed at what time and in which order. The ad scheduler is downloaded as part of the game that is sent to the different local servers.
An ad tracking component allows accurately tracking the advertising views. Each time the player sends a score, the ads which have been viewed are sent along with that score. This provides accurate counts of the number of ad views, by tracking the actual number of client ads that have been displayed to the player. This data is stored in the session server database, and then synced with the game server database each evening.
Ad reporting tools can also be used to capture and report about ad serving data. Each time an ad is displayed, a number of information about the set-top box that displays the ad is collected, including:
The MAC address of the set-top box,
The date and time that the ad was displayed,
the ad ID,
The number of ad impressions indicating the number of times the ad was displayed,
The number of views, indicating the number of players who were logged in prior to the ad being displayed and who remained logged in for the duration after the ad was displayed.
In this way, the ad viewing can be accurately detected and reported.
A content aggregator tool can allow producers, managers etc. to create templates etc. These templates can form skins for the different games, allowing customization of the way the games look.
The head end administration tool provides operators with the ability to monitor player names and remove IDs from the database. For example, when a set-top box is returned, the player names from that set-top box can be removed by the administrator. Administrators who notice undesirable names within the login IDs may also be able to remove those players and submit additional words to the “dirty word list”.
The timing table module manages the creation of tables for games on the platforms. Each game has its own timing table which dictates the game structure and timing. The timing table is formed of a series of stages which includes events within the game timing table. The stages in the timing table make up the game sequence. In this way, the timing of the game can be set by an administrator.
The real-time statistics tools collect the necessary data to determine player traffic and game play trends. This can be used to optimize the kind of games which are played and used.
An overall monitoring administrative tool is used to monitor the session server and the game server. This allows the administrators to update and review all channel files, stop and restart servers, check on status updates of each service, check on exceptions of the service, check to see which messages the server can handle, check the status of schedule processes, and monitor the server activity for each deployment.
Any error message forms of a specific error message including date, timestamp, and time zone. It produces an error code produced from the game sought, group ID, subcode, an operator system. An error message is also provided.
A number of different kinds of errors referred to as in game error scenarios may also be displayed to the user.
Further detail on the content aggregator tool is provided herein. The content aggregator allows creating and deploying games by creating skin templates, graphics, and content for the media servers.
The following content may be included as part of the content aggregator.

First, definitions



Template	A template is the structure of framework defined
	by an MSO, Middleware, Local System and Locale
	type.
Skin	A skin is the collection of images, text, logos,
	colors, etc. that are specific to a template.
Template type	Each game skin requires a National, local, and
	Session template. When creating new templates,
	the type needs to be defined.
	The “type” exemplifies the framework of the
	template-whether it is the main game structure
	(National), specific to the local MSO (local),
	or specific to a game framework (session).
National	A National template is a master template for a
template	specific platform.
Local	A Local template is a template specific to the
template	Local MSO/per platform.
Session	A Session template is a template that is specific
template	to a game type.
National skin	The National skin is created from the National
	template and contains the properties that are
	specific to a game structure.
Local skin	A local skin is created from a local template and
	contains a properties that are specific to a
	local MSO on a specific platform.
Session skin	A session skin is created from a session
	template. Each game slot requires it own session
	skin. If there are 6 game slots that have the
	same format, each will have its own session skin,
	created from the main session template.
Property	A property is assigned to a template and defines
	a type of element that will be used in a skin.
Element	An element is an actual file or text that is
	attached to a property.
Game Type	This is a grouping of game types (Trivia, Arcade)
Package
Game Type	This is a specific type of game (Poker,
	Countdown, Kids Trivia, Checkers)
Content group	Not built yet
Template	These are elements that are associated with a
properties	game template.
Rules	Rules are specification for properties,
	including color values, character limitations,
	file size limitations, dimensions, etc.

Content Aggregator Navigation
Certain links are accessible from the top of every page in the content aggregator. As the user selects each view, the data will be displayed in the main page. Each page has custom search capabilities and every column is sortable.
Templates

- View templates>>click to view all the existing templates that have been created. This screen will list out all National, local, and session templates available.
- Create a new template>>click to create a new template (National, local, or session).
- Copy a template>>click to create a new template with the properties of an existing template already attached. Instead of having to create a new template and attach multiple properties, the user can select an existing template and copy over the existing properties all at once. From there, copy one to use as a new template.
- View unused templates>>click to view all templates that are not currently in use.

Properties

- View all properties>>click to view all properties that have been uploaded.
- Create a new property>>create a new property for a template.
- View unused properties>>click to view all properties that have been created, but not yet attached to a template.

Property Rules

- View all property rules>>click to view a list of all property rules that have been established. The rules will be grouped by MSO, but can be attached to any template.
- Create a new property rule>>click to add a property rule. This can then be attached to any template.
- View unused property rules>>click to view all property rules that have been created, but not yet attached to a template.

Skins

- View skins>>click to view all existing skins in the system, grouped by MSO and by the template to which it is associated.
- Copy a skin>>click to copy a skin that already exists.

Elements

- View elements>>click to view all elements in the system.
- Create a new element>>click to create a new element. The elements will then be available to attach to a property.
- View unused elements>>click to view elements that have been uploaded, but not yet attached to a skin.

Element Types

- View element types>>click to view all element types available. For instance, element types that exist right now are “ad,” “container,” “image,” “logo,” and “shape.”
- Create a new element type>>click to create a new element type. This new type will contain the framework for different elements.
- View unused element types>>click to view element types that have been created, but not yet assigned.

Element Subtypes

- View element subtypes>>click to view element subtypes.
- Create a new element subtype>>click to create new element subtypes.
- View unused element subtypes>>click to view element subtypes that have been created, but not yet assigned.

Admin

- Game type packages>>Click to view game type packages.
- View game type packages>>View all game type packages that have been created.
- Create new game type packages>>Create a new game type package. Once it is created, it can be assigned to a template.
- Scope types>>click to view scope types.
- View scope types>>click to view scope types. These are the types added to the system by an administrator, which will be options when creating new templates. These types denote the type of template that is being created (National, local, or session).
- Create a new scope type>>click to add a new scope type to the system. When added, the new “type” will be available in the “scope type” dropdown box shown when the user is creating a new template.
- Content builders>>click to view Content builders
- View Content builders>>view the existing types of content builder (Trivia, Arcade).
- Create a new content builder>>click to create a new content builder type.
- Copy items>>click to copy items.
- Unused items>>click to view all unused items.

Templates

- Locked when a skin that is using it is deployed (Locked means it cannot modified).
- Once a skin has been created from a template, the template cannot be deleted.
- A locked template cannot be unlocked, except through the database directly
- Right now, can't share templates across game types (trivia, arcade)—this may change.

Template Properties

- Locked when more than 1 template uses the same property OR a skin has been created using the template.
- A property remains unlocked if only 1 template uses it and a skin has not yet been created from it.
- Unlocked when 0 or 1 template uses it and there are no skins assigned to that template.

Template Property Rules

- Locked when more than 1 template property is using the rule.
- Unlocked when 0 or 1 template property is using the rule.

Elements

- Locked once assigned to a skin.
- Unlocked when not assigned to any skin.

Skins

- Locked once deployed.
- Unlocked (currently cannot be unlocked except thru database directly)
- Right now, can't share skins across game types (trivia, arcade)—this may change.

1.9 Rules: Game Type Packages/Game Types
The following items are affected by the rules surrounding game type packages:
Templates
Skins
Template Properties
Property Rules
Subtypes
Elements
The game type package is required for all of these. The game type setting can be configures to be usable for ANY game type within the same game type package, or for 1 particular game type. For the most part, most items that have a specific game type assigned to them are going to be used at the SESSION SCOPE level. The following rules apply for game types:
Templates

- If a template is usable for ANY game type, then all of the Template Properties must also be usable for ANY game type.
- If a template is usable for 1 particular game type, then it can use Template Properties specified for either ANY or that particular game type.
- When creating a Template, ask whether this is a common template that may be used across game types (then game type should be ANY), or if this property is so specific that it should only be sued for that particular game type.

Template Properties

- If a template property is usable for ANY game type, then its subtype must also be usable for ANY game type, also all of its Property Rules must be usable for ANY game type.
- If a template property is usable for 1 particular game type, then its subtype and its Property Rules can be for either ANY or that particular game type.
- When creating a Property, ask whether this is a common property that may be used across game types (then game type should be ANY), or if this property is so specific that it should only be used for that particular game type.

Property Rules

- When creating a Rule, ask whether this is a common rules that may be used across game types (then game type should be ANY), or if this rule is so specific that it should only be used for that particular game type.

Element Subtypes

- When creating a subtype, ask whether this is a common subtype that may be used across game types (then game type should be ANY), or if this subtype is so specific that it should only be sued for that particular game type.

Skins

- The skins game type is determined based on the template it is using and cannot be changed. So whatever the game type of the template, that will be the game type of the skin.

Elements

- When assigning an element to a skins property, the default game type of that element will be that of the skin (which is determined by the template).
- If the skins game type is for ANY, than the element will be usable by ANY
- If the skins game type is for 1 particular game type, then the element can be set to be either usable for ANY, or for the particular game type that the skin is.
- When creating a new element, ask whether this is a common element that may be used across game types (then game type should be ANY), or if this element is so specific that it should only be used for that particular game type.

NOTE: Since element's game type is determined based on the skin and not the particular property, it is possible to have the scenario where the element has a particular game type while the template property is usable for ANY game type. This is OK and actually preferable even though it may seem wrong at first.
In operation, the user uses the content aggregator to create templates and skins that are used for the game deployment. As noted above, the template is the basic structure that makes up a system. The properties are identified within the template and may include text, logos, colors and the like, and assigned to the template. Templates are made of combinations of these properties. Once the template has been created and the properties have been assigned, the template is ready to be skinned. The skins are created from a template to form the various screens again. Once these elements have been uploaded, the different parts can be sent to the media server, and eventually used to form the game skin and deploy that skin.
The process of deploying a game skin is illustrated in FIG. 6. At 600, the game is scheduled in the backend. 602 checks to see up a global skin has been assigned, and if not checks at 604 to see if there is a request for a new skin. If the skin is not new, then 604 checks if the skin is new, and if not checks If the skin has been deployed at 606, and if so it is used at 608, and flow returns. If the skin has not been deployed, then the skin is deployed to the media servers at 610. If the skin is not new at 604, then 612 checks at a template is available, and if not creates a template at 614. If a template is available at 612, then it is selected at 616. Either way, this information is used to create a skin at 618. Properties can be added at 620, where 620 refers to adding a property, 622 determines of the property is new, and if not it is selected at 624. If the property is new, it is created at 626. If all the properties have been properly assigned, at 626, a rule may be created at 628.
If a global skin has been assigned at 602, then 612 determines if a local skin is assigned. If not, the process follows a analogous path to that beginning at 604. Analogously, a session skin is detected at 632, if not, flow passes to 604. A schedule record is determined at 634.
An element may be selected at 636 to assigned to a property. 638 detects whether the element follows the properties rules, and if yes at the element is attached to the property. If not, the rules the element does not follow our shown at 642. Rules are created at 644 or selected at 646.
The above has extensively discussed the templates, and their use in forming skins. Once the national local and session templates have been created, as discussed above, the user needs to add properties to these templates. These properties determine the structure of the game on each level: national, local and session level. Once the properties have been created, the user needs to attach the specific properties to the template to which they are added. The user can add or attach properties to a template using the template tool.
FIG. 7 illustrates a screenshot of the template tool. The player can select templates, view templates, select the template to which properties are to be added, and edit the template. An existing template property can be added to the template from the list of available properties. Analogously, a new property can be added. The property can be defined according to its name, description, and family, element type, element subtype, and other characteristics. Once appropriately added, the template is saved, that new rule for the template or applied, edit, or created.
A tool that allows entering a new template property showing the different elements that can be added including the description, game type, and element type is also described. When the user saves this template, the screen refreshes, allowing the user the option to add rules to the property as shown in the screenshot of FIG. 9.
Different rules may be predefined, for different aspects of different games. For example, one predefined rule may be the width of the screen. Another predefined rule may be a height, number of characters, color, file size, file extensions, and others. A property rule can be defined in terms of any of these characteristics. FIG. 10 illustrates a screenshot showing the different property rules that can be created using predefined problem types.
As another alternative, properties can be copied from the existing templates. Users can simply choose to copy a template property from the main navigation links at the top of the page. This frees the user of the need to create a new template and attach all the properties to that template. A good example of the usefulness of this system is if six games are running in one area, and the user wants to launch the same games in another service area, the properties from the one area can be copied to the new area. The copy template includes the same properties as the original template, which may include the properties of width, height, characters, color (red, green, blue), file size, file extensions, and the like. Templates can also be edited, to change to another template property. Conversely, both the templates and the skins can be locked to prevent their editing.
A skin can be created from any template on the system. This is done by first taking the template to be used for the skin, and requesting to make a skin using that template.
As part of the game formation, administrators can log in, and based on their permissions, can access different aspects of the trivia back end. The back end users can sort and classify records in a way that may improve the game composition. For example, a ratings system using a scale between one and 10 may allow the games to be sorted based on their difficulty. Difficulty ratings are dynamically adjusted based on average player performance/score as measured during online play. This allows the game content to be tailored to audience expectation. Ratings are initially entered by the editors, but adjusted based on real information obtained during the real play. For example, the average player score during a question may be used to set its difficulty rating, where if the average players score is over 900, the difficulty rating is one, where if the average players score is less than zero, the difficulty rating may be 10. Difficulty ratings may be changed depending on the desired demographic characteristics. Another backend control is the spot generator. Administrators can log in based on assigned permissions, and creates spots by uploading conforming images or other media, as well as designating a name, advertiser, game type and the like. Spots are scheduled nationally or locally to run either in specified times or randomly. In operation, the user can upload an image and fill out a form to create a spot that is available for schedule in specified markets. The user fills out the name, the advertiser, the owner, and the game type package that corresponds to the image being uploaded. Different spot types may be used for different users. In another scenario, a user can view available slots, allowing the user to figure out which spots are available. Another scenario allows the user to schedule one of the spots. To do this, the user selects a spot, and selects different aspects. First pay period type indicates whether the spot will be one time, or repeating in some way either daily, weekly or continually. Start and end times and dates are created. An ad order is selected in the order the spot should air. The ad order includes a first order which is a random behavior, a second order which is a given date and time, and others. A priority characteristic allows the new entered ad to take priority over the rest of the pool.
Schedule viewing may allow the users to view the different schedules.
Reports can also be generated. Data is captured and displayed indicating different aspects of different slots. The data which is captured and display may include the total airing indicating how often a spot has been displayed, the total number of unique views, defined as the number of unique MAC addresses that view a particular spot, the total views, which is the cumulative number of views, either by unique MAC addresses or by MAC addresses that are yet not unique, and the unique player views indicating the number of unique views by player name. Custom searches are also available, to provide special information about reporting beyond this.
Event tracking is also possible. In the event tracking scenario, the administrators track all actions and modifications taken by the users. This may include creating a spot, editing a spot, scheduling the spot, editing a schedule, archiving the spot or on archiving the spot, deleting the spot, creating editing or deleting entries in an administrative table.
An administration scenario allows changing of the spot based on new platforms and game types.
Schedule changes which are made, are only made locally. A force schedule update function enables the users to force their updates which have been made to the head end.
FIG. 11A illustrates the create a spot user interface, showing the features discussed above. FIG. 11B illustrates the different spots in the view spots function. FIG. 11C shows the way a spot can be scheduled by the system. FIG. 11D illustrates the spots which are active. FIG. 11E shows the schedule list. Finally, FIG. 11F shows the schedule snapshot and FIG. 11G shows the schedule calendar. The reporting screen is shown in FIG. 11I, which can report by days, or by games, or by event tracking.
A flowchart of the spot creation is shown in FIG. 12. Another backend tool is the trivia editor which enables people from some remote locations to enter trivia which can be analyzed by the system. The initial screen enables users to enter new data.
FIG. 13 shows a screenshot of the screen for creating a question. Note that the screen includes a provision of selecting the different formats, such as countdown or the like, and also includes different fields. The question is entered at 1302, while the user enters different clues, which are presented to players after a certain amount of time. The right and wrong answers are entered at 1304, and a fun fact is entered at 1306. An expiration date can be set at 1308. This might be used, for example, for something that is a relatively current event. The question editor enters the difficulty, which can be changed based on player operations. Category types can also be entered at 1312. Out of the questions which are answered and the possible questions, the user selects the one that is correct.
Only writers who have an account on the extranet web server can upload a question that could be used as part of the trivia system. The questions submitted can be checked online, to determine if they have been accepted or not.
The general structure and techniques, and more specific embodiments which can be used to effect different ways of carrying out the more general goals have been described herein.
Although only a few embodiments have been disclosed in detail above, other embodiments are possible and the inventor (s) intend these to be encompassed within this specification. The specification describes specific examples to accomplish a more general goal that may be accomplished in other way. This disclosure is intended to be exemplary, and the claims are intended to cover any modification or alternative which might be predictable to a person having ordinary skill in the art. For example, other games and platforms may be used by this system.
Also, the inventor(s) intend that only those claims which use the words “means for” are intended to be interpreted under 35 USC 112, sixth paragraph. Moreover, no limitations from the specification are intended to be read into any claims, unless those limitations are expressly included in the claims.
The computers described herein may be any kind of computer, either general purpose, or some specific purpose computer such as a workstation. The computer may be a Pentium class computer, running Windows XP or Linux, or may be a MacIntosh computer. The programs may be written in C, or Java, or any other programming language. The programs may be resident on a storage medium, e.g., magnetic or optical, e.g. the computer hard drive, a removable disk or other removable medium. The programs may also be run over a network, for example, with a server or other machine sending signals to the local machine, which allows the local machine to carry out the operations described herein.
Although only a few embodiments have been disclosed in detail above, other embodiments are possible and the inventors intend these to be encompassed within this specification. The specification describes specific examples to accomplish a more general goal that may be accomplished another way. This disclosure is intended to be exemplary, and the claims are intended to cover any modification or alternative which might be predictable to a person having ordinary skill in the art. The computers described herein may be any kind of computer, either general purpose, or some specific purpose computer such as a workstation. The computer may be a Pentium class computer, running Windows XP or Linux, or may be a Macintosh computer. The programs may be written in C, or Java, or any other programming language. The programs may be resident on a storage medium, e.g., magnetic or optical, e.g. the computer hard drive, a removable disk or other removable medium. The programs may also be run over a network, for example, with a server or other machine sending signals to the local machine, which allows the local machine to carry out the operations described herein.
Also, the inventors intend that only those claims which use the words “means for” are intended to be interpreted under 35 USC 112, sixth paragraph. Moreover, no limitations from the specification are intended to be read into any claims, unless those limitations are expressly included in the claims.

Claims

1. A method, comprising:

playing a game over a network by forming a plurality of questions to be answered by each of a plurality of users associated with the network;

sending said questions to each of said users over the network;

scoring the user answers of based on both whether an answer is correct, and how fast the answer is given;

giving hints about answers to the questions when a user takes longer than a specified amount of time to enter the question; and

after a time for answering the question is complete, displaying the correct answer and also displaying a fact related to the question, to each user.

2. A method as in claim 1, wherein the game is played over the network, using a game server to coordinate all users to answer all questions, and using local servers, each local server connected to the game server, and each local server coordinating responses of a plurality of local users, which is less than all of local users.

3. A method as in claim 2, further comprising assembling global statistics about all users, using the game server to assemble all the statistics, and wherein the local server receives statistics from a local user, and sends those statistics to the game server.

4. A method as in claim 2, further comprising storing a plurality of questions at the local servers, each of the plurality of questions and answers representing information to be used for a game at a future time.

5. A method as in claim 1, wherein said plurality of questions each include an XML file representing the question, and additional information representing additional information to be displayed as part of the question.

6. A method as in claim 5, wherein said additional information includes pictures and other media.

7. A method as in claim 3, wherein the local server sends only some of the statistics to the game server.

8. A method as in claim 1, further comprising associating at least one of the questions with an expiration information, and preventing the question from being used after said expiration.

9. A method, comprising:

at a first server, storing a plurality of questions and answers which can be used to form a game, and storing global statistic information related to all users' previous playing of the game;

sending questions and answers from the first server to a plurality of second servers;

at each of the second servers, carrying out a game operation allowing a plurality of users to see the questions, and answer the questions, and receiving scores from each of the plurality of users about the questions;

sending only part of those scores from the users from this plurality of second servers to the first server; and

maintaining global scores of each of the users playing the game on the first server.

10. A method as in claim 9, further comprising providing advertising to the users from the second servers, where at least one of the second servers has different advertising content then a different one of the second servers.

11. A method as in claim 10, wherein the advertising content is local advertising content, for an area of said at least one of said second servers that is local to said at least one second server.

12. A method as in claim 9, wherein said first server stores a plurality of questions which include expiration dates that indicate a date after which the questions are no longer used.

13. A method as in claim 9, wherein said questions are stored in XML format.

14. A method as in claim 9, further comprising storing at least one days worth of questions at each of the second servers.

15. A game system, comprising:

a main server, storing a plurality of questions and answers, and storing global statistics about answering of the questions;

a plurality of secondary servers, each connected to the main server, receiving questions and answers therefrom, and coordinating the game with a plurality of users, and reporting back some, but not all, of statistics about the game being played by the plurality of users using the questions; and

said main server sending, to each of the secondary servers and displayed to each of the players, global statistics about ranking of each of the players relative to all the other players.

16. A system as in claim 15, wherein the main server stores each of the plurality of questions and answers in XML format.

17. A system as in claim 15, wherein the secondary server stores advertising content and causes each of the plurality of users connected to the secondary server to view said advertising content, where advertising content for one of the secondary servers is different than advertising content for others of the secondary servers.

18. A system as in claim 15, wherein said plurality of questions and answers include hints associated with the questions and answers, and also includes at least one fact associated with the questions and answers, said fact to be displayed at the same time as the answer is displayed.

19. A system as in claim 15, further comprising a memory at each of the secondary servers, storing at least one days worth of cached questions for games.

20. A system as in claim 15, wherein the main server stores at least some of the plurality of questions with expiration dates associated therewith.