US20060089200A1 - Systems and methods for processing game metrics from handheld computing devices - Google Patents

Systems and methods for processing game metrics from handheld computing devices Download PDF

Info

Publication number
US20060089200A1
US20060089200A1 US11/228,470 US22847005A US2006089200A1 US 20060089200 A1 US20060089200 A1 US 20060089200A1 US 22847005 A US22847005 A US 22847005A US 2006089200 A1 US2006089200 A1 US 2006089200A1
Authority
US
United States
Prior art keywords
game
score
handheld computing
server
computing device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/228,470
Inventor
Timothy Twerdahl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inventec Appliances Corp
Original Assignee
Inventec Appliances Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inventec Appliances Corp filed Critical Inventec Appliances Corp
Priority to US11/228,470 priority Critical patent/US20060089200A1/en
Assigned to INVENTEC APPLIANCES CORPORATION reassignment INVENTEC APPLIANCES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: TWERDAHL, TIMOTHY D.
Priority to TW95100885A priority patent/TWI300357B/en
Publication of US20060089200A1 publication Critical patent/US20060089200A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/79Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/798Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for assessing skills or for ranking players, e.g. for generating a hall of fame
    • A63F13/12
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/90Constructional details or arrangements of video game devices not provided for in groups A63F13/20 or A63F13/25, e.g. housing, wiring, connections or cabinets
    • A63F13/92Video game devices specially adapted to be hand-held while playing
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5546Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/558Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by assessing the players' skills or ranking

Definitions

  • the present invention relates generally to handheld computing devices, and more particularly to systems and methods for processing game metrics from handheld computing devices.
  • Video games have historically stored a list of high scores, so gamers can measure their own performance and their performance against other gamers.
  • the list of high scores also provides a sense of competition between gamers and goals for gamers to achieve.
  • Some arcade games are connected to a network, so an aggregate list of high scores can be displayed at each arcade game.
  • a user receives a code upon completion of the game. The user could then call an 800 number with the code to win a competition for the first to complete Zelda.
  • Handheld gaming devices also keep high scores for certain games. For some games, a user receives a code from the handheld gaming device. The user then manually enters the code and the score at a website for a certain game. The website can then display a list of high scores for games on the handheld gaming device.
  • One problem with this system is that there is no way to automatically generate a list of high scores for games on handheld devices.
  • a system for processing game metrics includes a handheld computing device and a game metric server.
  • the handheld computing device captures the game metrics for a game and transfers the game metrics.
  • the game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.
  • the system for processing game metrics from a handheld computing device automatically transfers the game metrics to a game metric server that can manage and share game metrics such as high scores for games.
  • game metrics such as high scores for games.
  • players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world.
  • the system allows for development of time-dependent tournaments and competitive game ladders for games on handheld computing devices.
  • FIG. 1 is an illustration of a system for game metrics in an exemplary implementation of the invention
  • FIG. 2 is a flowchart for a handheld computing device executing a game metric reporting application programming interface in an exemplary implementation of the invention
  • FIG. 3 is a flowchart for a computer system executing conduit software in an exemplary implementation of the invention.
  • FIG. 4 is a flowchart for a game metric server executing game metric processing software in an exemplary implementation of the invention.
  • Game metrics include any score, measurement, or status that indicates progress in a game.
  • One example of a game metric is a high score for a game.
  • the game metrics are transferred from the handheld computing device to a game metric server that manages and shares high scores for games.
  • the game metric is a type of score that is a 32 bit unsigned integer.
  • Game metrics are points, times, goals, and scores for tournaments.
  • Game metrics may be organized by different score types, where each score type is treated as a totally independent score category.
  • a ‘normalized score’ is not displayed to the user via a high score manager or a website running on the game metric server.
  • a formatted string accompanies each score and is displayed for the user. This provides flexibility to the applications to report scores in various ways such as times, points, kills, or goals. If a combination of variables is important to game play (e.g. best time and most kills and most secrets discovered), then the game can combine these values into one 32-bit value for comparison purposes.
  • the string for the game metric can be formatted to describe different score attributes.
  • the scorer for a given game can be considered to be the registered owner of the device. In some embodiments, there is one date included for each high score record.
  • FIG. 1 depicts an illustration of a system 100 for game metrics in an exemplary implementation of the invention.
  • the system 100 includes a handheld computing device 110 , a computer system 120 , a communication network 130 , and a game metric server 140 .
  • the handheld computing device 110 is coupled to the computer system 120 .
  • the computer system 120 is coupled to the communication network 130 .
  • the communication network 130 is coupled to the game metric server 140 .
  • the elements in FIG. 1 can be coupled together by either wired or wireless connections.
  • the handheld computing device 110 is any handheld device that includes a processor for executing instructions and is configured to capture the game metrics for a game and transfer the game metrics to the computer system 120 .
  • Some examples of the handheld computing devices are handheld gaming devices, personal digital assistants, and mobile phones.
  • One embodiment of the handheld computing device 110 is the Zodiac gaming device from Tapwave of Mountain View, Calif.
  • the handheld computing device 110 includes a game metric reporting Application Programming Interface (API) 115 .
  • the game metric reporting API 115 can be any other type of software program operating in accord with the invention. The operation of the handheld computing device 110 executing the game metric reporting API 115 is described in further detail below in FIG. 2 .
  • the game metric reporting API 115 includes a high score manager configured to store all the high scores for all games on a given device. In some embodiments, each application on the handheld computing device 110 can control how many high scores are saved.
  • the computer system 120 is any computer with a processor for executing instructions and that is configured to transfer game metrics from the handheld computing device 110 to the game metric server 140 via the communication network 130 .
  • the computer system 120 includes conduit software 125 for synchronization to transport the data between the handheld computing device 110 and the game metric server 140 .
  • the operation of the computer system 120 executing the conduit software 125 is described in further detail below in FIG. 3 .
  • the conduit software transmits only the highest local score per game and score type to the game metric server 140 .
  • the communication network 130 is any network of communication devices. Some examples of the computer network 130 are the Internet, PSTN, local area network, and wide area network.
  • the game metric server 140 is any system or server configured to receive and process game metrics from the handheld computing device 110 .
  • the game metric server 140 includes a web front end to sort, filter, and display the high score data.
  • the game metric server 140 includes game metric processing software 145 . The operation of game metric server 140 executing the game metric processing software 145 is described in further detail below in FIG. 4 .
  • FIG. 2 depicts a flowchart for the handheld computing device 110 executing the game metric reporting API 115 in an exemplary implementation of the invention.
  • FIG. 2 begins in step 200 .
  • the handheld computing device 110 executing the game metric reporting API 115 captures scores from game software running on the handheld computing device 110 .
  • the handheld computing device 110 generates a master record for score type and game.
  • the high score manager also allows each game to include a 32 bit “checksum” value with each score, which can be used to validate that the score was actually achieved during game play, and not simply added to the database using, for example, PalmOS APIs. It would be up to the game developer to decide how to generate and validate the checksum, and conspire with the web site developer to filter scores that fail checksums. Checksums assist with integrity of the game metrics because some game players may be tempted to get higher scores by either hacking the game or hacking the score reporting mechanism.
  • all high score data is stored in a single record database, with the records laid out in a 68K (big-endian) format.
  • the high score database can be a record database, with the name “High Scores”, the creatorID ‘twHS’, and the data manager type ‘DATA’.
  • the creatorlD associates the high score database with a dummy “High Score” application, which is embedded in the ROM of the handheld computing device 110 , always present, and thus should always allow the conduit software to run.
  • the high score database has an applnfo structure which should contain the following information: TYPE (size) Field Name Field Description Int32 (4) syncWithServer If non-zero, the conduit should attempt connections to the server.
  • the database is maintained in sorted order for efficient access. Overall the records are kept sorted by creatorID and scoreType, so that all records for a given game/type combination will sort together. Within this set, the master record is always first (and always present if any scores are present), followed by 0 or more local scores and then 0 or more server scores.
  • the following table illustrates one embodiment for the master record.
  • Type Size
  • UInt32 (4) CreatorID The unique, registered creatorID of the game.
  • UInt16 (2) ScoreType The arbitrarily chosen type identifier for this score.
  • UInt16 (2) RecordType Identifies a master record (and sorts first).
  • MASTER_ID 0
  • Char* (var) GameName The rest of the record is character data that contains the user-visible name of the game for the High Score manager.
  • the handheld computing device 110 generates a score record for the saved score.
  • the following table illustrates one embodiment for the score record.
  • Type (Size) Field Name Field Description UInt32 (4) CreatorID The unique, registered creatorID of the game.
  • UInt16 (2) ScoreType The arbitrarily chosen type identifier for this score
  • UInt32 (4) Score The normalized score value.
  • UInt32 (4) Checksum A checksum, used to validate the score value.
  • UInt32 (4) timeAndDateUTC The date and time that the score was reported, as time in seconds since midnight Jan. 1, 1904 in UTC. Char* userString The (null-terminated) string that goes with the (var) score. For server scores, the user string is prefixed with the alias of the scorer followed by the tab character.
  • the handheld computing device 110 stores the master record and the score record for synchronization between the handheld computing device 110 and the computer system 120 .
  • the handheld computing device 110 determines whether synchronization is occurring. If there is no synchronization, the handheld computing device 110 proceeds to step 214 . If synchronization is occurring, the handheld computing device 110 transmits the master record and the score record to the computer system 120 in step 212 . FIG. 2 ends in step 214 .
  • FIG. 3 depicts a flowchart for the computer system 120 executing the conduit software 125 in an exemplary implementation of the invention.
  • FIG. 3 begins in step 300 .
  • the computer system 120 executing the conduit software 125 determines whether synchronization is occurring between the handheld computing device 110 and the computer system 120 . If synchronization is not occurring, the computer system 120 proceeds to step 318 . If synchronization is occurring, the computer system 120 receives the master record and the score record from the handheld computing device 110 .
  • the conduit software 125 transfers all scores from the handheld computing device 110 , effectively backing up the high score records. Any records deleted on the handheld computing device 110 will also be deleted on the computer system 120 .
  • step 306 the computer system 120 then determines whether the score from the master record and the score record is the high score. If the highest score for a given master record (game+scoreType combination) is new, then the score needs to be transmitted to the game metric server 140 . If the score is not a high score, the computer system 120 proceeds to step 318 .
  • the computer system 120 checks whether the sync with server flag is set in step 308 .
  • the conduit software 125 checks an “opt in” setting stored on the handheld computing device 110 . Server connections will only be attempted if the user has enabled them, by setting the appropriate flag on the handheld computing device 110 . If the sync with server flag is not set, the computer system 120 proceeds to step 318 . If the sync with server flag is set, the computer system 120 determines whether the server is enabled for a game and score type in step 310 . If the server is not enabled for a game and score type, the computer system 120 proceeds to step 318 .
  • the computer system 120 determines whether a connection is established to the game metric system 140 via the communication network 130 in step 312 .
  • the connection to the game metric server 140 needs to be live during synchronization for the transaction to take place.
  • the computer system 120 is not connected to the Internet at the time of synchronization, or if the server is unresponsive, then the data is not transferred. In this example, the user needs to synchronize again to re-attempt the connection.
  • a handheld computing device 110 restore, all records should be restored to the handheld computing device 110 during synchronization.
  • conflict rules are fixed: the handheld computing device 110 overrides the computer system 120 for game master records and local scores, the computer system 120 overrides the handheld computing device 110 for server based scores.
  • the computer system 120 transmits the game metrics to the game metric server 140 in step 314 . If a connection is not established, the computer system 120 stores the master record and the score record for future synchronizations in step 316 .
  • the game metrics that are transferred to the game metric server 140 are in an Uniform Resource Locator (URL) format.
  • game score submission consists of sending a URL with specified name/value parameters in the query string to the game metric server 140 that describes a score for a particular game played on the user's device.
  • the server component that handles this request can be a Java Servlet.
  • the Servlet should be written such that either an HTTP Post or HTTP Get message of the specified URL will be handled in the same manner. In other words, the doGet( ) and doPost( ) methods of the Servlet should be written to call the same logic.
  • hardwareID A 16 digit base-34 value A unique value that identifies the hardware “0T000139C111601J” device. This value comes from the Road Dawg hardware ROM. creatorID 32 bit unsigned hex integer A 4-byte value that unique defines an “0x00000000 . . .
  • 0xFFFFFFFFFF application developer. While this value is most likely a 4 letter value (e.g. DOOM, ADDR) its representation it is still defined as an integer.
  • the CreatorID is also assigned by Palm.
  • scoreType 16 bit unsigned decimal A value used to define which game type integer this score is associated (used primarily for “0 . . . 65535” game tournaments to identify a score being submitted for a tournament).
  • score 32 bit unsigned decimal A numerical value that describes a score integer achieved for a particular game. “0..4294967295” checksum 32 bit unsigned hex integer Used to verify a score was created on a “0xFFFFFFFF” device, rather than a faked score. Currently not evaluated on the server.
  • this is a high score for the game (for this user) is determined by the game metric server 140 .
  • the information is recorded that this particular user has played a particular game and achieved a score. If the game metric server 140 determines that the score is a high score (for this user) for the game, it will be stored in a high score repository.
  • the scoreType value will be used to relate a score to a particular tournament being played.
  • the checksum value is used as a further check to verify the integrity of the score being submitted. Ultimately, the checksum value will be used to ensure that the score is genuine.
  • the recorded parameter is used to timestamp when the high score was achieved. It should be sent as a long value, which contains the number of milliseconds since the Epoch (Jan. 1, 1970 00:00:00) in UTC (i.e. GMT).
  • the userString value defines a displayable format for scores and is used on the Zodiac/Zorro device. This value should be stored within the server database for a high score. There can be characters within the string that may have to be escaped when sending back to the client (e.g. a space needs to be converted into %20). FIG. 3 ends in step 318 .
  • FIG. 4 depicts a flowchart for the game metric server 140 executing the game metric processing software 145 in an exemplary implementation of the invention.
  • FIG. 4 begins in step 400 .
  • the game metric server 140 executing the game metric processing software 145 receives the game metric in the URL format from the computer system 120 via the communication network 130 .
  • the game metric server 140 determines whether the score is the high score for the user ID, game creator ID, and score type. If the score is not the high score, the game metric server 140 proceeds to step 410 .
  • the game metric server 130 stores all score data (as defined above) for only the highest score for each combination of: user ID (looked up from device serial number)+game creatorID+game scoreType. If a higher score with matching user ID, creatorlD and scoreType is sent, the existing record is replaced with the new higher record.
  • the algorithm for taking into account whether a new score belongs in the high score table includes the following:
  • the game metric server 140 stores the master record and the score record in step 406 . In step 408 , the game metric server 140 stores the checksum value for future validation.
  • the game metric server 140 transmits an Extended Mark-up Language (XML) response back to the computer system 120 indicating the status of the high score submission.
  • the response to the score submission may be an XML-formatted message that provides status for the operation.
  • One field will describe the message status.
  • a description field will provide more detailed information about what happened.
  • a successful high score submission to the game metric server 140 returns in the HTTP sponse header the status value of 200 (which is the well known value returned by HTTP servers for a success request operation). In this case, the XML-formatted response will exist. In the event of a server error, the status code of 500 (Internal server error) will be returned, and no XML-formatted response message will exist.
  • the status field within the XML response message will describe what took place on the game metric server 140 when this high score submission was made.
  • the value of this field is numeric, and can take on the following values: Status value Description 100 A score did not exist for this user and game; therefore a new high score was added into the high score database. 101 A score did exist for this user and game, and the submitted score is higher; therefore the existing high score was updated. 102 A score did exist for this user and game, and the submitted score is not higher; therefore the existing high score remains. 103 The specified user (identified by the SecurityID value) does not exist within the system. No high score was added to the system. 104 A general error occurred while parsing the input parameters
  • step 412 the game metric server 140 displays the high score for a creator ID and score type.
  • the games on the handheld computing device 110 can have a play mode that is validated for tournaments. In this play mode, cheats are disabled, and as much as possible the game experience is normalized to that scores on different devices can be compared. The resulting scores are reported as a new scoreType for the same game.
  • a tournament can be run on a server by looking specifically for high scores from the given game and game type, reported within a particular time range, and generated on the handheld computing device 110 within a particular time range. For tournament play, special attention should be given to the checksums for the scores.
  • the game metric server 140 receives a high score request.
  • an application on the handheld computing device 110 requests that a certain number of highest scores can be retrieved from the game metric server 140 , which depends on other variables such as whether the user is registered with the website and how often the user synchronizes.
  • the conduit software 125 queries the game metric server 140 for the top N high scores for each game and score type, and the existing server score records on the handheld computing device 110 is replaced with the new scores from the game metric server 140 .
  • the userString for the high scores is prefixed with the alias that corresponds to the original high score, followed by the tab character. For example, if device A reports a high score as “100 points”, and is registered to “Mad Bob”, the game metric server 140 reports the high score with the user string “Mad Bob ⁇ t100 points”.
  • HardwareID A 16 digit base-34 value A unique value that identifies the hardware device. This value comes from the Road Dawg hardware ROM. CreatorID 32 bit unsigned hex integer A 4-byte value that unique defines an “0x00000000 . . . 0xFFFFFFFF” application developer. While this value is most likely a 4 letter value (e.g.
  • DOOM, ADDR DOOM, ADDR
  • the CreatorID is also assigned by Palm.
  • ScoreType 16 bit unsigned decimal A value used to define which game type integer this score is associated (used primarily for “0 . . . 65535” game tournaments to identify a score being submitted for a tournament).
  • Scores Integer A value used to limit the number of scores “0 . . . 32767” for a game returned.
  • a practical maximum value is the largest signed 16 bit number, which is the maximum number of records that can exist in a PalmOS database.
  • Requests for game scores can be made on the server, which will return the information as an xml-formatted message.
  • step 416 the game metric server 140 transmits the high scores in an XML formatted message.
  • FIG. 4 ends in step 418 .
  • the above-described functions can be comprised of instructions that are stored on storage media. These instructions can be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with the invention. Those skilled in the art are familiar with instructions, processor, and storage media.

Abstract

A system for processing game metrics includes a handheld computing device and a game metric server. The handheld computing device captures the game metrics for a game and transfers the game metrics. The game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application claims the benefit of U.S. Provisional Application No. 60/610,317 filed Sep. 15, 2004 and titled “Systems and Methods for Processing Game Metrics from Handheld Computing Devices” which is incorporated herein by reference.
  • BACKGROUND
  • 1. Field of the Invention
  • The present invention relates generally to handheld computing devices, and more particularly to systems and methods for processing game metrics from handheld computing devices.
  • 2. Description of the Prior Art
  • Video games have historically stored a list of high scores, so gamers can measure their own performance and their performance against other gamers. The list of high scores also provides a sense of competition between gamers and goals for gamers to achieve. Some arcade games are connected to a network, so an aggregate list of high scores can be displayed at each arcade game.
  • In one example of a video game called Zelda for console games, a user receives a code upon completion of the game. The user could then call an 800 number with the code to win a competition for the first to complete Zelda. Handheld gaming devices also keep high scores for certain games. For some games, a user receives a code from the handheld gaming device. The user then manually enters the code and the score at a website for a certain game. The website can then display a list of high scores for games on the handheld gaming device. One problem with this system is that there is no way to automatically generate a list of high scores for games on handheld devices.
  • SUMMARY OF THE INVENTION
  • The invention provides systems and methods for processing game metrics from handheld computing devices. A system for processing game metrics includes a handheld computing device and a game metric server. The handheld computing device captures the game metrics for a game and transfers the game metrics. The game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.
  • The system for processing game metrics from a handheld computing device automatically transfers the game metrics to a game metric server that can manage and share game metrics such as high scores for games. Thus, players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world. Besides simple high scores lists, the system allows for development of time-dependent tournaments and competitive game ladders for games on handheld computing devices.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is an illustration of a system for game metrics in an exemplary implementation of the invention;
  • FIG. 2 is a flowchart for a handheld computing device executing a game metric reporting application programming interface in an exemplary implementation of the invention;
  • FIG. 3 is a flowchart for a computer system executing conduit software in an exemplary implementation of the invention; and
  • FIG. 4 is a flowchart for a game metric server executing game metric processing software in an exemplary implementation of the invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • The embodiments discussed herein are illustrative of one example of the present invention. As these embodiments of the present invention are described with reference to illustrations, various modifications or adaptations of the methods and/or specific structures described may become apparent to those skilled in the art. All such modifications, adaptations, or variations that rely upon the teachings of the present invention, and through which these teachings have advanced the art, are considered to be within the spirit and scope of the present invention. Hence, these descriptions and drawings should not be considered in a limiting sense, as it is understood that the present invention is in no way limited to only the embodiments illustrated.
  • The invention provides systems and methods for processing game metrics from handheld computing devices. Game metrics include any score, measurement, or status that indicates progress in a game. One example of a game metric is a high score for a game. The game metrics are transferred from the handheld computing device to a game metric server that manages and shares high scores for games. Thus, players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world. In one embodiment, the game metric is a type of score that is a 32 bit unsigned integer.
  • Other examples of game metrics are points, times, goals, and scores for tournaments. Game metrics may be organized by different score types, where each score type is treated as a totally independent score category. In some embodiments, a ‘normalized score’ is not displayed to the user via a high score manager or a website running on the game metric server. A formatted string accompanies each score and is displayed for the user. This provides flexibility to the applications to report scores in various ways such as times, points, kills, or goals. If a combination of variables is important to game play (e.g. best time and most kills and most secrets discovered), then the game can combine these values into one 32-bit value for comparison purposes. The string for the game metric can be formatted to describe different score attributes. The scorer for a given game can be considered to be the registered owner of the device. In some embodiments, there is one date included for each high score record.
  • FIG. 1 depicts an illustration of a system 100 for game metrics in an exemplary implementation of the invention. The system 100 includes a handheld computing device 110, a computer system 120, a communication network 130, and a game metric server 140. The handheld computing device 110 is coupled to the computer system 120. The computer system 120 is coupled to the communication network 130. The communication network 130 is coupled to the game metric server 140. The elements in FIG. 1 can be coupled together by either wired or wireless connections.
  • The handheld computing device 110 is any handheld device that includes a processor for executing instructions and is configured to capture the game metrics for a game and transfer the game metrics to the computer system 120. Some examples of the handheld computing devices are handheld gaming devices, personal digital assistants, and mobile phones. One embodiment of the handheld computing device 110 is the Zodiac gaming device from Tapwave of Mountain View, Calif.
  • The handheld computing device 110 includes a game metric reporting Application Programming Interface (API) 115. In some embodiments, the game metric reporting API 115 can be any other type of software program operating in accord with the invention. The operation of the handheld computing device 110 executing the game metric reporting API 115 is described in further detail below in FIG. 2.
  • In some embodiments, the game metric reporting API 115 includes a high score manager configured to store all the high scores for all games on a given device. In some embodiments, each application on the handheld computing device 110 can control how many high scores are saved.
  • The computer system 120 is any computer with a processor for executing instructions and that is configured to transfer game metrics from the handheld computing device 110 to the game metric server 140 via the communication network 130. The computer system 120 includes conduit software 125 for synchronization to transport the data between the handheld computing device 110 and the game metric server 140. The operation of the computer system 120 executing the conduit software 125 is described in further detail below in FIG. 3. In some embodiments, the conduit software transmits only the highest local score per game and score type to the game metric server 140.
  • The communication network 130 is any network of communication devices. Some examples of the computer network 130 are the Internet, PSTN, local area network, and wide area network.
  • The game metric server 140 is any system or server configured to receive and process game metrics from the handheld computing device 110. In some embodiments, the game metric server 140 includes a web front end to sort, filter, and display the high score data. The game metric server 140 includes game metric processing software 145. The operation of game metric server 140 executing the game metric processing software 145 is described in further detail below in FIG. 4.
  • FIG. 2 depicts a flowchart for the handheld computing device 110 executing the game metric reporting API 115 in an exemplary implementation of the invention. FIG. 2 begins in step 200. In step 202, the handheld computing device 110 executing the game metric reporting API 115 captures scores from game software running on the handheld computing device 110.
  • In step 204, the handheld computing device 110 generates a master record for score type and game. The high score manager also allows each game to include a 32 bit “checksum” value with each score, which can be used to validate that the score was actually achieved during game play, and not simply added to the database using, for example, PalmOS APIs. It would be up to the game developer to decide how to generate and validate the checksum, and conspire with the web site developer to filter scores that fail checksums. Checksums assist with integrity of the game metrics because some game players may be tempted to get higher scores by either hacking the game or hacking the score reporting mechanism.
  • In some embodiments, all high score data is stored in a single record database, with the records laid out in a 68K (big-endian) format. The high score database can be a record database, with the name “High Scores”, the creatorID ‘twHS’, and the data manager type ‘DATA’. The creatorlD associates the high score database with a dummy “High Score” application, which is embedded in the ROM of the handheld computing device 110, always present, and thus should always allow the conduit software to run. The high score database has an applnfo structure which should contain the following information:
    TYPE
    (size) Field Name Field Description
    Int32 (4) syncWithServer If non-zero, the conduit should
    attempt connections to the server.
    Chars (16) deviceSerialNum The 16 digit base-34 device serial
    number, read from the hardware.
    This is just a copy of the serial
    number, and it will be validated (and
    changed if necessary) during normal
    device operations.
    UInt32 (4) serverSyncTimeUTC Time in seconds since midnight Jan.
    1, 1904 in the UTC time zone that the
    server sync was last completed. 0 if
    never synced.
    Char* Alias The alias used by the user on the
    (var) Tapwave website, created at
    registration, cached here for use by
    games.
  • There are two types of records stored in the database, a ‘master’ record for each combination of score type and game, and one ‘score’ record for each saved score. Both the server pool and the local pool use the same record format. Both the master record and score records have the same format for the first 3 fields, which aids sorting.
  • The database is maintained in sorted order for efficient access. Overall the records are kept sorted by creatorID and scoreType, so that all records for a given game/type combination will sort together. Within this set, the master record is always first (and always present if any scores are present), followed by 0 or more local scores and then 0 or more server scores. The following table illustrates one embodiment for the master record.
    Type (Size) Field Name Field Description
    UInt32 (4) CreatorID The unique, registered creatorID of the game.
    UInt16 (2) ScoreType The arbitrarily chosen type identifier for this
    score.
    UInt16 (2) RecordType Identifies a master record (and sorts first).
    MASTER_ID = 0
    UInt16 (2) numLocalScoresToKeep An integer that specifies how many scores to
    keep in the local pool for this game.
    UInt16 (2) numServerScoresToKeep An integer that specifies how many scores to
    keep in the local pool for this game.
    UInt16 (2) reportScoresToServer TRUE (1) to report scores to server for this
    game and score type, FALSE(0) to not report
    scores to server.
    Char* (var) GameName The rest of the record is character data that
    contains the user-visible name of the game for
    the High Score manager.
  • In step 206, the handheld computing device 110 generates a score record for the saved score. The following table illustrates one embodiment for the score record.
    Type (Size) Field Name Field Description
    UInt32 (4) CreatorID The unique, registered creatorID of the game.
    UInt16 (2) ScoreType The arbitrarily chosen type identifier for this score
    UInt16 (2) RecordType The record type, 1's for local scores and 2's for
    LOCAL_POOL = 0x1111 server scores. All the local scores come before
    SERVER_POOL = 0x2222 any server scores.
    UInt32 (4) Score The normalized score value.
    UInt32 (4) Checksum A checksum, used to validate the score value.
    UInt32 (4) timeAndDateUTC The date and time that the score was reported, as
    time in seconds since midnight Jan. 1, 1904 in UTC.
    Char* userString The (null-terminated) string that goes with the
    (var) score. For server scores, the user string is
    prefixed with the alias of the scorer followed by
    the tab character.
  • In step 208, the handheld computing device 110 stores the master record and the score record for synchronization between the handheld computing device 110 and the computer system 120. In step 210, the handheld computing device 110 determines whether synchronization is occurring. If there is no synchronization, the handheld computing device 110 proceeds to step 214. If synchronization is occurring, the handheld computing device 110 transmits the master record and the score record to the computer system 120 in step 212. FIG. 2 ends in step 214.
  • FIG. 3 depicts a flowchart for the computer system 120 executing the conduit software 125 in an exemplary implementation of the invention. FIG. 3 begins in step 300. In step 302, the computer system 120 executing the conduit software 125 determines whether synchronization is occurring between the handheld computing device 110 and the computer system 120. If synchronization is not occurring, the computer system 120 proceeds to step 318. If synchronization is occurring, the computer system 120 receives the master record and the score record from the handheld computing device 110. The conduit software 125 transfers all scores from the handheld computing device 110, effectively backing up the high score records. Any records deleted on the handheld computing device 110 will also be deleted on the computer system 120.
  • In step 306, the computer system 120 then determines whether the score from the master record and the score record is the high score. If the highest score for a given master record (game+scoreType combination) is new, then the score needs to be transmitted to the game metric server 140. If the score is not a high score, the computer system 120 proceeds to step 318.
  • If the score is a high score, the computer system 120 then checks whether the sync with server flag is set in step 308. The conduit software 125 checks an “opt in” setting stored on the handheld computing device 110. Server connections will only be attempted if the user has enabled them, by setting the appropriate flag on the handheld computing device 110. If the sync with server flag is not set, the computer system 120 proceeds to step 318. If the sync with server flag is set, the computer system 120 determines whether the server is enabled for a game and score type in step 310. If the server is not enabled for a game and score type, the computer system 120 proceeds to step 318.
  • If the server is enabled for a game and score type, the computer system 120 determines whether a connection is established to the game metric system 140 via the communication network 130 in step 312. In some embodiments, the connection to the game metric server 140 needs to be live during synchronization for the transaction to take place. In one example, if the computer system 120 is not connected to the Internet at the time of synchronization, or if the server is unresponsive, then the data is not transferred. In this example, the user needs to synchronize again to re-attempt the connection. During a handheld computing device 110 restore, all records should be restored to the handheld computing device 110 during synchronization. In some embodiments, conflict rules are fixed: the handheld computing device 110 overrides the computer system 120 for game master records and local scores, the computer system 120 overrides the handheld computing device 110 for server based scores.
  • If a connection is established, the computer system 120 transmits the game metrics to the game metric server 140 in step 314. If a connection is not established, the computer system 120 stores the master record and the score record for future synchronizations in step 316.
  • In one embodiment, the game metrics that are transferred to the game metric server 140 are in an Uniform Resource Locator (URL) format. In this embodiment, game score submission consists of sending a URL with specified name/value parameters in the query string to the game metric server 140 that describes a score for a particular game played on the user's device. The server component that handles this request can be a Java Servlet. The Servlet should be written such that either an HTTP Post or HTTP Get message of the specified URL will be handled in the same manner. In other words, the doGet( ) and doPost( ) methods of the Servlet should be written to call the same logic. An exemplary URL and appropriate parameters are described below: Example URL: http://hsupload.tapwave.com/desktop/reportScore/?hardwareID=0T000139C111601J&cr eatorID=0x54574853&scoreType=1001&score=1000&checksum=0x000003e8&recorde d=1067899622000&userString=1000%20points
    Name Data Type Description
    hardwareID A 16 digit base-34 value A unique value that identifies the hardware
    “0T000139C111601J” device. This value comes from the Road
    Dawg hardware ROM.
    creatorID 32 bit unsigned hex integer A 4-byte value that unique defines an
    “0x00000000 . . . 0xFFFFFFFF” application developer. While this value is
    most likely a 4 letter value (e.g. DOOM,
    ADDR) its representation it is still defined
    as an integer. The CreatorID is also
    assigned by Palm.
    scoreType 16 bit unsigned decimal A value used to define which game type
    integer this score is associated (used primarily for
    “0 . . . 65535” game tournaments to identify a score being
    submitted for a tournament).
    score 32 bit unsigned decimal A numerical value that describes a score
    integer achieved for a particular game.
    “0..4294967295”
    checksum 32 bit unsigned hex integer Used to verify a score was created on a
    “0xFFFFFFFF” device, rather than a faked score. Currently
    not evaluated on the server.
    recorded 64 bit unsigned decimal A numerical value that defines when the
    Long high score was achieved on the device.
    “10678996222000” This value is the number of milliseconds
    since the Epoch (Jan. 1, 1970 00:00:00)
    in GMT.
    userString (escaped) String Provides a user friendly display format for
    “1000% 20Points” the high score
  • Whether or not this is a high score for the game (for this user) is determined by the game metric server 140. The information is recorded that this particular user has played a particular game and achieved a score. If the game metric server 140 determines that the score is a high score (for this user) for the game, it will be stored in a high score repository.
  • The scoreType value will be used to relate a score to a particular tournament being played. The checksum value is used as a further check to verify the integrity of the score being submitted. Ultimately, the checksum value will be used to ensure that the score is genuine. The recorded parameter is used to timestamp when the high score was achieved. It should be sent as a long value, which contains the number of milliseconds since the Epoch (Jan. 1, 1970 00:00:00) in UTC (i.e. GMT).
  • The userString value defines a displayable format for scores and is used on the Zodiac/Zorro device. This value should be stored within the server database for a high score. There can be characters within the string that may have to be escaped when sending back to the client (e.g. a space needs to be converted into %20). FIG. 3 ends in step 318.
  • FIG. 4 depicts a flowchart for the game metric server 140 executing the game metric processing software 145 in an exemplary implementation of the invention. FIG. 4 begins in step 400. In step 402, the game metric server 140 executing the game metric processing software 145 receives the game metric in the URL format from the computer system 120 via the communication network 130.
  • In step 404, the game metric server 140 determines whether the score is the high score for the user ID, game creator ID, and score type. If the score is not the high score, the game metric server 140 proceeds to step 410. In some embodiments, the game metric server 130 stores all score data (as defined above) for only the highest score for each combination of: user ID (looked up from device serial number)+game creatorID+game scoreType. If a higher score with matching user ID, creatorlD and scoreType is sent, the existing record is replaced with the new higher record.
  • In some embodiments, the algorithm for taking into account whether a new score belongs in the high score table includes the following:
      • Verifying that the new score is better than the current score achieved by this user for this game. This is done by comparing the unsigned 32 bit values. Higher values are typically better.
      • If a game high score is submitted to the server, and that game cannot be found in the high score database, then the assumption is made that this is a new game and the score is entered as the current high score for this user.
      • The checksum value associated with a high score is stored in the database.
      • The scoreType value associated with a high score is stored in the database. The scoreType value can be used for tournaments.
  • If the score is a high score, the game metric server 140 stores the master record and the score record in step 406. In step 408, the game metric server 140 stores the checksum value for future validation.
  • In step 410, the game metric server 140 transmits an Extended Mark-up Language (XML) response back to the computer system 120 indicating the status of the high score submission. The response to the score submission may be an XML-formatted message that provides status for the operation. One field will describe the message status. A description field will provide more detailed information about what happened.
    For example:
    <?xml version=1.0 encoding=”ISO-8859-1”?>
    <highscore>
    <status>100</status>
    <description>A new high score for Tony Hawk was registered
    </description>
    </highscore>
    Or
    <?xml version=1.0?>
    <highscore>
    <status>104</status>
    <description>All data in the database was corrupted -
    ouch</description>
    </highscore>
  • A successful high score submission to the game metric server 140 returns in the HTTP sponse header the status value of 200 (which is the well known value returned by HTTP servers for a success request operation). In this case, the XML-formatted response will exist. In the event of a server error, the status code of 500 (Internal server error) will be returned, and no XML-formatted response message will exist.
  • In the case of a successful request operation, the status field within the XML response message will describe what took place on the game metric server 140 when this high score submission was made. The value of this field is numeric, and can take on the following values:
    Status
    value Description
    100 A score did not exist for this user and game; therefore a new
    high score was added into the high score database.
    101 A score did exist for this user and game, and the submitted score
    is higher; therefore the existing high score was updated.
    102 A score did exist for this user and game, and the submitted score
    is not higher; therefore the existing high score remains.
    103 The specified user (identified by the SecurityID value) does not
    exist within the system. No high score was added to the system.
    104 A general error occurred while parsing the input parameters
  • In step 412, the game metric server 140 displays the high score for a creator ID and score type.
  • For tournaments, the games on the handheld computing device 110 can have a play mode that is validated for tournaments. In this play mode, cheats are disabled, and as much as possible the game experience is normalized to that scores on different devices can be compared. The resulting scores are reported as a new scoreType for the same game.
  • A tournament can be run on a server by looking specifically for high scores from the given game and game type, reported within a particular time range, and generated on the handheld computing device 110 within a particular time range. For tournament play, special attention should be given to the checksums for the scores.
  • For social policing of high scores, similar features such as “block” and “warn” for instant messaging can be implemented in the game metric server 140. This would allow the customers to self-police, claming that scores for a given user are phony. Since scores are necessarily tied to the device serial number which is associated with a registered account, the names of people that may be cheating can be registered, which would discourage from making fake high scores. The threat of disabling all high score posting for a given account can be used to further dissuade people from making up fake scores.
  • In step 414, the game metric server 140 receives a high score request. In some embodiments, an application on the handheld computing device 110 requests that a certain number of highest scores can be retrieved from the game metric server 140, which depends on other variables such as whether the user is registered with the website and how often the user synchronizes. If enabled, the conduit software 125 queries the game metric server 140 for the top N high scores for each game and score type, and the existing server score records on the handheld computing device 110 is replaced with the new scores from the game metric server 140.
  • In some embodiments, the userString for the high scores is prefixed with the alias that corresponds to the original high score, followed by the tab character. For example, if device A reports a high score as “100 points”, and is registered to “Mad Bob”, the game metric server 140 reports the high score with the user string “Mad Bob\t100 points”.
  • The table below provides information about data types that are relevant for the high score API's. Along with the name of the data, its type information and a brief description of what the information is will also be given. Example URL: http://hsupload.tapwave.com/desktop/listGameScores/?scores=5&creatorID=0x54574853 &scoreType=0
    Name Data Type Description
    HardwareID A 16 digit base-34 value A unique value that identifies the hardware
    device. This value comes from the Road
    Dawg hardware ROM.
    CreatorID 32 bit unsigned hex integer A 4-byte value that unique defines an
    “0x00000000 . . . 0xFFFFFFFF” application developer. While this value is
    most likely a 4 letter value (e.g. DOOM,
    ADDR) its representation it is still defined
    as an integer. The CreatorID is also
    assigned by Palm.
    ScoreType 16 bit unsigned decimal A value used to define which game type
    integer this score is associated (used primarily for
    “0 . . . 65535” game tournaments to identify a score being
    submitted for a tournament).
    Scores Integer A value used to limit the number of scores
    “0 . . . 32767” for a game returned. A practical maximum
    value is the largest signed 16 bit number,
    which is the maximum number of records
    that can exist in a PalmOS database.
  • Requests for game scores can be made on the server, which will return the information as an xml-formatted message. One embodiment for the format of the request for game scores is defined as follows:
    <?xml version=1.0 encoding=”ISO-8859-1”?>
    <games list=”1”>
      <game title=”Doom”>
        <highscores list=3>
          <highscore>
            <displayName>ray</displayName>
            <score>50000</score>
            <scoreType>1</scoreType>
            <checksum>0</checksum>
            <userstring>xxx:xyzzy</userString>
            <recorded>1058470322000</recorded>
            <submitted>1058470322000</submitted>
          </highscore>
          <highscore>
            <displayName>bob</displayName>
            <score>45000</score>
            <scoreType>1</scoreType>
            <checksum>0</checksum>
            <userstring>xxx:xyzzy</userString>
            <recorded>1058470322000</recorded>
            <submitted>1058470322000</submitted>
          </highscore>
          <highscore>
            <displayName>neal</displayName>
            <score>44550</score>
            <scoreType>1</scoreType>
            <checksum>0</checksum>
            <userstring>xxx:xyzzy</userString>
            <recorded>1058470322000</recorded>
            <submitted>1058470322000</submitted>
          </highscore>
        </highscores>
      </game>
    </games>
  • In step 416, the game metric server 140 transmits the high scores in an XML formatted message. FIG. 4 ends in step 418.
  • The above-described functions can be comprised of instructions that are stored on storage media. These instructions can be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with the invention. Those skilled in the art are familiar with instructions, processor, and storage media.
  • Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention.

Claims (2)

1. A system for processing game metrics, the system comprising:
a handheld computing device configured to capture the game metrics for a game and transfer the game metrics; and
a game metric server configured to receive the game metrics from the handheld computing device via a computer system and a communication network and process the game metrics.
2. A method for processing game metrics, the method comprising:
capturing the game metrics for a game into a handheld computing device;
transferring the game metrics from the handheld computing device;
receiving the game metrics into a game metric server from the handheld computing device via a computer system and a communication network; and
processing the game metrics in the game metric server.
US11/228,470 2004-09-15 2005-09-15 Systems and methods for processing game metrics from handheld computing devices Abandoned US20060089200A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/228,470 US20060089200A1 (en) 2004-09-15 2005-09-15 Systems and methods for processing game metrics from handheld computing devices
TW95100885A TWI300357B (en) 2005-09-15 2006-01-10 Systems and methods for processing game metrics from handheld computing devices

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US61031704P 2004-09-15 2004-09-15
US11/228,470 US20060089200A1 (en) 2004-09-15 2005-09-15 Systems and methods for processing game metrics from handheld computing devices

Publications (1)

Publication Number Publication Date
US20060089200A1 true US20060089200A1 (en) 2006-04-27

Family

ID=36206829

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/228,470 Abandoned US20060089200A1 (en) 2004-09-15 2005-09-15 Systems and methods for processing game metrics from handheld computing devices

Country Status (1)

Country Link
US (1) US20060089200A1 (en)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070191101A1 (en) * 2006-02-16 2007-08-16 Microsoft Corporation Quickly providing good matchups
US20070191102A1 (en) * 2006-02-16 2007-08-16 Microsoft Corporation Tournament matchups for a multiplayer environment
US20070218996A1 (en) * 2006-03-20 2007-09-20 Harris Adam P Passive validation of network devices
US20070238524A1 (en) * 2006-03-20 2007-10-11 Harris Adam P Active validation of network devices
US20070238528A1 (en) * 2006-03-20 2007-10-11 Harris Adam P Game metrics
US20080052704A1 (en) * 2006-06-02 2008-02-28 Apple Computer, Inc. Media management system for management of games acquired from a media server
US20080113805A1 (en) * 2006-11-15 2008-05-15 Microsoft Corporation Console based leaderboard rendering
US7753795B2 (en) 2006-03-20 2010-07-13 Sony Computer Entertainment America Llc Maintaining community integrity
WO2011031678A1 (en) * 2009-09-11 2011-03-17 Qualcomm Incorporated System and method of providing leaderboards for mobile gaming in a wireless network
US20120322561A1 (en) * 2011-06-16 2012-12-20 Sony Computer Entertainment Europe Limited Leaderboard system and method
US20130035161A1 (en) * 2011-08-04 2013-02-07 Ami Entertainment Network, Inc. Amusement device including provision for tracking a player's top score
US8924432B2 (en) 2011-09-26 2014-12-30 Ami Entertainment Network, Llc Portable hand held controller for amusement device
US20150058359A1 (en) * 2013-08-20 2015-02-26 International Business Machines Corporation Visualization credibility score
US9636589B2 (en) 2010-11-02 2017-05-02 Sony Interactive Entertainment America Llc Detecting lag switch cheating in game

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2003A (en) * 1841-03-12 Improvement in horizontal windivhlls
US2002A (en) * 1841-03-12 Tor and planter for plowing
US2005A (en) * 1841-03-16 Improvement in the manner of constructing molds for casting butt-hinges
US5746656A (en) * 1996-04-23 1998-05-05 Bezick; William Video game competition method and apparatus
US20020128065A1 (en) * 2001-01-16 2002-09-12 Chung Ho Ming Real time data exchange system
US20050037747A1 (en) * 2003-06-26 2005-02-17 Geary John N. System and method for dissemination of information in a limited-access environment
US20050227770A1 (en) * 2004-04-13 2005-10-13 Global Direct Management Corp. Mobile gaming system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2003A (en) * 1841-03-12 Improvement in horizontal windivhlls
US2002A (en) * 1841-03-12 Tor and planter for plowing
US2005A (en) * 1841-03-16 Improvement in the manner of constructing molds for casting butt-hinges
US5746656A (en) * 1996-04-23 1998-05-05 Bezick; William Video game competition method and apparatus
US20020128065A1 (en) * 2001-01-16 2002-09-12 Chung Ho Ming Real time data exchange system
US20050037747A1 (en) * 2003-06-26 2005-02-17 Geary John N. System and method for dissemination of information in a limited-access environment
US20050227770A1 (en) * 2004-04-13 2005-10-13 Global Direct Management Corp. Mobile gaming system

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070191101A1 (en) * 2006-02-16 2007-08-16 Microsoft Corporation Quickly providing good matchups
US20070191102A1 (en) * 2006-02-16 2007-08-16 Microsoft Corporation Tournament matchups for a multiplayer environment
US7753795B2 (en) 2006-03-20 2010-07-13 Sony Computer Entertainment America Llc Maintaining community integrity
US20070218996A1 (en) * 2006-03-20 2007-09-20 Harris Adam P Passive validation of network devices
US20070238528A1 (en) * 2006-03-20 2007-10-11 Harris Adam P Game metrics
US8771061B2 (en) 2006-03-20 2014-07-08 Sony Computer Entertainment America Llc Invalidating network devices with illicit peripherals
US8715072B2 (en) 2006-03-20 2014-05-06 Sony Computer Entertainment America Llc Generating rules for maintaining community integrity
US7480656B2 (en) * 2006-03-20 2009-01-20 Sony Computer Entertainment America Inc. Active validation of network devices
US9526990B2 (en) 2006-03-20 2016-12-27 Sony Interactive Entertainment America Llc Managing game metrics and authorizations
US20070238524A1 (en) * 2006-03-20 2007-10-11 Harris Adam P Active validation of network devices
US11077376B2 (en) 2006-03-20 2021-08-03 Sony Interactive Entertainment LLC Managing game metrics and authorizations
US8032502B2 (en) 2006-03-20 2011-10-04 Sony Computer Entertainment America Llc Validation of network devices
US10293262B2 (en) 2006-03-20 2019-05-21 Sony Interactive Entertainment America Llc Managing game metrics and authorizations
US10124260B2 (en) 2006-03-20 2018-11-13 Sony Interactive Entertainment America Llc Invalidating network devices with illicit peripherals
US9717992B2 (en) 2006-03-20 2017-08-01 Sony Interactive Entertainment America Llc Invalidating network devices with illicit peripherals
US8972364B2 (en) 2006-03-20 2015-03-03 Sony Computer Entertainment America Llc Defining new rules for validation of network devices
US8626710B2 (en) 2006-03-20 2014-01-07 Sony Computer Entertainment America Llc Defining new rules for validation of network devices
US8622837B2 (en) 2006-03-20 2014-01-07 Sony Computer Entertainment America Llc Managing game metrics and authorizations
US20080052704A1 (en) * 2006-06-02 2008-02-28 Apple Computer, Inc. Media management system for management of games acquired from a media server
US20130165222A1 (en) * 2006-06-02 2013-06-27 Apple Inc. Media management system for management of games acquired from a media server
US20080113805A1 (en) * 2006-11-15 2008-05-15 Microsoft Corporation Console based leaderboard rendering
WO2011031678A1 (en) * 2009-09-11 2011-03-17 Qualcomm Incorporated System and method of providing leaderboards for mobile gaming in a wireless network
US20110065511A1 (en) * 2009-09-11 2011-03-17 Mahan Michael P System and method of providing leaderboards for mobile gaming in a wireless network
JP2013504377A (en) * 2009-09-11 2013-02-07 クアルコム,インコーポレイテッド System and method for providing a ranking table for mobile games in a wireless network
KR101397799B1 (en) * 2009-09-11 2014-05-21 퀄컴 인코포레이티드 System and method of providing leaderboards for mobile gaming in a wireless network
JP2016093527A (en) * 2009-09-11 2016-05-26 クアルコム,インコーポレイテッド System and method of providing leaderboards for mobile gaming in wireless network
US9616348B2 (en) * 2009-09-11 2017-04-11 Qualcomm Incorporated System and method of providing leaderboards for mobile gaming in a wireless network
US9636589B2 (en) 2010-11-02 2017-05-02 Sony Interactive Entertainment America Llc Detecting lag switch cheating in game
US10092845B2 (en) 2010-11-02 2018-10-09 Sony Interactive Entertainment America Llc Detecting lag switch cheating in game
US8715088B2 (en) * 2011-06-16 2014-05-06 Sony Computer Entertainment Europe Limited Leaderboard system and method for displaying location-based leatherboards with reverse geocoding GPS co-ordinates
US20120322561A1 (en) * 2011-06-16 2012-12-20 Sony Computer Entertainment Europe Limited Leaderboard system and method
US20130035161A1 (en) * 2011-08-04 2013-02-07 Ami Entertainment Network, Inc. Amusement device including provision for tracking a player's top score
US8696468B2 (en) * 2011-08-04 2014-04-15 Ami Entertainment Network, Llc Amusement device including provision for tracking a player's top score
US8924432B2 (en) 2011-09-26 2014-12-30 Ami Entertainment Network, Llc Portable hand held controller for amusement device
US9665665B2 (en) 2013-08-20 2017-05-30 International Business Machines Corporation Visualization credibility score
US9672299B2 (en) * 2013-08-20 2017-06-06 International Business Machines Corporation Visualization credibility score
US20150058359A1 (en) * 2013-08-20 2015-02-26 International Business Machines Corporation Visualization credibility score

Similar Documents

Publication Publication Date Title
US20060089200A1 (en) Systems and methods for processing game metrics from handheld computing devices
US11734260B2 (en) Methods and apparatus for a distributed database within a network
US8210918B2 (en) Method and system for operating and participating in fantasy leagues
US7788176B2 (en) System and method for providing online SMS games
US6986712B1 (en) Score management system, score management server, and data recording medium
KR100859132B1 (en) Game device
RU2388056C1 (en) Method, system, client terminal and server for preventing cheating in network games
US20080305860A1 (en) Systems, Media and Methods for Determining a Winner of a Multiplayer Game
US8812514B2 (en) Web-based competitions using dynamic preference ballots
US11192030B2 (en) Box office game
CN108260015B (en) Voting data processing method and device and electronic equipment
JP2006192142A (en) Network ranking system and program
JP6942927B2 (en) Game system, management server program and game device program
US9283474B2 (en) Method and system for operating and participating in fantasy leagues
JP2013208201A (en) Game parlor system
CN110585722A (en) Block chain-based game time information processing method and device and game control method and device
JP2005049973A (en) Campaigning device
JP2004242816A (en) Quiz provision system
JP2023041928A (en) Game system, computer program used therefor, and server device
JPWO2019026327A1 (en) GAME SYSTEM, COMPUTER PROGRAM USED FOR THE SAME, AND SERVER DEVICE
US20180157725A1 (en) Query-Based Application Data Retrieval
CN110941680B (en) Data processing method, device and storage medium
TWI300357B (en) Systems and methods for processing game metrics from handheld computing devices
WO2010010827A1 (en) Play result processing system
CN117379800A (en) Block chain-based data processing method, device, equipment and readable storage medium

Legal Events

Date Code Title Description
AS Assignment

Owner name: INVENTEC APPLIANCES CORPORATION, TAIWAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TWERDAHL, TIMOTHY D.;REEL/FRAME:016882/0496

Effective date: 20051115

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION