Abstract:
A method and apparatus are provided for using cell phones as controllers in a console video game, thereby allowing a large party of players to play simultaneously and to use an interface with which they are familiar. Best suited for question-and-answer style games, the cell phone interface is more adept at text-based answers than is a typical game controller. Key components in the system is an intervening server which conducts the communications between the game console and the service provider(s) for the players cell phones, and a cell phone database which tracks the players and games in progress for subsequently directing incoming messages from cell phones to the appropriate game console.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates generally to a system and method for using personal cell phones as controllers of a video game. 
       CROSS REFERENCE TO RELATED APPLICATIONS 
       [0002]    Not Applicable. 
       STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
       [0003]    Not Applicable 
       REFERENCE TO COMPUTER PROGRAM LISTING APPENDICES 
       [0004]    Not Applicable 
       BACKGROUND OF THE INVENTION 
       [0005]    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. 
         [0006]    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). 
         [0007]    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. 
         [0008]    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. 
         [0009]    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. 
         [0010]    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. 
         [0011]    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. 
         [0012]    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. 
         [0013]    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. 
         [0014]    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. 
         [0015]    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. 
         [0016]    Dusenberrys application suffers from at least a number of significant drawbacks. 
         [0017]    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. 
         [0018]    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. 
         [0019]    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. 
         [0020]    Fourth, the cost of a continuous connection, depending upon ones contract with the service provider, may be expensive. 
         [0021]    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. 
         [0022]    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. 
         [0023]    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. 
         [0024]    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. 
         [0025]    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. 
         [0026]    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. 
         [0027]    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&#39;t compel players to be a vocal nuisance; is not prone to missing feedback; and allows media-rich presentation without interrupting game play. 
       OBJECTS AND SUMMARY OF THE INVENTION 
       [0028]    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&#39;s cell phone and for the player to respond to the server, yet have the message appropriately relayed to the appropriate game system. 
         [0029]    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. 
         [0030]    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. 
         [0031]    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. 
         [0032]    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. 
         [0033]    It is also an object of the present invention to permit multiple consoles to participate in the same game. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0034]    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: 
           [0035]      FIG. 1  is a block diagram of a system for using cell phones as controllers for a game console; 
           [0036]      FIG. 2  is a flowchart for registering a player&#39;s cell phone to a game, with the registration being initiated by the game console; 
           [0037]      FIG. 3  is a flowchart for registering a player&#39;s cell phone to a game, but where each cell phone initiates its own registration; 
           [0038]      FIG. 4  is a flowchart for asking a question and receiving answers from the players using their registered cell phones; 
           [0039]      FIG. 5  is an exemplary database used to store registrations of cell phones to games; and, 
           [0040]      FIG. 6  is a flowchart for the server handling incoming messages which may or may not be registered in the database. 
       
    
    
       [0041]    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. 
       DETAILED DESCRIPTION OF THE INVENTION 
       [0042]    Referring to  FIG. 1 , game system  100  is shown. A facility  102 , most commonly a player&#39;s den, contains a prior art game system comprising game console  110 , display  114 , audio speaker(s)  116 , and conventional controllers  120  and  124  operated by players  121  and  125 , respectively. Controller  120  has a wired connection  122  to console  110 , while controller  125  has wireless connection  126  to console  110 . Typically, wireless connection  126  is implemented using Bluetooth protocols, but may use another kind of RF connection or an infra-red link to communicate directly with console  110 . 
         [0043]    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. 
         [0044]    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). 
         [0045]    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 . 
         [0046]    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 . 
         [0047]    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. 
         [0048]    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. 
         [0049]    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. 
         [0050]    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). 
         [0051]    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. 
         [0052]    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 . 
         [0053]    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 . 
         [0054]    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. 
         [0055]    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. 
         [0056]    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. 
         [0057]    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. 
         [0058]    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 . 
         [0059]    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 . 
         [0060]    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). 
         [0061]    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). 
         [0062]    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. 
         [0063]    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. 
         [0064]    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. 
         [0065]    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. 
         [0066]    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  FIGS. 2 &amp; 3 . For the fundamental interaction portion of the process, exemplary process  410  is shown in  FIG. 4 . 
         [0067]    In reference to  FIG. 2 , a configuration and registration process  210  is shown in which players cell phones are registered to create cell phone database  136 . In game preparation step  211 , the game and its communication channel is initialized. Initial control over the game console, which may include selecting a game that allows cell phone controller use, is performed with conventional controllers such as  120  and  124 . 
         [0068]    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. 
         [0069]    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. 
         [0070]    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  FIG. 1  SMS gateways  140  and  160  are shown connected to only one entity, servers  132  and  152 , respectively. 
         [0071]    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 . 
         [0072]    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 . 
         [0073]    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. 
         [0074]    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 . 
         [0075]    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 . 
         [0076]    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 . 
         [0077]    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. 
         [0078]    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 . 
         [0079]    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. 
         [0080]    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. 
         [0081]    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 . 
         [0082]    In  FIG. 3 , and alternate configuration and registration process  310  is shown, which ultimately produces the same results (the cell phones  148  and  168  are registered to players  149  and  169  in the game on console  110 ), but with a lower burden of data entry using controllers  120  and  124 , but a slight increase in data entry through cell phones  148  and  168 . This should represent a net decrease in burden, as follows. 
         [0083]    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 . 
         [0084]    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. 
         [0085]    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 . 
         [0086]    In another alternative embodiment, the console  110  can provide the password, which would be provided to lobby server  132  in a message. 
         [0087]    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. 
         [0088]    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. 
         [0089]    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). 
         [0090]    In the preferred embodiment, however, an email address is used. 
         [0091]    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). 
         [0092]    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. 
         [0093]    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. 
         [0094]    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. 
         [0095]    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. 
         [0096]    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. 
         [0097]    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 . 
         [0098]    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. 
         [0099]    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 . 
         [0100]      FIG. 4  shows an example of game play employing the present invention. 
         [0101]    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. 
         [0102]    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  FIG. 4  assumes that all players  149 ,  169 ,  121 , and  125  have their own, registered cell phones. While it will be apparent to those skilled in the art of game design how to accommodate a mixture of both cell phone interactions and controller interactions in actual play, the explanation of game play is clearer if all players are assumed to be using the same mode of interaction. 
         [0103]    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. 
         [0104]    The question is presented to the players on display  114  or through audio output  116  in presentation step  412 . 
         [0105]    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 . 
         [0106]    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. 
         [0107]    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 . 
         [0108]    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. 
         [0109]    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. 
         [0110]    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 
         [0111]    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. 
         [0112]    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. 
         [0113]    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 . 
         [0114]    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 . 
         [0115]    In resolution step  419 , console  110  evaluates each players answer in accordance with the game rules. 
         [0116]    Preferably, the game rules interpret answers to accommodate the more likely errors associated with texting under the pressures of speed and competition. 
         [0117]    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. 
         [0118]    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. 
         [0119]    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. 
         [0120]    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. 
         [0121]    With the answers received and processed, the question and answer transaction completes in step  420 . 
         [0122]    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. 
         [0123]    The question and answer process  410  can be used in many ways, are a few examples of which follow. 
         [0124]    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? 
         [0125]    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. 
         [0126]    Besides the question and answer process  410 , other game play processes are possible, and should be considered within the scope of the present invention. 
         [0127]    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 . 
         [0128]    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. 
         [0129]      FIG. 5  shows an exemplary implementation of cell phone database  136 . 
         [0130]    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 . 
         [0131]    Individual players and their cell phones are tracked by records  525 ,  526 ,  527 ,  528 , and  529  in players table  520 . 
         [0132]    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  FIG. 5  indicate that each game record may have zero or more players, but that each player record will have, at the most, one associated game record. 
         [0133]    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. 
         [0134]    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  FIG. 6 . 
         [0135]    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 . 
         [0136]    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. 
         [0137]    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. 
         [0138]    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. 
         [0139]    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  FIG. 6  as message handler  600 . 
         [0140]    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. 
         [0141]    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 . 
         [0142]    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. 
         [0143]    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 . 
         [0144]    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. 
         [0145]    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. 
         [0146]    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. 
         [0147]    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 . 
         [0148]    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 . 
         [0149]    An alternative embodiment may skip password request step  621 , and instead ignore messages from unknown source addresses that dont contain recognized passwords. 
         [0150]    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.