Patent Publication Number: US-2012046096-A1

Title: System and method for allowing remote wagers (both for real wagers and for fun/points/prizes) by confirming player location using network generated and/or network centric data

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation-in-part of U.S. patent application Ser. No. 12/851,943 filed Aug. 6, 2010, which claims the benefit of U.S. Provisional Application No. 61/231,994 filed Aug. 6, 2009. 
    
    
     FIELD OF THE INVENTION 
     The embodiments of the present invention relate generally to systems and methods for allowing a player to make wagers over remote devices and computers, and more particularly, to systems and methods for confirming the location of the player using location based services and authenticating and verifying that location through (mobile) Carrier network generated and/or network centric data that validates the location of the player and creating a system whereby there is a client/server authentication process that provides the security, authentication and management of subscriber device control and communication. The systems and methods according to the embodiments of the present invention also allow for marketing, advertising, and commercial transactions based on the player&#39;s authenticated location through the remote device. 
     BACKGROUND OF THE INVENTION 
     Wireless gaming is on the horizon. There are generally two types of wireless gaming. First, a particular jurisdiction, for example a state in the U.S., may allow certain types of wagers to be made over a wireless device as long as the player is within the borders of the state. The player may make a wager over a telephone through an interactive voice recognition (IVR) system. 
     Second, wireless based gaming may be provided within a particular casino. Since 2006, the state of Nevada has allowed wireless gaming (e.g., the placing of wagers using wireless devices within a casino.) Other states may soon follow suit. The jurisdiction may allow casino patrons to use remote, wireless devices to place wagers within the sports book or other designated areas within the casino such as restaurants and pool areas while prohibiting the placement of wireless wagers within other areas such as hotel rooms. 
     The United States&#39; Global Positioning System (GPS) typically allows the location of a GPS receiver to be determined with sufficient accuracy to determine if the receiver is within the borders of a given jurisdiction or within a specific location. Additionally, many cell phones, computers, and wireless modems include a GPS receiver. Thus, it is possible to determine the location of the cell phone or other remote device using the GPS receiver integrated with the remote device or a GPS receiver attached herewith. 
     However, such location determinations may be “spoofed” or otherwise falsified. For example, several GPS providers and location based applications allow users to determine and self-report their GPS-based location to provide maps and/or directions and to share their location with other users. However, the application allows the user to set the location (e.g., by address, city, or state) that other users observe, which allows by-passing of the GPS determined location. 
     One known method  10  for attempting to verify the location and identity of a caller attempting to make a wager is shown in  FIG. 1 . This method requires the use of a telephone which establishes the location of the telephone using a beeper. In a first step  12 , the caller uses the telephone to call into an IVR and enters an account number. The IVR system sends an account access request (based on the entered account number) to the wagering system (step  14 ). The wagering system verifies that the account is valid, active and is authorized to use beepers, and generates a PIN (step  16 ). In step  18 , the wagering system sends the PIN to a beeper system which sends the PIN to the caller&#39;s beeper. The wagering system sends the PIN and other account information to the IVR system in step  20 . The IVR system asks the caller to enter the PIN (step  22 ) which is then entered by the caller (step  24 ). In step  26 , the IVR system verifies that the entered PIN matches the information received from the wagering system and then allows the caller to place wagers. 
     The aforementioned system is cumbersome to players and not suitable for a system designed to handle a large number of transactions. Additionally, this system requires capital investments including the cost, use, and maintenance associated with additional equipment including beepers and the beeper system. Currently the system is only available in Las Vegas and is limited to the broadcast range of the beeper system. The embodiments of the present invention are directed at one or more of the shortcomings identified above. 
     Other variations, embodiments and features of the present invention will become evident from the following detailed description, drawings and claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a prior art method of verifying the location and identification of a caller making a wager; 
         FIG. 2  is a block diagram of a system for allowing a player to make a wager using a remote device over a network, according to a first embodiment of the present invention; 
         FIG. 3  is a block diagram of a system for allowing a player to make a wager using a remote device over a network, according to a second embodiment of the present invention; 
         FIG. 4  is a flow diagram of a method for allowing a player to make a wager using a remote device over a network, according to a first embodiment of the present invention; 
         FIG. 5  is a flow diagram of a method for allowing a player to make a wager using a remote device over a network, according to a second embodiment of the present invention; 
         FIG. 6  is a flow diagram of a method for allowing a player to make a wager using a remote device over a network, according to a third embodiment of the present invention; 
         FIG. 7  is a flow diagram of a method for allowing a player to make a wager verbally using a remote device over a network, according to a fourth embodiment of the present invention; 
         FIG. 8  is a diagram of a conventional cell tower grid; 
         FIG. 9  is a diagram showing a cell phone location being determined using signal strength data acquired by cell towers; 
         FIG. 10  is an exemplary system configuration according to the embodiments of the present invention; and 
         FIGS. 11   a - 11   j  illustrate a validation process and sub-processes according to the embodiments of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF INVENTION 
     For the purposes of promoting an understanding of the principles in accordance with the embodiments of the present invention, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Any alterations and further modifications of the inventive feature illustrated herein, and any additional applications of the principles of the invention as illustrated herein, which would normally occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention claimed. 
     The system and method described herein may be used with a wagering component involving money wagers and payouts, sweepstakes component involving prize giveaways and an advertising and promotional data component. The type of location determination and verification methodology used may be more stringent based on the regulatory issues involved with each component. As provided herein GPS means satellite system location based on an internal chipset; A-GPS means system location based on cell tower triangulation; carrier or control plane means location derived from the network; and device or user plane means location derived from the device. The system/method described herein is configured to manage the location based on a client being on a smart phone or similar device for which the system/method manages spoofing and/or remote control processes. 
     Referring to the figures, wherein like numerals indicate like or corresponding parts throughout the several views, a system and/or method allows wagers to be placed from remote devices over a wireless network (e.g., 2G, 3G, 4G, 5G—1XRTT, EVDO, Wimax, LTE, etc.) networks where the networks determine location from fixed access points. One of the primary concerns with placing wagers over wireless networks is the ability to ascertain with certainty the location of the individual placing the wager. The system and method described herein address the ability to identify with certainty the location of an individual placing a wager. Moreover, the system and method validate the device, application and subscriber ensuring that there is adequate security authentication and subscriber management system around the application operation as to not allow other remote processes to allow the device to be manipulated from a device outside of the allowed gaming jurisdiction as well as validating that the device, application or network has not been compromised and therefore presenting false or manipulated information to a validation server which would allow a user to gain unauthorized or illegal access to the system. 
     With reference to  FIG. 2 , a system  100  allows a player to use a remote device  102  (e.g., cellular telephone) to place a wager on a wagering system  106  over a wireless network  104 . The system  100  verifies that the player and the remote device  102  are within a given, predetermined location (e.g., state, jurisdiction, building, or other predetermined location or locations within a larger geographic area). Only after the player&#39;s location is verified to be within the predetermined location, and with a verified device ID and user credentials along with all the other security, authentication and subscriber control functionality, does the system  100  allow a wager to be placed. 
     The most commonly used system to locate the position of items is GPS. Automobiles, cellular telephones, hikers and any other item may be tracked using GPS. GPS while accurate, is dependent on the remote device  102  reporting itself as part of a 3-D trilateration system. Such a system can be subjected to spoofing and falsification. With the embodiments of the present invention, a validation location is compared to the network information relative to the device based on the Carrier Location Infrastructure based upon the base stations/cell towers with which the remote device is actually communicating (i.e., control plane). 
     It should be noted that gaming includes placing wagers using real money in the form of tokens, electronic funds or other financial instruments in which the player may be provided an award or payout based on a winning result of the game or may include simply playing a game, such as a video or arcade game in which the player is not awarded a prize or is awarded a non-monetary award, such as a ticket or merchandise. Some systems are for money systems and some systems are for points. In other words, in some systems wagers are made with money (or equivalent) and wins are paid out in money and in some systems, wins are paid out with prize awards. In each instance, location will be used to determine player location not only to validate their ability to play for money or for points but also to provide insight into presenting advertisements tailored to the location of the consumer. 
     As described below, the embodiments of the present invention use control plane functionality to derive an accurate location of a user based on carrier tower triangulation data. However, in one aspect, the decision to allow a wager is determined not just based on location, but also business logic and other account, subscriber profile and “limits” placed by gaming regulations and other processes which may also be considered before allowing a person to place a wager—this includes device authentication and subscriber management functions. In one embodiment, the system also informs the player that the player cannot place a wager and provides relocation data to an area where the wager can be placed. 
     The wagering system  106  may be any type of electronic wagering system which allows a player to place a wager. For example, the wagering system  106  can be provided by a casino (or race and sports book operator) and allow the player to place a wager on a sporting event at the casino sports book, on a keno game, table game or other casino game. For example, the wagering system may be the type of sports book system utilized by Nevada casinos to allow live cash wagers but configured to accept wireless wagers. Such systems are conventional and need only be modified to accept wireless incoming transmissions and transmit outgoing transmissions regarding accepted wagers. 
     In one embodiment of the present invention, the player&#39;s location is established using network generated and/or centric data, i.e., data which comes from the wireless network, carrier or authorized carrier location aggregator. Such a location determination method is not subject to spoofing and/or falsification like GPS. In one embodiment, the location determination method includes identifying the cell phone tower with which the remote device  102  is in communication. That is, cell phones communicate with cell towers in proximity to the cell phone. In general, this network centric and network generated data cannot be spoofed since the network validates the location of the device within the network based on the physical tower(s), or carrier installed base station(s), with which the device is communicating and the device is authenticated. Such Carrier data may use fixed position antennas and towers. In other embodiments, it is conceivable that Carrier data may be collected using ancillary network connection points (e.g., Femtocells) or other spectrum access such as LTE or Wimax nodes or antennas with which the wireless device is communicating. 
       FIG. 8  shows a conventional cell phone tower grid. The grid  300  includes a plurality of individual cells  305  each including a cell tower  310  and base station housing electronics (e.g., receivers and transmitters) which facilitate the functionality of the cell network. The cell towers constantly track cell phone signals and the strength of those signals. This allows the towers to compute roughly the caller&#39;s general location in the cell phone grid  300 . Since the cell towers  310  only have a certain radius within which they can pick up and send calls, the cell towers  310  need to pass off the signal reception to another nearby cell tower  310  if the caller moves too far out of range. This constant exchange of information allows an exact cell phone location to be determined. Moreover, cell phones connect to a switch and HLR/VLR to track position such that it is a network connecting with a device allocating the best towers and controlling hand off (i.e., the system knows if a person is entering a legal area or exiting a legal area if needed). 
       FIG. 9  shows a diagram  350  visually indicating how the location of a cell phone is determined using signal strength data of three cell towers  310 - 1  through  310 - 3 . The methodology involves determining the cell tower  310 - 1  with the strongest signal and plot the radius of signal detection associated with the cell tower  310 - 1 . Since the signal as detected by cell tower  310 - 1  is the strongest, the cell phone must be within the radius of signal detection of cell tower  310 - 1 . Next plot the radius of the cell tower  310 - 2  with the second strongest reception. Lastly, plot the radius of the cell tower  310 - 3  with the third strongest reception. The point of intersection  355  corresponds very closely to the cell phone position. Mobile device carriers may be required to provide such communication information between remote devices and remote device stations including towers. 
     For example, in one embodiment the wireless network is a cell phone network provided by a wireless carrier, such as Sprint, AT&amp;T, Verizon, etc., as well as new wireless network providers like Clear, etc. The remote device  102  is a cell phone, computing device using an external or internal wireless modem or other data device, such as a cell phone used as a wireless modem, or other device capable of connecting to the wagering system  106  over the wireless network  104 . When the remote device  102  connects to the wireless network  104 , the connection is through a cell phone tower (not shown). The location of each cell phone tower is geographically fixed and known. Thus, as set forth above, the location of the remote device  102  can be determined based on the signal strength measured by multiple cell towers  310 . A single cell tower  310  is also able to determine the general location (as determined by the radius of operation of the cell tower handing the call or transmission) of the remote device  102  but not a specific location as with multiple cell towers. This is important since it may be used for transmissions and communications not requiring the specific location of the remote device  102 . 
     To further improve the verification of cell phone location, additional data, such as a signal transmission time to cell towers, may be combined with the signal strength data described above. Also, GPS and/or A-GPS data may be used as a backup to verify the location as determined by the cell phone tower triangulation methodology. 
     In another embodiment, the system detects mechanical operations (e.g., key presses or touch screen manipulations) of the cell phone or remote device  102  to prevent spoofing or unauthorized remote communication to a remote device  102  in the permitted jurisdiction while the player is not located within the permitted jurisdiction. For example, it is possible to operate a first remote device in a first location via a second remote device in a second location without the user interface (e.g., keypad or touch screen) being manipulated. To prevent such use, a software application downloaded on the remote device  102  from the wagering system  106  or affiliated server is configured to transmit verification of mechanical operations to the wagering system  106  which can be used as another step in the location verification methodology described above. The software application transmits signals to the wagering system responsive to all or some of the mechanical operations associated with the use of the remote device associated with the communications between the remote device and the wagering system  102 . In one specific example, the software application can determine if a player pin (required to access the wagering system) is entered using the remote device&#39;s keypad or touch screen. More specifically, the wagering system may cause certain actions by the remote wireless device (e.g., blink a light on the remote wireless device) and request that the user enter into the remote wireless device the number of blinks. The software application may also be configured to determine if the remote device  102  is running any suspect applications of the type associated with spoofing and other acts which would seek to defeat the accurate identification of the remote device location. Also, the system validates that the device is not remotely being operated—by evaluating other processes running on the cell phone that could take control of the device. 
     An optional, additional layer of security involves matching the electronic serial numbers (ESN) or similar remote device identification information (IP address) associated with individual cell phones to the cell towers in communication with the cell phones within a cell tower grid. In this instance, the remote device identification information is compared with stored or known data regarding the device identification information. Such matching ensures that the registered remote device is the actual remote device being used to place the wagers and communicates with the wagering system (e.g., server). As set forth below, the system is configured to consider App ID, tokens, user information, location, etc., whereby security is determined by locking the device preventing other communication, control and specifically not allowing remote operations. 
     The aforementioned methods of location verification may be used singularly or in any combinations depending on the jurisdiction, service type and/or operator. 
     It should be noted that a player has total control of their location privacy. That is, a player is able to prevent the system from deriving the location of the remote device  102  via a software application installed on the remote device  102  at the time it is manufactured. Alternatively, the software facilitating the system hereunder includes a prompt allowing the player to refuse to provide remote device data needed to determine the location. Under such conditions, the system is unable to process a wager from the player because the location of the player (i.e., remote device  102 ) cannot be determined. If a person does not allow themselves to be located via Carrier information, the person is preventing from placing a wager. 
     Below are described the registration process and various embodiments of the present invention directed to verifying the location of the player via the remote device  102  based on the above-described systems and methods. 
     As referenced above, there embodiments of the present invention may be used to facilitate a wagering component involving money wagers and payouts, sweepstakes or free play component involving prize giveaways and an advertising and promotional data component. The type of location verification methodology used may be more stringent based on the regulatory issues involved with each component. That is, the wagering component will likely require the most stringent location verification followed by the sweepstakes component while the advertising and promotional data component requires the least stringent location verification. 
     Prior to allowing players to participate in wagering via the system, players are required to register. In one embodiment, the registration process takes place in a brick and mortar casino offering casino games and/or sports wagering. Prospective players complete a registration form which requests personal information of the prospective player. Once approved, the player is optionally provided or permitted to establish a PIN or similar code. Also, the player is able to deposit a sum of money which is held by the casino and used to fund the wagering activities. The money may be in the form of cash or withdrawn from a credit card or bank account. If a credit card or bank account is used, the player may authorize the credit card or bank account information to be securely stored by the casino for later use (e.g., additional withdrawals) if necessary. The player may also decline to allow the credit card or bank account information to be stored by the casino. The player then downloads the wagering software onto the player&#39;s remote device which allows the player to interface with the wagering system  106 . The software download may be accomplished via a wired or wireless connection to the server hosting the wagering software. 
     With specific reference to  FIG. 4 , a method  120  for allowing a player to utilize a remote device  102  to place a wager on a wagering system  106  is described. In a first step  122 , the player initiates a wager session over the wireless network  104  utilizing the remote device  102 . The manner in which the player initiates the wager session will depend, in part, on the nature of the remote device  102  (see below). At this stage, the player may be required to enter a PIN or similar code to access the wagering system  106 . In a second step  124 , the wagering system  106  receives information which identifies the remote device  102 . In one example, the remote device  102  transmits its ESN to the wagering system  106  for verification. Alternatively, the gaming software downloaded on the remote device  102  may incorporate a security key or similar data which allows the wagering system to identify the remote device  102 . The location of the remote device  102  is established as a function of the remote device ID information and network centric data (step  126 ). In a decision block  128 , if the established location can be validated, e.g., the location can be established with sufficient certainty to be within the subject jurisdiction, then in step  132 , the player is informed that the location has been verified and the player is allowed to place a wager or wagers. For example, the player&#39;s device identification, account number and entered PIN have to match, and the device identification has to match the application identification. 
     As discussed above, in one embodiment of the present invention, the player&#39;s location is established on the basis of the cell phone towers  310  through which the remote device  102  is communicating with the network  104 . Additionally, it should be noted that, as discussed above, if the player&#39;s location cannot be verified solely based on the information received from the cell phone towers, other network centric methods and other safeguards may be utilized. 
     With reference to  FIG. 3 , in a second embodiment of the present invention, a system  200  allows user(s) to utilize various types of remote devices  202  to wirelessly place wagers on a wagering system  206  over a wireless network  204 . In the illustrated embodiment, the remote device  202  can be a computing device  202 A, such as a notebook, laptop, netbook, desktop computer, or other computing device cable of using an external or integrated cell modem, a cell phone  202 B through a web-browser application or a dedicated application, or a cell phone  202 C using voice activated commands. 
     In the illustrated embodiment, wagering system  206  includes a wager server  212  and an application server  214 . The computing device  202 A and the cell phone  202 B communicate over the wireless network  204  to the application server  214 . The application server  214  and the wager server  212  communicate over a network  210 , such as the Internet or other network. 
     In general, the connection over the network  210  needs to be secure. For example, the connection can utilize a VPN direct connection to a known server with a client/server dependency that controls the connection and validates the device to the server. Or the connection can be a specific network connection that may be wireless or wired that requires that the device be connected to a common access point that can only connect via a secure connection to a wager or casual gaming server. 
     The cell phone  202 C communicates verbal commands from the player to the wagering system  200  via an interactive voice recognition (IVR) server  208 . The IVR server  208  is connected to the wagering system  200  over the network  210 . 
     With reference to  FIG. 5  in one aspect of the present invention, a method  220  of allowing a player to place a wager on a wagering system  206  using a remote computing device  202 A is provided. In one embodiment, the remote computing device  202 A utilizes a wireless modem or other communications transceiver (not shown), such as a cell modem which allows the remote computing device  202 A to communicate over the wireless network  204 . 
     In one aspect, the cell modem is an external cell modem embodied in a data card (not shown) which connects to the remote computing device  202 A via a USB or other data port. ??? 
     In a first step  222 , the player inserts or connects the data card to the remote computing device  202 A. In a second step  224 , the remote computing device shuts off all other communications ports. In a third step  226 , the remote computing device  202 A initiates a virtual private network (VPN) to ensure secure and private communications between the remote computing device  202 A and the wagering system  206  and runs a wagering application. The wagering application may either be a web-browser based application or a dedicated application. When linking through a VPN or other secure or dedicated connection, the application has to validate the account number and the location of the device is reported via the data card GPS reporting capabilities and from the network as the final validation. 
     Once the wagering application is in communication with the wager server  212 , the application server  214  receives the base station ID, i.e., cell tower, through which the remote computer device  202 A is communicating over the wireless network  204  and establishes the location of the remote computing device  202 A (step  228 ). In decision block  230 , if the established location has been established with a predetermined degree of certainty, based on the application, wager type, wagering system  206 , etc., and a wager can be placed at the location, then the method  220  proceeds to step  238 , in which the player is notified that their location has been verified and approved and the player is then allowed to place wagers. If the location established as a function of the base station ID cannot be verified in block  230 , then the method  220  proceeds to step  232  in which the location of the remote computing device  202 A is established using a second network centric process, such as assisted-GPS. In decision block  234  if the second established location is valid, then the method proceeds to step  238 . Otherwise, the player is informed that their location cannot be verified and/or is not valid for making the wager in step  236 . 
     With reference to  FIG. 6 , in another aspect of the present invention, a method  250  of allowing a player to place a wager on a wagering system  206  using a cell phone  202 B is provided. The cell phone communicates with the wagering system  206  over the wireless network  204 . 
     In a first step  252 , the player installs and runs a software application on the cell phone  202 B. The software application may be a web-browser application or specific application for placing a wager. If this is done in WAP Mobile Browser Session then specific access information has to be installed to derive location (e.g., asking the user to allow location to be utilized). In a second step  254 , the application server  214  receives handset identification (e.g., the telephone number from the cell phone and the International Mobile Equipment Identity or IMEI or other mobile device identification information, such as, IMSI, MAC Address (if Wi-Fi is being used), B-SSID, and/or other information). 
     In one aspect of the present invention, the system and method collect both application and device ID information that must be connect together in order to validate subscription. 
     The telephone number is specific to (e.g., the sim card) in the cell phone, and the IMEI number is specific to the handset. Device ID&#39;s on Blackberry devices include PIN numbers of the device and Android or Apple have Unique ID&#39;s such as UDID&#39;s which the system uses to tie the device to the application. In step  256 , the handset identification is compared with the handset assigned to the player&#39;s account. If the data matches, then the player can be identified and authenticated. This ensures that the sim card is being used with the correct handset. It should be noted that different phones report their ID differently and different carriers manage the users&#39; privacy and access differently. The present invention has the ability, if needed, to track the phone and locations and help restrict access, if a person&#39;s phone or sim card is stolen. 
     In step  258 , the application server  214  receives the base station ID, i.e., cell tower, through which the cell phone  202 B is communicating over the wireless network  204  and establishes a location of the cell phone  202 B (step  258 ). In one aspect the system receives a latitude/longitude reading and an accuracy determination from the network. 
     In decision block  260 , if the location has been established with a predetermined degree of certainty, based on the application, wagering system  206 , etc., and a wager can be placed at the location, then the method  250  proceeds to step  268 , in which the player is notified that their location has been verified and approved and the player is then allowed to place wagers. If the location established as a function of the base station ID cannot be verified in block  260 , then the method  250  proceeds to step  262  in which the location of the cell phone  202 A is established using a second network centric process, such as assisted-GPS. In decision block  264  if the second established location is valid, then the method proceeds to step  268 . Otherwise, the player is informed that their location cannot be verified and/or is not valid for making the wager in step  266 . 
     With reference to  FIG. 7 , in another aspect of the present invention, a method  270  of allowing a player to verbally place a wager on a wagering system  206  using a cell phone  202 B is provided. The cell phone communicates with the IVR server  208  over the wireless network  204 . 
     In a first step  272 , the player places a call to the IVR server  208  and enters or says their account number. It should be noted that the player may either speak their account number or input their account number using the handset. The IVR server  208  also collects the telephone number of the handset (from Caller ID). 
     In a second step  274 , the IVR server  208  sends an account access request (using the account number and the telephone number) to the wager server  212 . The wager server  212  verifies that the account is active and valid and is authorized to GPS phones in step  276 . Once the account has been verified, the IVR server  208  requests the cell tower through which the cell phone is communicating and establishes the location of the cell phone as a function of the cell tower. 
     In decision block  280 , if the established location has been established with a predetermined degree of certainty, based on the application, wagering system  206 , etc. (see above) and a wager can be placed at the location, then the method  270  proceeds to step  288 , in which the player is notified that their location has been verified and approved and the player is then allowed to place wagers. If the location established as a function of the base station ID cannot be verified in block  280 , then the method  270  proceeds to step  282  in which the location of the cell phone  202 C is established using a second network centric process, such as assisted-GPS. In decision block  264  if the second established location is valid, then the method proceeds to step  288 . Otherwise, the player is informed that their location cannot be verified and/or is not valid for making the wager in step  286 . It should be noted that in all four methods  120 ,  220 ,  250 ,  270 , the established location may be compared with a GPS determined location (derived at the user level, i.e., the remote computing device  202 ). 
       FIG. 10  shows an exemplary system  400  configuration according to the embodiments of the present invention. The system  400  comprises a first component  405  and second component  505 . The first component  405  is designated to manage national contests, sweepstakes and similar less regulated matters while the second component  505  is designated to manage local sports wagering and similar highly-regulated matters. For example, the second component  505  may be configured to handle sports wagers from players proven to be located in Nevada as discussed above. 
     A first architecture of the first component  405  includes a router  410 , firewall  415 , switch  420 , optional traffic load balancer  425 , web server  430 , optional load-balanced servers  435 , switch  440 , back-end firewall  445 , switch  450  and integrity servers  455 . A second connection architecture of the first component  405  incorporates a download server  460 . A VPN connection  465  is also shown. 
     The architecture of the second component  505  includes router  510 , firewall  515 , switch  520 , web server  525 , blackberry enterprise server  530 , back-end firewall  535 , router with explicit access list  540 , switch  545 , integrity servers  550 . VPN connections  555  provide access to the integrity servers  550  via corporate network core  560 . The blackberry enterprise server  530  is exemplary and those skilled in the art will recognize that other mobile device brand servers may be incorporated to handle other mobile devices and carriers. 
       FIGS. 11   a - 11   j  show a validation process and associated sub-processes. More particularly, the figures show a process initialization, connectivity test, blacklist request, mobile device version test, authentication server methodology, check account process, A-GPS locate process and send token process. The system, as described above, and below in the various flow charts, locks wagering access to a single application and single device for which the device and application are registered with the wagering system and verified with internal device and external network processes in serial or parallel process flows. 
     So, in general the process to open an account, as set forth herein, involves opening a wagering account by appearing in person and presenting ID and depositing cash into a wagering account. In other embodiments, players open an account via a kiosk or computer in communication with the wager system. Once the subscriber is deemed suitable for a subscriber account, the mobile wagering application specific to that subscriber is sent to the wireless device which is downloaded and installed on the device. The subscriber must also create their own subscriber ID and credentials. Once downloaded and installed, the wagering application gathers specific information about the device such as its device ID, internal ID, phone number and specifically each application must also have its own ID which is locked to the device ID which in turn must match the user credentials so that only one application can be downloaded to one device with only one set of subscriber credentials so that a subscriber can only use their credentials on their device through their application in order to gain access to wager system. 
       FIG. 11   a  shows a process initialization flow chart  700 . At  705 , a connectivity test is run. Should the connectivity test fail, at  710 , the application ends (i.e., user not connected). Should the connectivity test succeed, at  715 , a blacklist request is run. Should the blacklist request fail, at  720 , the application ends (i.e., user not connected). If the blacklist test succeeds, at  725 , the user is connected and requested to input username and password. At  730 , the device sends the username, password, unique device ID, phone number, application version, encrypted version signature, device name, operation system version, platform version and device network to an authentication program running on an authentication sever. At  735 , the device receives a response from the authentication program. At  740 , it is determined if the authentication is successful. If not, at  745 , the application ends. If so, at  750 , the device is communicatively linked to the ticket/wager server. 
       FIG. 11   b  shows a connectivity test flow chart  800  which details the connectivity test conducted at  705  of  FIG. 11   a . At  805 , it is determined if the device USB port is connected to an external device. If so, at  810 , the user is advised to disconnect the external device and the application is exited. Other connection ports may be tested as well. If not, at  815 , it is determined if the device WiFi is turned on. If so, at  820 , the WiFi is turned off by the device application software or manually by the user. If not, at  825 , it is determined if the Bluetooth Radio is on. If so, at  830 , the user is advised to turn off the Bluetooth Radio and the application exits. The connectivity test may also check for any other radio communication protocols. If not, at  835 , the unique device ID, application version, device name, operating system version, platform version and device network are sent to blacklist request ( 715  in  FIG. 11   a ). The objective of the connectivity test is to assist with ensuring all remote control processes are disabled while the wagering application is in operation. Such security features prevent the wireless device from being remotely operated by users outside of the gaming jurisdiction. 
       FIG. 11   c  shows a blacklist request flow chart  900 . At  905 , a list of prohibited applications are read from a blacklist table  910 . At  915 , a list of application versions are read from a versions table  920 . At  925 , it is determined if the application version is supported. If not, at  930 , a supported flag is set to No. If so, at  935 , it is determined if the application version is current. If not, at  940 , a current flag is set to No. If so, at  945 , it is determined if the application version is current and supported. If not, at  950 , the current version and version URL are retrieved from database. At  955 , an encryption seed is generated. At  960 , an XML response including prohibited application list, supported and current flags, current version and current version URL and encryption seed is sent to the device. 
       FIG. 11   d  shows a mobile device version test flow chart  1000 . At  1005 , prohibited applications and version information are retrieved. At  1010 , it is determined if the installed version of the application software on the mobile device is supported. If not, at  1015 , the user is prompted to accept a new version of the application software. If the user declines, at  1020 , the application ends. If the user accepts, at  1025 , the user downloads a current version of the application software and exits the application. If the installed version is current, at  1030 , it is determined if the installed version of the application software is current. If not, at  1035 , the user has the option to accept an update at  1040 . If the user declines to accept the update at  1035 , the application is exited. At  1045 , all applications installed on the mobile device are listed. At  1050 , it is determined if there are matches between the list of applications and impermissible applications (i.e., applications of the type which facilitate remote operation of the mobile device or raise other problematic security concerns). If any match is found, at  1055 , the application is ended. If, at  1050 , no matches are found, at  1060 , a random seed is generated and, at  1065 , the seed is stored by Unique Device ID. The seed is unique for each gaming session. At  1070 , an XML response is sent to the mobile device. 
       FIG. 11   e  shows continued validation process flow chart  1100  involving operations of the authentication server and its communications with the mobile device. At  1105 , server logs an access request and stores all supplied information. The server logs the access request in access request table maintained in database  1110 . At  1115 , the server retrieves a version signature and blacklist seed by unique device ID from blacklist request table and version table maintained by databases  1120 ,  1125 , respectively. At  1130 , the server decrypts an application version signature string which is compared, at  1135 , to a stored version signature. If the version signatures do not match, at  1140 , the device is sent an error message and the application ends. If the version signatures do match, at  1145 , the username and password are validated through a check account process (see  FIG. 11   h ). At  1150 , the username and password pass the validation. 
     Upon validation, at  1155 , it is determined whether a row corresponding to the user is in the user table  1160 . If yes, at  1165 , device location efforts continue. If no row exists, at  1170 , it is determined whether a username exits in the user table  1160 . If so, at  1175 , an error message is sent to the user device and the application ends. If the username does not exist in the user table  1160 , at  1180 , it is determined whether the user device phone number exists in the user table  1160 . If so, at  1185 , an error message is sent to the user device and the application ends. If not, at  1190 , a new user row is written in the user table  1160 . 
       FIG. 11   f  shows a flow chart  1200  detailing continued operations of the authentication server and its communications with the mobile device. At  1205 , the user device phone number is sent to a third party location service for control plane request. At  1210 , it is determined if the response is valid. If no, at  1215 , a third party location service error message is sent to the user device and the application ends. If valid, at  1220 , latitude, longitude, accuracy and account information is sent to SYSTEMLOCATE (see  FIG. 11   i ). At  1225 , it is determined whether the user device is located in the state of Nevada based on the received carrier network information, as described in more detail below. If not, at  1230 , an error message is sent to the user device and the application ends. If the user device is located in the state of Nevada, at  1235 , the application software continues with token which facilitates communication between the mobile device and ticket/wager server once the location is verified. At  1220 , if it is determined that the user device may be in the state of Nevada: (i) at  1240 , a subsequent request for A-GPS location from the third party location service is sent; (ii) at  1245 , latitude, longitude and accuracy based on A-GPS is received from the third party location service; and (iii) at  1250 , the latitude, longitude, accuracy based on A-GPS and account information is sent to SYSTEMLOCATE. At  1255 , it is again determined whether the user device is located in the state of Nevada. If not, at  1260 , an error message is sent to the user device and the application ends. If the user device is determined to be in the state of Nevada, at  1235 , the application software continues with token which facilitates communication between the mobile device and ticket/wager server once the location is verified. If, at  1255 , it is determined that the user device may be located, but not within an acceptable accuracy threshold, in the state of Nevada, at  1265 , an error message is sent to the user device and the application ends. 
     Carrier network/control plane information is information received from Carriers which use several techniques to determine mobile device location. For example, Time Difference of Arrival (TDOA) trilateration may be used by Carriers to determine mobile device location. Network-based TDOA relies on time differences between mobile device transmissions and three or more cell towers to triangulate a mobile device location. Systems based on received signal strength in addition to, or in lieu of, the time-based systems are also implemented by Carriers. The communications between the mobile device and carrier network and/or cell towers (or femtocells and other network hardware devices) facilitate both of the time-based and signal strength systems. 
     Given the concern over personal privacy, the industry has enacted best practice policies which suggest if not mandate that the subscriber control who, what and where location information is available to “third parties.” Subscribers must opt-in in order for their location information to be processed and released to a third party—in this case the system utilizes a third party location privacy system and opt-in/opt-out subscriber management system, that is independently run by a company which acts as an aggregator of Carrier/Network information. However, in some embodiments, the system of the present invention integrates its own subscriber location authorization system based upon rules and regulations required by both industry and Carrier best practices and for gaming approval requirements or other business rules authorizing access to subscriber location where the subscriber must opt-in in order to be located to allow the application to access the system for making a wager. Such a system allows consumers to control access to location information for different applications. If a consumer does not want their location to be known, the consumer would not opt-in and therefore would not be authenticated prohibiting access to the wager server. 
     In certain embodiments, the present system maintains the user&#39;s location stored on secure servers for compliance verification and as part of customer service records. Advantageously, the system maintains the records in a virtualized format and maintained on a server that is only accessible by the system or governmental agencies (e.g., gaming boards) so that the subscriber can enjoy using the wager system on demand without worry about being tracked or visible to other applications or services. 
     Depending on the system configuration, location information is only disclosed when an user logs on or is preparing to place a wager. Since the location aggregators and Carriers charge for ‘location information lookups’ the instant system can determine at which point in the authentication and verification process a location look up may occur—for instance once the account is verified the subscriber may only be looking at account updates or specific sports information, then a location look up and verification only occurs when a wager sequence is to be submitted. However, location look ups may also utilize an initial location look up for purposes of location advertising and in advanced applications may conduct a look up to determine if a user arrives in a legal or authorized wager location such that that the application may notify the user that he or she may place a wager. Location is a valuable tool to present promotions and advertising to subscribers based on their account status or analytics that will help deliver the right advertisement or promotion to a subscriber at the right place and right time. For instance, the ability to send a companion casino offer to a person that is in a casino or to send relevant dining, entertainment or other commercial offers to subscribers relevant to their profile, preferences and of course location. 
     As detailed above, the system may also have direct connections with the Carrier and other network information which can provide accurate and independently verified and authenticated information such as a direct location with Carriers like Verizon, Sprint or AT&amp;T—or a location validation from a handset network group such as Research in Motion, Android or iPhone where the devices are providing accurate and true location to an enterprise or workgroup, network or system independent or in conjunction with the Carrier. The system location look ups are therefore unique as part of a process that determines not only location but accuracy to take into account the edge of a boundary area such as a stateline, licensed gaming footprint, or even a specific area inside or outside of a building. Therefore the system creates authorized gaming areas and at the same time creates areas for which gaming on the wireless device may not be allowed. For instance, if a person is at a casino, instead of placing a wager on a mobile device, the user/device is validated yet the user is ‘prompted’ to go to a sports book window instead of using the device to place the wager. 
       FIG. 11   g  shows a flow chart  1300  detailing continued operations of the authentication server and its communications with the mobile device. At  1305 , a session token is created. At  1310 , the server logs the session token with username and timestamp in the token table  1315 . At  1320 , the username, password and token are sent to SENDTOKEN (see  FIG. 11   j ). At  1325 , the server receives acknowledgment from SENDTOKEN. At  1330 , it is determined if the token communications are successful. If not, at  1335 , an error message is sent to the mobile device and the application ends. If successful, at  1340 , server sends token and successful authentication to mohile device and the process ends. 
       FIG. 11   h  shows a flow chart  1400  detailing a check account process (“CHECKACCT process”). At  1405 , it is determined if the account ID and password has been received. If not, at  1410 , CHECKACCT fails. If the account ID and password are received, at  1415 , it is determined if an account exists corresponding to the received account ID and password. If not, at  1420 , CHECKACT fails. If the account exists, at  1425 , it is determined if the account is inactive. If so, at  1430 , CHECKACCT fails. If the account is active, at  1435 , it is determined if the account status is open. If not, at  1440 , CHECKACCT fails. If the account status is open, at  1445 , it is determined if the received password matches the stored password for the open account. If not, at  1450 , CHECKACCT fails. If the received password matches the stored password, at  1455 , CHECKACCT is deemed a success. 
       FIG. 11   i  shows a flow chart  1500  detailing a location process (generally designated “SYSTEMLOCATE process” which includes Carrier information and potentially A-GPS). At  1505  it is determined if latitude, longitude, accuracy, account ID, phone number and mode are received from the Carrier. If not, at  1510 , SYSTEMLOCATE fails. If latitude, longitude, accuracy, account ID, phone number and mode are received, at  1515 , it is determined if the mobile device is located in the state of Nevada. If not, at  1520 , a no response is returned. If maybe, at  1520 , a maybe response is returned. If yes, at  1525 , a mode is determined between A-GPS and AREANOW (i.e., Carrier-provided information). If, at  1530 , the accuracy of the AREANOW is less than a threshold distance (5000 feet), at  1535 , the device is declared to be in the state of Nevada and, at  1520 , a yes response is returned. If Carrier information does not provide location verification at the desired accuracy threshold A-GPS is used and, at  1540 , the accuracy of the A-GPS is less than a threshold distance (2000 feet), at  1535 , the device is declared to be in the state of Nevada and, at  1530 , a yes response is returned. More specifically, if border control functionality determines that the accuracy factor is greater than the ‘distance’ (e.g., 2000 feet or 5000 feet) to the border, the subscriber is not allowed access. If greater than the threshold distance, at  1545 , the location of the mobile device is deemed unverifiable. Thus, to determine if a person is authorized to place a wager, the reported mobile device location must be less than the accuracy factor reported by the Carrier to show that the subscriber is in a legal wagering location. If further location accuracy is required the Carrier can again derive more accurate information from the network by calculating both the signal time domain or time of flight (i.e., the time required for the signal, which is fixed, to bounce between the mobile device and the tower or network—by calculating the times and distances with at least three points, Cartesian coordinates can determine the location with much more accuracy and therefore improve the accuracy factor allowing for a further validation test). A-GPS is used as a secondary system because of the cost and efficiency associated therewith. 
     In another embodiment, the accuracy thresholds become more stringent as the perceived distance between a mobile device in an approved gaming area and non-approved gaming area decreases. For example, if it is determined that the user is 1000 meters from the border of the state of Nevada (approved gaming area) and Utah (non-approved gaming area), the system requires a first accuracy threshold to validate the location while if it is determined that the user is 500 meters from the same border, the system requires a second more stringent accuracy threshold to validate the location. 
       FIG. 11   j  shows a flow chart  1600  detailing a send token process (“SENDTOKEN process”). At  1605 , it is determined if the account ID, password, and token are received. If not, at  1610 , the SENDTOKEN process fails. If the account ID, password, and token are received, at  1615 , it is determined if the account ID equals zero. If so, at  1620 , the SENDTOKEN process fails. If the account ID does not equal zero, at  1625 , it is determined if the password equal zero. If so, at  1630 , the SENDTOKEN process fails. If the password does not equal zero, at  1635 , it is determined if the token is empty. If yes, at  1640 , the SENDTOKEN process fails. If, at  1635 , the token is not empty, at  1645 , a token is added to the valid token list. At  1650 , success is achieved and a yes is returned. 
     Those skilled in the art will recognize that the order of the steps of the various flow charts may be altered without departing from the spirit and scope of the present invention. Although not shown in the flow chart diagrams, if the player is unable to place wagers because of his or her location, the system may be configured to provide the player with location information which would allow the player to place the wager. For example, if the player attempted to place a sports wager from Baker, Calif., the system would initially not allow the wager to be made. Thereafter however, the system may alert the player if the player proceeds to Primm, Nev. (about 60 miles north on I-15) the wager may then be placed. 
     Based on the location and the type of wager being made, data acquired using different location verification methods may be sufficient. For example, sports wagering is only legal in a few states including Nevada. Therefore, sports wagers could be made by registered players via a remote device  102  assuming the cell tower triangulation method described above is able to verify that the player is within the borders of the state of Nevada. In another example, sweepstakes, contests and free play games are allowed by many states such that the location verification may rely on a GPS-based verification system. In one embodiment, the system  100  initially conducts a “free” lookup to determine if the user is out of state and therefore only allowed access to sweepstakes and/or free game play (i.e., no money involved). 
     The system herein may also be configured to transmit location-based advertising, promotions and offers. Such transmissions do not require the same level of location verification as the gaming and sweepstakes components. Indeed, the location may be used but does not need to be validated. This allows the system  100  to determine how to insert either location-based or customer profile-based advertising, promotions, and offers. The advertisements, promotions and offers can be of any type but in one example they are related to wagering games, sweepstakes, contests and free play in an effort to expand the services utilized by players. Non-related businesses may also seek to allow ad content to be disseminated via the wagering system  100 . The location data allows the advertising, promotions and offers to be tailored to the location of the player. For example, assuming a player registers to utilize the wagering system  100  at a first casino property, which is part of a casino corporate entity having multiple casino properties, the player may be sent advertising, promotions and offers regarding a second casino property operated by the same casino corporate entity when the player is near the second casino property in an effort to encourage the player to enter the second casino property. 
     In another embodiment, an optional rooted detection method is used to determine if an operating system associated with the user device (e.g. Android®) has been modified to allow “root” access. Because Android® is built on an open source code base, world-wide developers are free to create and install modified versions of the Android® operating system on Android® devices. Rooting is a process that allows users of Android® cellphones to attain privileged control within Android&#39;s® Linux subsystem or to completely or partially replace portions of the Android® operating system. Privileged access to the Linux kernel can potentially bypass otherwise secure features of the operating system, such as the hypothetical capability of controlling a device via remote access or spoofing the location reported by the internal GPS subsystem. Some applications require verification beyond reasonable doubt that all security features are properly in place in order to demonstrate various requirements, such as proving that a device cannot be operated remotely. In order to provide this verification, these applications must prove that the phone has not been rooted. 
     The primary objective of the rooted detection method herein is to test for the existence of system files that identify the Linux operating system as providing root access. The list of files tested against remains secret. To increase the security of the method, the secret list of root files can optionally be delivered to the rooted detection algorithm dynamically at runtime by a central server. This provides several benefits in terms of secrecy, but also allows the rooted detection algorithm to respond to any modifications to new root kernels that may sidestep the algorithm in the future. The rooted detection method detects devices that have been given root access or are otherwise rooted. Hence, the method can become an integral part in the verification of other phone services, such as ensuring that a device is not being operated via remote control. 
     Advantageously, the system allows subscribers access to all wager and non-wager applications based upon location. That is, if a person is a wager customer but not located in the state of Nevada they can still log in and retrieve information but not place a wager. However, the person may be prompted to emulate the experience using ‘points’ instead of a cash since the system is able to notify the person that they are not in an authorized or legal wagering area. Importantly, as other states or countries legalize wagering, the system has the ability to locate, notify and allow waging in different jurisdictions from one common application and authentication process. For example, if a person leaves the state of Nevada and arrives in the state of Florida, the person can continue the wagering experience using the application, system and account. 
     The system can therefore automatically morph (or ‘reskin’) to conform to local jurisdiction rules where the application presents new rules. Location and business rules also allow the application to remorph the user interface so that a person in a casino can have the application automatically morph to present the brand and user experience for that casino. If the person walks across the street to another casino, while the functionality of the application remains the same, the look and feel change. 
     Although the invention has been described in detail with reference to several embodiments, additional variations and modifications exist within the scope and spirit of the invention as described and defined in the following claims.