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.
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.
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.
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.
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.
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
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
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,
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
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
Properties
Property Rules
Skins
Elements
Element Types
Element Subtypes
Admin
Templates
Template Properties
Template Property Rules
Elements
Skins
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
Template Properties
Property Rules
Element Subtypes
Skins
Elements
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
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.
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
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.
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.
A flowchart of the spot creation is shown in
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.
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.
Number | Date | Country | |
---|---|---|---|
60641247 | Jan 2005 | US |