U.S. patent application number 11/734207 was filed with the patent office on 2008-08-14 for systems and methods for providing lottery game play through an unmanned terminal.
This patent application is currently assigned to LINQ3. Invention is credited to Daniel Silverman Cage, C.J. (Christopher Jon) Little.
Application Number | 20080194311 11/734207 |
Document ID | / |
Family ID | 39645174 |
Filed Date | 2008-08-14 |
United States Patent
Application |
20080194311 |
Kind Code |
A1 |
Cage; Daniel Silverman ; et
al. |
August 14, 2008 |
SYSTEMS AND METHODS FOR PROVIDING LOTTERY GAME PLAY THROUGH AN
UNMANNED TERMINAL
Abstract
A game play system comprises a banking system that includes at
least one terminal configured for financial transactions and an
acquirer transaction server coupled with the terminal, the acquirer
transaction server configured to provide game plays to a user
through the terminal. The game play system further comprises a game
play authority in communication with the acquirer transaction
server, the game play authority configured to receive game play
requests from the acquirer transaction server and game play
information from one or more authorities associated with various
game plays.
Inventors: |
Cage; Daniel Silverman; (Los
Angeles, CA) ; Little; C.J. (Christopher Jon); (Los
Angeles, CA) |
Correspondence
Address: |
BAKER & MCKENZIE LLP;PATENT DEPARTMENT
2001 ROSS AVENUE, SUITE 2300
DALLAS
TX
75201
US
|
Assignee: |
LINQ3
Los Angeles
CA
|
Family ID: |
39645174 |
Appl. No.: |
11/734207 |
Filed: |
April 11, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60886818 |
Jan 26, 2007 |
|
|
|
Current U.S.
Class: |
463/17 ;
705/35 |
Current CPC
Class: |
G07F 17/3223 20130101;
G07F 17/329 20130101; G06Q 40/00 20130101; G07F 19/20 20130101 |
Class at
Publication: |
463/17 ;
705/35 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method for providing games through terminal configured for
financial transactions, comprising: in response to the initiation
of a financial transaction via the terminal, determining whether
game plays are available; when it is determined that game plays are
available, then determining what game type of game plays are
available; once the type of game plays is determined, presenting
game play options via the terminal; in response to a game play
selection of one of the options, authenticating a user; obtaining
the game play information from a an authority associated with the
game play selection; and Presenting the game play information to
the authenticated user via the terminal.
2. The method of claim 1, wherein the terminal is a Automatic
Teller Machine (ATM).
3. The method of claim 1, wherein the authority is a lottery
authority, and wherein at least one of the game play options is a
lottery game play option.
4. The method of claim 1, wherein authenticating the user comprises
authenticating the user's identity.
5. The method of claim 4, wherein authenticating the user's
identity comprises receiving an identity verification from an
issuing bank authority associated with the financial
transaction.
6. The method of claim 1, wherein authentication the user comprises
authenticating the user's age.
7. The method of claim 6, wherein authenticating the user's age
comprises receiving age verification information from an issuing
bank authority associated with the financial transaction.
8. The method of claim 1, wherein authenticating the user comprises
receiving information associated with the user from an issuing bank
authority associated with the financial transaction and verifying
game play eligibility with the authority associated with the game
lay selection.
9. The method of claim 1, further comprising receiving game play
fee information from the terminal and processing the game play fee
through an issuing bank authority associated with the financial
transaction.
10. A game play system, comprising: a banking system, the banking
system comprising: at least one terminal configured for financial
transactions, and an acquirer transaction server coupled with the
terminal, the acquirer transaction server configured to provide
game plays to a user through the terminal; and a game play
authority in communication with the acquirer transaction server,
the game play authority configured to receive game play requests
from the acquirer transaction server and game play information from
one or more authorities associated with various game plays.
11. The game play system of claim 10, wherein the terminal is an
ATM.
12. The game play system of claim 10, wherein the terminal is
configured to process a financial transaction initiated by the
user.
13. The game play system of claim 12, wherein a financial
transaction is initiated via insertion of a card into the
terminal.
14. The game play system of claim 12, wherein the acquirer
transaction server is configured to pull information regarding the
user form the terminal and from an issuing bank authority
associated with the financial transaction.
15. The method of claim 14, wherein the acquirer transaction server
is configured to generate a play request based on the pulled
information and to forward the play request to the game play
authority.
16. The game play system of claim 15, wherein the acquirer
transaction server is configured to receive a play ticket from the
from the game play authority and to pass the game play ticket to
the terminal, and wherein the terminal is configured to present
options related to the game play ticket to a user.
17. The game play authority of claim 16, wherein the game play
authority is configured to receive the play request from the
acquirer transaction authority and compare information contained in
the game play request with certain game play criteria.
18. The game play system of claim 17, wherein the game play
authority is configured to generate the play ticket if it is
determined that game play is possible based on the information
contained in the game play request.
19. The game play system of claim 12, wherein the terminal is
configured to receive a game play purchase request.
20. The game play system of claim 19, wherein the terminal is
configured to process the financial transaction initiated by the
user along with a fee associated with the game play purchase
request.
21. The game play system of claim 19, wherein the terminal is
configured to present the user with the option to input game play
information, use previously input game play information, or use
stored game play information.
22. The game play system of claim 12, wherein the acquirer
transaction server is configured to receive the game play purchase
request, match it with a previous play request, and complete an
eligible play ticket based on information contained in the previous
play request and the game play purchase request.
23. The game play system of claim 22, wherein the acquirer
transaction server is further configured to log the completed
eligible play ticket and forward the completed eligible play ticket
to the game play authority.
24. The game play system of claim 23, wherein the game play
authority is configured to receive an eligible play ticket from the
acquirer transaction server and to process a game play purchase
with an appropriate authority associated with the game play
purchase.
25. The game play system of claim 24, wherein the game play
authority is configured to generate a game play ticket upon
successful processing of the game play purchase with the
appropriate authority.
26. The game play system of claim 25, wherein the game play
authority is configured to associate the game play ticket with a
user account based on the eligible play ticket and to store the
lottery ticket.
27. The game play system of claim 26, wherein the acquirer
transaction server is configured to receive the game play ticket
from the game play authority, tag the game play ticket as
successful, and pass the game play ticket to the terminal.
28. The game play system of claim 27, wherein the terminal is
configured to display and print the game play ticket.
29. The game play authority of claim 12, wherein the terminal is
configured to prompt the user for the user's PIN and to forward the
PIN to an issuing bank authority for authentication.
30. The game play authority of claim 29, wherein the terminal is
configured to continue processing the financial transaction if the
PIN is authenticated and to prompt the user for a game play
selection.
Description
RELATED APPLICATION INFORMATION
[0001] This application claims priority under 35 U.S.C. 199(e) to
U.S. Provisional Patent Application 60/886,818, entitled "Systems
and Methods for Integrating ATM and Lottery Functions," filed Jan.
26, 2007, which is incorporated herein by reference in its
entirety.
BACKGROUND INFORMATION
[0002] 1. Field
[0003] The embodiments described below are directed to electronic
lottery game play, and more particularly to providing lottery game
play through existing ATM infrastructures.
[0004] 2. Background
[0005] Use of ATM, debit, banking, credit, etc., cards is
ubiquitous. In fact, the distinction between such cards is
diminishing as many conventional cards can act as more than one
type of card. Further, more and more features and capabilities are
being added to conventional cards. For example, conventional cards
will soon be equipped with contact-less smart card technology,
allowing the user to simply wave their card in front of an
appropriate terminal in order to complete a transaction.
Additionally, more and more cards will include microprocessors, or
the like and the ability to store more data related to the user and
the user's accounts, even allowing the card to be used for multiple
accounts.
[0006] To date, conventional cards typically do not provide
non-financial transaction capabilities. In other words, while
conventional cards are making it easier to perform financial
transactions, they do not provide the ability to access other
systems such a lottery systems, or other game systems. This is
because the typically financial infrastructures, e.g., ATM
infrastructures, are not interfaced with other infrastructures such
as lottery infrastructures.
SUMMARY
[0007] A method for providing games through terminal configured for
financial transactions comprises, in response to the initiation of
a financial transaction via the terminal, determining whether game
plays are available and when it is determined that game plays are
available, then determining what game type of game plays are
available. Once the type of game plays is determined, presenting
game play options via the terminal, then in response to a game play
selection of one of the options, authenticating a user and
obtaining the game play information from a an authority associated
with the game play selection. The method further comprises
presenting the game play information to the authenticated user via
the terminal.
[0008] In another aspect, a game play system comprises a banking
system that includes at least one terminal configured for financial
transactions and an acquirer transaction server coupled with the
terminal, the acquirer transaction server configured to provide
game plays to a user through the terminal. The game play system
further comprises a game play authority in communication with the
acquirer transaction server, the game play authority configured to
receive game play requests from the acquirer transaction server and
game play information from one or more authorities associated with
various game plays.
[0009] These and other features, aspects, and embodiments of the
invention are described below in the section entitled "Detailed
Description."
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Features, aspects, and embodiments of the inventions are
described in conjunction with the attached drawings, in which:
[0011] FIG. 1 is a diagram illustrating an example integrated
lottery and ATM system in accordance with one embodiment;
[0012] FIG. 2 is a diagram illustrating an example method for
accessing a game play through a ATM network in accordance with one
embodiment;
[0013] FIG. 3 is a flow chart illustrating an example method for
determining a user's eligibility to play a lottery game in the
system of FIG. 1 in accordance with on embodiment;
[0014] FIG. 4 is a diagram illustrating an example method for
processing a transaction request within the system of FIG. 1 in
accordance with one embodiment;
[0015] FIG. 5 is a diagram illustrating an example method for
authenticating the user in the system of FIG. 1 in accordance with
on embodiment; and
[0016] FIG. 6 is a diagram illustrating a process overview for the
system of FIG. 1 in accordance with one embodiment.
DETAILED DESCRIPTION
[0017] The systems and methods described below are directed to
providing integrated ATM access and lottery game play. It will be
understood, however, that the systems and methods described below
are not necessarily limited to ATM and lottery transactions. For
example, other types of terminals and transactions can be provided
as well as other types of game plays. Other types of terminals that
can be provided include Point-Of-Sale (POS) terminal including,
e.g., grocery store POS terminals, gas pump POS terminals, etc.
Generally, any type of terminal configured for POS transactions,
e.g., magnetic stripe "swipe" terminals, contact or contact-less
smart card terminals, etc. (collectively unmanned terminals), can
be provided in accordance with the systems and methods described
herein. Accordingly, the embodiments described below will be seen
as representative examples and not necessarily as limiting the
embodiments to particular infrastructures, systems, transactions,
or game plays.
[0018] FIG. 1 is a diagram illustrating an example integrated ATM
and lottery game play system 100 configured in accordance with one
embodiment. As can be seen, a plurality of banking systems, e.g.,
banking systems 103a and 103b can be interfaced with a game play
authority 114. The term "authority" as used herein is intended to
refer to all of the systems, hardware and software, required to
perform the functions described below. Thus, the term authority is
used to refer to all of the servers, routers, terminals, computers,
processors, databases, application interfaces, applications, etc.,
required to perform the functions described below.
[0019] Each banking system incorporates an acquirer transaction
server, for example acquirer transaction servers 106a and 106b.
Acquirer transaction servers 106a and 106b are configured to
provide an interface between game play authority 114 and the more
traditional banking infrastructures comprising banking systems 103a
and 103b. In certain instances, an acquirer transaction server will
be interfaced directly to stand-alone ATMs comprising part of the
banking system. For example, in system 103a acquirer transaction
server 106a is interfaced directly with a stand-alone ATM 108a. It
will be understood that system 103a can comprise a plurality of
stand-alone ATMs 108a, all interfaced with acquirer transaction
server 106a, and that a single stand-alone ATM 108a is illustrated
for simplicity. In other systems, e.g., system 103b, acquirer
transaction server 106b will be interfaced with a host processor
112. Host processor 112 is then interfaced with one or more ATMs,
such as ATM 108b. Again, it will be understood that host processor
112 can be interfaced with a plurality of ATMs and that a single
ATM 108b is shown for simplicity.
[0020] In systems such as system 103b, host processor 112 provides
much of the processing resources required for transactions using
ATM 108b. In systems such as 103a, such processing resources are
distributed among stand-alone ATMs, such as stand-alone ATM
108a.
[0021] Banking Systems 103a and 103b are interfaced with one or
more issuing bank authorities 102 via network 104. Issuing bank
authority 102 is associated with the user accounts of users 110a
and 110b. Thus, users 110a and 110b must be authenticated by
issuing bank authorities 102 prior to transaction completion. Once
the transaction is completed, the transaction information is
forwarded from banking systems 103a and 103b to the appropriate
issuing bank authority 102 for transaction completion. The
components comprising a typical issuing bank authority 102 are well
known and will not be discussed in detail here.
[0022] Network 104 can comprise one or more wired or wireless Wide
Area Networks (WANs), one more wired or wireless Metropolitan Area
Networks (MANs), one or more wired or wireless Local Area Networks
(LANs), and/or one or more wired or wireless Personal Area Networks
(PANs). Communication can occur over network 104 using any one of a
variety of communication protocols suited for such a
network(s).
[0023] The components of systems 103a and 103b must communicate via
networking interfaces as well. In some instances, components
comprising systems 103a and 103b can be co-located, while in other
instances, the components will be geographically distributed. For
example, acquirer transaction server 106b may be co-located with
host processor 112, while ATM 108b is located at a geographically
remote location. Similarly, stand-alone ATM 108a can be located at
a location that is geographically remote from acquiring transaction
server 106a. Accordingly, the components comprising systems 103a
and 103b can communicate via one or more wired or wireless WANs,
one or more wired or wireless LANs, one or more wired or wireless
MANs and/or one or more wired or wireless PANs, and using one or
more communication protocols as required by a particular
implementation.
[0024] In general, the components comprising systems 103a and 103b
will communicate over the banking systems intranet. It will be
understood that communications within an intranet are generally
more secure than communications external to the intranet, and that
communications outside of the intranet are generally limited in
order to increase security. In system 100, game play authority 114
is located outside of the banking systems' intranets. Accordingly,
acquiring transaction servers 106a and 106b can be configured to
communicate with game play authority 114 via secure connections
113a and 113b.
[0025] Secure connection methods are well known and will not be
described in detail here for the sake of brevity; however, it will
be understood that game play authority 114 can be interfaced with
banking systems 103a and 103b via one or more wired or wireless
WANs, one or more wired or wireless MANs, one or more wired or
wireless LANs, and/or one or more wired or wireless PANs, and using
one or more communication protocols as required by a particular
implementation.
[0026] Game play authority 114 is interfaced with various lottery
authorities 116a, 116b, and 116c. The lottery authorities 116 are
configured to provide lottery game play ability for plurality of
lottery games, e.g., different state lottery games. In certain
embodiments, one or more lottery authorities 116a, 116b and 166c
can be configured to provide game play capability for games other
than lottery games. Game play authorities 116a, 116b and 116c can
be interfaced with a game play authority 114 via one or more wired
or wireless WANs, one or more wired or wireless MANs; one or more
wired or wireless LANs and/or one or more wired or wireless PANs,
and using one or more communication protocols as required by a
particular implementation. It will also be understood that three
lottery authorities 116a, 116b, and 116c, are provided by way of
example only and that system 100 is not limited to certain number
of lottery authorities.
[0027] In system 100, the existing banking system and issuing bank
information can be leveraged in order to provide authentication,
play limiting, re-marketing, and automatic redemption for lottery
games provided via game play authority 114. For example, a high
degree of user authentication can be achieved because all users can
be verified via a physical media, i.e., their bank or ATM card, a
logical code, i.e., their Personal Identification Number (PIN), as
well as via the associated issuing bank before the transaction is
completed. This is commonly referred to as multi-factor
authentication, i.e., the user is authenticated via something they
have (their ATM card) and something they know (their PIN).
[0028] Using the authentication factors described above, e.g., the
user's current location, home location, and age eligibility can be
easily confirmed before allowing the user to participate in the
game, or games being offered by game play authority 114. Further,
the possession of the ATM card and the proper PIN, ensures that the
user is an authorized user for the funds being offered for
participation in the game. This can be referred to as account
access authentication, and use of the factors described above
ensures that there will be little or no fraud as a result of the
strong third party verification provided. Additionally, age
eligibility and game eligibility can be authenticated. In general,
the mere possession of an ATM or bank card by an authorized user
ensures that the user is at least 18 years of age. This is due to
the issuing regulations of issuing banks. For many game types made
available via game play authority 114, the eligibility age is also
18 years of age. Accordingly, simply verifying the possession of
the ATM or bank card can often also verify the age eligibility of
the user.
[0029] Certain games may only be available to certain users. For
example, a user's residence and/or location may dictate whether the
user is eligible to play certain games, such as certain state
lotteries. Further, only certain games may be made available via
certain banking systems. In this respect, acquiring transaction
servers 106a and 106b can determine the location of the user by
verifying the location of the ATM 108a or 108b they are using. The
location information would be verified by querying the banking
system's infrastructure. This information can be used to properly
determine which game types can be made available to the user.
Additionally, the user's residence location can in some instances
be ascertained from the associated issuing bank authority 102. This
information can also be used to verify the user's game eligibility,
e.g., eligibility for a certain states lottery.
[0030] FIG. 2 is a flow chart illustrating an example process by
which a user can access a game via an ATM terminal in accordance
with one embodiment of the systems and methods described herein.
First, in step 202, once a user has initiated a transaction via an
ATM machine, the system can determine whether game plays are
available for that user. Whether game plays are available can,
depending on the embodiment, be determined based on the user's age,
account status, residence, location, banking institution, etc. If
no game are available, then the process ends; however, the user can
continue with any conventional ATM transaction the user may have
initiated.
[0031] If game plays are available, then precisely what type of
games can be determined in step 204. In step 206, the game options
can be presented to the user via the ATM machine's user interface,
i.e., the game options can be displayed on the ATM display. If the
user does not select any of the game options, then the process can
end, although the user can continue with any conventional ATM
transaction the user may have initiated.
[0032] If the user does select a game, then the user can be
authenticated in step 210. If the authentication fails then the
process can end, although the user can continue with any
conventional ATM transaction the user may have initiated, unless
prohibited due to the failed authentication But if authentication
is successful, then the selected game play can be obtained from the
appropriate lottery authority in step 214 and the game play can be
presented to the user, e.g., the lottery numbers can be printed out
for the user via the ATM machine. The process will then end,
although the user can continue with any conventional ATM
transaction the user may have initiated. Additionally, in certain
embodiments, the user can be allowed to go back and select a second
game (step 208).
[0033] FIGS. 3 through 6 are flowcharts illustrating the various
processes carried out by System 100, in order to implement the
process of FIG. 2 as seen in detail from the perspective of the
various components comprising System 100. For example, FIG. 3 is a
diagram illustrating an example process for determining a
customer's eligibility for game play in accordance with one
embodiment. First, in step 302, the terminal, e.g., ATM machine
108a or 108b, receives a transaction initiation request initiated
by a user, e.g., user 110a or 110b. As will be understood, the
transaction is usually initiated via the user inserting their ATM
card, or other type of card, into ATM machine 108a or 108b. In step
304, the terminal will then request information from the associated
acquiring transaction server in step 304. In step 306, the terminal
will continue to step through any financial transactions initiated
by the user. In step 308, if a game play, or play ticket is
received from the associated acquiring transaction server, then a
terminal will present the game play options to the user in step
308.
[0034] In step 310, the acquirer transaction server will begin
accessing user information in response to the request of step 304.
As explained above, this information can include the authentication
information obtained by the associated issuing bank authority. In
step 312, the acquirer transaction server will then generate a play
request, which is forwarded to the associated game play authority
in step 314. In one embodiment, the game play request can comprise
the customer's name, account number, card type, terminal location,
or some combination thereof. This information can generally be
obtained from the associated issuing bank authority 102.
[0035] In step 316, the acquirer transaction server can forward an
eligible play ticket received from the game play authority to the
terminal. An eligible play ticket is generated by the game play
authority after the game play authority compares the information
obtained in the game play request with the lottery, or game play
criteria associated with the respective lottery authority 116. If
the game play authority determines that game play is possible based
on the comparison of step 318, then the game play authority can
generate a valid game play ticket in step 320 and return it to the
appropriate acquirer transaction server.
[0036] The eligible game play ticket can be completed based on
further information received from the terminal in response to the
options presented in step 308. In such instances, the eligible game
play ticket will then be resubmitted to the game play authority for
final processing and purchase. In other embodiments, the game play
authority can be configured to query for previously stored customer
options, e.g., stored numbers or previous customer plays. This
information can then be encapsulated into the eligible play ticket
returned in step 320.
[0037] FIG. 4 is a diagram illustrating an example process for
processing a transaction request via a terminal, such as terminal
108a or 108b, in accordance with one embodiment. With reference to
FIG. 3, game play options can be presented to the user via the
terminal in step 308. In step 402, the user can select to purchase
a game play, or lottery ticket and select the game type. The user
can then input their game play information, e.g., lottery numbers,
via the terminal. In step 404, the terminal will relay this
information, i.e., the game play purchase, game type, and game
information, to the associated acquirer transaction server and will
process the fee associated with the game play. For example, this
fee can just be added into, or process with any financial
transactions engaged in by the user via the terminal. In step 406,
the terminal can continue to process any such financial
requests.
[0038] In step 408, if the financial transaction succeeds,
including processing of the game play fee, then the terminal can be
configured to display a lottery, or game play ticket to the user
via the terminal. If the financial transaction did not succeed,
then the terminal can forward a failure notice to the associated
acquirer transaction server in step 408. Otherwise, the terminal
can print the lottery ticket in step 410. The ticket can comprise
game play information, such as the numbers played by the user,
e.g., batch numbers, as well as verification numbers from the
lottery authority.
[0039] In step 412, the associated acquirer transaction server can
receive the game play request from the terminal and match the
request to a previous eligible play ticket, i.e., generated by the
game play authority in step 320 and provided to the acquirer
transaction server in step 316. In step 414, the eligible play
ticket can be completed using the information received in step 412
and forwarded to the game play authority. In certain embodiments,
the completed eligible play ticket can also be logged by the
acquirer transaction server in step 414. In step 416, a lottery
ticket can be passed back to the terminal for display in step
408.
[0040] In step 418, game play authority 114 can receive the
completed eligible play ticket and process the game play purchased
by forwarding the information to the respective lottery authority.
Upon successful completion of the purchase, the eligible play
ticket can be returned to the game play authority in step 420 and a
lottery ticket can be generated. In step 422, the lottery ticket
can be stored and associated with the user's account based on the
information contained in the eligible play ticket. The lottery
ticket can then be forwarded to the game play authority. In step
424, the appropriate lottery authority can receive the eligible
play ticket information from the game play authority and then
accept or deny the request. Assuming the request is accepted, then
the information needed to finish the lottery ticket in step 420 can
be forwarded to the game play authority.
[0041] FIG. 5 is a diagram illustrating an example process for
customer authentication in accordance with one embodiment. In step
502, the customer can initiate a financial transaction, e.g., by
inserting their ATM card into a terminal. In step 504, the terminal
can prompt the customer to enter their PIN and in step 506, the PIN
can be received as entered by the customer. In step 508, if the PIN
is confirmed then the transaction is allowed to proceed, and in
step 510 the financial transaction and any game play transactions
can continue. In step 512, the issuing bank authority can receive
the PIN from the terminal for verification. The issuing bank
authority, can then provide the confirmation to the terminal in
step 508. In step 514, the associated acquirer transaction server
can use the authorization code generated by the issuing bank
authority for the financial transaction upon purchase of a game
play, or lottery ticket. In step 516, the authorization code can be
forwarded to game play authority 114 to authenticate the user.
[0042] FIG. 6 is a flowchart illustrating an example overall
process flow for a game play transaction using system 100. The
process illustrated in FIG. 6 can be referred to as an up-sell
process where upon completion of a financial transaction the user
is provided the option to play one or more games via the terminal.
First, in step 602, a user can successfully complete a financial
transaction via a terminal, such as terminal 108a or 108b. In step
604, the terminal can be configured to automatically prompt the
user to play one of the games available via the terminal. If the
user elects to play a game, then in step 606, the terminal can be
configured to allow the user to play the game, e.g., by supplying
numbers for the game play. In certain embodiments, the user can be
allowed to select their own numbers, previously stored numbers, or
quick pick numbers.
[0043] Once the numbers are selected, then in step 608, the numbers
are provided to the acquiring bank's processor, e.g., processor
112, or in system such as system 103a, the processing function can
be implemented within terminal 108a. In step 610, the terminal can
be configured to display an acknowledgement or a
non-acknowledgement to the user and print the confirmation of the
transaction success or failure.
[0044] If stored numbers are to be used, then in step 612, the
processor can receive the user stored numbers from a memory, e.g.,
a cash memory, or from the associated acquirer transaction server.
These numbers can then be displayed to the user for election in
step 606. In step 614, the processor can be configured to ensure
that the game play fee is available before committing to the
transaction. In step 616, the fee can be processed by the processor
and forwarded to the associated issuing bank authority. Assuming
the funds for the game play fee are available, then the processor
will receive an acknowledgement in step 618 and earmark the funds
accordingly. The acknowledgement will then be forwarded to the
terminal for confirmation in step 610. If the funds are not
available, then the processor will receive a non-acknowledgement in
step 618 which can be forwarded for confirmation in step 610.
[0045] In step 620, the interbank network, e.g., network 104 and
issuing bank authority 102, can receive the game play fee in order
to confirm that funds are available in the user's account and to
debit the user's account the appropriate funds. Assuming the funds
are available, then the interbank network will forward an
acknowledgement; however, if the funds are not available then the
interbank network will forward a non-acknowledgement.
[0046] In step 622, the game play back end, e.g., the acquiring
transaction server and game play authority, can be configured to
access a user stored or previously played numbers and forward them
via the bank processor to the terminal for display to the user. In
step 624, the game play back end can be configured to ensure that
the game play fee is acceptable before initiating the transaction
with the appropriate lottery authority.
[0047] In step 626, the game play back end can receive an
acknowledgement or non-acknowledgement from the associated lottery
authority, which it can forward to the processor for forwarding to
the associated issuing bank authority. In step 628, the appropriate
lottery authority can process the game play request, tie the game
play request to the customer, e.g., via the customer's account, and
return the acknowledgement or non-acknowledgement.
[0048] Thus, the existing banking terminals, networks,
authentication procedures, etc., can be linked with lottery
authorities in order to provide easy access and payment for lottery
games. Further, the banking network processes can be used for game
play eligibility verification, game play limiting, payment, and
authentication, which can reduce costs and increase game plays.
Still further, one of skill in the art will realize that the game
play backend, i.e., acquirer transaction server and game play
authority, are implemented in a non-parasitic manner. In other
words, while the game play backend uses the existing banking system
for access to users and authentication, it also provides a separate
game play operation and provides the associate benefits. Further,
the existing hardware and infrastructure do not need to be altered
in order to add the game play capability
[0049] In other embodiments, since a relationship with the user is
maintained, various degrees of remarketing and continued marketing
can be employed. For example, users can be offered points via a
loyalty/affinity program or the opportunity to play their favorite
game types and numbers via a `quick select` play on the POS.
[0050] In certain embodiments, automatic redemption of winning
tickets to the user's bank account can be provided as a free
service, or for a fee. This will provide the user with the
confidence that when they purchase a winning ticket through the
system of FIG. 1, then they are assured to reap the benefit of
their purchase, regardless of who holds the paper stock.
[0051] While certain embodiments of the inventions have been
described above, it will be understood that the embodiments
described are by way of example only. Accordingly, the inventions
should not be limited based on the described embodiments. Rather,
the scope of the inventions described herein should only be limited
in light of the claims that follow when taken in conjunction with
the above description and accompanying drawings.
* * * * *