Patent Application
20190122492
The present invention relates generally to gaming networks, and more particularly to financial transactions and monetary instruments for gaming networks.
It is generally well known that casinos and other gaming establishments are vulnerable to fraud and other financial crimes because of the nature of their operations. Typically casinos and gaming institutions can be fast-paced, cash-intensive businesses that provide a broad array of financial products and services, some of which are similar to those provided by depository institutions and money service businesses. A common provision involves the use of a physical instrument having a cash or monetary value, such as a printed ticket or cash voucher. Such monetary instruments can be subject to criminals wishing to engage in suspect activities, however, such as fraud or anonymous money laundering that might exploit problems with the provided monetary instrument systems. There can also be features that help promote customer services and interest, such as advertisements or coupons on printed cash vouchers.
While gaming monetary instruments and systems have worked well in practice over many years, there is always a desire to improve the security, functionality, and efficiency of these items and systems. What is desired then are improved gaming monetary systems, particularly with respect to the ability to provide greater tracking for fraud prevention and to provide improved customer services to players.
It is an advantage of the present disclosure to provide useful data and tracking for monetary instruments across gaming systems. In particular, such data can be useful for tracking activity patterns regarding anonymous gaming monetary instruments, such as printed tickets or vouchers having a cash value. This can be accomplished at least in part through the use of system nodes and a system server in communication therewith, with these system items having improved abilities with respect to the generation and organization of data, data structures, and historical records that can be associated with some or all of the gaming monetary instruments used within the system.
In various embodiments of the present disclosure, a gaming monetary instrument tracking system can include a plurality of system nodes and a system server coupled thereto. Some or all of the system nodes can be configured to generate data with respect to gaming monetary instruments associated with the gaming instrument tracking system, where each of the gaming monetary instruments have a monetary value associated therewith. Some or all of the system nodes can also be configured to issue new gaming monetary instruments associated with the system. The system server can be configured to receive data generated by the system nodes and create data structures that link multiple gaming monetary instruments with each other according to multiple different transactions regarding the multiple gaming monetary instruments at different times and across multiple different nodes from the plurality of system nodes.
In various detailed embodiments, the system nodes can include electronic gaming kiosks, electronic gaming machines, and electronic gaming tables. Also, the system server can be configured to facilitate issuance at a first system node of a first gaming monetary instrument associated with the gaming instrument tracking system, to associate a first data structure with the first gaming monetary instrument, and to generate and store a first historical record for the first gaming monetary instrument. The first historical record can account for an entire monetary value of the first gaming monetary instrument, with the entire monetary value involving different transactions at different times and at different nodes from the plurality of system nodes. In some embodiments, the first historical record includes unique identifiers regarding cash value instruments used for the monetary value of the first gaming monetary instrument, which unique identifiers can include a serial number from a cash note. In various embodiments, the first gaming monetary instrument is a printed ticket having a cash value. Further, the first gaming monetary instrument can be transferable, where neither the first gaming monetary instrument nor the first historical record includes any data regarding a specific person.
In various detailed embodiments, the system server can be further configured to receive new data regarding acceptance of the first gaming monetary instrument at a second system node, and to update the first data structure with the new data. In addition, the system server can be further configured to facilitate issuance at the second system node a second gaming monetary instrument, to associate the first data structure with the second gaming monetary instrument, and to generate and store a second historical record for the second gaming monetary instrument, and wherein the second historical record includes data from the first historical record in addition to new data regarding the second system node.
In various embodiments of the present disclosure, a gaming monetary instrument tracking system can include at least a system server coupled to multiple system nodes across a gaming system, each of the multiple system nodes being configured to generate data with respect to gaming monetary instruments having monetary values associated therewith. The system server in such embodiments can be configured to at least receive data generated by the multiple system nodes, facilitate the creation of a first gaming monetary instrument at one of the multiple system nodes, the first gaming monetary instrument having a first monetary value associated therewith, create a first data structure for the first gaming monetary instrument, the first data structure including data regarding multiple different transactions at multiple different times and at multiple different nodes from the plurality of system nodes, and generate a historical record for the first gaming monetary instrument based on the first data structure, wherein the historical record accounts for the entire first monetary value and includes monetary values from at least two related, previously issued, and expired gaming monetary instruments.
In various detailed embodiments, the system server may be configured to analyze the historical record with respect to one or more predefined gaming activity patterns, provide an alert to casino personnel when the analyzing results in detection of a suspicious gaming activity pattern, and/or provide a specific reward to a player when the analyzing results in detection of a player rewardable gaming activity pattern. The system server may be configured to accept the first gaming monetary instrument at a second node of the multiple system nodes, provide a monetary credit at the second node, and update the first data structure to reflect the accepting and providing at the second node.
In still further embodiments, a computer implemented method for facilitating monetary instrument tracking in a casino gaming network can cause at least one processor to execute a plurality of instructions involving all or some of the foregoing features in any desired combination.
Other apparatuses, methods, features and advantages of the disclosure will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the disclosure, and be protected by the accompanying claims.
The included drawings are for illustrative purposes and serve only to provide examples of possible structures and arrangements for the disclosed inventive apparatuses, systems and methods for gaming monetary instrument tracking. These drawings in no way limit any changes in form and detail that may be made to the disclosure by one skilled in the art without departing from the spirit and scope of the disclosure.
Exemplary applications of apparatuses and methods according to the present disclosure are described in this section. These examples are being provided solely to add context and aid in the understanding of the disclosure. It will thus be apparent to one skilled in the art that the present disclosure may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the present disclosure. Other applications are possible, such that the following examples should not be taken as limiting. In the following detailed description, references are made to the accompanying drawings, which form a part of the description and in which are shown, by way of illustration, specific embodiments of the present disclosure. Although these embodiments are described in sufficient detail to enable one skilled in the art to practice the disclosure, it is understood that these examples are not limiting, such that other embodiments may be used, and changes may be made without departing from the spirit and scope of the disclosure.
The present disclosure relates in various embodiments to devices, systems, and methods for providing, conducting and facilitating the automated issuance and tracking of gaming monetary instruments, creating data structures and historical records thereof so as to link transactional activities across multiple system nodes and instruments, and also providing records, alerts, and other promotions or features related thereto. One aspect disclosed herein is directed to different methods, systems, and computer program products for facilitating automated tracking, recording, and follow up activities regarding gaming monetary instrument activities implemented in and across a casino gaming network. At least one system processor may be caused to execute a plurality of instructions related to such automated tracking, recording, and follow up activities.
Casinos and other gaming establishments are vulnerable to fraud and other financial crimes because of the nature of their operations. These gaming institutions can be fast-paced, cash-intensive businesses that provide a broad array of financial products and services, some of which are similar to those provided by depository institutions and money service businesses. Moreover, these gaming institutions tend to serve a diverse and transient customer base about which they may have relatively little knowledge. Nevertheless, many gaming institutions still utilize physical instruments having a cash or monetary value, such as printed tickets or cash vouchers. Such monetary instruments can be subject to criminals wishing to engage in suspect activities, however, such as fraud or anonymous money laundering that might exploit problems with the provided monetary instrument systems. There can also be features that help promote customer services and interest, such as advertisements or coupons on printed cash vouchers.
Both state-licensed and tribal casinos typically offer games where players essentially bet against the casino or “house.” Examples of such games are blackjack, roulette, slot machines, bingo, keno, and the like. Casinos also offer customers a variety of financial services, including maintaining accounts, accepting deposits into these accounts, issuing credit and receiving payments on credit, cashing checks, issuing casino checks, sending and receiving wire transfers, and exchanging currency. Many financial transactions take place at the “cage” or casino bank or window. Financial transactions may also occur at casino gaming areas, where players can buy tokens for slot machines or chips for table games. Card clubs offer many of the same financial services as traditional casinos Like casinos, card clubs may maintain a cage where cashiers conduct financial transactions. However, unlike casinos, card clubs rarely extend credit to customers.
Casinos, card clubs, and other gaming establishments that are subject to the federal Bank Secrecy Act (“BSA”) may desire to implement fraud detection programs that include procedures for detecting and reporting suspicious transactions (e.g., money laundering, counterfeiting, electronic tampering, theft, etc.), and for assisting with the identification and reporting of such suspicious transactions. Various embodiments of fraud detection and reporting techniques described herein are directed to different methods and systems for enabling automated, rule-based monitoring, analysis, detection and reporting of suspicious activities relating to financial or monetary transactions (referred to herein as “financial transactions”) conducted in casino gaming establishments, casino networks, and/or non-casino environments. Examples of various types of financial transactions may include, but are not limited to, one or more of the following (or combinations thereof):
One or more of these transactions may occur at various casino-related devices, machines, systems, and/or locations of the casino environment such as, for example, one or more of the following (or combinations thereof):
Other transactions may occur at various devices, machines, systems, and/or locations of non-casino environments such as, for example, one or more of the following (or combinations thereof):
According to different embodiments, information relating to casino-related financial transactions may be captured (e.g., in real-time or non-real-time) at the device or system where the financial transaction is taking place, and uploaded (e.g., in real-time or non-real-time) to a central server. For purposes of discussion, the devices and systems where financial transactions take place can generally be referred to as “system nodes,” while the central server can be referred to as a “system server” that is in communication with the system nodes. For example, at the casino gaming devices and/or game tables, players may either deposit their money (cash and/or ticket vouchers), or put up credits (pre-established credit accounts), as well as removing them. Regardless, these types of data may be captured, uploaded, and analyzed for suspicious activities. Preferably, the capturing and uploading of the financial transaction information may be performed in real-time so as to allow the casino to detect and respond to potential fraud and other suspicious activities in a timely manner. All such criminal and suspicious activities will generally be referred to as “fraud” or “fraudulent” type activities throughout the various discussions herein. In addition, the financial transaction information can also be used to provide other benefits to the casino and players, such as with respect to anonymous player tracking and rewards provisions. Analysis, detection, and alerts can take place at the system server and/or another suitable network device.
In at least one embodiment, the uploaded financial transaction information may be analyzed at a casino server system for detection of suspicious fraudulent activities. Financial transactions which are flagged as potentially suspicious fraudulent activities may be logged, and additional analysis may be performed if specific triggering criteria is satisfied. For example, in at least one embodiment, a multi-step analysis process may be utilized for suspicious money laundering activity analysis, whereby all (or selected) financial transactions are each initially screened and analyzed for one or more triggering events/conditions which, if satisfied, may necessitate additional (in-depth) suspicious fraudulent activity analysis of the identified financial transaction. For example, in some embodiments, less than 1% of the total casino-related financial transactions analyzed may undergo in-depth suspicious fraudulent activity analysis.
By way of example, in one embodiment, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that total consecutive money cashed in (e.g., for a given player over a given time period such as, for example, 3 minutes) exceeds $3000 or some other specified threshold value.
In some embodiments, a substantial cash in (e.g., at least $3000), follow by a minimum amount of gaming (e.g., at least 3 games of at least $20 wager each), followed by a cash out, can trigger a deeper analysis for suspicious fraudulent activity.
In some embodiments, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that cumulative money cashed in for a given player over a given time period exceeds some specified threshold value. For example, frequent money-in into a gaming terminal, at 3-minute to 5-minute intervals, of $3000 or more each time, for a total of more than $10,000 in 15 minutes, may trigger a deeper analysis for suspicious fraudulent activity.
In some embodiments, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that total consecutive money cashed out (e.g., for a given player over a given time period) such exceeds some specified threshold value. For example, frequent cash-out events at a gaming terminal, at 1-minute to 5-minute intervals, of $2000 or more each time, for a total of more than $9,000 over a 20-minute time window, may trigger a deeper analysis for suspicious fraudulent activity.
In some embodiments, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that total money cashed out (for a given player over a given time period) exceeds some specified threshold value.
In yet other embodiments, the triggering of in-depth suspicious fraudulent activity analysis may be based, at least partially, on statistical information relating to one or more group(s) of gaming devices over a period of time, and/or may be based, at least partially, on statistical information relating to other types of financial transactions which occur over one or more specified time periods(s).
For example, financial transactions for a given gaming device (or a specified group of gaming devices) may be averaged over a specified time period or time interval (e.g., 90 days) to establish a relative baseline of what a “normal” transaction is for that particular gaming device (or group of gaming devices). Any detected financial transactions (new and/or historical) associated with the identified gaming device (or associated with one or more gaming devices of the identified group of gaming device) may then be compared to the baseline “normal” transaction. If, based on the results of the comparison(s), it is determined that an identified transaction exceeds predefined threshold comparison criteria (e.g., greater than 3 sigmas or 3 standard deviations higher than the baseline “normal” transaction), such a determination may trigger in-depth suspicious fraudulent activity analysis of the identified new transaction.
By way of illustration, in one example, a statistical average analysis may be performed for cash-in transactions occurring at an identified gaming device over a 3-month time period. Based on this analysis it may be determined that the baseline “normal” cash-in transaction value and standard deviation value for the identified gaming device is $300, +/−$200. In one embodiment, the $300 value may represent the baseline “normal” cash-in transaction, and the “+/−$200” value may represent one standard deviation. One of the cash-in transactions which occurred during the analyzed 3-month time period relates to a cash-in transaction for $3000. This identified transaction may be determined to be about 13.5× standard deviations higher than the calculated baseline “normal” cash-in transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the identified transaction. Another, (new) cash-in transaction for $1800 is detected at the identified gaming device. This newly identified transaction may be determined to be about 7.5× standard deviations higher than the calculated baseline “normal” cash-in transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the newly identified transaction.
Similarly, in at least one embodiment, a statistical average analysis may be performed for cash-out transactions occurring at an identified gaming device over a 200-day moving time period. Based on this analysis it may be determined that the 200-day moving average, or the baseline “normal” cash-out transaction value and standard deviation value for the identified gaming device is $200, +/−$100. In one embodiment, the $200 value may represent the baseline “normal” cash-out transaction, and the “+/−$100” value may represent one standard deviation. One of the cash-out transactions which occurred during the analyzed 200-day moving time period relates to a cash-out transaction for $2000. This identified transaction may be determined to be about 18× standard deviations higher than the calculated baseline “normal” cash-out transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the identified transaction. Another, (new) cash-out transaction for $800 is detected at the identified gaming device. This newly identified transaction may be determined to be about 6× standard deviations higher than the calculated baseline “normal” cash-out transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the newly identified transaction.
In some embodiments, multiple different types of baseline “normal” transaction values and associated standard deviation values may be calculated for a given gaming device (or given group of gaming devices), which, for example, may be based on analysis of filtered sets of financial transaction data occurring at the identified gaming device (or identified group of gaming devices) over different time periods such as, for example, one or more of the following (or combinations thereof):
In some embodiments, general trends relating to the fluctuation of baseline “normal” financial transactions over different time periods at a given gaming device (or given group of gaming devices) may be analyzed in order to determine one or more types of baseline “normal” transaction values and corresponding standard deviation values to be associated with the identified gaming device (or identified group of gaming devices).
For example, in some casino environments, it may be observed that the average wager amounts and/or cash-in amounts on Friday nights and Saturday nights are relatively higher than the average wager amounts and/or cash-in amounts on weekday nights. One reason for this may be attributable to the tendency for casinos to increase their minimum wager amounts at table games and/or other gaming devices on Friday nights and Saturday nights. Accordingly, in at least one embodiment, it may be desirable to calculate a separate “Friday-Saturday” baseline “normal” cash-in transaction value and related standard deviation value for an identified gaming device (or identified group of gaming devices). In one embodiment, the “Friday-Saturday” baseline “normal” cash-in transaction value and related standard deviation value may be determined by analyzing a filtered set of cash-in transactions which occur at the identified gaming device (or group of gaming devices) on Fridays and Saturdays over a specified time period (such as, for example, 3 consecutive months). If desired, a separate the “Friday-Saturday night” baseline “normal” cash-in transaction value and related standard deviation value may be determined, for example, by analyzing a filtered set of cash-in transactions which occur at the identified gaming device (or group of gaming devices) on Fridays and Saturdays between the hours of 5 pm and 2 am over a specified time period (such as, for example, the last 100 days).
Non-limiting examples of various types of baseline “normal” transaction criteria and associated standard deviation criteria which may be calculated for a given gaming device (or given group of gaming devices) may include one or more of the following (or combinations thereof):
It will be appreciated that the various types of baseline “normal” transaction and standard deviation criteria which may be generated and utilized for triggering of in-depth suspicious fraudulent activity analysis may depend upon the desired types of financial transaction filter criteria to be applied (such as, for example, time period filter criteria, transaction date filter criteria, transaction day of week filter criteria, transaction time filter criteria, etc.). Additionally, in at least some embodiments, the range of acceptable standard deviation variance may also be used as a definable criteria for triggering of in-depth suspicious fraudulent activity analysis. For example, any transactions which have been identified as exceeding 4× standard deviations from the baseline “normal” transaction may be flagged for in-depth suspicious fraudulent activity analysis.
In some embodiments, one or more detected transactions occurring at a given gaming device (or group of gaming devices) may be analyzed and compared against multiple different types of baseline “normal” transaction and standard deviation criteria. For example, in one embodiment, a cash-in transaction for $1500 occurring at a specific gaming device on a Friday evening may be analyzed and compared against each of the following types of baseline “normal” transaction and standard deviation criteria:
In at least one embodiment, the results of the baseline comparison analyses for the identified $1500 cash-in transaction may be as shown below:
In at least one embodiment, if, based on the baseline comparison analyses, the identified $1500 cash-in transaction is determined to exceed standard deviation criteria associated the one or more of the baseline “normal” transaction criteria (which it has, as indicated by the results of (i) and (ii) above), then the identified $1500 cash-in transaction may be flagged for in-depth suspicious fraudulent activity analysis. In other embodiments, the identified $1500 cash-in transaction may be flagged for in-depth suspicious fraudulent activity analysis only if it is determined to exceed standard deviation criteria associated the all (or some specified combination such as, for example, at least two) of the baseline “normal” transaction criteria.
According to different embodiments, the techniques for analyzing selected financial transaction information and determining the various baseline “normal” transaction and standard deviation criteria (e.g., such as those described above with respect to single or individual gaming devices) may similarly be applied to one or more sets or groups of gaming devices. For example, in some embodiments, a statistical average analysis may be performed for cash-in transactions occurring at one or more identified group(s) of gaming devices over a specified time period. Similarly, in some embodiments, a statistical average analysis may be performed for cash-out transactions occurring at one or more identified group(s) of gaming devices over a specified time period.
In some embodiments, various types of pattern recognition techniques may be utilized or employed for identifying suspicious financial transactions which may correspond to one or more different types of fraudulent activities. Non-limiting examples of pattern recognition techniques may include, but are not limited to, one or more of the following (or combinations thereof):
In some casino gaming environments, such as, for example, those allowing the user of mobile gaming devices, certain types of pattern recognition analysis may be more difficult to perform. For example, pattern recognition by location for mobile gaming devices may be difficult to implement due to the mobility of the device, particularly in casinos where the casino's system is only capable of detecting that the mobile game device is somewhere within a legal gaming location, but is not capable of determining the real-time location of a given mobile gaming device. In such situations, it may be preferable to rely more on the more effective pattern recognition techniques (e.g., pattern recognition by time, pattern recognition by player behavior, and/or pattern recognition by transaction types) and rely less on the less effective pattern recognition techniques.
Additionally, the degree of severity of an identified suspicious activity may also be assessed (e.g., in real-time) in order to determine, for example: (i) which type(s) of response action(s) should be performed (e.g., in response to detection of the identified suspicious activity), and/or (ii) the appropriate timeframe for initiating or implementing each response action to be performed.
By way of illustration, non-exhaustive examples of different types of response actions which may be automatically and dynamically initiated or implemented in response to detection of the identified suspicious activity may include, but are not limited to, one or more of the following (or combinations thereof):
By way of illustration, non-exhaustive examples of different types of criteria may be considered when determining the degree of priority or urgency to be assigned to a given response action may include, but are not limited to, one or more of the following (or combinations thereof):
Some events may be assigned relatively higher priorities than other events. Assignment of relative priorities may depend upon the particular facts and/or conditions associated with each event. Additionally, in some embodiments, the degree of urgency or priority of dispatching alert(s) communications and/or notification(s) for a given event may be determined, at least partially, as a function of the priority associated with that event. For example, detection of a $9000 cash-in event at a specific gaming device, followed by an $8990 cash-out event at the same gaming device within 1 minute may be assigned a high priority, or may be assigned a relatively higher priority than detection of a $9000 cash-in event at the gaming device, followed by an $8990 cash-out event at the same gaming device 2 hours later. In the former situation, it may be determined that there is a relatively high degree of urgency to immediately send out an alert to casino security and the casino floor supervisor, alerting them of the detected fraudulent activity. In the latter situation, it may be determined that there is a relatively lower degree of priority (or no need) for sending out alert(s) communications relating to the detected event. In another example, a cash-out after a Jackpot win of $10,000 is may not be assigned as a high priority event for suspicious fraudulent activity. However, in at least one embodiment, the detection of such an event will trigger a flag for automatic reporting purposes for causing the detected event to be logged and reported to the appropriate agencies for tax reporting purposes.
Referring first to
According to different embodiments, a Gaming Network 100 may include a plurality of different types of components, devices, modules, processes, systems, etc., which, for example, may be implemented and/or instantiated via the use of hardware and/or combinations of hardware and software. For example, as illustrated in the example embodiment of
According to specific embodiments, at least some of the computing clouds may include several different types of local area networks such as, for example, a backbone LAN which may be utilized for providing localized communication between various local network elements within a given computing cloud, and an internet LAN which, for example, may be utilized for providing WAN or Internet access to various local network elements within the computing cloud. In at least one embodiment, one or more of the computing clouds may be operable to host a variety of different types of applications and/or other software for performing various types of services such as, for example, one or more of those described herein. Additionally, in at least one embodiment, one or more of the computing clouds may be operable to provide various types of database services such as, for example, data storage, database queries, data access, etc. As illustrated in the example embodiment of
As illustrated in the example embodiment of
According to different embodiments, the Casino Server System(s) 140 may include various systems, components, and/or devices for facilitating, initiating, and/or performing various operation(s), action(s), feature(s), and/or other functionality, such as, for example, one or more of the following (or combinations thereof):
According to different embodiments, Electronic Game Device(s) (EGDs) may include one or more of the following (or combinations thereof): mechanical slot machines, electronic slot machines, electronic gaming machines, mobile gaming devices, video gaming machines, server-based gaming machines, and/or other types of devices or components which provide capabilities for enabling casino patrons to participate in gaming and/or wagering activities. In some embodiments, at least some mobile gaming devices may be implemented using personal mobile computing devices such as tablets, smartphones, laptops, PC's, and the like. As illustrated in the example embodiment of
According to different embodiments, Gaming Tables(s) may include one or more of the following (or combinations thereof): traditional casino gaming tables (e.g., craps, baccarat at, blackjack, roulette, etc.), electronic gaming tables, server-based gaming tables, and/or other types of devices or components which provide capabilities for enabling two or more casino patrons to concurrently participate in gaming and/or wagering activities. As illustrated in the example embodiment of
In at least one embodiment data collection and reporting components (e.g., 113, 123, 153, 183) may include functionality for facilitating, aggregating, enabling, initiating, and/or performing collection and reporting of various types of information relating to conditions and/or events occurring at an associated gaming device and/or gaming table game, such as, for example: game-related information, player tracking information, wager-related information (e.g., including financial transaction events), and the like.
In at least one embodiment, Local Administration System 130 may include various types of devices or components (such as, for example, mobile devices 132, tablets 134, computer systems 136, etc.) which provide capabilities for enabling casino administrators to implement or perform administration of one or more aspects, components, systems, operations, and/or activities relating to a casino gaming network (e.g., 101). Additionally, local administrative access can be provided for the casino manager for configuring, registering, monitoring, analyzing, sending alerts, generating reports, etc., relating to fraudulent and suspicious activities.
According to different embodiments, Remote Devices 170 may include various types of devices or components (such as, for example, smart phones 172, tablets 174, computer systems 176, etc.) which provide capabilities for enabling a remote user to remotely participate in gaming and/or wagering activities at a casino gaming network (e.g., 101). In at least one embodiment, one or more remote device components may also be used by remote casino administrators to implement or perform remote administration of one or more aspects, components, systems, operations, and/or activities relating to a casino gaming network (e.g., 101).
In at least one embodiment, the Gaming Network may be operable to utilize and/or generate various different types of data and/or other types of information when performing specific tasks and/or operations. This may include, for example, input data/information and/or output data/information. For example, in at least one embodiment, the Gaming Network may be operable to access, process, and/or otherwise utilize information from one or more different types of sources, such as, for example, one or more local and/or remote memories, devices and/or systems. Additionally, in at least one embodiment, the Gaming Network may be operable to generate one or more different types of output data/information, which, for example, may be stored in memory of one or more local and/or remote devices and/or systems. Examples of different types of input data/information and/or output data/information which may be accessed and/or utilized by the Gaming Network may include, but are not limited to, one or more of those described and/or referenced herein. According to specific embodiments, multiple instances or threads of the Gaming Network processes and/or procedures may be concurrently implemented and/or initiated via the use of one or more processors and/or other combinations of hardware and/or hardware and software.
According to different embodiments, various different types of encryption/decryption techniques may be used to facilitate secure communications between devices, systems, and/or components of the Gaming Network(s). Examples of the various types of security techniques which may be used may include, but are not limited to, one or more of the following (or combinations thereof): random number generators, SHA-1 (Secured Hashing Algorithm), MD2, MD5, DES (Digital Encryption Standard), 3DES (Triple DES), RC4 (Rivest Cipher), ARC4 (related to RC4), TKIP (Temporal Key Integrity Protocol, uses RC4), AES (Advanced Encryption Standard), RSA, DSA, DH, NTRU, and ECC (elliptic curve cryptography), PKA (Private Key Authentication), Device-Unique Secret Key and other cryptographic key data, SSL, etc. Other security features contemplated may include use of well-known hardware-based and/or software-based security components, and/or any other known or yet to be devised security and/or hardware and encryption/decryption processes implemented in hardware and/or software.
It will be appreciated that the Gaming Network 101 of
Generally, the automated gaming monetary instrument tracking techniques described herein may be implemented in hardware and/or hardware+software. Hardware and/or software+hardware hybrid embodiments of the automated gaming monetary instrument tracking techniques described herein may be implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. Such programmable machines may include, for example, mobile or handheld computing systems, PDA, smart phones, notebook computers, tablets, netbooks, desktop computing systems, server systems, cloud computing systems, network devices, etc.
According to different embodiments, the Gaming Network 900 may include a plurality of different types of components, devices, modules, processes, systems, etc., which, for example, may be implemented and/or instantiated via the use of hardware and/or combinations of hardware and software. For example, as illustrated in the example embodiment of
The functionality of the various systems and components of
Accounting/transaction server 220 may compile, track, store, and/or monitor cash flows, voucher transactions, winning vouchers, losing vouchers, and/or other transaction data for the casino operator and for the players. Transaction data may include the number of wagers, the size of these wagers, the date and time for these wagers, the identity of the players making these wagers, and the frequency of the wagers. Accounting/transaction server 220 may generate tax information relating to these wagers. Accounting/transaction server 220 may generate profit/loss reports for predetermined gaming options, contingent gaming options, predetermined betting structures, and/or outcome categories.
Voucher and Chip Tracking Components 245, which, for example, may be configured or designed to include functionality for generating, storing, updating, tracking, and analyzing data with respect to the issuance and redemption of printed tickets, casino chips, and other voucher items having cash or credit values. These can include printers and readers for printed tickets or other gaming monetary instruments or vouchers, as well as components, systems, and databases to record and analyze collected data.
Gaming server 225 may generate gaming options based on predetermined betting structures and/or outcome categories. These gaming options may be predetermined gaming options, contingent gaming options, and/or any other gaming option disclosed in this disclosure. Authentication server 230 may determine the validity of vouchers, players' identity, and/or an outcome for a gaming event. Player tracking server 235 may track a player's betting activity, a player's preferences (e.g., language, drinks, font, sound level, etc.). Based on data obtained by player tracking server 235, a player may be eligible for gaming rewards (e.g. free play), promotions, and/or other awards (e.g., complimentary food, drinks, lodging, concerts, etc.).
Voucher server 240 may generate a voucher, which may include data relating to a printed ticket or other cash or credit value instrument. Various specific items and details for such data that can be generated, stored, and tracked are provided below. If there is a time deadline, that information may be generated by voucher server 240. Vouchers may be physical (e.g., paper) or digital.
AML Server 236 may be configured or designed to include functionality for facilitating, enabling, initiating, and/or performing various AML analysis, detection, and/or reporting activities, operation(s), action(s), and/or feature(s) such as one or more of those described herein.
Searching server 242 may implement a search on one or more gaming devices to obtain gaming data. Searching server 242 may implement a messaging function, which may transmit a message to a third party (e.g., a player) relating to a search, a search status update, a game status update, a wager status update, a confirmation of a wager, a confirmation of a money transfer, and/or any other data relating to the player's account. The message can take the form of a text display on the gaming device, a pop up window, a text message, an email, a voice message, a video message and the like. Searching server 242 may implement a wagering function, which may be an automatic wagering mechanism. These functions of searching server 242 may be integrated into one or more servers.
Searching server 242 may include one or more searching structures, one or more searching algorithms, and/or any other searching mechanisms. In general, the search structures may cover which table games paid out the most money during a time period, which table games kept the most money from players during a time period, which table games are most popular (top games), which table games are least popular, which table games have the most amount of money wager during a period, which table games have the highest wager volume, which table games are more volatile (volatility, or deviation from the statistical norms, of wager volume, wager amount, pay out, etc.) during a time period, and the like. Search may also be associated with location queries, time queries, and/or people queries (e.g., where are the table games that most of my friends wager on, where are my favorite dealers, what do players wager on the most today, when are most wagers placed, etc.).
Display 310 may show previous game results, a betting structure, outstanding wagers, transaction volume, present value of betting options, a table minimum wager, a table maximum wager, wager and/or game play instructions input by one or more remote players (e.g., via their respective EGDs), instructions to the live dealer/attendant relating to game play activities to be performed by the dealer/attendant, video data, and/or any other type of data or content. Printer 315 may generate vouchers, promotional items, food tickets, event tickets, and/or lodging tickets. Vouchers may be physical (e.g., paper) or digital. Electronic shuffler 322 may be configured or designed to automatically shuffle multiple decks of cards, and to track the relative order of each of the cards of the shuffled decks of cards. The electronic shuffler can include an off the shelf unit. A dealer can use the electronic shuffler to shuffle the decks of cards before dealing the required hands, and place the shuffled decks of cards into the electronic shoe 320. In this way, the electronic gaming table may determine the relative order of all cards in the card shoe at the start of one or more game session(s), and/or at all other times of game play.
Electronic shoe 320 may obtain data and/or images of gaming objects utilized with gaming table 260. This data and/or images may be transmitted to electronic gaming device and displayed as images from table games. For example, on a blackjack table a ten of spades may be dealt to a player. This information is obtained via electronic shoe 320 and utilized to generate an image and/or illustration of a ten of spades card on an electronic gaming device. In another example, electronic shoe 320 may receive data relating to the numbers on dice, transmit this data to electronic gaming device, which may be utilized to generate an image/illustration of the dice on electronic gaming device.
In at least one embodiment, the electronic shoe can include an electronic reading system, such as an optical reader for recognizing the face value of each card. The electronic shoe can be designed to communicate directly with the card dealing/shuffling system to read or otherwise obtain the value of each card being dealt by the dealer as the card leaves the card dealing/shuffling system. For example, an optical reader or similar device can be attached to the card dealing/shuffling system, and the electronic shoe can obtain the scanned value of cards in the card dealing/shuffling system. In some implementations, the electronic shoe can interface with the table to read the value of each card being dealt by the dealer. For example, the table can include one or more scanning interfaces to scan each card before or after the card is dealt by the dealer. The electronic shoe can communicate with the one or more scanning interfaces to obtain the value of each card before or after the card is dealt by the dealer.
Card reader 325 may provide identification, authentication, and application processing functions. Card reader 325 may interface with smart cards, magnetic striped card, bar code reader, RFID card, and the like. Jackpot controller 330 may track and compile data associated with a jackpot. Jackpot controller 330 may award the jackpot on a specific occurrence (e.g., blackjack event, dealing a royal flush, etc.) and/or randomly award a jackpot. Chips reader 335 may compile and track data associated with the amount of chips one or more players possesses, the amount of chips won/lost at gaming table 260, the amount of chips in the dealer's rack at gaming table 260, an amount of chips wager by one or more players, amount of chips in the betting pool, and/or any combination thereof.
Camera 340 may obtain data from gaming table 260. Camera 340 may be one or more cameras located to view the gaming objects (e.g., cards, dice, dominos, ball, wheel, etc.), the dealer, the shoe, the players' hands, the players, and/or any combination thereof. Camera 340 may transmit this data to gaming table, which may be utilized to generate an image/illustration of the gaming objects. Speakers 342 may be used to provide audio information to the game table dealer/attendant. Examples of different types of audio information may include, for example, audio instructions and/or other audio/verbal communications from one or more remote players, computer-generated audio instructions/content, sound effects, and/or other types of audio content. Microphone 343 may be used to capture, record, and/or stream audio information from the electronic gaming table region, which, for example, may include verbal communications from the table game dealer/attendant.
Game And Wager Data Collection Component(s) 344 may include functionality for facilitating, enabling, initiating, and/or performing collection and reporting of various types of information relating to conditions and/or events occurring at an associated gaming device and/or gaming table game, such as, for example: game-related information, player tracking information, wager-related information (e.g., including financial transaction events), and/or other types of data/information described and/or referenced herein.
Voucher and Chip Tracking Components 345, and Voucher and Chip Reading Components 346, both of which, for example, may be configured or designed to include functionality for generating, storing, updating, tracking, and analyzing data with respect to the issuance and redemption of printed tickets, casino chips, and other voucher items having cash or credit values.
According to specific embodiments, a variety of different game states may be used to characterize the state of current and/or past events which are occurring (or have occurred) at a given live gaming table. For example, in one embodiment, at any given time in a game, a valid current game state may be used to characterize the state of game play (and/or other related events, such as, for example, mode of operation of the gaming table, etc.) at that particular time. In at least one embodiment, multiple different states may be used to characterize different states or events which occur at the gaming table at any given time. In one embodiment, when faced with ambiguity of game state, a single state embodiment forces a decision such that one valid current game state is chosen. In a multiple state embodiment, multiple possible game states may exist simultaneously at any given time in a game, and at the end of the game or at any point in the middle of the game, the gaming table may analyze the different game states and select one of them based on certain criteria. Thus, for example, when faced with ambiguity of game state, the multiple state embodiment(s) allow all potential game states to exist and move forward, thus deferring the decision of choosing one game state to a later point in the game. The multiple game state embodiment(s) may also be more effective in handling ambiguous data or game state scenarios.
According to specific embodiments, a variety of different entities may be used (e.g., either singly or in combination) to track the progress of game states which occur at a given gaming table. Examples of such entities may include, but are not limited to, one or more of the following (or combination thereof): master controller system, display system, gaming system, local game tracking component(s), remote game tracking component(s), etc. Examples of various game tracking components may include, but are not limited to: automated sensors, manually operated sensors, video cameras, intelligent playing card shoes, RFID readers/writers, RFID tagged chips, objects displaying machine readable code/patterns, etc.
According to a specific embodiment, local game tracking components at the gaming table may be operable to automatically monitor game play activities at the gaming table, and/or to automatically identify key events which may trigger a transition of game state from one state to another as a game progresses. For example, in the case of Blackjack, a key event may include one or more events which indicate a change in the state of a game such as, for example: a new card being added to a card hand, the split of a card hand, a card hand being moved, a new card provided from a shoe, removal or disappearance of a card by occlusion, etc.
Input devices 428 may be mechanical buttons, electronic buttons, a touchscreen, a microphone, cameras, an optical scanner, or any combination thereof. Input devices 428 may be utilized to make a wager, to make an offer to buy or sell a voucher, to determine a voucher's worth, to cash in a voucher, to modify (e.g., change sound level, configuration, font, language, etc.) electronic gaming device 400, to select a movie or music, to select live video streams (e.g., table 1, table 2, table 3), to request services (e.g., drinks, manager, etc.), or any combination thereof.
Display 426 may show video streams from one or more gaming tables 260, gaming objects from one or more gaming tables 260, computer generated graphics, predetermined gaming options 106, and/or contingent gaming options 108.
Memory 404 may include various memory modules 440. Memory 404 via various memory modules 440 may include a confirmation module 412, a validation module 414, a voucher module 416, a reporting module 418, a maintenance module 420, a player tracking preferences module 424, and an account module 432.
Confirmation module 412 may utilize data received from a voucher, the transaction history of the voucher (e.g., the voucher changed hands in a secondary market), and/or the identity of the player to confirm the value of the voucher. In another example, confirmation module 412 may utilize game event data, along with voucher data to confirm the value of the voucher.
Validation module 414 may utilize data received from a voucher to confirm the validity of the voucher.
Voucher module 416 may store data relating to generated vouchers, redeemed vouchers, bought vouchers, and/or sold vouchers.
Game And Wager Data Collection Component(s) 434 may include functionality for facilitating, enabling, initiating, and/or performing collection and reporting of various types of information relating to conditions and/or events occurring at an associated gaming device and/or gaming table game, such as, for example: game-related information, player tracking information, wager-related information (e.g., including financial transaction events), and/or other types of data/information described and/or referenced herein.
Voucher and Chip Tracking Components 445, and Voucher and Chip Reading Components 446, both of which, for example, may be configured or designed to include functionality for generating, storing, updating, tracking, and analyzing data with respect to the issuance and redemption of printed tickets, casino chips, and other voucher items having cash or credit values.
Sensor(s)/Camera(s) 450 may be configured or designed to detect and capture external data, events, and/or conditions including, for example, biometric information (e.g., facial images, facial features, fingerprints, voice recordings, etc.) relating to the player(s) or user(s) interacting with the gaming device. In some embodiments, the camera and/or other sensor(s) of the electronic gaming device may be remotely controlled and actuated. For example, in one embodiment, if it is determined that suspicious fraudulent activities may be occurring at a given electronic gaming device, the camera of the electronic gaming device may be caused to be remotely actuated in order to capture a facial image of the person(s) who is/are interacting with the electronic gaming device.
Reporting module 418 may generate reports related to a performance of electronic gaming device 400, electronic gaming system 200, table game 260, video streams, gaming objects, credit device 112, and/or identification device 114.
In one implementation, reporting module 418 may reside on a central server and can aggregate and generate real time statistics on betting activities at one or more table games at one or more participating casinos. The aggregate betting statistics may include trends (e.g., aggregate daily wager volume and wager amount by game types, by casinos, and the like), top games with the most payouts, top tables with the most payouts, top search structures used by players, most popular dealers by wager volume, most searched for game, tables with least payouts, weekly trends, monthly trends, and other statistics related to game plays, wagers, people, location, and searches.
The information and statistics generated by the server-based reporting module 418 can be displayed publicly or privately. For example, popular trending and statistical information on wager volume and wager amount for the top ten table games can be publicly displayed in a casino display system so that players can study and decide what game to play, where, when, etc. Such a public display of general statistics can also be posted on the Internet, sent out as a text, an email, or multimedia message to the player's smart phones, tablets, desktop computer, etc. In another example, the trending and statistical information can also be distributed privately to privileged players such as casino club members.
Maintenance module 420 may track any maintenance that is implemented on electronic gaming device 400 and/or electronic gaming system 200. Maintenance module 420 may schedule preventative maintenance and/or request a service call based on a device error. Player tracking preferences module 424 may compile and track data associated with a players preferences.
Account module 432 may include data relating to an account balance, a wager limit, a number of wagers placed, credit limits, any other player information, and/or any other account information.
Data from account module 432 may be utilized to determine whether a wager may be accepted. For example, when a search has determined a triggering event, the device and/or system may determine whether to allow this wager based on one or more of a wager amount, a number of wagers, a wager limit, an account balance, and/or any other criteria.
For example, the system and/or device determines via searching function that a triggering event has occurred. Based on this triggering event, the player would like to make a $400 wager, however, the player's account balance is only $50. In this case, the system and/or device may not accept the wager, modify the wager to the account balance (e.g., $50), send a notice to the player, modify the wager to some percentage (e.g., 10%, 25%, 50%, 75%, etc.) of the account balance (e.g., $5, $12.50, $25, $37.5, etc.), send a notice to the gaming entity, make a flat wager (e.g., $10), and/or any combination thereof.
In another example, the system and/or device determines via searching function that a triggering event has occurred. Based on this triggering event, the player would like to make a $400 wager and the player's account balance is $150. However, the system and/or device may not accept the wager because one betting parameter may be that no one wager may be more than a certain percentage (e.g., fifty percent) of a player's account balance. In this case, the system and/or device may not accept the wager, modify the wager to the predetermined limit (e.g., $75), send a notice to the player, modify the wager to some other percentage (e.g., 5%, 10%, 25%, 40%, etc.) of the account balance, send a notice to the gaming entity, make a flat wager (e.g., $10), and/or any combination thereof.
In another example, the gaming jurisdiction, the casino, the system and/or device may not allow an individual to place a wager over a specific value (e.g., $25, $400, $1,000, $10,000, $400,000, $1,000,000, etc.).
In another example, the system and/or device may not allow an individual to lose more than a specific amount of money in a predetermined timeframe. An individual may only be allowed to lose $200 (or any other number) over a two hour period (or any other time period).
In another example, based on this triggering event, the player would like to make a $400 wager and the player has a $200 balance. However, the player has made a predetermined number of wagers within a predetermined time frame. For example, the system and/or device may not allow an individual to make more than 5 wagers a day, 25 wagers a week, 1,000 wagers a year, etc. Any of these betting parameters may be combined by the system and/or device.
In at least one embodiment, at least a portion of the modules discussed in block diagram 400 may reside locally in gaming terminal 400. However, In at least some embodiments, the functions performed by these modules may be implemented in one or more remote servers. For instance, modules 412-420 and 424 may each be on a remote server, communicating with gaming terminal 400 via a network interface such as Ethernet in a local or a wide area network topology. In some implementations, these servers may be physical servers in a data center. In some other implementations, these servers may be virtualized. In yet some other implementations, the functions performed by these modules may be implemented as web services. Regardless of how the modules and their respective functions are implemented, the interoperability with the gaming terminal 400 is seamless.
In one implementation, reporting module 418 may reside on a central server and can aggregate and generate real time statistics on betting activities at one or more table games at one or more participating casino's. The aggregate betting statistics may include trends (e.g., aggregate daily wager volume and wager amount by game types, by casinos, and the like), top games with the most payouts, top tables with the most payouts, top search structures used by players, most popular dealers by wager volume, most searched for game, tables with least payouts, weekly trends, monthly trends, and other statistics related to game plays, wagers, people, location, and searches.
The information and statistics generated by the server-based reporting module 418 can be displayed publicly or privately. For example, popular trending and statistical information on wager volume and wager amount for the top ten table games can be publicly displayed in a casino display system so that players can study and decide what game to play, where, when, etc. Such a public display of general statistics can also be posted on the Internet, sent out as a text, an email, or multimedia message to the player's smart phones, tablets, desktop computer, etc. In another example, the trending and statistical information can also be distributed privately to privileged players such as casino club members.
One or more cameras (e.g., 562) may be used to monitor, stream and/or record image content and/or video content relating to persons or objects within each camera's view. For example, in at least one embodiment where the gaming system is implemented as an EGD, camera 562 may be used to generate a live, real-time video feed of a player (or other person) who is currently interacting with the EGD. In some embodiments, camera 562 may be used to verify a user's identity (e.g., by authenticating detected facial features), and/or may be used to monitor or tract facial expressions and/or eye movements of a user or player who is interacting with the gaming system.
In at least one embodiment, display system 590 may include one or more of the following (or combinations thereof):
According to various embodiments, display device(s) 595 may include one or more display screens utilizing various types of display technologies such as, for example, one or more of the following (or combinations thereof): LCDs (Liquid Crystal Display), Plasma, OLEDs (Organic Light Emitting Display), TOLED (Transparent Organic Light Emitting Display), Flexible (F)OLEDs, Active matrix (AM) OLED, Passive matrix (PM) OLED, Phosphorescent (PH) OLEDs, SEDs (surface-conduction electron-emitter display), EPD (ElectroPhoretic display), FEDs (Field Emission Displays) and/or other suitable display technology. EPD displays may be provided by E-ink of Cambridge, MA. OLED displays of the type list above may be provided by Universal Display Corporation, Ewing, N.J.
In at least one embodiment, master gaming controller 512 may include one or more of the following (or combinations thereof):
In at least one embodiment, Peripheral Devices 550 may include one or more of the following (or combinations thereof):
In one implementation, processor 510 and master gaming controller 512 are included in a logic device 513 enclosed in a logic device housing. The processor 510 may include any conventional processor or logic device configured to execute software allowing various configuration and reconfiguration tasks such as, for example: a) communicating with a remote source via communication interface 506, such as a server that stores authentication information or games; b) converting signals read by an interface to a format corresponding to that used by software or memory in the gaming system; c) accessing memory to configure or reconfigure game parameters in the memory according to indicia read from the device; d) communicating with interfaces, various peripheral devices and/or I/O devices; e) operating peripheral devices such as, for example, card readers, paper ticket readers, etc.; f) operating various I/O devices such as, for example, displays 535, input devices 530; etc. For instance, the processor 510 may send messages including game play information to the displays 535 to inform players of cards dealt, wagering information, and/or other desired information.
In at least one implementation, the gaming system may include card readers such as used with credit cards, or other identification code reading devices to allow or require player identification in connection with play of the card game and associated recording of game action. Such a player identification interface can be implemented in the form of a variety of magnetic card readers commercially available for reading a player-specific identification information. The player-specific information can be provided on specially constructed magnetic cards issued by a casino, or magnetically coded credit cards or debit cards frequently used with national credit organizations such as VISA, MASTERCARD, AMERICAN EXPRESS, or banks and other institutions.
The gaming system may include other types of participant identification mechanisms which may use a fingerprint image, eye blood vessel image reader, or other suitable biological information to confirm identity of the player. Still further it is possible to provide such participant identification information by having the dealer manually code in the information in response to the player indicating his or her code name or real name. Such additional identification could also be used to confirm credit use of a smart card, transponder, and/or player's personal player input device (UID).
The gaming system 500 also includes memory 516 which may include, for example, volatile memory (e.g., RAM 509), non-volatile memory 519 (e.g., disk memory, FLASH memory, EPROMs, etc.), unalterable memory (e.g., EPROMs 508), etc. The memory may be configured or designed to store, for example: 1) configuration software 514 such as all the parameters and settings for a game playable on the gaming system; 2) associations 518 between configuration indicia read from a device with one or more parameters and settings; 3) communication protocols allowing the processor 510 to communicate with peripheral devices and I/O devices 511; 5) a secondary memory storage device 515 such as a non-volatile memory device, configured to store gaming software related information (the gaming software related information and memory may be used to store various audio files and games not currently being used and invoked in a configuration or reconfiguration); 5) communication transport protocols (such as, for example, TCP/IP, USB, Firewire, IEEE1394, Bluetooth, IEEE 802.11x (IEEE 802.11 standards), hiperlan/2, HomeRF, etc.) for allowing the gaming system to communicate with local and non-local devices using such protocols; etc. In one implementation, the master gaming controller 512 communicates using a serial communication protocol. A few examples of serial communication protocols that may be used to communicate with the master gaming controller include but are not limited to USB, RS-232 and Netplex (a proprietary protocol developed by IGT, Reno, Nev.).
A plurality of device drivers 542 may be stored in memory 516. Example of different types of device drivers may include device drivers for gaming system components, device drivers for gaming system components, etc. Typically, the device drivers 542 utilize a communication protocol of some type that enables communication with a particular physical device. The device driver abstracts the hardware implementation of a device. For example, a device drive may be written for each type of card reader that may be potentially connected to the gaming system. Examples of communication protocols used to implement the device drivers include Netplex , USB, Serial, Ethernet 575, Firewire, 110 debouncer, direct memory map, serial, PCI, parallel, RF, Bluetooth™, near-field communications (e.g., using near-field magnetics), 802.11 (WiFi), etc. Netplex is a proprietary IGT standard while the others are open standards. According to a specific embodiment, when one type of a particular device is exchanged for another type of the particular device, a new device driver may be loaded from the memory 516 by the processor 510 to allow communication with the device. For instance, one type of card reader in gaming system 500 may be replaced with a second type of card reader where device drivers for both card readers are stored in the memory 516.
In some embodiments, the software units stored in the memory 516 may be upgraded as needed. For instance, when the memory 516 is a hard drive, new games, game options, various new parameters, new settings for existing parameters, new settings for new parameters, device drivers, and new communication protocols may be uploaded to the memory from the master gaming controller 512 or from some other external device. As another example, when the memory 516 includes a CD/DVD drive including a CD/DVD designed or configured to store game options, parameters, and settings, the software stored in the memory may be upgraded by replacing a first CD/DVD with a second CD/DVD. In yet another example, when the memory 516 uses one or more flash memory 519 or EPROM 508 units designed or configured to store games, game options, parameters, settings, the software stored in the flash and/or EPROM memory units may be upgraded by replacing one or more memory units with new memory units which include the upgraded software. In another embodiment, one or more of the memory devices, such as the hard-drive, may be employed in a game software download process from a remote software server.
In some embodiments, the gaming system 500 may also include various authentication and/or validation components 544 which may be used for authenticating/validating specified gaming system components such as, for example, hardware components, software components, firmware components, information stored in the gaming system memory 516, etc. Examples of various authentication and/or validation components are described in U.S. Pat. No. 6,620,047, entitled, “ELECTRONIC GAMING APPARATUS HAVING AUTHENTICATION DATA SETS,” incorporated herein by reference in its entirety for all purposes.
Sensors 560 may include, for example, optical sensors, pressure sensors, RF sensors, Infrared sensors, motion sensors, audio sensors, image sensors, thermal sensors, biometric sensors, etc. As mentioned previously, such sensors may be used for a variety of functions such as, for example: detecting the presence and/or monetary amount of gaming chips which have been placed within a player's wagering zone; detecting (e.g., in real time) the presence and/or monetary amount of gaming chips which are within the player's personal space; etc.
In one implementation, at least a portion of the sensors 560 and/or input devices 530 may be implemented in the form of touch keys selected from a wide variety of commercially available touch keys used to provide electrical control signals. Alternatively, some of the touch keys may be implemented in another form which are touch sensors such as those provided by a touchscreen display. For example, in at least one implementation, the gaming system player may include input functionality for enabling players to provide their game play decisions/instructions (and/or other input) to the dealer using the touch keys and/or other player control sensors/buttons. Additionally, such input functionality may also be used for allowing players to provide input to other devices in the casino gaming network (such as, for example, player tracking systems, side wagering systems, etc.)
Wireless communication components 556 may include one or more communication interfaces having different architectures and utilizing a variety of protocols such as, for example, 802.11 (WiFi), 802.15 (including Bluetooth™), 802.16 (WiMax), 802.22, Cellular standards such as CDMA, CDMA2000, WCDMA, Radio Frequency (e.g., RFID), Infrared, Near Field Magnetic communication protocols, etc. The communication links may transmit electrical, electromagnetic or optical signals which carry digital data streams or analog signals representing various types of information.
An example of a near-field communication protocol is the ECMA-340 “Near Field Communication—Interface and Protocol (NFCIP-1)”, published by ECMA International (www.ecma-international.org), herein incorporated by reference in its entirety for all purposes. It will be appreciated that other types of Near Field Communication protocols may be used including, for example, near field magnetic communication protocols, near field RF communication protocols, and/or other wireless protocols which provide the ability to control with relative precision (e.g., on the order of centimeters, inches, feet, meters, etc.) the allowable radius of communication between at least 5 devices using such wireless communication protocols.
Power distribution components 558 may include, for example, components or devices which are operable for providing wireless power to other devices. For example, in one implementation, the power distribution components 558 may include a magnetic induction system which is adapted to provide wireless power to one or more portable UIDs at the gaming system. In one implementation, a UID docking region may include a power distribution component which is able to recharge a UID placed within the UID docking region without requiring metal-to-metal contact.
In at least one embodiment, motion/gesture detection component(s) 551 may be configured or designed to detect player (e.g., player, dealer, and/or other persons) movements and/or gestures and/or other input data from the player. In some embodiments, each gaming system may have its own respective motion/gesture detection component(s). In other embodiments, motion/gesture detection component(s) 551 may be implemented as a separate sub-system of the gaming system which is not associated with any one specific gaming system or device.
Game And Wager Data Collection Component(s) 576 may include functionality for facilitating, enabling, initiating, and/or performing collection and reporting of various types of information relating to conditions and/or events occurring at an associated gaming device and/or gaming table game, such as, for example: game-related information, player tracking information, wager-related information (e.g., including financial transaction events), and/or other types of data/information described and/or referenced herein.
As illustrated in the example of
In at least one embodiment, the mobile gaming device may include further Mobile Device App Component(s) which have been configured or designed to provide functionality for enabling or implementing at least a portion of the various automated issuance and tracking of gaming monetary instruments and related techniques at the mobile gaming device. These further components can include, for example:
According to specific embodiments, various aspects, features, and/or functionalities of the mobile gaming device may be performed, implemented and/or initiated by one or more of the following types of systems, components, systems, devices, procedures, processes, etc. (or combinations thereof):
In according to one embodiment, network device 760 may include a master central processing unit (CPU) 762, interfaces 768, and a bus 767 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 762 may be responsible for implementing specific functions associated with the functions of a desired network device. For example, when configured as a server, the CPU 762 may be responsible for analyzing packets; encapsulating packets; forwarding packets to appropriate network devices; instantiating various types of virtual machines, virtual interfaces, virtual storage volumes, virtual appliances; etc. The CPU 762 preferably accomplishes at least a portion of these functions under the control of software including an operating system (e.g. Linux), and any appropriate system software (such as, for example, AppLogic™ software).
CPU 762 may include one or more processors 763 such as, for example, one or more processors from the AMD, Motorola, Intel and/or MIPS families of microprocessors. In an alternative embodiment, processor 763 may be specially designed hardware for controlling the operations of server system 780. In a specific embodiment, a memory 761 (such as non-volatile RAM and/or ROM) also forms part of CPU 762. However, there may be many different ways in which memory could be coupled to the system. Memory block 761 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc.
The interfaces 768 may be typically provided as interface cards (sometimes referred to as “line cards”). Alternatively, one or more of the interfaces 768 may be provided as on-board interface controllers built into the system motherboard. Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the server system 780. Among the interfaces that may be provided may be FC interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, Infiniband interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, ASI interfaces, DHEI interfaces and the like. Other interfaces may include one or more wireless interfaces such as, for example, 802.11 (WiFi) interfaces, 802.15 interfaces (including Bluetooth™), 802.16 (WiMax) interfaces, 802.22 interfaces, Cellular standards such as CDMA interfaces, CDMA2000 interfaces, WCDMA interfaces, TDMA interfaces, Cellular 3G/4G/5G interfaces, etc.
Generally, one or more interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 762 to efficiently perform routing computations, network diagnostics, security functions, etc.
In at least one embodiment, some interfaces may be configured or designed to allow the server system 780 to communicate with other network devices associated with various local area network (LANs) and/or wide area networks (WANs). Other interfaces may be configured or designed to allow network device 760 to communicate with one or more direct attached storage device(s) 770.
Although the system shown in
Regardless of network device's configuration, it may employ one or more memories or memory modules (such as, for example, memory block 765, which, for example, may include random access memory (RAM)) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the various automated fraud and suspicious activity detection and reporting techniques described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store data structures, and/or other specific non-program information described herein.
Because such information and program instructions may be employed to implement the systems/methods described herein, one or more embodiments relates to machine readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable storage media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and hardware devices that may be specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). Some embodiments may also be embodied in transmission media such as, for example, a carrier wave travelling over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.
Various embodiments of automated fraudulent activity detection, analysis, and reporting techniques described herein are directed to different methods and systems for enabling automated, rule-based and/or pattern-based monitoring, detection, analysis, and reporting of suspicious activities relating to financial or monetary conducted in casino gaming establishments, casino networks, and/or non-casino environments. According to different embodiments, one or more Suspicious Activity Pattern Database(s) (e.g., 892) may be provided for storing and/or providing access to various types of information for use in conducting suspicious fraudulent activity pattern analysis, detection and/or reaction. For example, in some embodiments, at least a portion of the information stored in the Suspicious Activity Pattern Database(s) 892 may include rule-based and/or pattern-based criteria for use in facilitating identification of suspicious fraudulent activity during analysis of casino-related financial transactions.
Non-limiting examples of various suspicious fraudulent activity rule-based and/or pattern-based criteria may include, but are not limited to, one or more of the following (or combinations thereof):
According to different embodiments, it may be preferable or desirable for a casino to develop and implement an effective fraud and suspicious activity detection program. The casino's size, location, dollar volume, types of games, type/nature of customers, and internal controls are some of the factors to consider when analyzing the possible risk of money laundering occurring at the casino. Additionally, in at least some embodiments, an effective anti-money laundering program may be configured or designed to include automated notification and reporting mechanisms (such as, for example, E-Filing and Report Component(s) 854) which may include functionality for facilitating, enabling, initiating, and/or performing various types of reporting and notification activities such as, for example: automated electronic filing of detected suspicious fraudulent activities at appropriate governmental agencies; automated generation and/or transmission of notifications and alerts (e.g., such as those relating to detected suspicious fraudulent activities) to appropriate authorities (e.g., police, Federal agencies, local law enforcement, casino security personnel, casino employees, etc.); and/or other types of types of reporting and notification activities such as those described herein.
In at least one embodiment, the automated money laundering analysis, detection and reporting components of a Casino Gaming Network may be operable to: (i) automatically analyze data relating to financial transaction events and other activities occurring at the casino; (ii) automatically detect suspicious fraudulent activities and/or reportable financial transaction events; and (iii) automatically generate and electronically file appropriate electronic reports (e.g., relating to the detected suspicious fraudulent activities and/or reportable financial transaction events) at one or more specified entities or agencies.
For example, in one embodiment, the automated money laundering analysis, detection and reporting components of a Casino Gaming Network may automatically generate and electronically file one or more a Currency Transaction Report(s) (CTRs) for reporting each transaction in currency involving cash-in and cash-out of more than $10,000 in a gaming day.
In at least one embodiment, transactions in currency involving cash-in may include, but are not limited to one or more of the following (or combinations thereof):
In at least one embodiment, transactions in currency involving cash-out may include, but are not limited to one or more of the following (or combinations thereof):
In some embodiments, multiple currency transactions may be treated as a single transaction if, for example, the casino has knowledge that they are by, or on behalf of, any person and result in either cash in or cash-out totaling more than $10,000 during any gaming day. In some embodiments, cash-in and cash-out transactions may preferably be aggregated separately. In some embodiments, a CTR may preferably be electronically filed within 15 calendar days following the day the reportable transaction occurs. In some embodiments, Suspicious Activity Reports (SARs) be filed for any detected suspicious transaction(s) that may be relevant to the possible violation of any law or regulation, and which involves or aggregates at least $3,000 in funds or other assets.
According to different embodiments, Casino Gaming Networks may be configured or designed to retain copies of electronically filed CTR and SAR reports for a specified period of time, as may be legally required (e.g., five years from the date of the report). Additionally, in some embodiments, evidence relating to any detected suspicious fraudulent activity (e.g., such as financial transactions, player information, gaming information, wagering information, captured video or images, etc.) may also be retained for a specified period of time.
In at least one embodiment, the term “Casino Cage” may be interpreted to include a secure work area within a casino that houses cashiers and storage facilities for cash, chips, tokens, and credit documents. Cashiers at the cage conduct transactions with customers and other casino areas.
In at least one embodiment, the term “Front Money” may be interpreted to include money deposited by a customer into a personal casino account with a cage cashier. The customer can later withdraw the front money at gaming tables or at the cage in the form of chips, currency, casino check, or wire transfer.
In at least one embodiment, the term “Marker or Counter Check” may be interpreted to include credit extended to a customer in exchange for chips, tokens, or currency. The marker or counter check may be intended for use in gambling.
In at least one embodiment, the term “Multiple Transaction Log” may be interpreted to include casino and card club documents used to record and keep track of customer currency transaction activity above a given dollar threshold. Many casinos and card clubs maintain multiple transaction logs for pit and cage (including slot booth) transactions, sometimes pursuant to state, local, or tribal gaming laws, or within the ordinary course of business.
In at least one embodiment, the term “Player Club Points” may be interpreted to include casinos “club points,” which may be awarded to casino patrons based on how much customers bet and how often they play. Patrons can redeem these club points for goods and services at restaurants, retail shops, or hotels.
In at least one embodiment, the term “Player Rating Card” may be interpreted to include a card used in a casino pit to keep track of a player's activity at a single gaming table for purposes of determining if a player is entitled to receive complimentary services (“comps”). Each time a rated player begins gambling at a table, designated casino employees who monitor customer's play prepare a “player rating card,” also known as a “rating card” or “rating slip.”
In at least one embodiment, casinos may assign different “Player Ratings” to different patrons, which may be used for awarding complimentary services to attract and retain customers. A common player rating method is based on theoretical win—the amount a casino expects to win from a particular customer. It is calculated using a number of factors, including the length of time the gambler plays.
In at least one embodiment, the term “Pit” may be interpreted to include an area of a casino or card club floor that contains gaming tables. Each pit contains several gaming tables organized by game type. Each pit is under the supervision of a single floor supervisor (or “pit boss”). Customers can buy chips and conduct other transactions at the pit.
In at least one embodiment, the term “Sportsbook” may be interpreted to include a place where individuals can wager on various sports competitions, such as golf, football, basketball, baseball, boxing, and horse racing.
In at least one embodiment, the term “Surveillance” may be interpreted to include various types of surveillance components including, for example, video cameras, monitors, recorders, video printers, switches, selectors and other ancillary equipment to observe and record activities at the gaming establishment Casinos often identify individuals conducting unusual, suspicious or potentially criminal financial transactions through surveillance.
In at least one embodiment, the term “cash” may be interpreted to include coin and currency of the United States or any other country, and may include cashier's checks, gaming vouchers, bank drafts, traveler's checks, or money orders received over $10,000 in one transaction (or two or more related transactions) during a 12-month period.
According to different embodiments, at least a portion of the functions, operations, actions, and/or other features provided by the various procedures, steps, and/or operations described herein may be implemented at one or more client systems(s); at one or more server systems(s) such as, for example, casino server system(s) (e.g., 140,
In at least one embodiment, one or more of the various procedures, steps, and/or operations described herein may be operable to utilize and/or generate various different types of data and/or other types of information when performing specific tasks and/or operations. This may include, for example, input data/information and/or output data/information. For example, in at least one embodiment, the automated fraud detection analysis, detection and reporting procedures may be operable to access, process, and/or otherwise utilize information from one or more different types of sources, such as, for example, one or more local and/or remote memories, devices and/or systems. Additionally, in at least one embodiment, the automated fraud detection analysis, detection and reporting procedures may be operable to generate one or more different types of output data/information, which, for example, may be stored in memory of one or more local and/or remote devices and/or systems. Examples of different types of input data/information and/or output data/information which may be accessed and/or utilized by the automated fraud detection analysis, detection and reporting procedures may include, but are not limited to, one or more of those described and/or referenced herein.
In at least one embodiment, a given instance of one or more of the various procedures described herein may access and/or utilize information from one or more associated databases. In at least one embodiment, at least a portion of the database information may be accessed via communication with one or more local and/or remote memory devices. Examples of different types of data which may be accessed by the automated fraud detection analysis, detection and reporting procedures may include, but are not limited to, one or more of those described and/or referenced herein.
According to specific embodiments, multiple instances or threads of the Transaction Analysis and Suspicious Activity Screening and Notification Procedure and/or Suspicious Activity Analysis Procedure may be concurrently implemented and/or initiated via the use of one or more processors and/or other combinations of hardware and/or hardware and software. For example, in at least some embodiments, various aspects, features, and/or functionalities of the Suspicious Activity Screening and Notification Procedure and/or Suspicious Activity Analysis Procedure may be performed, implemented and/or initiated by one or more of the various systems, components, systems, devices, procedures, processes, etc., described and/or referenced herein.
According to different embodiments, one or more different threads or instances of the Suspicious Activity Screening and Notification Procedure and/or Suspicious Activity Analysis Procedure may be initiated in response to detection of one or more conditions or events satisfying one or more different types of minimum threshold criteria for triggering initiation of at least one instance of one or more of the procedures. Various examples of conditions or events which may trigger initiation and/or implementation of one or more different threads or instances of the various procedures may include, but are not limited to, one or more of those described and/or referenced herein.
According to different embodiments, one or more different threads or instances of the Suspicious Activity Screening and Notification Procedure and/or Suspicious Activity Analysis Procedure may be initiated and/or implemented manually, automatically, statically, dynamically, concurrently, and/or combinations thereof. Additionally, different instances and/or embodiments of the Suspicious Activity Screening and Notification Procedure and/or Suspicious Activity Analysis Procedure may be initiated at one or more different time intervals (e.g., during a specific time interval, at regular periodic intervals, at irregular periodic intervals, upon demand, etc.).
In at least one embodiment, initial configuration of a given instance of the Suspicious Activity Screening and Notification Procedure and/or Suspicious Activity Analysis Procedure may be performed using one or more different types of initialization parameters. In at least one embodiment, at least a portion of the initialization parameters may be accessed via communication with one or more local and/or remote memory devices. In at least one embodiment, at least a portion of the initialization parameters provided to an instance of a given procedure may correspond to and/or may be derived from the input data/information.
Different embodiments of the Transaction Analysis and Suspicious Activity Screening and Notification Procedure 1000 and/or Suspicious Activity Analysis Procedure 1100 may be configured or designed to provide various methods and techniques for enabling automated, rule-based monitoring, analysis, detection and reporting of suspicious activities relating to financial or monetary transactions conducted in casino gaming establishments, casino networks, and/or non-casino environments. One or more of these transactions may occur at various casino-related devices, machines, systems, and/or locations of casino environments and/or non-casino environments.
According to different embodiments, information relating to casino-related financial transactions may be captured (e.g., in real-time or non-real-time) at the device, table, or system where the financial transaction even has occurred, and uploaded (e.g., in real-time or non-real-time) to a server such as, for example, the Casino Server System 140 (
For example, at the casino gaming devices and/or game tables, casino patrons may place wagers or participate in various cash-in transaction(s) by depositing their money (e.g., via cash, printed ticket, voucher, wagering tokens, etc.), and/or by putting up credits (e.g., from pre-established credit accounts). Casino patrons may also participate in various cash-in transaction(s) at financial kiosks and cashier cages. Similarly, casino patrons may participate in various cash-out transaction(s) at different gaming devices, gaming tables, financial kiosks, cashier cages, etc. According to different embodiments, data and other information relating to each of these transactions may be automatically captured, uploaded to a casino server system, and analyzed for suspicious activities. Preferably, the capturing and uploading (or reporting) of the financial transaction information may be performed in real-time (or near real-time) so as to allow the casino to detect and respond to suspicious or fraudulent activities in a timely manner. Examples of various types of data and/or information which may be captured (and uploaded) for a given financial transaction event may include, but are not limited to, one or more of the following (or combinations thereof):
As illustrated in the example embodiment of
In at least one embodiment, the received financial transaction information may be analyzed (1008) by the casino server system (and/or cloud-based system(s)) for detection of possible fraudulent activities and/or other suspicious activities. Financial transactions which are flagged as potentially suspicious or even fraudulent activities may be logged, and additional analysis may be performed if one or more specific triggering criteria is satisfied. For example, in at least one embodiment, a multi-step analysis process may be utilized for suspicious fraudulent activity analysis, whereby all (or selected) financial transactions are each initially screened and analyzed (e.g., 1008, 1010) for one or more triggering events/conditions which, if satisfied, may necessitate additional (in-depth) suspicious fraudulent activity analysis (e.g., 1012) of the identified financial transaction (e.g., as shown in
Accordingly, as illustrated in the example embodiment of
For example, in one embodiment, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that total consecutive money cashed in (e.g., for a given player over a given time period such as, for example, 3 minutes) exceeds $3000 or some other specified threshold value. In some embodiments, a substantial cash in (e.g., at least $3000), follow by a minimum amount of gaming (e.g., at least 3 games of at least $20 wager each), followed by a cash out, can trigger a deeper analysis for suspicious fraudulent activity. In some embodiments, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that cumulative money cashed in for a given player over a given time period exceeds some specified threshold value. For example, frequent money-in into a gaming terminal, at 3-minute to 5-minute intervals, of $3000 or more each time, for a total of more than $10,000 in 15 minutes, may trigger a deeper analysis for suspicious fraudulent activity. In some embodiments, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that total consecutive money cashed out (e.g., for a given player over a given time period) such exceeds some specified threshold value. For example, frequent cash-out events at a gaming terminal, at 1-minute to 5-minute intervals, of $2000 or more each time, for a total of more than $9,000 over a 20-minute time window, may trigger a deeper analysis for suspicious fraudulent activity. In some embodiments, in-depth suspicious fraudulent activity analysis may be triggered in response to detecting that total money cashed out (for a given player over a given time period) exceeds some specified threshold value.
In yet other embodiments, the triggering of in-depth suspicious fraudulent activity analysis may be based, at least partially, on statistical information relating to one or more group(s) of gaming devices over a period of time, and/or may be based, at least partially, on statistical information relating to other types of financial transactions which occur over one or more specified time periods(s). For example, financial transactions for a given gaming device (or a specified group of gaming devices) may be averaged over a specified time period or time interval (e.g., 90 days) to establish a relative baseline of what a “normal” transaction is for that particular gaming device (or group of gaming devices). Any detected financial transactions (new and/or historical) associated with the identified gaming device (or associated with one or more gaming devices of the identified group of gaming device) may then be compared to the baseline “normal” transaction. If, based on the results of the comparison(s), it is determined that an identified transaction exceeds predefined threshold comparison criteria (e.g., greater than 3 sigmas or 3 standard deviations higher than the baseline “normal” transaction), such a determination may trigger in-depth suspicious fraudulent activity analysis of the identified new transaction.
By way of illustration, in one example, a statistical average analysis may be performed for cash-in transactions occurring at an identified gaming device over a 3-month time period. Based on this analysis it may be determined that the baseline “normal” cash-in transaction value and standard deviation value for the identified gaming device is $300, +/−$200. In one embodiment, the $300 value may represent the baseline “normal” cash-in transaction, and the “+/−$200” value may represent one standard deviation. One of the cash-in transactions which occurred during the analyzed 3-month time period relates to a cash-in transaction for $3000. This identified transaction may be determined to be about 13.5× standard deviations higher than the calculated baseline “normal” cash-in transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the identified transaction. Another, (new) cash-in transaction for $1800 is detected at the identified gaming device. This newly identified transaction may be determined to be about 7.5× standard deviations higher than the calculated baseline “normal” cash-in transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the newly identified transaction.
Similarly, in at least one embodiment, a statistical average analysis may be performed for cash-out transactions occurring at an identified gaming device over a 200-day moving time window. Based on this analysis it may be determined that the 200-day moving average, or the baseline “normal” cash-out transaction value and standard deviation value for the identified gaming device is $200, +/−$100. In one embodiment, the $200 value may represent the baseline “normal” cash-out transaction, and the “+/−$100” value may represent one standard deviation. One of the cash-out transactions which occurred during the analyzed 200-day moving time window relates to a cash-out transaction for $2000. This identified transaction may be determined to be about 18× standard deviations higher than the calculated baseline “normal” cash-out transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the identified transaction. Another, (new) cash-out transaction for $800 is detected at the identified gaming device. This newly identified transaction may be determined to be about 6× standard deviations higher than the calculated baseline “normal” cash-out transaction for the identified gaming device, which may cause the triggering of in-depth suspicious fraudulent activity analysis to be performed on the newly identified transaction.
It will be appreciated that the various types of baseline “normal” transaction and standard deviation criteria which may be generated and utilized for triggering of in-depth suspicious fraudulent activity analysis may depend upon the desired types of financial transaction filter criteria to be applied (such as, for example, time period filter criteria, transaction date filter criteria, transaction day of week filter criteria, transaction time filter criteria, etc.). Additionally, in at least some embodiments, the range of acceptable standard deviation variance may also be used as a definable criteria for triggering of in-depth suspicious fraudulent activity analysis. For example, any transactions which have been identified as exceeding 4× standard deviations from the baseline “normal” transaction may be flagged for in-depth suspicious fraudulent activity analysis.
According to different embodiments, the techniques for analyzing selected financial transaction information and determining the various baseline “normal” transaction and standard deviation criteria (e.g., such as those described above with respect to single or individual gaming devices) may similarly be applied to one or more sets or groups of gaming devices. For example, in some embodiments, a statistical average analysis may be performed for cash-in transactions occurring at one or more identified group(s) of gaming devices over a specified time period. Similarly, in some embodiments, a statistical average analysis may be performed for cash-out transactions occurring at one or more identified group(s) of gaming devices over a specified time period.
In some embodiments, various types of pattern recognition techniques may be utilized or employed for identifying suspicious financial transactions which may correspond to one or more different types of fraudulent financial activities. Non-limiting examples of pattern recognition techniques may include, but are not limited to, one or more of the following (or combinations thereof):
Returning to the example embodiment of
In at least some embodiments, one or more different persons and/or entities may subscribe or register to receive alerts and/or notifications relating to various types of suspicious activities and/or potential money laundering transactions. Collectively, the various persons and/or entities who subscribe to receive selected suspicious activity/fraudulent transaction alert(s) may be referred to as subscribers. According to different embodiments, there may be different classes of subscribers such as, for example:
Other types of subscribers may include, but are not limited to: casino employees, security personnel, casino floor managers, casino floor pit bosses, law enforcement personnel, government personnel, gaming regulators, governmental agencies, gaming regulatory agencies, financial regulatory agencies, etc.
According to different embodiments, different persons and/or entities may each provide or configure their respective subscription preferences and other subscription rules/criteria for receiving alerts and/or notifications relating to desired types of suspicious or fraudulent activities or transactions. Examples of various types of subscription preferences, rules, and criteria may include, but are not limited to, one or more of the following (or combinations thereof):
In some embodiments, alert/event monitoring may be performed at an operator control panel in a back room of the casino. In other embodiments, alert/event monitoring may be performed in mobile environments (e.g., while the monitoring person is on the move).
For example, in one embodiment, a security officer (who is determined to be on-duty) may receive an alert or notification (e.g., via SMS text alert) on his smart phone or other mobile device. The security office may tap on the alert to open an activity monitoring application on the mobile device which may display an interactive Alert Floor Map GUI of the casino floor (or portion thereof) and which may also highlight (e.g., by visual display) the gaming device/table/machine at which a suspicious or fraudulent activity or event has been detected. In one embodiment, the security officer may interact with the Alert Floor Map GUI (e.g., by touching the highlighted gaming device) to access additional information and details relating to the nature of the alert, the transaction event(s), player identity, and/or other types of information relating to the detected suspicious or fraudulent activity or event. In some embodiments, the mobile device and/or Alert Floor Map GUI may be configured or designed to include functionality for:
In some embodiments the degree of severity of an identified suspicious activity may also be assessed (e.g., in real-time) in order to determine, for example: (i) which type(s) of response action(s) should be performed (e.g., in response to detection of the identified suspicious activity), and/or (ii) the appropriate timeframe for initiating or implementing each response action to be performed. By way of illustration, non-exhaustive examples of different types of criteria may be considered when determining the degree of priority or urgency to be assigned to a given response action may include, but are not limited to, one or more of the following (or combinations thereof):
Some events may be assigned relatively higher priorities than other events. Assignment of relative priorities may depend upon the particular facts and/or conditions associated with each event. Additionally, in some embodiments, the degree of urgency or priority of dispatching alert(s) communications and/or notification(s) for a given event may be determined, at least partially, as a function of the priority associated with that event.
For example, detection of a $9000 cash-in event at a specific gaming device, followed by an $8990 cash-out event at the same gaming device within 1 minute may be assigned a high priority, or may be assigned a relatively higher priority than detection of a $9000 cash-in event at the gaming device, followed by an $8990 cash-out event at the same gaming device 2 hours later. In the former situation, it may be determined that there is a relatively high degree of urgency to immediately send out an alert to casino security and the casino floor supervisor, alerting them of the detected fraudulent activity. In the latter situation, it may be determined that there is a relatively lower degree of priority (or no need) for sending out alert(s) communications relating to the detected event. In another example, a cash-out after a Jackpot win of $10,000 is may not be assigned as a high priority event for suspicious fraudulent activity. However, in at least one embodiment, the detection of such an event will trigger a flag for automatic reporting purposes for causing the detected event to be logged and reported to the appropriate agencies for tax reporting purposes.
It will be appreciated that different embodiments of the Transaction Analysis and Suspicious Activity Screening and Notification Procedure (not shown) may include additional features and/or operations than those illustrated in the specific embodiment of
As shown at 1104, one or more specific transaction(s) may be identified for analysis. For purposes of simplification and clarification, it is assumed in the example embodiment of
As shown at 1106, various details associated with the identified transaction may be analyzed. In at least one embodiment, such details may include, for example, one or more of the following (or combinations thereof): information identifying one or more persons involved in the transaction; information identifying the kiosk, gaming device, gaming table or other device(s) associated with transaction; transaction time/date; transaction location; transaction amount; win amount; etc.
As shown at 1108, if desired, additional information relating to the identified transaction (if available) may be acquired, generated, and/or retrieved which may be relevant to suspicious or fraudulent activity analysis of the identified transaction. In at least one embodiment, at least a portion of the additional information may be retrieved and/or accessed from one or more sources such as, for example: casino server system database(s), external database(s), etc. Examples of such additional information may include, but are not limited to, one or more of the following (or combinations thereof):
As shown at 1110, pattern information relating to fraudulent activity and/or other types of suspicious activity may be accessed and/or retrieved from one or more Suspicious Activity/fraudulent Activity Pattern Database(s) (such as, for example, 892,
As shown at 1112, details of the identified transaction and the additional acquired information may be analyzed for suspicious/potential fraudulent activity using the retrieved suspicious/fraudulent activity pattern data. In at least one embodiment, the Suspicious Activity Analysis Procedure may determine and assign (1114) respective match probability values for selected fraudulent patterns and/or other suspicious activity patterns based on analyzed details of the identified transaction and additional acquired information. As shown at 1116, selected transaction details relating to the identified transaction may be logged along with the calculated pattern match probability values. In at least one embodiment, this archive of historical transaction analysis information may be used for future analysis and/or detection of suspicious fraudulent activity.
In at least one embodiment, if at least one pattern match is identified (1118) for which the associated calculated pattern match probability value meets or exceeds predefined minimum threshold criteria (e.g., pattern match probability value >50%), then the identified transaction may be flagged (1120) as suspicious/potential money laundering transaction. Additional financial transactions flagged for in-depth suspicious activity analysis may be analyzed (1122) in a similar manner to that described above.
The foregoing features, embodiments, and procedures provide an overview and examples of various systems and methods to detect and provide alerts across gaming systems and networks with respect to suspicious and fraudulent activities and events. Another tool that can be used to help detect such activities and events can relate to gaming monetary instruments that are used within such gaming systems and networks. For example, printed tickets or vouchers having cash values are often printed and issued by slot machines, gaming tables, gaming kiosks, and other electronic devices throughout a casino and/or gaming enterprise or network. Often these printed tickets or vouchers are anonymously issued, in that any player or person holding a voucher may redeem such voucher for the cash value printed thereon. Unfortunately, present systems tend to provide inadequate help in detecting suspicious and fraudulent activities with respect to printed tickets and vouchers for gaming systems.
Accordingly, the disclosed embodiments also provide improved gaming monetary instrument tracking systems that allow for enhanced tracking and detection of suspicious and fraudulent gaming activities involving gaming monetary instruments. Again, a gaming monetary instrument can refer to a wide variety of items, such as, for example, printed tickets, vouchers, casino chips, markers, smart cards, magnetic stripe cards, and the like. For purposes of discussion, all such gaming monetary instruments or items shall be referred to as “vouchers” herein where context is appropriate.
In various embodiments, printed tickets and other vouchers can have tracking details associated therewith. Some or all printed tickets or vouchers within a gaming system or network can each be associated with a data structure, and can each be associated with a historical record that allows tracking across multiple different transactions over time. In some embodiments, a given voucher can have an identifier that not only associates a cash value with the voucher, but that also associates a historical record that identifies some or all sources of the cash value for that voucher, such as across several gaming transactions. In this manner, a more transparent level of continuity is provided across a series of gaming transactions that may involve multiple gaming devices and multiple vouchers.
Sequence 1200 includes the generation and redemption of multiple different printed tickets or vouchers 1203, 1205, 1207, which are used at multiple different system nodes or gaming devices 1202, 1204, 1206, 1208 over time across the casino. At an initial transaction, a player can insert $20 in cash at a first system node 1202, which can be, for example, “Kiosk #8” (Node 1). The player then requests a printed ticket 1203, upon which “Voucher A” in the amount of $20 is issued by Kiosk #8. As noted in greater detail below, a data structure and historical record on the gaming system can both be associated with Voucher A, with such data structure and historical record having sufficient data to track information regarding Voucher A. For example, the historical record can at least include data regarding the cash amount inserted at Kiosk #8, as well as Kiosk #8 being the gaming device that issued Voucher A. Further data can include the date and time that Voucher A was issued, and may also include other details, such as a serial number of a $20 bill inserted to procure the cash value of Voucher A, for example.
The player then moves to a second system node 1204, which can be, for example, “Slot Machine #1234” (Node 2), and inserts Voucher A for a credit of $20. The player then plays 10 games at $1 each and wins $50 at Slot Machine #1234, after which the player requests a cash out. A printed ticket 1205 represented as “Voucher B” in the amount of $60 (10+50) is then issued by Slot Machine #1234. Again, a data structure and historical record on the gaming system can both be associated with Voucher B, with such data structure and historical record having sufficient data to track information regarding Voucher B. For example, the historical record may include some or all of the data in the historical record for Voucher A, as well as additional information regarding the date and time of the insertion of Voucher A into Slot Machine #1234, the amounts and times of games played, the amounts won for the games played, and the date and time of the issuance of Voucher B from Slot Machine #1234. Accordingly, the historical record for Voucher B would contain data noting that Voucher B for $60 came about due to the $20 of Voucher A and a net win of $40 at Slot Machine #1234, such that the historical record accounts for the entire monetary value of Voucher B. In addition, the historical record for Voucher A may be updated with a forward reference to Voucher B.
The player then moves to a third system node 1206, which can be, for example, “Blackjack Table #34” (Node 3), and inserts or otherwise redeems Voucher B for a credit of $60. This credit can be taken in the form of $5 chips at the blackjack table, for example. The player then plays 20 games of blackjack at $5 per game, and wins a total of $140 over the 20 games. The net win then is $40 to go with the original $60 buy-in, giving the player $100 in chips. The player then requests a cash out, upon which a printed ticket 1207 represented as “Voucher C” in the amount of $100 is issued at Blackjack Table #34.
As in the above iterations, a data structure and historical record on the gaming system can both be associated with Voucher C, with such data structure and historical record having sufficient data to track information regarding Voucher C. For example, the historical record may include some or all of the data in the historical records for both of Voucher A and Voucher B, as well as additional information regarding the date and time of the redemption of Voucher B at Blackjack Table #34, the amounts and times of the blackjack games played, the amounts won for the games played, and the date and time of the issuance of Voucher C from Blackjack Table #34. Accordingly, the historical record for Voucher C would contain data noting that Voucher C for $100 came about due to the $20 of Voucher A and a net win of $40 at Slot Machine #1234, and a net win of $40 at Blackjack Table #34, such that the historical record accounts for the entire monetary value of Voucher C. In addition, the historical records for Voucher A and Voucher B may both be updated with a forward reference to Voucher C. Such forward reference updates can include some or all of the data contained in the forward referenced voucher or vouchers, such as Voucher C in this instance.
The player then moves to a fourth system node 1208, which can be, for example, “Cashier's Cage #5” (Node 4), and redeems Voucher C for $100 cash. The system can then invalidate Voucher C once it has been redeemed (to prevent any further redemption or other fraud), but may still retain the historical records for Vouchers A, B, and C, such as to detect larger patterns of gaming activities and transactions.
Data structures and/or historical data for printed tickets and other vouchers can include various data items, such as voucher sequence data, for example. Such voucher sequence data can indicate some or all sources from which a voucher is derived (e.g., “backward references”, as well as some or all vouchers that derive from the instant voucher (e.g., “forward references”). As shown, printed ticket 1304 (i.e., Voucher B) can be associated with historical data that can include voucher sequence data. In particular, the historical data for Voucher B can include a backward reference to Voucher A, as well as a forward reference to Voucher C. Of course, the forward reference to Voucher C cannot be input or detailed until Voucher C is created or otherwise known of. As such, historical data for a given voucher can be updated over time to reflect forward references.
Again an initial transaction, a player can insert cash at a first system node 1402, which can be, for example, “Kiosk #8” (Node 1), upon which a printed ticket 1403 is issued therefrom as Voucher H. As an addition to the pattern of sequence 1200 above, a separate cash in and gaming event can take place at a second system node 1410, which can be, for example “Slot Machine #1435” (Node 2), after which a printed ticket 1409 is issued therefrom as Voucher J. As in the foregoing examples, each of Voucher H and Voucher J can have a data structure and historical record associated therewith.
Voucher H and Voucher J can then both be inserted for credit at a third system node 1404, which can be, for example, “Slot Machine #1434” (Node 3). After a gaming session at Slot Machine #1434, a requested cash out can result in the issuance of another printed ticket 1405, represented as Voucher K. Unlike the foregoing simpler pattern example of sequence 1200, Voucher K will then have additional information or data in its historical record here in sequence 1400. That is, while the corresponding historical record for Voucher B above included historical record data for Voucher A, gaming session data for the games at Slot Machine #1434, and issuance data for Voucher B, the historical record for Voucher K can include historical record data for Voucher H, gaming session data for the games at Slot Machine #1434, issuance data for Voucher K, and also historical record data for Voucher J.
Further iterations at Blackjack Table #34, Voucher L issuance and historical record creation, and Cashier's Cage #5 can all also reflect the additional historical record data with respect to Voucher J. In this manner, all gaming transactions and vouchers that contribute to or reflect the amount of any value for a given voucher can be reflected in the historical record for that voucher. For example, if ten more vouchers are also added to the gaming session at Slot Machine #1434, then historical record data for each of these additional ten vouchers can also be added to the historical record for each of downstream or later sequential vouchers K and L.
Again, data structures and/or historical data for printed tickets and other vouchers can include various data items, such as voucher sequence data, for example. As shown, printed ticket 1504 (i.e., Voucher K) can be associated with historical data that can include voucher sequence data. In particular, the historical data for Voucher K can include backward references to Vouchers H and J, as well as a forward reference to Voucher L. Again, the forward reference to Voucher L cannot be input or detailed until Voucher L is created or otherwise known of.
As shown at optional step 1604, Voucher A can then be inserted into or otherwise provided for credit at a Casino Device B that is separate from Casino Device A which issued Voucher A. For purposes of simplification and clarification, it is assumed in the example embodiment of
As shown at step 1606, an inquiry can be made as to whether a voucher redeem event is detected at Casino Device B. If no voucher redeem event is detected, then the procedure skips to step 1616 as shown. If a voucher redeem event is detected, however, such as after Voucher A has been inserted into or presented thereat in optional steps 1602 and 1604, then the procedure continues to step 1608 where the Voucher Identification (e.g., unique number or code) of Voucher A is determined and a Voucher Redemption Tracking Procedure is initiated. A more detailed description of such a Voucher Redemption Tracking Procedure is set forth at
At step 1610, a Voucher Screening Procedure is initiated for the identified Voucher A, details for which are set forth at
If the identified voucher does pass screening at step 1612, however, then an appropriate amount of credits are distributed from the identified voucher to the credit meter of the electronic gaming device accepting the voucher at step 1614. In this particular example as shown, the cash value of Voucher A is distributed or transferred as credits to the meter of Casino Device B. At step 1616, the player then participates in wager-based gaming activities at Casino Device B. At step 1618, funds and/or credits from redeemed vouchers, which can include Voucher A and potentially one or more additional vouchers, are then used to fund wagers for the wager-based gaming activities at Casino Device B.
At step 1620, information and data relating to the wager-based gaming activities during the gaming session at Casino Device B are collected and recorded, such that data structures and historical records relating to Voucher A and any other relevant vouchers associated with the gaming session can be created. It should be noted that this collection and recording step 1620 may be performed before Voucher A is redeemed, after the gaming session is over, and/or can be performed dynamically during the gaming session at Casino Device B. At step 1622, information and data relating to any other additional vouchers and/or cash that is inserted into Casino Device B during the gaming session can be collected and recorded. In particular, redeemed vouchers, cash, and/or other credits that are comingled with credits from Voucher A are also tracked for purposes of linking and tracking all vouchers associated with the gaming session. Similar to step 1620, this step 1622 may also be performed at different times in the provided procedure, such as before Voucher A is redeemed and/or before some of the wager-based gaming activities that take place on Casino Device B.
As shown at the following step 1624, an inquiry can made as to whether a “Cash Out” request is detected at Casino Device B. If not, then the procedure reverts to step 1606, after which all steps can then be repeated as may be appropriate. If a “Cash Out” request is detected at step 1624, however, then the procedure continues to step 1626 where Player Cashout Procedure(s) are initiated. At step 1628, various data items are created and recorded for the new voucher that is about to be issued. Such data items can include a Node ID (e.g., the node identifier for Casino Device B), Node Envelope Data, Node Session Data, and other informational items that can be placed into the historical record associated with the new voucher, which can be called Voucher B.
At step 1630, the new voucher (i.e., Voucher B) is created and dispensed at Casino Device B. This can be accomplished, for example, by way of a ticket printer at the device issuing a printed ticket. At step 1632, a Voucher Forward Link Procedure is initiated for the newly issued voucher (i.e., Voucher B), details for which are set forth at
At step 1704, details regarding the offered and redeemed voucher are identified or determined. Such details and information can include, for example:
At step 1706, the foregoing voucher redemption transaction information can be recorded at the appropriate Voucher/Chip Tracking Database(s). A detailed example of potential items for such recorded information is provided at
At step 1754, details regarding the issued voucher are identified or determined. Such details and information can include, for example:
At step 1756, the foregoing voucher issuance transaction information can be recorded at the appropriate Voucher/Chip Tracking Database(s), such that this data or information can then be provided to all forward linked vouchers. At step 1758, one or more appropriate records on the Voucher/Chip Tracking Database(s) can then be updated to indicate that the new voucher has been issued. For example, a forward link relating to the newly issued voucher can be provided to any other system node and/or data structure or historical record for a future issued voucher. This forward link can identify the newly issued voucher and provide a location where appropriate information and data can be located to be included in the data structures and historical records of such future issued vouchers that are related to the instant voucher. The procedure then ends after step 1658.
Initial step 1802 shows that a voucher screening request has been received from a Casino Device on the system. This can correspond to that which takes place at step 1610 in the foregoing example of
As shown at step 1804, the offered voucher being screened is then authenticated and validated, such as according to the foregoing informational items. At step 1806, an inquiry is then made as to whether the offered voucher being screened passed the authentication and validation process. If not, then the procedure moves to step 1824 where a Return/Report Voucher Screening Failure is recorded and appropriate alerts are sent, after which the procedure ends. If the voucher being screened passes at step 1806, however, then the procedure continues to step 1808, where historical transactions related to the screened voucher are accessed and linked to the screened voucher and any associated player ID (as may be applicable).
At step 1810, the authenticated and validated voucher is then analyzed according to its related transactions for fraudulent or suspicious activities (e.g., for possible money laundering patterns). At step 1812, another inquiry is made as to whether the authenticated voucher being screened has any suspicious or potentially fraudulent activities identified according to the accessed historical data. If such suspicious or possibly fraudulent activities are detected at step 1812, then the procedure similarly moves to step 1824 where a Return/Report Voucher Screening Failure is recorded and appropriate alerts are sent, after which the procedure ends. If the voucher being screened for fraudulent or suspicious activity passes at step 1812, however, then the procedure continues to step 1814, where subscribers are identified accordingly to subscription preferences, and alerts and/or notifications are generated and sent to the appropriate subscribing casino personnel and/or other relevant parties.
At step 1816, data regarding the screened voucher is recorded, one or more suitable reports are generated, and automated electronic filing is performed for the recorded data and reports (e.g., historical records), as may be desired or required per system preferences or parameters. At step 1818, an inquiry is made as to whether any additional actions regarding the screened voucher may be desired or required. If not, then the procedure moves to step 1822, where a Return/Report Voucher Screening Approval is recorded, after which the procedure ends. If any other actions are desired at step 1818, however, then such additional other action(s) are initiated and performed as may be desired or required at step 1820, after which the procedure moves to step 1822 for the same action noted above, and after which the procedure ends.
As shown, Envelope Data File 1900 can include data items relating to forward and backward references to other vouchers (e.g., Vouchers C and A), time stamp data, location data, Casino Device and node type data, a credit amount, any player ID and/or biometric (e.g., fingerprint or picture) information, and a redemption confirmation number, among other possible data items. Such other possible data items may include other fields, such as a field and subfields for co-mingled funds details. Also, while the redemption confirmation number is presently blank, it will be readily appreciated that this field can be updated whenever Voucher B is redeemed, such as at another Casino Device.
As shown, Session Data File 2000 can include data items such as an issued voucher ID, the game type and theme (e.g., slots), the number of games played and number of games won, jackpots won, net win, and the average rate of game play, among other possible data items.
As shown, Voucher Redemption Data File 2100 can include data items relating to time stamp data, location data, redemption amount, any player ID and/or biometric information if applicable (in this case Anonymous), a credit amount, and a redemption confirmation number, among other possible data items. Again, while the redemption confirmation number is presently blank, it will be readily appreciated that this field can be updated whenever Voucher B is redeemed, such as at another Casino Device.
Similar to the foregoing example, Envelope Data File 2200 can include data items relating to forward and backward references to other vouchers (e.g., Vouchers L forward and Vouchers H and J backward), time stamp data, location data, Casino Device and node type data, a credit amount, any player ID and/or biometric information, and a redemption confirmation number, among other possible data items, such as a field and subfields for co-mingled funds details. Again, while the redemption confirmation number is presently blank, it will be readily appreciated that this field can be updated whenever Voucher K is redeemed, such as at another Casino Device.
At step 2304, Voucher A is then redeemed at Blackjack Table A, and a gaming session of blackjack at the table commences. At step 2306, an additional $5,000 in cash is added during the gaming session at Blackjack Table A. At step 2312, which may occur before or after step 2304, a Partial Cash Out from the gaming session at Blackjack Table A is requested. The Partial Cash Out results in the issuance of a new Voucher A1 in the amount of $3,000, which amount is deducted from the pending credit balance at Blackjack Table A. Such a Partial Cash Out might take place, for example, where a spouse or friend of the player at Blackjack Table A desires funds for his or her own separate gaming session. As such, steps 2306-2310 can occur in parallel with steps 2312-2322. Alternatively, either series of these steps may occur before or after the other.
Continuing from step 2306, the gaming session ends at Blackjack Table A at step 2308, whereupon a full Cash Out of the remaining credit balance for the gaming session there is requested. This Cash Out results in the issuance of another new Voucher A2 in the amount of $6,000, which is the remaining balance at Blackjack Table A. At the next step 2310, Voucher A2 is backward referenced to the original Voucher A. In addition to the backward reference to Voucher A, data regarding the extra $5,000 added during the gaming session, the Partial Cash Out resulting in new Voucher A1, and other gaming session details can be added to the historical record for newly issued Voucher A2 at step 2310 or a subsequent step (not shown).
Continuing from step 2312, newly issued Voucher A1 can be backward linked or referenced to original Voucher A at step 2314. Additional data can also be added to a historical record for new Voucher A1, similar to that which is described for Voucher A2 above. At a following step 2316, Voucher A1 is redeemed at Slot Machine #1234, and a slots gaming session at the Slot Machine commences. At step 2318, an additional $5,000 in cash is added during the gaming session at Slot Machine #1234. At step 2320, the gaming session ends at Slot Machine #1234, whereupon a full Cash Out of the remaining credit balance for the gaming session there is requested. This Cash Out results in the issuance of another new Voucher A3 in the amount of $7,500, which is the remaining balance at Slot Machine #1234. At the next step 2322, Voucher A3 is backward referenced to Voucher A1, and can be backward referenced to the original Voucher A as well. In addition to the backward reference to Voucher A, data regarding the extra $5,000 added during the gaming session, and other gaming session details can be added to the historical record for newly issued Voucher A3 at step 2322 or a subsequent step.
At step 2308, Voucher #1 is then redeemed at Slot Machine #1234 for a Cash In value of $4,970. At step 2510, a gaming session commences at Slot Machine #1234, which gaming session involves the play of 10 games at $1 each for a net loss of $5. At step 2512, a full Cash Out request results in the issuance of Voucher #2 in the amount of $4,965 at Slot Machine #1234. During the gaming session and/or Cash Out at Slot Machine #1234, an Analyze Voucher Sequence may be performed at step 2516. After the Cash Out at step 2512, Voucher #2 is then redeemed at Cashier's Cage #5 for its full value of $4,965 in cash. An Analyze Voucher Sequence may also be performed with respect to this transaction at step 2516.
Step 2516 represents an Analyze Voucher Sequence that may be performed with respect to any or all transactions regarding the redemption or issuance of a voucher. At step 2518, an inquiry is made as to whether any potential fraud or other suspicious activity is detected with respect to any patterns in the data associated with the analyzed transaction. In no suspicious activity pattern is detected, then the Voucher Sequence Data is simply logged at step 2520. This data is then available for data structures and historical records for the subject voucher and any related or linked vouchers. In the event that suspicious activity is detected, however, then a suspicious activity alert (e.g., AML alert) is generated and sent to the appropriate personnel. In addition, a report can also be generated, stored, and sent as desired or required according to system protocols.
For the foregoing flowcharts, it will be readily appreciated that not every method step provided is always necessary, and that further steps not set forth herein may also be included. For example, added steps to involve further player tracking or suspect gaming activity pattern detection may be added. Furthermore, the exact order of steps may be altered as desired, and some steps may be performed simultaneously. In addition, while the provided examples are with respect to gaming monetary instrument tracking, it will be readily understood that such steps can also be adapted to apply to RFID casino chip tracking, cash transactions, player tracking, resort transactions, and the like.
It should be understood that the devices, systems and methods described herein may be adapted and configured to function independently or may also interact with other systems or applications, such as for example, a casino management system or player tracking system. As such, gaming cash instrument tracking data may be recorded and stored in connection with casino or resort management data, player information, or other data retrieved from a table, terminal or other pertinent location. It should also be readily apparent that additional computerized or manual systems may also be employed in accordance with the disclosure in order to achieve its full implementation as a system, apparatus or method.
Those skilled in the art will readily appreciate that any of the systems and methods of the disclosure may include various computer and network related software and hardware, such as programs, operating systems, memory storage devices, data input/output devices, data processors, servers with links to data communication systems, wireless or otherwise, and data transceiving terminals, and may be a standalone device or incorporated in another platform, such as an existing electronic gaming machine, portable computing device or electronic platforms with multiple player positions. In addition, the system of the disclosure may be provided at least in part on a personal computing device, such as home computer, laptop or mobile computing device through an online communication connection or connection with the Internet. Those skilled in the art will further appreciate that the precise types of software and hardware used are not vital to the full implementation of the methods of the disclosure so long as players and operators thereof are provided with useful access thereto or the opportunity to play the game as described herein.
The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. Various aspects of the described embodiments can be implemented by software, hardware or a combination of hardware and software. Computer readable medium can be any data storage device that can store data which can thereafter be read by a computer system. Examples of computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storage devices, and carrier waves. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
Although the foregoing disclosure has been described in detail by way of illustration and example for purposes of clarity and understanding, it will be recognized that the above described disclosure may be embodied in numerous other specific variations and embodiments without departing from the spirit or essential characteristics of the disclosure. Certain changes and modifications may be practiced, and it is understood that the disclosure is not to be limited by the foregoing details, but rather is to be defined by the scope of the appended claims.
This application claim priority of U.S. Provisional Patent Application No. 62/576,048, filed Oct. 23, 2017, and entitled “GAMING MONETARY INSTRUMENT TRACKING SYSTEM,” which is hereby incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 62576048 | Oct 2017 | US |
