Patent Application
20090227375
The present invention relates generally to a system and method for using personal cell phones as controllers of a video game.
Not Applicable.
Not Applicable
Not Applicable
Video games are best played on a computer adapted to the purpose: a high-performance personal computer (PC), often one equipped with special processing or graphics capabilities; dedicated gaming consoles (e.g., the Xbox by Microsoft, Inc. of Redmond, Wash., or the PlayStation 3 by Sony Computer Entertainment America, Inc. of Foster City Calif.); or on a commercial arcade machine. Such game computers often make use of one or more game controllers comprising a wired or wireless connection through which players affect the progress of the game.
PCs and dedicated gaming consoles are configured to interact with only a limited number of controllers, four being a common upper limit. This limits play to, at most, a like number of players, which makes gaming in larger groups awkward (e.g., more players must take turns).
Alternatively, the limited-controller problem can be avoided by networking additional consoles. This, however, requires the investment in and availability of not only the multiple consoles, but additional displays and sound systems as well.
Game controllers are typically hand-held and usually comprise a collection of buttons more numerous than the players fingers, plus two or more joysticks. In the hands of a practiced gamer, these controllers are highly effective interface devices capable of complex, rapid command of on-screen actions. However, the required period of learning and acclimation for novice or casual players renders such controllers confusing and significantly ineffective.
Commercial arcade video games such as Dance Dance Revolution developed and manufactured by Konami Computer Entertainment of Japan employ unique interfaces, and these suffer the same difficulties of limiting the numbers of simultaneous players.
There remains a need in computer, console, and arcade games for a way to allow many players to participate simultaneously, each with their own controller. Preferably, this way should be operable with extant game systems and with little or no acquisition of further equipment by the players.
In the prior art, game controllers were associated with players who, for the most part, could only send messages (e.g., button presses) to the game. There was very little in the way of messages received from the game through the game controllers. A common exception to this is a vibrator contained within many controllers. In some controllers, audio feedback and indicator lights are also included, an example being the Wii Remote by Nintendo of America, Inc., Redmond, Wash. The Visual Memory Unit, described in U.S. Pat. No. 6,478,679 to Himoto et al., was an accessory that plugged into the controllers of the Dreamcast video game console, both sold by Sega of America, San Francisco, Calif., that provided a private display for each player in addition to the primary shared display.
It is the case that a majority of modern cell phones are able to send and receive messages, in particular, text messages, with ease. Some can also send and receive images, video, and sound as messages for later receipt by the addressee. However, such store-and-forward messaging is not generally suitable for a real-time situation, such as a game.
Unfortunately, uniformly message-rich capabilities are lacking in the array of game controllers, wired or wireless, available for the pantheon of PCs and video game consoles made today. Though this could feasibly change with the creation and wide adoption of a game controller functionality standard, this is neither likely to happen, nor likely to be inexpensive.
Thus, there exists a need for a system that can adapt the rich message capabilities of widely available cell phones for use, many at a time, with a single PC or game console.
Prior art systems, such as those proposed by Dusenberry et al., in U.S. patent application Ser. No. 10/638,831, use a cell phone to dial and maintain a continuous connection over the telephony network to a telephony server. While connected, the telephony server is able to decode in-band dual-tone multiple-frequency (DTMF) tones generated by the cell phone to recognize which keys of the cell phone have been pressed. The telephony server is also able to perform speech recognition on spoken commands by the player using the cell phone. The resulting key presses or recognized commands, combined with caller-ID, are passed via the Internet to a game server which can make use of that players key presses or commands driving a display for the player.
Dusenberrys application suffers from at least a number of significant drawbacks.
First, there is no feedback for player input. Because the keystrokes are rendered as DTMF tones and not interpreted until they are received by the telephony server, there is no editing ability provided to the player. They are typing blind. The fact that the telephony server is equipped with pre-recorded voice tracks and programming that could provide feedback (Dusenberry is not overly descriptive on this point), does not relieve the clumsy interface of pushing keys, then holding the phone up to your ear to hear what youve typed.
Second, most modern cell phones are rated for a two-hour talk-time before the battery is exhausted. This presumes starting with a fully charged battery. While it is reasonable to presume that most members of the game-playing demographic will have at hand a cell phone, it is not reasonable to expect a fully charged battery, yet Dusenberry teaches a continuous connection throughout the game, with spoken commands or key presses coming anytime within the interaction. For this reason, the upper limit for an interaction using Dusenberrys system is likely an hour. A system using an on-demand connection would make more effective, longer-lived use of the limited power resources.
Third, the cost of maintaining a continuous connection for an hour or so may be significant. If such interactions became enormously successful, for instance in a large venue such as a stadium, then bandwidth may become an issue. A system using a store-and-forward messaging service would make better use of finite bandwidth and would recover more successfully in situations where the bandwidth is temporarily saturated.
Fourth, the cost of a continuous connection, depending upon ones contract with the service provider, may be expensive.
Fifth, in a highly-connected demographic (that is, those who carry cell phones and are constantly messaging friends or being messaged by them), to have an on-going connection that would preclude remaining connected with friends, represents a serious drawback.
Sixth, spoken commands are not secret. In order to give a command, a player must speak intelligibly. Voice recognition doesnt fare well with whispering. As a result, others can hear what a player is preparing to do, thus putting him at a disadvantage.
Seventh, spoken commands can be heard by more than one cell phone. If a first player speaks loudly enough, other players cell phones may pick up the first players voice as acoustic crosstalk and incorrectly transmit someone elses command.
Eighth, while a gaming environment is often not a quiet environment, the game audio can be monitored on headsets. However, even a single player periodically speaking commands to his cell phone will represent a strange intrusion to a gathering.
Ninth, private feedback to the individual player is prone to being missed. Since verbal feedback is provided over the telephony network, an important message may be missed while a player is pressing keys.
Tenth, richer protocols interrupt the game session. Dusenberry briefly suggests that Wireless Application Environment (WAP) by Phone.com, now Openwave Systems, Inc. of Redwood City, Calif.) or Java 2, Micro Edition (J2ME) by Sun Microsystems, Inc. of Santa Clara, Calif. may be used to provide graphics. However, use of such protocols terminate the telephonic connection and would require the player to dial back into the game session to rejoin.
Thus, there remains an unsatisfied need for a system that employs a players cell phone as a game controller in manner that takes advantage of the text entry and editing capabilities; minimizes battery consumption, bandwidth use, and connection costs; leaves the cell phone available for intervening communications; maintains the secrecy of game commands; is substantially immune to crosstalk; doesn't compel players to be a vocal nuisance; is not prone to missing feedback; and allows media-rich presentation without interrupting game play.
The present invention relates generally to a system and method for using personal cell phones as controllers of a video game, whether the game system comprises a PC, game console, or commercial arcade machine. In particular, the present invention provides a server through which a connection is made to a Short Message Service (SMS) gateway so as to provide a path for the game system to communicate with a player's cell phone and for the player to respond to the server, yet have the message appropriately relayed to the appropriate game system.
It is an object of the present invention to allow an arbitrarily large number of players to participate in a game playing on a single game console (which may be, for example without limitation, a dedicated game console, a PC, or an arcade machine). This is to overcome a limitation commonly designed into extant game systems, namely that they allow relatively few controllers (typically, four) without imposing the burden of buying a large number of dedicated-purpose game controllers.
It is an object of the present invention to allow an expressive, intuitive mode of interface, well-known to a large population, that is, text messaging (also known as texting or messaging) using a telephone keypad or miniature keyboard (as found on the Blackberry, by Research In Motion LTD, of Waterloo, Ontario, Canada). This preferably includes the T9 method of entering text, as described in U.S. Pat. No. 5,818,437 to Grover et al.
It is a further object of the present invention to provide these capabilities without requiring personal data (e.g., phone number or email address) to be revealed to other participants.
Yet another object of the present invention is to support multiple simultaneous games, each preferably on a separate console, but without requiring servers for the system to be duplicated.
It is also an object of the present invention to permit multiple consoles to participate in the same game.
The aspects of the present invention will be apparent upon consideration of the following detailed description taken in conjunction with the accompanying drawings, in which like referenced characters refer to like parts throughout, and in which:
While the invention will be described and disclosed in connection with certain preferred embodiments and procedures, it is not intended to limit the invention to those specific embodiments. Rather it is intended to cover all such alternative embodiments and modifications as fall within the spirit and scope of the invention.
Referring to
Common to such game consoles 110 is storage 112 for containing game programs and related data. Such storage 112 can comprise CD-ROMS, DVDs, hard drives, memory cartridges, FLASH memory chips, NVRAM, etc., individually or in combination. In some cases, some or all of storage 112 is removable. To the extent that certain game data may be retained in volatile memory, storage 112 may be considered to further comprise RAM.
Also common today is an interface 128 to a communications channel, most commonly the Internet 130 by way of DSL or cable modems (neither shown), but historically also including dial-up modems (not shown), including those used for point-to-point connections (rather than going through the Internet).
In the prior art, when console 110 was running an instance of a networkable game, connection 131 would be formed to an interface (not shown) on lobby server 132. If required by business rules, console 110 or at least one of its players 121 and 125 would log into an account stored in account database 134.
Once connected and (if required) logged in, console 110 could host a game (making it the host game console, or game host) and lobby server 132 would permit discovery of this game by other consoles 138. Console 138, running its own instance of the networkable game and having its own connection to lobby server 132 (not shown), would communicate through connection 137 with host game console 110 and join the game hosted by 110. For this reason, console 138 may also be called the joined game console 138.
In some cases, lobby server 132 would host the game, and all consoles 110 and 138 would join the game that server 132 hosts. The principles of this invention can be easily applied to server-hosted games, but for the purposes of presentation, game console 110 will be treated as the game host.
Cell phone networks 142 and 162, representative cell phone towers 144 and 164, and cell phones 148 and 168 held by subscribers 149 and 169, all respectively, are all of the prior art.
It is a primary function of the present invention to incorporate cell phones 148 and 168 as controllers into the game played by game console 110. Cell phone users 149 and 169 are soon to become players 149 and 169, by the operation of the present invention.
In the preferred embodiment, lobby server 132 further comprises a cell phone database 136 (described in detail below) and has a communication channel to provider network 142 by way of connection 141 to a corresponding SMS gateway 140 (here too, the interfaces are not shown).
In the preferred embodiment, SMS gateway 140 accepts messages formatted as emails using the Simple Mail Transfer Protocol (SMTP) and forwards them to a first Short Message Service Center (SMSC) (not shown) within the provider network 142, preferably using the Short Message Peer-to-Peer protocol (SMPP). It is the function of the first SMSC to store and forward a message addressed to cell phone 148 so that it can be transmitted from cell tower 144 providing wireless connection 146, to be received by cell phone 148. The routing within provider network 142 from the first SMSC to cell tower 144 may be by way of additional SMSCs (not shown) within provider network 142, as necessary.
Note that alternative embodiments may provide different connections between and among server 132, provider network 142, and cell tower 144. Their selection is governed by the cell phone provider owning network 142. For instance, the provider of network 142 may allow (and may prefer) server 132 to establish an SMPP connection to gateway 140 for more efficient transfer of messages into and out of provider network 142.
Alternative embodiments may employ more advanced protocols, such as Enhanced Message Service (EMS), which is an extension of SMS that supports images and sound effects; Multimedia Message Service (MMS), which further supports video and audio clips; Mobile Instant Messaging (MIM), and other or future message protocols supported by cell phones. Each of these protocols uses a gateway, analogous in purpose to the SMS gateways 140 and 160.
EMS uses an EMS-enabled SMS gateway, since EMS is merely enhanced SMS. However, EMS seems to have been supplanted in the evolution of cell phone message protocols by MMS. MMS requires an MMS gateway, and for MMS, SMSCs are replaced by Multimedia Message Service Centers (MMSCs). MMS gateways and MMSCs, such as those manufactured by Openwave Systems, Inc. of Redwood City, Calif., are well-known. MIM uses a Mobile Messaging gateway (MMG) and, as with all instant messaging systems, a presence server (well-known, but not shown). For MIM, SMSCs are replaced by Instant Message Service Centers (IMSCs). MMGs and IMSCs, such as those manufactured by NeuStar, Inc. of Sterling, Va., are well-known. Whether any of these protocols eventually provides near-universal penetration into the cell phone population, and whether there will be sufficient uniformity of capabilities (e.g., image size), remains to be seen. Another basis for choosing among multiple available protocols includes selecting one that is handled by networks 130, 142, and 162 with a substantially minimum latency, or knowingly trading off a higher latency in exchange for a richer protocol. Which is why, for now, the preferred embodiment presented herein employs the entirely adequate, broadly adopted, and uniformly functional Short Message Service.
With the SMTP protocol used to form communication channel 141, both SMS gateway 140 and the server 132 are required to either have well-known domain names or IP addresses that remain constant during an exchange.
For example, the provider of network 142 may offer the use of SMS gateway 140 to its subscribers by publishing a domain name under which the SMS gateway 140 operates, for example provider_network—142.com. In this way, 4255551212@provider_network—142.com would be the form of an email directed at a cell phone having the number 4255551212.
The same is not strictly required of the server 132. Lobby server 132 may have a well-known domain name used by game consoles 110 and 138 to determine its current IP address on the Internet 130. However, in the context of the present invention, it is not necessary for a domain name to be used when cell phone 148 is addressing a message to server 132. Using a current IP address assigned to server 132, an email address can be formed, e.g., lobby@100.100.100.100, and will be received on well-known port 25 which is the officially assigned port for SMTP.
In an alternative embodiment, lobby server 132 may inform console 110 of another email server 152, whether by domain name or IP address. Alternatively, email server 152 may be identified in the game program and data 112, or email server 152 may be known to one of the players 125, 121, 149, or 169. When using another email server 152, at least a portion of cell phone database 136 may reside with console 110 in store 112.
In an alternative embodiment employing separate email server 152, console 110 communicates over connection 151 to email server 152, again preferably using SMTP. An email address to cell phone 168 would be directed by email server 152 to SMS gateway 160, preferably using SMTP. As above, gateway 160 would send the message using provider-determined protocols and routing to traverse provider network 162 to cell tower 164 from which, by wireless connection 166, the message ultimately reaches cell phone 168. As before, the email message is transformed at SMS gateway 160 (or later) into an SMS message or the like, for delivery to cell phone 168.
If cell phone 168 were to direct a message to an email address hosted at email server 152, as before, either a domain name or current IP address would be used to form the email address. In the case of email server 152, received messages from cell phones would be held awaiting retrieval by a client on game console 110 using, for example, the Internet Message Access Protocol (IMAP) or Post Office Protocol version 3 (POP3).
It should be apparent to those skilled in the art that use of email server 152 requires that console 110 poll for newly received messages, since IMAP and POP3 are pull protocols, as opposed to SMTP, which is a push protocol. Still, an implementation of email server 152 may be made more efficient by rejecting large messages (i.e., those in excess of an SMS message). Further, email server 152 may be configured with a portion of cell phone database 136 (discussed in more detail below) so as to be able to reject messages not originated by registered players, messages to addresses other than those associated with registered games, or messages not conforming to a registration process (discussed in more detail below).
In an alternative embodiment where a cell phone 148 or 168 is implemented as a wireless email client such as the Blackberry mentioned above, then a message thereto may remain in email form.
An advantage of the preferred implementation using SMTP to communicate over connection 141 to the lobby server 132 is that receipt of a message can induce an immediate communication to the game console 110 over connection 131 using a lightweight protocol, even smaller than the SMS protocol itself. This protocol can be smaller since the message will be coming from one of players 149 and 169 currently registered to a game on console 110. Since the message is being delivered to console 110, the destination address (TO) is implied and not explicit. Since the message is from one of a small number of players, i.e., perhaps a few hundred, and those players are typically known to the lobby server 132 and game console by an ordinal player number, i.e., player 1 , player 2 etc. This makes the source address (FROM) possible to encode in a very small size, e.g., a single byte for games that have up to 256 players.
In comparison, the TO and FROM portions of an email header can span many dozens of bytes. Even in SMPP, the destination and source can consume up to 46 bytes (see the DELIVER_SM operation in section 4.6 of the Short Message Peer-to-Peer Protocol Specification v3.4 as published Oct. 12, 1999 by the SMPP Developers Forum, Northgrove LTD, of Dublin, Ireland.
If joined console 138 has players of its own (not shown) who are using their own cell phones (not shown) to participate, then messages to and from those cell phones may be directed to console 138 from lobby server 132 or email server 152 (neither connection shown), or those messages may be directed to host game console 110 and then forwarded to joined game console 138 over connection 137 using the same lightweight protocol as described above, since any console 138 or 110 in the game would be able to reference any player in the game by the players ordinal number.
The overall process for using system 100 of the present invention has two main steps. First, cell phones are registered to a particular game being played on a console 110, and second, the game playing on console 110 interacts with the players corresponding to the registered cell phones. For the registration portion of the process, while many implementations are possible, two exemplary processes 210 and 310 are shown in
In reference to
In lobby entry step 212, the console, usually under direction of a game already selected in step 211, connects with lobby server 132. In the prior art, during this connection, console 110 would indicate that it wishes to host a game for other consoles 138 to join. In the prior art, if console 110 was not going to invite other consoles 138 to join, connection to the lobby server 132 would be unnecessary. However, in the present invention, this connection is needed whether or not other consoles 138 will be allowed to join the game being hosted, because console 110 is looking for additional services from lobby server 132, as described in subsequent steps and elsewhere herein.
Registration process 210 relies on registration of a cell phone originating through the console 110. Player registration step 213 embodies this. Each player 149 and 169 is registered by information sufficient to determine an SMS destination for their respective cell phones being entered.
For the purposes of this discussion, consider that both SMS gateways 140 and 160 can reach and be reached by substantially any server on the Internet 130, such as email server 152, the email services of lobby server 132, or other protocol used to form connection 141, even though in
This data entry during registration step 213 is preferably performed using controller 120 or 124. If console 110 is embodied as a PC, then the typically available keyboard and mouse (not shown) may be used. A user interface (UI) for this entry process is provided by console 110 on display 114. Generally, the information to be entered takes the form of an email address provided to them by their cell phone service provider and is usually of the form 4255551212@telco.com, that is, the cell phones telephone number followed an at sign, and the cell phone providers domain name. On the Internet, the domain name must resolve to equipment providing the SMS gateway 140 or 160.
Preferably, a name, nickname, or other identifier is entered or selected for each player, John Doe, JD, or the player can be associated with pre-existing identities in the game, e.g., the short plumber character. Otherwise, the association can be the simply ordinal Player 1.
If storage 112 maintains a record of previously registered players and cell phones, such record may be selected and recalled, rather than requiring that the information be re-entered.
In password distribution step 214, console 110 provides a password, secret, or other identification mechanism to the players on display 114. The password should be sufficiently unique that it is unlikely to be guessed or accidentally entered by players of any other games also registering with lobby server 132. The same password or secret may be used for all of the players 149 and 169.
Once the players have the password, their registrations are sent to lobby server 132 in step 215. The registrations are recorded in cell phone database 136.
In invitation step 216, the lobby server 132 uses the registrations recorded in cell phone database 136 to send a join message to each registered players cell phone 148 and 168 by way of corresponding SMS gateways 140 and 160.
In acceptance step 217, the players 149 and 169 receive the join message on cell phones 148 and 168, and each player replies to the message with merely the password. Preferably, the password is a sufficiently commonplace word or words that it is easily typed into an SMS message using the T9 text entry method mentioned above.
In step 218, the lobby server 132 receives the replies to the previously sent out invitations. If a reply contains the correct password, then the system is assured that the correct cell phone has been contacted and this updated status can be noted in cell phone database 136.
If in a reply, the password is incorrect or missing, the lobby server 132 may retry, but preferably refers the error back to the to console 110 to ensure that the correct email address was provided for the erring response.
In ready step 219, lobby server 132 reports to console 110 that the registration for each player 149 and 169 is complete and verified. As of completion step 220, the system is configured to proceed with the game.
In an alternative embodiment, password distribution step 214 may be skipped and the password omitted from the players replies to the join message. In this case, all replies to the join message are considered valid. If errors in data entry during registration step 213 are rare, or a UI is provided in completion step 220 to eliminate or redo the registration for players that have been mis-registered, then the elimination of the password may be used to streamline configuration and registration process 210.
In
The first two steps, game preparation 311 and lobby entry 312 are substantially the same corresponding step 211 and 212 in process 210. Here too, whether or not console 110 is hosting a game for other consoles 138 to join, the connection to the lobby server 132 is needed to admit cell phones 148 and 168.
In configuration and registration process 310, however, a password and address delivery step 313 is used. A message from lobby server 132 to console 110 provides not only a password, but an email address.
For the purposes of this discussion, the email address will be for lobby server 132, however in an alternative embodiment the email address would be for email server 152.
In another alternative embodiment, the console 110 can provide the password, which would be provided to lobby server 132 in a message.
In password and address presentation step 314, the password and address are presented on display 114 for use by players 149 and 169. If players are to be associated with pre-existing identities in the game, identifiers for those identities may also be shown (perhaps as a numbered list). However, if a players name, nickname, or other identifier is desired, it will not be entered until the next step.
In application step 315, each player 149 and 169 using cell phones 148 and 168 produce a text message preferably containing the password and the players name, nickname, or other identifier (which may be the identifier for a pre-existing identity in the game, if any. The text message is sent to the address provided. In an alternative embodiment, additional information may be included in the initial message, such as a team, role, or gender designation, or other player-specific information, if the game requests or supports such additional information. For example, a application message might be Bob password Jets male hunter, which would indicate that the player named Bob want to be on the Jets team playing a male hunter character, assuming that the game corresponding to the password given supports such options.
While it will be more common and more economical for the address provided in password and address presentation step 314 to be an email address (as most provider networks 142 and 162 are built to route SMS messages addressed to email address through gateways 140 and 160), a shorter, numeric code may be used. Well-known in the art, short codes are used for commercial SMS messages. Short codes are 4-6 digits long. Also available are long codes, 10-12 digits long, which look like phone numbers. Both short and long codes are associated with an account. When SMS messages are sent to these codes, the SMS gateway sends the message out of the provider network according to a configuration in this account, which may be to post an email to a previously designated account, or it may be to use an http-post transaction to send the information (this would be a case when connection 141 uses a non-SMTP protocol).
In the preferred embodiment, however, an email address is used.
The password and email address may be combined, such that the address is something of the form password@lobby server—132.com where lobby server 132 uses the same domain for all transaction with consoles 110 and 138, but provide each game with a separate email account name (in this example the email account name was password).
However, minimize typing, and thus errors, the preferred embodiment is to provide a consistent email address (e.g., lobby@server—132.com) that is consistently used, not only for all instances of the game, but preferably for all games using the present invention on a common brand of game or on a common brand of console. The reason for this is that a consistent email address lobby@server—132.com can be readily recorded in players cell phones 148 and 168 for re-use later. From a branding perspective, the actual email address itself can become an extension of the brand. In this preferred embodiment, the inclusion of a password in the text message of application step 315 is required to identify the specific console 110 or instance of the game for which application is being made.
In application receipt step 316, each text message sent in application step 315 is received by lobby If the player name or other identifier is missing or improper, but is required, a reply requesting the missing identifier may be sent.
Note that the application text message may be very informally formatted. If properly addressed to the lobby server, the contents of the message can be nothing more than Bob password or password Bob. In the exceedingly rare case where the desired player identifier and password happen to be the same, password password would be an acceptable, unambiguous message. In each case, a lobby server searching for a password in the message will be satisfied with the first or second word in the message, and the remainder of the message is used as the player identifier. However, to avoid a similarly rare occurrence wherein a player selects an identifier password_for_a_different_game, which could then result in server 132 (or in the previously mentioned alternative embodiment, email server 152). The lobby server 132 creates an entry in cell phone database 136 to record the return address of the sender, the current game or console 110 associated with the password, and the player name or identifier (if provided). If the password is missing, an error message may be returned to the sender via email, or the text message with the missing password may be ignored. ambiguous application messages of the form password_for_game_1 password_for_game_2 , it is preferred that the password and player identifier be provided in a predetermined order.
Once the record in cell phone database 136 is completed, a notification message may be sent to the newly-registered player in notification step 317. At the same time, a notice of registration may be sent to console 110 in console notification step 318. The notice of registration should contain the player identifier provided.
In an alternative embodiment where, in application step 315, additional information such as team, role, or gender designation was provided by the player, the additional information is passed on to console 110 as part of the notice of registration in console notification step 318 and is used to configure the players game records, to the extent that the game support the additional information.
In the alternative embodiment where the application text messages of step 315 are directed to email server 152, console 110 uses IMAP or POP3 protocols to access emails received at email server 152, reading through the most recent emails, looking for brief messages containing the password. In this configuration, cell phone database 136 is compiled and retained by console 110 in store 112. In this case, registration receipt step 316 includes the actions of both the email server 152 receiving application messages and console 110 retrieving them. Notification step 317 is performed by console 110 sending the notification messages through email server 152: It may be undesirable for console 110 to send email directly to the SMS gateways 140 and 160, if this might triggers a security feature of the SMS gateway. Step 318 has already been effectively incorporated into modified step 316.
In both the preferred embodiment using lobby server 312 and the alternative embodiment using email server 152, as of completion step 319 preparation and registration process 310 is complete.
In an alternative embodiment where joined game console 138 has players participating in a game hosted by host game console 110, lobby server 132 may direct all registrations to host game console 110, or more likely, lobby server 132 would direct the registrations for each consoles players to that console. The latter is more in keeping with the way that players are added to a game in the prior art. This would also allow each game console 110 and 138 to have distinct email servers 152 or at least distinct accounts, in an implementation using email server 152.
In general, cell phones 148 and 168 have been associated with players 149 and 169 in the game on console 110. Players 149 and 169 can send and receive arbitrary messages to and from console 110 to participate in the game.
It is expected that due to the nature of the interactions possible through cell phones 148 and 168 with console 110, that players 121 and 125 will choose to abandon controllers 120 and 124 for the majority of their interaction during the game in favor of their own cell phones (not shown) which are registered through preparation and registration process 210 or 310. The game play example in
Question and answer process 410 begins in step 411 where the game executing on console 110 is ready to ask a question of the players.
The question is presented to the players on display 114 or through audio output 116 in presentation step 412.
At the roughly the same time, a question form message is sent to the lobby server 132 in step 413. The lobby server can expand this question form message with information associated with the current game on console 110 in the cell phone database 136.
In SMS messaging step 414, the lobby server will generate a SMS message to the cell phones currently registered to each of the indicated players. If the question form message indicates that the question is being asked of all players, an SMS message is sent to each of the players. Alternatively, the question form message may direct the question to a subset of the players (e.g., one team), or to an individual, as called for by the games needs.
The SMS message containing the question message is received in step 415 by each players cell phone. There are two main advantages of providing the question message to the players as an SMS message, even though the question is to be presented on display 114.
The first advantage of providing the question to the player as an SMS message is that the while viewing an SMS message, most cell phones of the prior art present an easily accessible reply to this message button or menu selection. This spares the players a cell phone-specific and generally more involved, if only slightly so, process of explicitly creating and addressing an SMS message.
Thus, by selecting the reply to this message function in their specific cell phones UI, each player receiving a question message in step 415 is quickly able to compose and address their answer message as reply to the question message in reply step 416. Preferably the questions can be answered with just a few words entered with the T9 text entry technique previously discussed. Alternatively, a short answer such as 1 , 2 , 3 (if the question was multiple choice) or T, F (if the question was true/false) a may be used. This optimizes the time it takes a player to answer and speeds the game play along.
The second advantage of providing the question to the player as an SMS message is that the return address of the question message can be varied for each question posed. In this way, if there are a large number of questions being asked and answered in a brief time, each answer provided by a player is unambiguously associated with a particular question because of the email address to which it is sent. For example, a message to question—001@lobby_server—132.com would be distinctly associated with a first question. Timing or delivery variances would not confused that first answer with another answer received with an email address of question—002@lobby_server—132.com
A collateral advantage of varying the account name of the email address (e.g. question—001 in the example above) frequently, is that the lobby server 132 can be less subject to spam or other denial-of-service attacks because account names can be constantly changing and email messages easily rejected or ignored if sent to a currently unused account.
This same capability allows for better load management, where even the domain name in the email address may be varied: question—002@overflow_lobby_server—132.com, for example if the lobby server 132 has additional interfaces (not shown) or affiliated servers (not shown) configured to accept and handle excess traffic.
In receive reply step 417, the lobby server 132 receives incoming answer messages as replies. Each incoming reply has a sender address, which can be compared to cell phone database 136 to determine that the sender is a particular player associated with console 110.
In forward answer step 418, lobby server 132 forwards at least the contents of a players answer message and the players identity to console 110. If the lobby server is able to determine which question is being answered (as described above), then the question may be identified, too. The lobby server 132 may forward each players answer individually, or it may wait for all players answers to have been collected and forward the collected results to console 110.
In resolution step 419, console 110 evaluates each players answer in accordance with the game rules.
Preferably, the game rules interpret answers to accommodate the more likely errors associated with texting under the pressures of speed and competition.
For longer words, (e.g., Einstein), the evaluation may accept likely misspellings (e.g., Einstein), for example using a spell checker. Alternatively, for names of people and places, the evaluation by the game rules may choose to use the Soundex algorithm as taught by Robert Russel in U.S. Pat. No. 1,261,167, or the like. Perhaps a partial score is given for an incorrectly spelled, but similarly pronounced answer.
T9 text entry ambiguities may also be accommodated, as when the expected answer is very short, for example when the question is of the multiple choice variety and the expected answers would be 1, 2, or 3 Here the game rules preferably interpret an answer of A, B, or C as 2, since various implementations of T9 may interpret a press of the 2 key on a cell phone as the first letter of a word beginning with A, B, or C. Similarly, a press of the 3 key may result in the letters D, E or F. Pressing the 1 key may result in a character of punctuation. In the case of a true/false question, a players intent to enter T as their answer may result in U, V, or 8. The likely typographic errors for F are the same as those listed for 3 above. Yes/No questions should interpret a W, X, Y, Z, or 9 as Yes; and M, N, O, or 6 as No. In each of these cases, a player has not exercised the preferred T9 interface sufficiently to choose the precise one of the possible ambiguous answers intended by a single keystroke, but for many cases, the original intent can be accurately discerned.
Step 419 may also include a timeout, such that if an answer from a player is not received within a certain amount of time, the player is presumed to have passed on the question. Such a pass is resolved in accord with the predetermined rules of the game.
Those skilled in the art of game design will consider ways of accommodating the possibility that an SMS message-based transaction may fail or suffer delay for technical reasons unrelated to the skill or speed of the player(s) involved. The game designer will consider how scores or penalties within the game are assessed with this fact in mind. For example, a late delivery of an answer to a question might be accepted and allowed to retroactively affect a players score, but not if the player could have deliberately waited until the correct answer had been revealed and only then submitted an answer.
With the answers received and processed, the question and answer transaction completes in step 420.
In an alternative embodiment, where email server 152 is used, the question form message in step 413 is merely an email with more than one addressee. Email server 152 will relay the question form message as a separate email to each of the designated recipients in SMS messaging step 414. Most SMS gateways resolve the addressee (or addressee list) into a subscriber, and then strip off the email-base addressee list. Thus, the question message as received by each players cell phone in receipt step 415 is uncluttered by the addresses of other players cell phones. The players answer as before in reply step 416, and their answer messages are received by email server 152 in step 417. However, it is now the responsibility of console 110 in forward answer step 418 to interrogate email server 152 using the IMAP or POP3 protocols to retrieve and associate any received answer messages with individual players using information from the cell phone database 136 located in store 112, as previously described.
The question and answer process 410 can be used in many ways, are a few examples of which follow.
In one embodiment, game play may include a survey question, e.g., What is your favorite color? addressed to all players. Once the answers are tallied, a subsequent line of questions may include What other player do you think has the same favorite color as you? or What do you think the most popular color is, among this group?
In another embodiment, game play might include a first question may be directed to an individual first player, as discussed in conjunction with SMS messaging step 414. The answer that first player provides is kept secret by the system. Subsequently the remaining players may sent a second question asking what they think the first players answer was to the first question.
Besides the question and answer process 410, other game play processes are possible, and should be considered within the scope of the present invention.
In one embodiment, game play may use the message sending capability of the present invention to provide individuals with private information. An example of this would be in a murder mystery game, where individual players may be provided with information which only the character they are role-playing would know: You are the murderer, or You last saw the victim at 11PM. In this mode, the private information sent to a player would not be shown on display 114.
In another embodiment, the game may support the secret exchange of messages between players. A first player may send a message to the system, in reply to a question message or not, with the first line of the message being the name of a second player, used as an in-game destination address. Upon receipt by console 110, the game program will detect the name of the second player on the first line of the message, and forward the message to that second player, privately. Before forwarding the message, the console may annotate the message by removing the second players name from the first line and replacing it with From: and the name of the first player. If the game play supports spying or eavesdropping as a game mechanism, the message may be forwarded to a third player in addition to, or instead of the second player. This mode of private message exchange in-game also has the property of not revealing players actual cell phone addresses, and thus can maintain players privacy, if desired.
Multiple simultaneous games are supported by cell phone database 136, as would be likely in lobby server 132, through game records 514 and 515 in games table 510.
Individual players and their cell phones are tracked by records 525, 526, 527, 528, and 529 in players table 520.
Player records in players table 520 are associated with game records in games table 510 by game-player relationship 530. Those skilled in the art of database schemas will note that the symbols comprising game-player relationship 530 in
Each game record 514 and 515 in game table 510 is comprised of the Session_ID key field 511, which uniquely references a game. This would be the identifier console 110 would use to identify itself and the game being hosted to the lobby server. Session_ID 511 may include the IP address of console 110, or is otherwise associated with connection 131 so that lobby server 132 can generate messages to console 110. If needed, each game record 514 and 515 further comprises a Password field 512 and preferably a Status field 513 to track the state of the game session represented by the game record.
Each player record 525, 526, 527, 528, and 529 in players table 520 has a Player_Address key field 521 that uniquely distinguishes among players. Player_Name field 522 stores the player name, nickname, or other identifier which is used to identify each player in a game in transactions with console 110. Player_Name field 522 may comprise an ordinal (not shown) for additional economy in communications with console 110. Player_Status field 523 tracks the registration state of each player. Session_ID field 524 is a foreign key field which forms game-player relationship 530. Before a player is fully registered to a game, the corresponding player record may include null fields for Player_Name 522 and Session_ID 524. Such occurrences will be apparent from the discussion in conjunction with
In this example database, game record 514 has a Session_ID 511 of 123453, a Password 512 of tesla, and a Status 513 of configure indicating that the game is still engaged in a configuration and registration process 210 or 310. Game record 515 has a Session_ID 511 of 123456, a Password 512 of myriad, and a Status 513 of play indicating that the game is in progress, perhaps executing a phase of game play that might employ question and answer process 410.
Player records 525, 526, and 527 are all registered or registering for the game represented by game record 514, since they have a shared Session_ID of 123453. Player records 528 and 529 are registered for the game represented by game records 515, since they have a shared Session_ID of 123456.
Both player records 528 and 529 have a Player_Status 523 of playing, which represents that they are fully registered and the corresponding game is in progress.
The player records 525 and 526 have a Player_Status 523 of engaged to mark that they are fully registered for their game, but that it has not yet started, while player record 527 has a Player_Status 523 of joining indicating some intermediate stage of the registration process.
It is not necessary to provide a complete state diagram representing Status 513 and Player_Status 523 for the possible registration and game play processes, as such is within the ordinary skill in the art. However, when lobby server 132 receives an incoming message on a connection such as 141, the process for handling that inbound message is illustrated in
Message handler 600 begins when a message is received in step 610. The received message may be an incoming email using SMTP, or the message may be received through another protocol, such as an http-post transaction.
In address check step 611, the source address of the message is compared to those listed in player table 520 in the Player_Address field 521. If a corresponding player record is found, message handling continues at step 612.
In name check step 612, the player record is examined to determine if the Player_Name is already known. If so, then in message forward step 613 the message (or a sufficient portion of the message) is sent to the console 110 corresponding to the game related by value in Session_ID field 524, at which time message handler 600 concludes at step 614 with the message sent.
If in address check step 611 the source address of the message is not found in the Player_Address field 521 of any player record in player table 520, then the message is examined in password check step 620 to see if it contains a password associated with any game record in game table 510.
Note that some optimizations may be made for the password check. First, only short messages need to be examined. A message for a new player is expected to have at most only a password and a player name, thus messages longer than a few words can be rejected. Second, unless a game allows players to join at any time, then game records such as game record 515 that has a Status 513 of play can be excluded. Thus, only Passwords 512 for game records such as game record 514 for which the Status 513 is configure need to be considered, in this case, tesla.
When a message containing a password is found in password check step 620, processing of the message continues at player record creation step 640, where a new player record is added to table 520, with a Player_Address 521 of the current messages source address, a Player_Status 523 of new and a Session_ID 524 set to the Session_ID 511 of the game record having the Password 512 that was matched in password check step 620. Player_Name 522 may remain empty for the moment. The password can be removed or marked so that the remainder of the message is clearly discerned in further processing.
Following create player record step 640 or if in name check step 612 no name was found in the associated player record, then in name search step 641, the remainder of the message is checked to determine if it contains a player name (e.g., Bob). If so, then a check is made to ensure that the name found is unique among all player records currently associated with the same Session_ID. The new name is not a duplicate, then in add name step 643, the Player_Name field 522 is updated in the player record corresponding to the source address of the current message and in player record complete step 644, the Player_Status field can be set to engaged to mark the player as ready for play, and message handler 600 terminates successfully.
If however, in name search step 641 either no name is found, or the name found duplicates a Player_Name 522 in a player record sharing the Session_ID 524, then in name invalid step 642, a reply message is sent to the source address of the current message to inform the corresponding player that the proposed player name taken (or was absent), and that they should respond with a new choice of player name. In this case, message handler 600 terminates at incomplete registration handled step 630.
If in password check step 620, the message contains no recognized password suitable for joining a game, then message handler may continue at password request step 621 and reply to the current message with a request for the correct password for the game the would-be player is trying to join. The message handler 600 again concludes at step 630.
An alternative embodiment may skip password request step 621, and instead ignore messages from unknown source addresses that dont contain recognized passwords.
From the foregoing, it should be well within the ordinary skill in the art to implement a game and system that allows cell phones to be used as controllers in video games. As with all such systems, the particular features of the user interfaces and the performance of the processes, will depend on the architecture used to implement a system of the present invention, the operating system of the servers and database selected, the bandwidth and other properties of the network selected, and the software code written. It is not necessary to describe the details of such programming to permit a person of ordinary skill in the art to implement the processes described herein, and provide code and user interfaces suitable for executing the scope of the present invention. The details of the software design and programming necessary to implement the principles of the present invention are readily understood from the description herein. Various additional modifications to or combinations of the embodiments of the invention specifically illustrated and described herein will be apparent to those skilled in the art, particularly in light of the teachings of this invention. It is intended that the invention cover all modifications and embodiments, which fall within the spirit and scope of the invention. Thus, while preferred embodiments of the present invention have been disclosed, it will be appreciated that it is not limited thereto but may be otherwise embodied within the scope of the following claims.
