KR101990943B1 - Wagering system and method - Google Patents

Abstract

The system 100 may include an imaging device 178, a paper payment dispensing mechanism 182, a processor 170, and a memory 174 that stores instructions that can be executed by the processor. The instructions may include obtaining identification information and betting information from the barcode captured by the imaging device 178 from the client device 150 and dispensing the payment from the paper payment dispensing mechanism 182.

Description

[0001] WATERING SYSTEM AND METHOD [0002]

Cross-reference to related application

This application claims priority to U.S. Patent Application Serial No. 14 / 515,064, filed October 15, 2014, the disclosure of which is incorporated herein by reference.

In some betting systems, paper slips and tickets can be used to place bets. However, a large number of papers can be accumulated for a single user for a single bet. For example, the user can receive paper slips, paper tickets, and additional paper slips if the batting is successful. When a user makes multiple bets, the amount of paper may be doubled.

1 shows a schematic diagram of a batting system according to an aspect of the present disclosure;
2 is a flow chart illustrating a batting method in accordance with an aspect of the present disclosure;
3 is a flow chart illustrating a method of issuing a slip in accordance with an aspect of the present disclosure;
4 illustrates a client device displaying a slip in accordance with an aspect of the present disclosure;
5 is a flow chart illustrating a batting method in accordance with an aspect of the present disclosure;
Figure 6 illustrates a client device displaying a ticket 600 in accordance with an aspect of the present disclosure;
7 is a flow chart illustrating a batting cashing method in accordance with an aspect of the present disclosure; And
Figures 8A and 8B illustrate a client device displaying a ticket with a corresponding value according to an aspect of the present disclosure.

Figure 1 shows a schematic diagram of a batting system 100 in accordance with an aspect of the present disclosure. The system 100 may include a server 110, an application server 130, a client device 150, and a terminal 170.

The server 110, the application server 130, the client device 150, and the terminal 170 may communicate via the links 120, 140, 160, and 180. The links 120-180 may be any type of communication method or channel, such as a wired or wireless connection. For example, the wired communication channel may be Ethernet, a universal serial bus ("USB"), or any other wired communication channel. Wireless communication channel is a connection of any of the compliant Bluetooth, IEEE 802.11-type (e.g., IEEE 802.11a, IEEE 802.11b, and so on), and other wireless technologies (e.g., industrial, scientific, and medical ( "ISM" ) Wireless < / RTI > band). The links may also include cellular and wireless networks such as wide area networks, local area networks, private area networks, virtual private networks, private networks using proprietary communication protocols from one or more companies, 3G, 4G LTE and Wi-Fi networks, Including, but not limited to, various combinations of < / RTI > The links 120-180 may be made through a private or public network connection.

The server 110 may store all active bets and slips currently in use in the betting system 100. The server 110 may be any type of computer, such as a general purpose computer, and may include a processor 112 and memory 114. The memory 114 may store information that can be accessed by the processor 112. This information may include instructions and data that may be executed by processor 112 or otherwise used. The memory 114 may be any type of memory capable of storing information to be accessed by the processor 112. The memory 112 may be a computer-readable medium or any other medium that stores data that can be read with the aid of an electronic device such as a hard-drive, memory card, ROM, RAM, DVD or other optical disk, Other writeable and read-only memory. The systems and methods may include various combinations of the foregoing, and different portions of the instructions and data are stored on different types of media.

The instructions may be any set of instructions that are executed directly by the processor 112 (such as a machine code) or indirectly (such as by a script). For example, the instructions may be stored as computer code on a computer-readable medium. Here, the terms "command" and "program" may be used interchangeably herein. The instructions may be stored in object code format for directing processing by the processor, or may be stored in any other computer language, including a collection of independent source code modules or scripts that are interpreted or pre-compiled on demand. The functions, methods and routines of the instructions are described in detail below.

The data may be retrieved, stored, or modified by the processor 112 in response to an instruction. For example, although the system and method are not limited by any particular data structure, the data may be stored in a computer register, relational database as a table containing a plurality of various fields and records, XML documents or flat files. The data may be formatted into any computer-readable format. The data may include any information sufficient to identify the relevant information, e.g., a number, a description text, an exclusive code, a reference to the data stored in the same memory or other areas of the different memory (including other network locations) It may contain information used by the weighing function.

The processor 112 may be any conventional processor, such as a processor in a commercially available router. Alternatively, the processor may be a dedicated controller such as an ASIC or other hardware-based processor. The processor and memory may actually include a plurality of processors and memory that may or may not be stored in the same physical housing. For example, the memory may be a hard drive or other storage media located in a server farm in the data center. Accordingly, references to a processor, memory, or computer will be understood to include references to a collection of processors, memory, or computers that may or may not operate in parallel.

The server 110 may also include a transaction database 116. In one example, transaction database 116 may be stored in memory 114. In another example, the transaction database 116 may be stored in a separate memory of the server, or may be stored in a separate device separate from the server, e.g., a remote hard drive. The transaction database 116 may store all information related to the betting transaction to be described in detail below.

The application server 130 may receive transaction information from the server 110 and may communicate with the client device 150. The application server may be a general purpose computer such as the above-described general purpose computer with respect to the server 110. [ The application server 130 may include a processor 132 and memory 134. Processor 132 and memory 134 may be any type of processor and memory, such as processor 112 and memory 114 described above. Application server 130 may be connected to communicate with client device 150 via link 140. The link 140 may be any type of communication channel, such as the wired and / or wireless communication channel described above.

The application server 130 may further include an application database 136. In one example, application database 136 may be stored in memory 134. In another example, transaction database 136 may be stored in a separate memory of the server, or may be stored in a separate device separate from the server, e.g., a remote hard drive. In one example, application database 136 may store information such as transaction database 116. In another example, the application database may store less information than the transaction database 116 stores, as described below.

According to one implementation, the application server 130 and the server 110 may be a single device.

The client device 150 may receive transaction information from the application server. The client device 150 may be any type of computing device, such as a general purpose computer or a personal computer. In another example, the client device 150 may be a mobile device, such as a tablet, mobile phone, or any other type of handheld wired or wireless device. In this manner, the mobile device may have additional components and features in addition to the above-described components. For example, the mobile device may include a global positioning component and an orientation component to determine the location and orientation of the mobile device. The mobile device may include a speech recognition component that allows a user to interact with the speech. In addition, the mobile device may be configured to transmit and / or receive telephones, text messages, image messages, and e-mails.

The client device may include a processor 152 and memory 154, such as the processor and memory described above. The client device may be connected to the terminal 170 by way of a link 160. In addition to the communication methods and protocols described above, the link 160 may include a terminal 170 that scans the machine-readable information displayed on the client device 150, as described in detail below, and vice versa The same is true for the case.

The client device 150 may further include a display 156. The display may be any type of display, e.g., an LCD display, capable of displaying information to a user of the client device. Display 156 may be any size or shape. In one example, the display 156 may be a touch screen, such as a capacitive or resistive-type display. In another example, the display 156 may not include a touch screen input, and the client device may include a separate input, such as a keyboard.

The client device 150 may further include an imaging device 158. Imaging device 158 may be any type of imaging device, such as a camera. The camera may be any type of camera, such as a CCD- or CMOS-type camera. The imaging device may be capable of taking a picture or reading a bar code such as a linear or 2D bar code.

The client device 150 may also store an application, such as a betting application, in the memory 154. The betting application may include a graphical user interface (GUI) that displays information to the user. This information may include displaying a slip, ticket, balance, etc. The user may interact with the GUI via the touch screen or through any other input of the client device.

The client device 150 may be associated with a unique identifier (UID). The UID may be any string that can identify the client device. The characters may be any type of character, including alphanumeric or non-alphanumeric characters, and may be arranged along any bottom such as decimal, binary, or hexadecimal. For example, the UID may be the manufacturer's serial number provided to each device. In another example, the UID may be any random string. In another example, the UID may be a rewards number that identifies the user. The betting application may determine the UID associated with the client device 150, or in another example, the user may provide the UID to the betting application.

The terminal 170 may be any type of computer, such as a general purpose computer as described above. Terminal 170 may include a processor 172 and memory 174, such as the processor and memory described above. The terminal may be connected to communicate with the server via link 180 as described above.

The terminal 170 may further include a display 176. Display 176 may be any type of display, e.g., an LCD display, capable of displaying information to a user of the client device. Display 176 may be of any size or shape. In one example, the display 176 may be a touch screen, such as a capacitive or resistive-type display. In another example, the display 176 may not include a touch screen input, and the terminal 170 may include separate inputs such as a keyboard.

The terminal may comprise an imaging device 178. Imaging device 178 may be any type of imaging device, such as a camera. The camera may be any type of camera, such as a CCD- or CMOS-type camera. The imaging device may be capable of taking a picture or reading a bar code such as a linear or 2D bar code. According to one implementation, the imaging device 178 may be a barcode reader. The barcode reader may be a fixed barcode reader or may be a hand-held barcode reader that can be moved or adjusted relative to the terminal 170.

The terminal 170 may further include a paper pay dispenser mechanism, which may include a call management mechanism 182. The call management mechanism 182 may include a mechanism for dispensing and storing one or more types of calls such as banknotes or coins. The call management mechanism 182 may further include a call collection mechanism for receiving and processing calls. The call management mechanism may detect the amount of money deposited or withdrawn by any method, such as visual detection, magnetic detection, or any other detection technique. In addition, the call management mechanism may include a card reader for processing credit cards, debit cards, or other card-based transactions. The card reader may further read the Player Rewards Card. The call management mechanism 182 may perform transactions according to many protocols or methods, such as ACH, PayPal, or PINpocket.

The paper pay dispenser mechanism may additionally or alternatively comprise a printer. The printer may print a receipt identifying the amount to be paid to the holder of the receipt. For example, a receipt can display a code that can be used to authenticate the authenticity of the receipt and identify the amount of money. As an example, a holder of a receipt may take a receipt to a teller on the race track, and the teller pays the user the same amount of cash as the amount of money the user has authenticated the authenticity of the receipt. In some aspects, the receipt may include the same information as described below for the document. If the terminal includes both a call management mechanism and a printer configured to dispense a call, the terminal may encourage the user to select one of receiving cash or a document.

Terminal 170 may include a betting program stored in memory 174. [ The betting program may be a set of instructions that cause the display 176 to display a GUI so that the user can interact with the terminal 170. For example, the GUI may include a user-account interface, a document interface, a betting interface, and a cashing interface. The user-account interface may display information about the user's betting account, including the amount of money available in the user's betting account. The voucher interface can direct the user to deposit money and display the deposited amount. The betting interface may display any number of betting events, possible outcomes, and potential bets to be made. The cash-in interface allows the user to cash in any bet. The GUI can also display current balance information. The user may interact with the GUI by touch screen on the display 176 or any other type of input, such as a keyboard, keypad, arrow buttons,

Terminal 170 may be a stand alone kiosk located proximate to the physical location of the betting event. In another example, terminal 170 may have any geographic location and may not be limited by the physical location of the batting event. In another example, the terminal 170 may be a cash register and a barcode scanner that is visible at a department store or convenience store.

2 is a flow chart illustrating a batting method 200 in accordance with an aspect of the present disclosure. Although the following description refers to the various blocks of the method 200 in a particular order, it should be understood that the order in which the blocks are to be performed may be changed, and that the blocks may be added or omitted.

At block 202, a slip can be issued. For example, the user can deposit a currency, and a slip with the amount of the deposited currency amount can be issued. At block 204, bets may be made for the amount of the slip, or for any other pre-paid balance. At block 206, the betting may be cashed. For example, if the bet is successful, the ticket may have a value depending on the type of bet. These bets can be cashed in cash or in additional slips.

FIG. 3 is a flow diagram 300 illustrating a method of issuing a slip in accordance with an aspect of the present disclosure. Although the following description refers to the various blocks of the method 300 in a particular order, it should be understood that the order in which the blocks are performed may be changed, and that the blocks may be added or omitted.

At block 302, a user may initiate a betting application at a client device, such as client device 150. The betting application may determine the UID of the client device 150. In one example, the user may provide a UID to the client device 150. [ In another example, the batting application may query the memory 154 of the client device to determine the UID.

The client device 150 may communicate the query to the application server 130 about the status of the UID. The application server 130 may query the application database 136 to confirm any information associated with the UID. For example, the application database 136 may store active journal information, active ticket information, and journal balances associated with the UID. The ticket information may include a ticket value, a ticket price, and a batting result. The application server 130 may send this information to the client device 150 and this information may be displayed on the display 156 by the betting application GUI.

At block 304, the link 160 may be initiated between the client device 150 and a terminal, such as the terminal 170. In this block, the link 160 between the client device 170 and the terminal 170 may be temporarily initiated to transmit the UID associated with the client device 150 to the terminal 170. [ The link 160 may be constructed according to any of the communication methods described above. In addition to the methods described above, the imaging device of the terminal 170 may scan the displayed barcode on the display 156 of the client device 150. The barcode may be any type of barcode, such as a linear or two-dimensional barcode, or any other type of machine-readable barcode. In one example, the bar code may be a QR or Aztec ^® (Aztec) 2- dimensional bar code type. The barcode may represent the UID associated with the client device 150.

When the imaging device 176 scans the barcode displayed on the client device 150, the UID associated with the client device 150 may be transmitted to the terminal 170. The terminal 170 may then communicate the UID to the server 110 and query the transaction database 116 for the current balance associated with the UID. If a UID is sent to the server 110, any future transactions may be associated with that UID until the terminal 170 concludes the session associated with the UID. The server 110 may communicate the balance associated with the UID to the terminal 170 and the balance may be displayed in the GUI displayed on the display of the terminal 170. [ Once displayed on the terminal 170, the user can determine the balance associated with the client device 150.

At block 306, the call may be deposited to the terminal 170. The currency may be deposited using the call management mechanism 182 described above. Such currency may be any combination of cash or coins. Once the currency is deposited, the call management mechanism can determine the total amount of the deposited currency and the currency amount can be displayed on the terminal 170. Until the authorized terminal operator removes the excess call from the terminal, the terminal 170 may securely store the call. In other implementations, a credit card may be used to deposit funds. The terminal 170 may transmit the added currency amount to the server 110.

At block 308, a document may be created at the server based on the call added to the terminal. The document may include an amount and a transaction identifier (TID) and may be associated with a UID within the transaction database 116. The TID may be any string that identifies the document. The characters may be any type of character, including alphanumeric or non-alphanumeric characters, and may be arranged along any bottom such as decimal, binary, or hexadecimal. The TID may be generated by the server 110.

The document may also be associated with a UID such as the UID provided at block 302. [ The server 110 may update the transaction database 116 with the updated balance associated with the UID. For example, if the UID associated with the client device 170 has zero balance, depositing $ 50 will issue a $ 50 slip associated with that UID and a new balance of $ 50. In addition, the transaction will associate the TID of the document with the UID in the transaction database 116.

At block 310, the server 110 may communicate the TID and the amount of the document to the application server 130 along with the UID. In one implementation, the server 110 may not communicate any transaction information stored in the transaction database 116, such as transaction time, transaction location, and so on. According to another implementation, the server 110 may send all available information to the application server 130. The server 110 may lock the transaction database 116 such that the documents associated with the TID are not accessed at a separate terminal.

The application server 130 may update the application database 136 based on the amount of the voucher and may communicate the TID and the voucher amount to the client device 150 associated with the UID. The client device 150 associated with the UID may receive the slip, TID, and amount, and may display the slip at a later time to the user at block 312. The slip may then be designated active when sent to the client device 150 to allow betting to be made on the slip balance by the client device 150 associated with the UID.

At block 314, the server 110 may send the updated balance information to the terminal 170. The updated balance information may be an updated balance associated with the UID based on the deposited currency and the issued document. Once received at the terminal, the terminal may display the updated balance at block 316 as part of the betting program GUI.

If there is an active slip, the user can bet on the balance of the slip as will be described later. Alternatively, the user may log out of one or both of the batting application or the betting program. If the user logs out of the betting program at terminal 170, terminal 170 may disconnect link 180. Any active document may be designated as unlocked in the transaction database 116 for future access.

In another implementation, the link 160 between the client device 150 and the terminal 170 may be initiated by a barcode displayed on the display 176 of the terminal 170. In this manner, the display 176 can display machine-readable codes, such as linear or two-dimensional bar codes. In one example, the displayed barcode may represent a TID. In another example, the bar code may identify a particular terminal 170. The imaging device 158 of the client device 150 may scan the barcode and query the application server 130 in relation to the TID and UID associated with the client device 150. [ The application server 130 may then query the server 110 for the TID and UID. Server 110 may query transaction database 116 for TID and UID. The server 110 may then communicate active tickets, active ticket information, and any other information to the terminal 170. The terminal 170 may then display this information via the betting program GUI via the display 176. [

FIG. 4 illustrates a client device 170 displaying a document 400 in accordance with an aspect of the present disclosure. The document 400 may be displayed on the display of the client device 170. [ As described above, the voucher 400 may include a sum 02 and a TID 404, which may be displayed as part of the voucher 400. [ As shown in FIG. 4, the TID may be represented as a bar code, such as a character set such as a displayed alphanumeric character or a displayed 2D Aztec-style bar code. The slip 400 can be a virtual, digital, or electronic slip and can be displayed on the client device 150. The slip 400 may include additional information such as a publication time, a betting time, any brand name or logo associated with the publisher, an advertisement, or any other type of information. The betting application can also display application navigation buttons such as a logout button, directional arrows, menu options, and the like.

5 is a flow chart illustrating a batting method 500 in accordance with an aspect of the present disclosure. Although the following description refers to the various blocks of the method 500 in a particular order, it should be understood that the order in which the blocks are performed may be changed, and that the blocks may be added or omitted.

At block 502, the user may initiate a betting application at the client device 150 as described above.

At block 504, the user may select an active document. The user can navigate in the betting application GUI displayed on the client device 170. [ For example, the user can navigate in the GUI to display any active document. In some instances, a user may have more than one active document. In this example, the user can navigate to determine which document to display. Such navigation may be accomplished by swiping the touch screen or by any other input, such as a keyboard, keypad, arrow button, or user voice.

If the user does not have an active slip or has an active slip with a balance of zero, a slip issuing method 300 as described above can be used to obtain a slip at the client device 150.

At block 506, the link between the client device and the terminal may be initiated according to any of the methods described above. For example, the imaging device 178 of the terminal 170 may scan the TID associated with the active document displayed on the client device 150.

At block 508, the terminal 170 may query the server 110 for a balance associated with the UID or TID provided by the client device 170. As described above, the server 110 may query the transaction database 116 to determine the balance associated with the UID, and any active slips or bets. The server 110 may communicate the updated balance and any active slip or betting information to the terminal 170. The terminal may receive information from the server 110 and display such information on the GUI on the display 176 of the terminal 170. [

According to one implementation, the method of issuing a slip 300 can be executed, and a user may attempt to bet when an active slip is displayed on the client device 150. [ In this regard, the slip may be displayed at block 312 and the user may proceed to block 510 without having to repeat blocks 502-508 as described below.

At block 510, the user can navigate and bathe in the betting program GUI at terminal 170. [ For example, a user may provide inputs to the terminal 170 using such things as a touch screen, a keyboard, and the like. The user can select a betting event. The GUI can display the participants of the betting event, the possible outcome, and the potential betting to be made in relation to that betting event. For example, a betting event may be a race where the participants are a specific racehorse with a unique name. Betting takes place in a particular racehorse to win the race. Any other type of betting may be made, including but not limited to all the bets listed in the ARCI model rule for horse racing. The bet amount may be any amount, such as a predetermined amount or an amount that will change when additional bets are made.

At block 512, the terminal 170 may communicate the betting information to the server 110. As described above, this information may include a betting event and a betted particular result. This information may also include the terminal location where the bet occurred, the time of the bet, and any additional information associated with the transaction.

The server 110 may store the betting information in the transaction database 116 and update the transaction database 116 based on the betting information. Terminal 170 may reduce the balance associated with a particular UID based on the betting amount.

At block 514, the server 110 may generate a ticket and generate a new document based on the updated balance associated with the UID. The ticket may include a TID that can uniquely identify the ticket. The ticket may further include a price, a betting event information, a betting result, and a potential value when a betting result is displayed. Instead of creating a new slip, the system may credit the user's total balance.

At block 516, the server 110 may communicate the ticket information and the updated slip to the application server 130, where the application server 130 may update the application database 136 and tickets and slips may be updated at block 518 And may be communicated and displayed to the client device 150.

At block 520, the server 110 may communicate the updated balance information to the terminal 170, which information may be displayed at the terminal 170 at block 522.

FIG. 6 illustrates a client device 150 displaying a ticket 600 in accordance with an aspect of the present disclosure. Ticket 600 may include a bet 602, a unique TID 604, and a price 606 paid to the ticket 600. The TID may be represented by a set of characters, such as machine-readable code, such as barcodes, and / or alphanumeric characters. The ticket 600 may further include additional information such as a betting place, a betting event, a betting time, and the like.

FIG. 7 is a flow chart illustrating a batting cashing method 700 in accordance with an aspect of the present disclosure.

At block 702, the batting event may be terminated. For example, this may be the end of a race, a sporting event, or any other type of batting event. When the batting event ends, the result may be. The result of the betting event may be the particular betting rank of the participant participating in the betting event. For example, the betting event may be racing. When the race is over, a certain racehorse can arrive at work. The racehorses who have participated in the race can finish the race in other ranks.

At block 704, the result of the batting event may be verified by the server 110. For example, these results may be communicated to the server 110 and / or the application server 130 automatically. Alternatively, these results may be communicated to the server 110 by the betting manager. In this manner, the betting manager can provide details about the result of the batting event to the server 110 by inputting details to the server 110 by an input of the server 110 or by another computing device capable of communicating with the server 110 Can be input. The server 110 may update the transaction database 116 to update the value of each active ticket for the batting event.

At block 706, the user may start the batting application as described above.

At block 708, the user may select an active ticket. This can be done as described above in the context of selecting an active document.

At block 710, the link between the client device and the terminal may be initiated according to any of the methods described above. For example, the terminal may scan the TID associated with the active ticket displayed on the client device.

At block 712, the terminal may query the server 110 for the value of the ticket based on the result of the batting event. The server 110 may retrieve the stored ticket values from the database 116 and communicate these values to the terminal 170. For example, each participant in a batting event may have a predetermined probability, e. G., Odds, to obtain a particular result. For example, a racehorse can have 7-1 Oz to work on. If a bet of $ 1.00 is to be won by the racehorse, these tickets will be worth $ 8.00. The result of the betting may also be displayed on the terminal 170.

At block 714, the server 110 may generate a slip based on the previous value of any slip and any winning ticket.

At block 716, the server 110 may send the updated document information to the application server 130, which information may be stored in the application database 136 and transmitted to the client device 150. [ The client device can then display the updated document at block 718. The user can then bet on the amount of the voucher in accordance with the method 500 described above, or cash the voucher in cash at the terminal 170 or at the counter.

At block 720, the server 110 may send the updated balance information to the terminal 170, which information may be displayed at the terminal 170 at block 722. [ As described above, the user can bet within the range of the balance, or can cash the balance of the balance at some other location, such as the terminal 170 or the window.

According to another implementation, the server 110 can check the values of all active tickets associated with the betting event when the betting event is terminated. In this manner, the server 110 can communicate the value of the active ticket and issue the updated document to the application server 130, which updates the update transaction database 136 and updates the ticket value and update To the client device 150 associated with the UID for each ticket. In this example, the client device 150 does not need to initiate a link with the terminal 170 to validate the value of the ticket and obtain the updated document. In this manner, the user can start the betting application at the client device 150. [ The betting application may communicate with the application server 130 and receive updated ticket values and updated documents. When the user displays a ticket associated with a completed betting event, such a ticket may display a value on the face of the ticket as shown in Figures 8A and 8B.

In one example, the client device may share the shared ticket and the associated value with other devices. For example, the user may initiate the client device 150 to take a screenshot of the displayed tickets and / or ticket values to generate an image of a ticket that may be stored on the client device. The image of the ticket can be uploaded to the Internet, such as an image hosting website or a social media website, and the image can be displayed according to the user's security preferences. For example, an image hosting website can display an image openly, while a social media web site can display an image only to a user's friend or relative. In another example, a user may share images by e-mail, text messages, Bluetooth, or any file-sharing method that is typically accessible by a client device, e.g., a mobile device.

Figures 8A and 8B illustrate a client device 150 displaying a ticket 800 with a corresponding value, in accordance with an aspect of the present disclosure. Ticket 800 may include batting 802, TID 804, and price 806 as described above. Also, the value 808 of the ticket may be displayed, or may be superimposed on another portion. For example, the value 808 may be displayed on a portion of the ticket 800, but not on the machine-readable portion of the TID 804. In the example of FIG. 8A, there was no betting result, and therefore the value 808 of the ticket 800 is designated as "Lost " because it has no value. In the example of FIG. 8B, there is a betting result and the value 808 of the ticket is displayed as "$ 50 Acquisition (Win $ 50) ".

The betting system 100 is also compatible with the paper-based betting system, although the betting system 100 described above includes slips and tickets that can be displayed on the client device 170. [ For example, the terminal 170 may include a printing mechanism for printing physical slips or tickets and dispensing slips or tickets to the user. The player may scan the slip or ticket at the terminal and receive a bet or additional slip to be cashed at the counter.

According to another aspect of the disclosure, the UID of the device may be associated with an account stored in the transaction database of the server 110. [ In this example, the user may choose to store in the server 110 identification information, such as name, address, bank account information, credit card number, player compensation account information, and any other demographic information. In this regard, the betting system may include a server, an application server, and a client device. The function of the terminal may be performed in the client device by, for example, an application stored in the client device. The client device can communicate transaction information directly with the server. For example, a bet may be made at the client device and the betting information may be communicated to the server 110. This information may include a betting event, a specific result bet, a UID associated with the user and / or device, a time of betting, and any additional information associated with the transaction.

In some aspects, the system can determine the user's intention based on the information represented by the bar code and automatically perform the intended function of the user. As an example, the system may be able to determine whether the bar code represents an identifier of a user or a specific device, an identifier of a ticket or a ticket. For example, if imaging device 158 detects a barcode, terminal 170 extracts a string from such code and determines whether the string is a UID (e.g., preceded by a "U" Whether it is a "V" for the document or a number after the "T" for the ticket). Alternatively, the terminal 170 may send a value extracted from the barcode to the server 110, and the server may search the user, whether this value is associated with the document or ticket, .

If the terminal 170 determines that the bar code indicates a UID, the terminal may use that information to automatically establish a link with the user as described at block 304. [ In that regard, if the user deposits money in the terminal as described in block 306, the terminal may determine that the user desires to issue the slip. Accordingly, the user can issue the slip using the terminal 170 without touching the touch screen or the keyboard of the terminal.

However, if the terminal 170 determines that the bar code represents the TID of the document, the terminal may determine that the user wishes to bet and may automatically proceed to the batting process described in block 506, In addition, if the terminal 170 determines that the bar code represents the ticket's TID, the terminal may determine that the user wishes to cash the ticket and automatically proceed to the batting process as described in block 710 and the like.

Additional information may also be included in the bar code to facilitate the intended function of the user. For example, a user may use the betting application GUI and select an option to withdraw less than the full amount of the document. The betting application may then generate and display on the client device a barcode that includes the TID identifying the document and the amount to be fetched. If the barcode is scanned by the terminal 170, the terminal may interpret the amount that the user has defined as the amount of money in the barcode as an intention to fetch from the document identified by the TID. After confirming that the slip is valid, the terminal can dispense the same currency as the requested amount and issue a new slip against the balance. Alternatively, the barcode may encode the UID and ask to fetch a specific amount, and may dispense the requested amount after determining that the user's balance is more than the withdrawn amount. Instead of dispensing the amount, the terminal may print a receipt that the user can take to the window to withdraw the requested amount.

The barcode may also include user preferences. For example, a user may use a betting application to enter their preferred betting category, and the category may now be encoded with a barcode and displayed on the screen of the client device. If the barcode is scanned and the barcode determines that it includes the user ' s preferences, the terminal may display bets that meet the user ' s criteria. For example, according to the user's preferences, it may appear that the user is always betting a certain amount on the preferred team. By scanning for these preferences and the UID, the terminal can automatically generate a ticket with the requested value for the associated betting event.

The barcode may also be used to perform a complex set of instructions. For example, a user may use the client device to generate a set of instructions that cause ten different bets at approximately the same time. After the user has generated the command, the device may send this command to the server 110. The server may store a command to be used at a later time, and may transmit the unique identifier associated with the command back to the client device. If the user wishes to perform an instruction, for example, betting, the client device may generate a barcode containing a unique identifier. When the user is ready to bet, the user can scan the barcode at terminal 170, and the terminal extracts the identifier from the barcode. The terminal may then send the identifier to the server 110. Upon receiving a unique identifier and determining that the identifier is associated with a set of commands, the server 110 may execute an associated command, e.g., betting. The server may then send a confirmation to the terminal 170 that the command has been performed and the terminal 170 may display a confirmation message to the user.

For security purposes or for other purposes, the system may store a time range in which the command is to be executed. Using the previous example, if the server 110 stores a command, the server may also store a time range within which the user can use the barcode to execute the command, e.g., the start and end dates and times of the range. The server may further associate the command with the number of uses, wherein the number of uses defines the number of times the commands can be performed based on the barcode scan. Once the bar code is scanned and an identifier is sent to the server 110, the server may check whether the current time is within the time range associated with the command and may determine whether the number of uses is greater than zero. If so, the instructions are executed and the usage count can be subtracted. Otherwise, the server can decide that the command should not be executed.

According to one embodiment, an imaging device; A processor; And a memory for storing instructions that can be executed by the processor, the instructions comprising: capturing barcode information displayed on the mobile device to an imaging device; Identifying, among the barcode information, a plurality of bets; Identifying a usage value associated with a plurality of bets, the usage value being associated with the number of times the bet has been made; And betting based on usage values. Such a processor may include at least two processors, and the system may include a server that includes one of the two processors in network communication with a kiosk that includes one of the two processors. In one implementation, the usage value may be changed by one each time a bet is made.
Although the present invention has been described herein with reference to particular embodiments, it should be understood that these embodiments are merely illustrative of the principles and applications of the present invention. It is, therefore, to be understood that numerous modifications may be made to the exemplary embodiments and other devices may be devised without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (20)

An imaging device;
A paper payment dispensing mechanism;
A processor; And
A memory for storing instructions that can be executed by the processor,
The command is:
Obtaining identification information associated with a wager from the barcode captured by the imaging device and displayed on the mobile device;
Extracting a bet value depending on a result of the bet based on the identification information;
Obtaining, from the barcode, a value entered by the user into the mobile device;
Determining whether a value entered by the user is less than the bet value; And
And dispensing a payment, such as a value entered by the user, from the paper payment dispensing mechanism if the value entered by the user is less than the betting value. The method according to claim 1,
Wherein the paper payment dispensing mechanism dispenses the paper currency. The method according to claim 1,
Wherein the paper payment dispensing mechanism dispenses a payment voucher. The method according to claim 1,
Wherein the instructions further comprise, from the barcode, obtaining an indication that the user has requested to fetch the value entered by the user. The method according to claim 1,
The system further comprising a server in communication with the processor,
Wherein the command further comprises transmitting the identification information to a server and receiving the betting value as a response. The method according to claim 1,
The system further includes a display,
Wherein the command further comprises displaying an amount of the betting value and a value entered by the user. The method according to claim 1,
Wherein the system is a stand alone kiosk. An imaging device;
A processor; And
A memory for storing instructions that can be executed by the processor,
The command is:
Capturing barcode information displayed on the mobile device with the imaging device;
Extracting barcode information from the barcode;
Determining whether the barcode information indicates a user ' s identifier or bet;
Determining an identifier of the user from the barcode information if the barcode information indicates an identifier of the user; And
And determining a betting price and a betting event from the barcode information if the barcode information indicates a bet. 9. The method of claim 8,
The command includes:
Determining whether the bar code information represents a document, and
Further comprising determining an amount from the bar code information if the bar code information indicates a document. 10. The method of claim 9,
Wherein the system further comprises a call management mechanism configured to dispense cash,
The instructions further instructing the call management mechanism to dispense cash based on the amount. 9. The method of claim 8,
Wherein the system further comprises a call management mechanism configured to collect cash deposits,
Wherein the command further comprises associating the amount of cash deposited with a user associated with the user's identifier when the bar code information indicates an identifier of the user and the cash management mechanism is cash deposited. 12. The method of claim 11,
The system further includes a printer,
The instructions further instructing the printer to print a slip based on the amount of cash deposited. 9. The method of claim 8,
The system further includes a display,
The command includes:
Determining whether the bar code information represents user-selected criteria for a bet,
Determining if any of the bets meet the user-selection criteria if the barcode information indicates the user-selection criteria for betting; and
Further comprising displaying a bet that satisfies the user-selection criteria. An imaging device;
A processor; And
A memory for storing instructions that can be executed by the processor,
The command is:
Capturing barcode information displayed on the mobile device with the imaging device;
Identifying, among the barcode information, a plurality of bets;
Identifying a usage value associated with the plurality of bets, the usage value being associated with a number of times a bet has been made; And
Betting based on the usage value
. ≪ / RTI > 15. The method of claim 14,
Wherein the processor comprises at least two processors,
The system includes a server that includes one of two processors that are in network communication with a kiosk that includes one of the two processors,
The kiosk comprising the imaging device,
Wherein the plurality of bets are stored in the server. 15. The method of claim 14,
The betting is stored in association with a unique identifier,
And the barcode information encodes the unique identifier. 15. The method of claim 14,
Wherein the instructions further comprise identifying a time range associated with the plurality of bets,
The betting further comprises betting if the then-current time is within the time range. delete 15. The method of claim 14,
Wherein the usage value is changed by one each time a bet is made. 15. The method of claim 14,
The system further includes a display,
Wherein the display displays a confirmation to the user after the betting is done.

Images