|Publication number||US5737418 A|
|Application number||US 08/453,269|
|Publication date||Apr 7, 1998|
|Filing date||May 30, 1995|
|Priority date||May 30, 1995|
|Publication number||08453269, 453269, US 5737418 A, US 5737418A, US-A-5737418, US5737418 A, US5737418A|
|Inventors||Ali M. Saffari, James P. Hunt|
|Original Assignee||International Game Technology|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (35), Referenced by (150), Classifications (16), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention relates to encrypted communications between bill validators and the machines employing such bill validators. More specifically, the invention relates to bill validators and protocols they employ to send encrypted bill validation data to associated machine logic.
Many machines which provide goods or services--such as vending machines and gaming machines--contain a "bill acceptor" into which a user inserts currency. The typical bill acceptor first validates and then stores inserted currency in a secure location. A part of the bill acceptor known as a bill validator evaluates inserted bills and makes a preliminary determination as to whether the bill should be accepted or returned to a user. To this end, an item inserted into a bill acceptor must meet certain criteria to be accepted. By way of example, the item must have the markings and dimensions of a recognized, valid, non-counterfeit bill. If it does not, the bill validator will automatically reject it.
As standard bill validators are made for many different markets and applications, they are generally designed to recognize as valid some bills that are not appropriate for all machines. For example, a bill validator may be designed for applications throughout North America, and therefore recognize and accept Canadian, Mexican, and U.S. currency. Such bill validator will not automatically reject valid currency from any of these countries. However, if such bill validator is used in a vending machine located in Denver Colorado, the machine should reject all but U.S. currency. To ensure this result, bill validators are designed to communicate with other parts of a machine which have the necessary logic to determine which of the many bills that a bill validator finds acceptable are, in fact, acceptable to the machine as a whole.
Thus, some bill validators employ standard communication formats to transmit bill validation data to other parts of a machine. One such format requires that specific types of bill validation data be provided at specific locations in a signal, and that such signal be transmitted only under certain conditions. For example, the bill validation data may be arranged such that a code for the inserted currency's denomination ($1, $10, $20, etc.) is provided at one location in a signal and a code for the currency's country (Canada, Mexico, U.S., etc.) is specified at another location in the signal. Upon receiving a communication having this format, the appropriate machine logic then determines whether the inserted bill should be accepted or rejected, and instructs the bill validator to act accordingly.
Bill validators must generally be secure mechanisms. Unfortunately, the protocols employed in validator-machine communications as well as the signal format used in such communications are becoming increasingly well known. Armed with such knowledge, an industry competitor or a thief could tamper with the bill validator or machine logic to defeat a machine's security. Thus, it would be desirable to have a bill validator and/or bill validator-machine system that is as flexible as current systems, but provides additional security.
The present invention provides a method and system for encrypting bill validation data and sending that encrypted data from a bill validator to machine logic. The machine logic then decrypts the encrypted data, decides whether to accept or reject the bill, and relays its decision back to the bill validator. It has been recognized that this process is necessary because communications of bill validation data to machine logic may be intercepted and decoded in order to defeat a machine's security. By encrypting the bill validation data sent to the machine logic, a competitor or thief with access to a bill validator is unlikely to be able to reverse engineer the system for encoding bill validation data.
The expression "bill validation data" will be used throughout this document. As used herein, bill validation data refers generally to any information pertaining to a bill. Such information typically includes the bill's denomination and country or origin. However, it might also include such information as the magnetic content of the bill, and the markings on the bill including any images or ink type color.
One aspect of the present invention provides a method of validating currency in a currency accepting machine. The method can be generally characterized as including the following steps: (a) upon receipt of a bill in the currency accepting machine, generating a raw bill validation signal containing raw bill validation data, (b) encrypting the raw bill validation data in the bill validation signal to produce an encrypted bill validation signal, (c) communicating that encrypted bill validation signal to a machine which provides credit for goods or services (e.g., a gaming or vending machine), and (d) decrypting the encrypted bill validation signal to retrieve the raw bill validation data. The machine will then determine whether to accept or reject the bill based upon the raw bill validation data it obtains by decrypting.
In preferred embodiments of this invention, the bill validation data is encrypted by a method that involves the following steps: (a) using "previous" bill validation data for a bill that was previously accepted by the bill validator as an independent data source, (b) using an algorithm that employs at least three independent sources of data to select a new encryption key from among a group of available encryption keys, and (c) combining the new encryption key and the raw bill validation data to produce encrypted bill validation data. Three sources of data that have been found useful in selecting new encryption keys include the "previous" bill validation data, the previous encryption key, and the number of bills that have been accepted since a defined event. Regardless of how the encryption key is obtained, it is combined with the raw bill validation data by an XOR logical operation to produce an encrypted signal.
Another aspect of the invention is directed to a bill acceptor that can be characterized as having the following elements: (1) a detector which detects certain physical data pertaining to a bill, (2) a CPU coupled to the detector to receive the physical data, determine the bill's denomination, and determine whether the bill is valid, and (3) an interface for transmitting bill validation signals to a location outside of the bill acceptor. The CPU will include a memory and a processor which are adapted to (a) generate signals containing raw bill validation data including data codifying the bill's denomination, and (b) encrypt the raw bill validation data generated by the generator to produce an encrypted bill validation signal. The detector may take various forms and will typically detect signals from various sources. By way of example, the detector may include one or more light sensors for detecting the light energy transmitted through and/or reflected off the bill. In addition, the detector may include a magnetic field sensor for detecting magnetic fields emanating from the bill.
To encrypt the bill validation data, the bill acceptor may include a table of key words including a pointer which moves to key words in the table in accordance with a specified algorithm. Preferably, the CPU combines the raw bill validation data with a key word selected from the table of key words to produce the encrypted bill validation signal by an exclusive OR operation.
These and other features of the present invention will be presented in more detail in the following detailed description of the invention and the associated figures.
FIG. 1 is a diagram illustrating the primary components of a bill acceptor suitable for use with the present invention.
FIG. 2A is a generic representation of an event message signal.
FIG. 2B is a generic representation of the data pulse sequence portion of the signal shown in FIG. 2A
FIG. 2C is a specific representation of the data pulse sequence shown in FIG. 2B.
FIG. 3 is a diagram illustrating the encryption and decryption procedures used in the present invention.
FIG. 4A and 4B are together a process flow diagram setting forth the primary steps employed in a bill validation protocol of the present invention.
FIG. 5 is a process flow diagram illustrating the process steps employed to generate raw data used in a bill validation event message.
FIG. 5A is diagram of a country code table suitable for use with the present invention.
FIG. 5B is diagram of a denomination code table suitable for use with the present invention.
FIG. 6 is a process flow diagram presenting the principal process steps employed in an encryption technique suitable for use with the present invention.
FIG. 6A is a diagram of an encryption key table suitable for use with present invention.
FIG. 7 is a process flow diagram illustrating the principal process steps employed in an encryption protocol suitable for use with the present invention.
FIG. 8 is a process flow diagram showing the principal steps employed to determine a new pointer location in a key table in accordance with one embodiment of this invention.
FIGS. 9A and 9B are together a process flow diagram presenting the steps employed to generate a pointer offset according to a specific embodiment of the present invention.
FIG. 10 is a diagram showing a sequence of signal transitions employed in bill validation in accordance with one embodiment of this invention.
1. Physical Embodiment
The invention employs various process steps involving data stored in computing systems. These steps are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, characters, data structures, or the like. It should be remembered, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
Further, the manipulations performed are often referred to in terms, such as incrementing, encrypting, or combining. In any of the operations described herein that form part of the present invention, these operations are machine operations. Useful machines for performing the operations of the present invention include digital computing systems or other similar devices. In all cases, there should be borne in mind the distinction between the method of operations in operating a digital processor and the method of computation itself. The present invention relates to method steps for operating a digital processor in processing electrical or other physical signals to generate other desired physical signals.
The present invention also relates to an apparatus for performing these operations. This apparatus may be specially constructed for the required purposes, or it may be a general purpose bill validation system selectively activated or reconfigured by a computer program stored in the system. The processes presented herein are not inherently related to any particular bill validation system or other apparatus. In particular, various general purpose machines may be used with programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given below.
One implementation for the bill validation protocol of this invention is in an improved bill acceptor provided in a host machine. By way of example, a representative bill acceptor is illustrated in FIG. 1. As seen therein, a bill acceptor 10 includes a bill validator 14, a feed mechanism 8, and a bill repository (or "bill stacker") 18. The bill validator 14 is positioned to accept an inserted bill 12, and contains the detectors, data, and logic required to implement much of the present invention. Many makes and models of bill validators are commercially available, and may be used with the present invention in either unmodified or slightly modified states. By way of example, bill validation heads are available from a number of sources including Rowe International of Whippany, N.J., Japan Cash Machine Co., LTD. of Osaka, Japan, Mars Electronics, Inc. of West Chester, Pa., and Dixie Narco, Inc. of East Lake, Ohio.
The bill validator 14 shown in FIG. 1 includes an LED board 20 which shines light onto a bill 12 after it has been inserted into the validator. Light transmitted through bill 12 is detected by light sensitive sensors on a sensor board 22. In addition, the sensor board 22 may have its own light sources which shine light onto the bill 12 and detect some of that light which is reflected back onto its own light sensitive sensors. The intensity of the transmitted and reflected light is employed to ascertain any printed patterns on the bill 12. In addition to the light sensitive sensors, the sensor board 22 may also include a magnetism sensor to detect magnetic fields emanating from magnetic ink used on some currency. Additional bill data may be obtained from an encoder sensor 24 which monitors the revolutions of a motor 26 employed to move the bill 12 through the validator. This data is used to determine the length of inserted bill 12.
Data from the board 22 and sensor 24 is transmitted to a CPU board 16 which includes the necessary processors and memory to (1) make an initial determination of whether bill 12 is valid, and (2) control the encoding and encrypting of bill validation data provided by the sensors 22 and 24. Regarding the initial determination, a "valid" bill is one that is bona fide and non-counterfeit as determined by criteria of the bill validator 14. This determination is made without regard to the bill's denomination and country of origin. It is quite possible that a bill deemed valid by the validator 14 still will be rejected because the machine with which the bill validator is used determines that the bill's denomination or country of origin is unacceptable. Regarding the CPU board's encoding and encrypting functions, the board's memory will store tabular data specifying codes for a bill's denomination and issuing country. In addition, the memory will include an encryption key table which is described in detail below. Still further, the memory will include processor instructions for generating and encrypting validation data signals for use by the associated machine. The processor will, of course, act on these instructions to generate the appropriate signals. Such signals are communicated from bill validator 14 to the machine through an interface 5 (which is usually provided with an associated power supply for the bill validator).
After bill 12 passes by sensor board 22, it comes to rest with its tailing edge at position A, out of the user's reach. A bill at this location is said to be in an "escrow position." It is important to note that from the escrow position, the bill validator may either return the bill to the user or irretrievably stack the bill in a repository 18. This invention is primarily concerned with a protocol for determining whether to return bill from the escrow position or irretrievably stack it. Assuming that the bill validator 14, in conjunction with its associated machine, determines that bill 12 should be accepted, the bill is then transported along bill path 6 in feed mechanism 8 to the bill repository 18 where it is irretrievably held until the repository is removed from the bill acceptor 10.
Regarding the bill repository (or stacker) 18, some applications, such as gaming industry applications, require that the bill repository 18 to take the form of a secure cash box. It may also include a stacking mechanism to ensure that the bills are stacked in an orderly manner.
The host machine may be any of a number of possible machines which (1) provide credit to a user when the user inserts currency, and (2) dispense goods or services when the user issues appropriate instructions. By way of example, the host machine may be a gaming machine such as a slot machine or video poker machine, a vending machine such as a soda machine, a candy machine, or a cigarette machine, or an arcade game such as a video arcade game. In each instance, the host machine has a "crediting mechanism" or "machine logic" which makes the decision of whether to accept or reject an inserted bill and give a user credit for an accepted bill. As mentioned, the machine logic receives bill validation data from the bill validator 14 through interface 5. Thereafter, the machine transmits acceptance or rejection of a bill back through the interface to the bill validator. The machine logic will generally include a CPU having one or more processors and memory. The memory will store relevant instructions for using a key table to decrypt encrypted signals from the bill validator 14.
2. Bill Validation Data Formats
In accordance with the present invention, bill validation data for an inserted bill is converted to a binary data pulse sequence of specified format. This sequence is then encrypted and communicated to specialized logic in a machine. Upon receipt of the encrypted sequence, the machine logic decrypts it and uses it to determine whether to accept the inserted bill.
An exemplary format for communicating binary bill validation data is illustrated in FIGS. 2A-2C. Upon receiving a bill, the bill validator issues an "event report" in the form of a signal having the arrangement shown in FIG. 2A. The event report includes a "start sequence" shown as having a 50 millisecond low pulse followed by a 20 millisecond high pulse. Upon receiving this start sequence, the machine will be in a state to receive bill validation data. The data is provided as a binary "data pulse sequence" of a defined length and following the start sequence as shown in FIG. 2A. At the conclusion of the data pulse sequence, the event report includes a stop pulse shown as a 90 millisecond low pulse. Of course, event reports may have other formats so long as both the bill validator and the machine logic understand the format's features. By way of example, the start and stop sequences may include high and/or low pulses of varying lengths and combinations.
In the example shown in FIG. 2B, the data pulse sequence is further divided into three fields: a 6 bit country code, followed by a 5 bit denomination code, and concluded with a 4 bit checksum. As used herein, the country code end of the sequence will be referred to as the "most significant" end and the checksum end will be referred to as the "least significant" end. It should be understood that the size of the various fields used in this example could vary depending upon the number of possible countries or denominations handled by the machine. For example, if there were only 16 possible countries whose currency could be accepted, a 4 bit country code field would suffice, but if there were up to 64 possible countries, then a 6 bit country code field would be required. In addition, the data pulse sequence could contain other combinations of information. For example, it might include an additional field for another bill parameter or, it might have fewer fields if, for example, the bill validator recognized only one country's currency.
To obtain the binary values for the country code and denomination code fields, country code and denomination code tables are consulted. Exemplary versions of such tables are shown in FIGS. 5A and 5B and (and discussed in more detail below). Basically, the values corresponding to the country and denomination of the inserted currency are picked off these tables and converted to binary sequences for use in the country code and denomination code fields of the data pulse sequence. For example, such tables might specify that the denominations 1, 5, 10, 20, 25, and 50 have the numerical values 0, 1, 2, 3, 4, and 5 respectively, while the countries Argentina, Canada, Mexico, and the U.S. might have the numerical values 1, 5, 17, and 23 respectively. A bill validator reading a fifty dollar bill from the U.S. would generate a signal having the binary value of 23 in the country code field of the signal and the binary value of 5 in the denomination code field. As shown in the example of FIG. 2C, the country code has a binary value of 010111 (23), and the denomination code has a binary value of 00101 (5).
The checksum at the least significant end of the data pulse sequence is obtained by summing the binary 1's in the coventry code and denomination code fields (giving a value of 6 in this example), converting this number to a binary value (0110), and performing a 1's complement (1001). As known to those of skill in the signal processing arts, a checksum is commonly employed to help ensure to that data sequences have not been corrupted by noise or tampering during transmission.
One process for encrypting and decrypting bill validation data is illustrated in FIG. 3. The system shown in this example includes a bill validator unit 50 and a logic unit 60 for a machine requiring bill validation. Initially, the bill validator 50 detects information contained on an inserted bill 52 to generate a data pulse sequence 54. The data pulse sequence 54 is illustrated as a 15 bit binary sequence 56 having a country code field, a denomination code field, and a checksum as described above. The 15 bit binary value 56 is combined with a 16 bit key word 64 by an exclusive OR logic operation. The key word 64 is taken from a key table 58 stored in the bill validator. A pointer 62 determines which specific key word from key table 58 is to be combined with the binary sequence 56 by the exclusive OR logic operation. As explained below, the pointer 62 moves throughout key table 58 according to a specified algorithm chosen to make reverse engineering difficult. It should be noted that, in this example, the key word 64 contains 16 bits while the sequence containing the bill validation data contains only 15 bits. Thus, before the exclusive OR operation is performed, one of the terminal bits must be truncated from the key word. In this example, the bit at the most significant end (the left end) of key word 64 is deleted.
The exclusive OR logic operation generates a binary value 66 which is provided as an encrypted data pulse sequence. This sequence is communicated as an event message (described above) to machine 60 where it is decrypted by combination with a key word 72. Key word 72 is picked off of a key word table 68 (stored in machine 60) which contains the same entries as key word table 58 in the bill validator 50. In addition, key word table 68 includes a pointer 70 which move about the table according to the same algorithm employed to move pointer 62 about key table 58. Thus, the particular key word 64 used to encrypt data pulse sequence 54 is also used (as key word 72) to decrypt the data pulse sequence. To regenerate the original data pulse sequence (decrypted data pulse sequence 74), the encrypted data pulse sequence 66 is combined with key word 72 by an exclusive OR logic operation. As can be seen, the two successive exclusive OR logic operations performed with same key word serve to first encrypt and then regenerate the original data pulse sequence 56. Thus, the bit sequence in decrypted data 74 is identical to the bit sequence in raw data 56.
After decryption, the machine 60 will evaluate decrypted data pulse sequence 74 to determine if its checksum (i.e., the least significant 4 bits) agrees with the remainder of the sequence. If so, the machine 60 also determines whether the denomination code and country code of sequence 74 specifies a bill which should be accepted. If so, the machine 60 will instruct bill validator 50 to accept bill 52.
3. Process Details
A preferred embodiment of the invention will now be described with reference to process flow diagrams in FIGS. 4-9. In the discussion of these diagrams, each process and decision step will be indicated with either a "V" representing an action taken by the bill validator or a "G" representing an action taken by a gaming machine or other machine associated with the bill validator. It should be understood that bill validators of this invention may be employed with gaming machines, vending machines, or any other system that must act on bill validation data.
Referring initially to FIGS. 4A and 4B, the principal steps employed in the process are presented. The process begins at 100 and in a step 102, a bill is inserted into the bill validator. Thereafter, at a process step 106, the bill validator moves the bill into an escrow position within the validator. As explained above, a bill moved into the escrow position is out of reach of a user but, not irretrievably stored in a cash box.
After the bill has been moved into the escrow position, the bill validator "validates" the bill to ensure that it is not counterfeit, etc., at a step 110. Based on the information gathered at step 110, the bill validator decides, at a decision step 112, whether the inserted bill is or is not valid. Assuming that it determines that the bill is not valid--e.g., it is counterfeit--the bill validator returns the bill at a step 114. Thereafter, process control returns to a point before process step 102 where the system awaits insertion of a new bill. Most commercially available bill validators provide some mechanism for validating bills. As noted, such bill validators are available from, for example, Japan Cash Machine Co., LTD, Mars Electronics, Inc., Dixie Narco, Inc., etc.
Assuming that the bill validator determines that the bill is, in fact, valid at step 112, it then generates a denomination code and a country code (the "raw data") at a process step 118. This step will be described in more detail with reference to FIG. 5. Next, the bill validator encrypts the raw data at a step 120, and then communicates that encrypted data to the logic for the gaming machine at a step 122. Thereafter, the gaming machine logic decrypts the data at 126 and determines whether to accept the bill at a decision step 130. The machine logic will decide to reject a bill if its denomination or country code does not meet the machine's requirements. In addition, the machine may decide to reject a bill for other reasons. By way of example, a user may have exceeded a preset maximum credit limit. It should be apparent from the above discussion that the bill validator may determine that a particular bill is valid (at decision step 112) but nevertheless refuse to accept that bill because the machine logic has found it unacceptable (at decision step 130).
Assuming that decision step 130 is answered in the negative, the bill validator returns the bill at process step 114. If, on the other hand, decision step 130 determines that the inserted bill is acceptable, the machine logic acknowledges the bill by sending an appropriate message to the bill validator at a process step 134. The bill validator then irretrievably stacks the bill at a step 136 and communicates the stacking to the game at a step 138. Before concluding the procedure, the bill validator and the game concurrently identify, at a step 140, an encryption key to be used when the next bill is inserted into the bill validator. The process is then concluded at 142. Process step 140 will be described in more detail with reference to FIG. 8 below.
FIG. 5 is a process flow diagram illustrating the principle steps employed in the process of generating raw bill validation data (i.e., step 118 of FIG. 4A). The process begins at 150 and then a process step 152 identifies the country code and denomination code from appropriate tables residing in the system's memory. FIGS. 5A and 5B present exemplary country code and denomination tables. Next, the bill validator builds a data pulse sequence at a step 154 including the country code and denomination code that it identified at step 152. Thereafter, the process is concluded at 156.
This process is further illustrated with reference to FIGS. 5A, 5B, and 2C. Assume that the bill validator determines that the inserted bill is a U.S. fifty dollar bill at step 110 of FIG. 4A. First, the bill validator identifies a country code value for the United States from the table presented in FIG. 5A. As shown there, the United States has a corresponding country code value of 23, or, in binary format, 010111. As explained above and shown in FIG. 2C, the country code is provided in a 6 bit field which has been given the binary value 01011 corresponding to the U.S. country code. The denomination table shown in FIG. 5B is consulted to identify the numeric code value corresponding to a denomination of 50. As shown, the code value for this denomination is 5 which has a corresponding binary representation of 00101. As shown in FIG. 2C, the denomination code is provided in a 5 bit field which, in this example, has been given the binary value of 00101. Finally, as discussed above with reference to FIG. 2C, the data pulse sequence is provided with a checksum which is 1001 (for a complete data pulse sequence of 01011100101001).
After the raw data pulse sequence has been generated at step 118 (FIG. 4A), that sequence is encrypted at step 120 as mentioned above. Further details of the encryption process are now provided with reference to FIG. 6. The process begins at 160, and in a step 162, a key word is obtained from a list of key words. The specific key is identified by the location of a pointer which is recalculated after each new bill is accepted (The recalculation process will be described in more detail below with reference to FIGS. 8 and 9.) As shown in FIG. 6A, the list of keys is provided as a series of 8 bit values (in hexadecimal notation).
After the appropriate key word has been selected at step 162, a process step 164 combines that key word with the data pulse sequence by an exclusive OR logic operation ("XOR"). Specifically, the data sequence and the key word are combined as shown in FIG. 3 and discussed above. The process is then completed at 168.
FIG. 7 details the process of decrypting data sent from the bill validator to another part of the machine (i.e., step 126 of FIG. 4A). The process begins at 170 and then, in a process step 172, a key word is retrieved from a table of key words stored in the machine. As noted in the discussion of FIG. 3, the machine key table entries should be identical to the bill validator key table entries. In addition, the algorithm used to move the pointer among the key words of the machine table should be identical to the algorithm used to move the pointer in the bill validator table. Thus, at any given time, the pointers in both the bill validator and the gaming machine will point to the same key word. Next, in process step 176, the encrypted data pulse sequence is combined with the selected key word by a logical XOR operation (see FIG. 3). This will decrypt the encrypted data pulse sequence and return the original raw data including country code, denomination code, and checksum. The process is then completed at 178. It should be noted, that if the checksum provides an incorrect value, the machine will decide to reject the bill at decision step 130 as shown in FIG. 4A.
In a preferred embodiment, after the machine decides to accept or reject the inserted bill, that decision is communicated to the bill validator in the following manner. If the machine determines that the country code, checksum, etc. are acceptable, it will acknowledge the bill validator's message (i.e., decision step 130 is answered in the affirmative and process step 134 is performed). If on the other hand, the game determines that there is some problem with the data sequence from the bill validator, it will not acknowledge the message. Rather than giving up, the bill validator will then resend the bill validation message. If it is still not acknowledged, it will return the bill to the player as indicated at process step 114.
As noted, it is necessary to move the pointers to a new key word each time a bill has been accepted and irretrievably stacked. This makes decryption difficult for anyone who does not know the protocol for selecting a new key word. FIG. 8 details the process employed to select a new key word after a bill has been accepted (corresponding to process step 140 of FIG. 4B). The process begins at 180, and in process step 184, the pointer to the current key is retrieved. Next, a process step 186 calculates a new "adder" value. This value is then added to the current key pointer location to obtain a new key pointer location at a step 188. This new key pointer location specifies a key word that will be used to encrypt the data pulse sequence for the next bill that is inserted into the bill validator.
After the adder value has been determined at step 188, a step 190 increments the number of bills stacked since synchronization (discussed below). This value is referred to as "NB" herein. If three bills have been stacked since last synchronization, then NB should be equal to 3. Next, a decision step 192 determines whether the number of bills stacked "NB" is greater than a predefined number of bills. If not, the process is concluded at 200. If, on the other hand, NB is greater than this predefined number, then the system is resynchronized such that the new key pointer is set to a defined number (e.g., 1) at a step 194. In addition, at a step 196, the value of NB is reset to 0. Thereafter, the process is concluded at 200. It should be understood that the process of FIG. 8 is performed concurrently on both the machine logic and the bill validator logic. This ensures that the same key word will be used to encrypt and decrypt a given signal.
Many techniques are acceptable for calculating the adder values described above, but, in general, the chosen technique should be difficult to reverse engineer. It is known that algorithms using at least three independent sources of information tend to become unpredictable or chaotic. In the example presented in FIGS. 9A and 9B, three independent sources are employed in the adder calculation algorithm. These are (1) the raw validation data (country and denomination codes), (2) the encryption key, and (3) NB (i.e., the number of bills accepted since the last synchronization).
FIGS. 9A and 9B detail a preferred embodiment for calculating the adder value (step 186 of FIG. 8). In the embodiment described here, the adder value takes the form of an eight bit value. The process begins at 210, and in a process step 212, the raw binary value of the decrypted data pulse is retrieved. Thereafter, at a step 214, bit 0 (the least significant bit) of the raw data pulse is set equal to a value A. Next, the value of A is provided as bit 0 of the adder at a step 216. To obtain the next bit of the adder (bit 1), the current binary value of NB is retrieved at a step 220. From this binary value, bit 0 is isolated and set to the value B at a step 222. The value of B is then provided as bit 1 of the adder at a step 224. Next, bit number 2 of the encrypted data pulse is isolated and designated as C at a step 228. Then, at a step 230, bit 2 of the adder is set to the value of C. Thereafter, at a step 232, bit number 3 of the encrypted data pulse is isolated and designated as D. Then, bit 3 of the adder is given the value of D at a step 236. Finally, bits 4-7 of the adder are said equal to 0 at a step 238 and the process is concluded at 240.
Bill Validation Protocol
The following example illustrates a specific implementation of this invention's protocol for sending and receiving event report messages in a bill transaction. This example describes a two way pulsed based communication protocol, with handshaking, employing the following two physical communication paths: (1) an "Enable/Disable" signal which is the input to a triac which switches an AC signal, during zero crossings, from the machine to the bill validator, and (2) a Vend/Status signal which is a DC signal from the bill validator to the machine.
In general, the communication protocol consists of a series of messages involving handshaking for verification of receipt of messages. There are three message types used in this example: (1) event reports sent from the validator to the machine and to convey either a bill transaction or validator status, (2) toggling sent from the machine to the validator to indicate that the machine has verified receipt of the event report, and (3) stacked messages sent from the validator to the machine once the bill has been "irretrievably" stacked. In the case of a bill transaction, toggling specifically indicates that the machine wishes to accept the bill for credit and informs the validator to stack the bill.
Referring now to FIG. 10, the machine initially asserts an Enable/Disable signal, at time (A), to enable the bill validator. Thereafter, a bank note is inserted into the bill validator. The note is validated, and the bill validator initiates the bill transaction by sending the event report message on the Vend/Status signal to the machine at time (B). The message consists of a sequence of pulses in the following format, a start pulse sequence followed by a data pulse sequence followed by a single stop pulse. The data pulse sequence represents a bit coded country and denomination value to convert the bill's value into the correct number of credits.
The machine negates the Enable/Disable signal within 10 milliseconds of the first transaction of the start sequence, at time (C), thereby disabling the bill validator from further bill transactions until the current transaction has been completed. Upon completion of the event report message, the bill validator asserts the Vend/Status signal, at time (D). This signals the end of the event report message. The machine will then verify the message by decrypting, and calculating a 4 bit 1's complement checksum of the 11 bits making up the country and denomination codes and compare with the decrypted 4 bit checksum received from the bill validator.
If the checksums do not match, the message is declared to be invalid and the machine will not acknowledge receipt of this message. The validator must then wait a minimum of 200 milliseconds before attempting to resend the message. The total number of attempts, including the initial attempt, is three. After three unsuccessful tries, the validator will return the bill to the user. On the third attempt to send the message, the validator will use an encryption key which allows the machine and validator validator to resynchronize. Resynchronization forces the pointers on the key tables of the machine and bill validator to a common prespecified value, e.g. 7.
If the checksums do match, the machine will determine if it is allowed to accept this particular bill by using the country and denomination codes contained within the message. If any one of the codes does not match those of the approved values, as determined by the machine, the message will be declared invalid and no acknowledgment will be sent. If the codes are valid, the machine will acknowledge receipt of the event report message by toggling the Enable/Disable signal at time (E). The toggling takes the form of a 40 millisecond ±5 millisecond, period pulse sequence with a 50 percent duty cycle and must begin within 200 milliseconds from the completion of the bill acceptance message. Note that the toggling specification is for the timing of the input to a triac, which changes state at the zero crossing of the AC signal.
The bill validator will now validate the toggling in a two step process. First, the validator must detect at least three logical transitions in the toggling message. Second, the toggling must begin within 200 milliseconds from the completion of the bill acceptance message, as mentioned above. If either of these conditions are not met, the validator resends the bill message up to three times as described above.
If the bill validator can validate the machine toggling, it will transfer the note to the stacker and into the cash box. When the note is transferred to the stacker, at time (F), the bill validator will send a stacked sequence. This consists of a 10 millisecond, ±1 millisecond, low pulse, a 10 millisecond, ±1 millisecond, high pulse, and another 10 millisecond, ±1 millisecond, low pulse.
If the bill validator does not send the stacked sequence within 8 seconds from the first transition of the toggle, the machine will cease toggling. When the bill validator sends the stacked sequence within the specified time limit, the machine will validate the message by detecting the two logical transitions on the Vend/Status signal. The presence of these transitions is enough to declare the message to be valid. The machine will cease toggling within 6 milliseconds of detecting a valid stacked sequence, at time (G), and will begin crediting the user for the note. The bill validator must not initiate another bill transaction until the current transaction is complete and the machine has reasserted the Enable/Disable signal. Only after the proper amount of credit is given, at time (H), does the machine assert the Enable/Disable signal, thereby reenabling the bill validator for the next bill transaction.
The handshaking protocol employed in this example assures that noise or other types of interference cannot substitute for valid messages. The machine ensures that the bill is completely transferred to the stacker and cannot be retrieved by the user before crediting the user for the note. In addition, the machine will completely credit the note before re-enabling the validator for the next bill transaction.
The following example presents an encryption scheme employing a key table which is identical in both the bill validator, and the machine. A key word is XORed with the data pulse sequence and the result is the encrypted data pulse sequence which is sent over the Vend/Status signal. The data is decrypted by calculating the same key word and XORing it with the encrypted data pulse sequence. The result is the original data pulse sequence. The encryption/decryption rules for this example are as follows:
The status message will always use a key word of 0000H. That is the same as not encrypting or decrypting status messages. In some cases, it may desirable to encrypt status messages. If so, an encryption/decryption key word will be selected by an algorithm such as the following.
The key table will be 16 bytes long, and will be identical in the bill validator and the machine. The key is found by using a pointer value to point to a location in the key table. The two bytes at the pointer value are the most significant byte and the least significant byte of the key word, respectively. The pointer value is incremented by an eight bit adder value "X" after each irretrievably stacked pulse. X is derived from the data pulse sequence associated with the stacked message by the following algorithm (corresponding to FIGS. 9A and 9B):
X.0=Decrypted Data Pulse Bit 0
X.1=NB Bit 0; NB is the Binary Value of the Number of Bills Stacked since the Pointers were Synchronized
X.2=Encrypted Data Pulse Bit 2
X.3=Encrypted Data Pulse Bit 3
The following points apply in the encryption algorithm.
1. The number of bills stacked since the pointers were synchronized (NB) is kept independently by the bill validator and the machine.
2. The pointer is synchronized to 1 on power up. The pointer value is synchronized to 0 if the value of NB=20, and NB gets reset on any synchronization. The key table must be developed such that any encrypted country code is not 0 (this is reserved for status messages).
3. The key table must be developed such that the country code will always be incorrect if decrypted with an incorrect key.
Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. For instance, although the specification has described currency in the form of bills, other currency forms may be used as well. For example, coins may also be used. In addition, the reader will understand that the encryption protocol described herein can be used in systems other than bill validators. For example, the protocol here taught may be used with credit and debit card validators and their equivalent within the electronic fund transfer arts.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US2731621 *||Apr 1, 1952||Jan 17, 1956||C G S Lab Inc||Counterfeit detector|
|US3509535 *||Jun 9, 1966||Apr 28, 1970||Arcs Ind Inc||Ferromagnetic recognizer of documents|
|US3782543 *||Oct 12, 1972||Jan 1, 1974||Martelli M||Document recognition systems|
|US3990558 *||Oct 7, 1974||Nov 9, 1976||Gretag Aktiengesellschaft||Method and apparatus for preparing and assessing payment documents|
|US4074079 *||Jun 2, 1976||Feb 14, 1978||Bell Telephone Laboratories, Incorporated||Coin telephone antifraud system|
|US4183085 *||Oct 21, 1977||Jan 8, 1980||International Business Machines Corporation||Protection of data processing system against unauthorized programs|
|US4281215 *||May 3, 1978||Jul 28, 1981||Atalla Technovations||Method and apparatus for securing data transmissions|
|US4315101 *||Oct 9, 1979||Feb 9, 1982||Atalla Technovations||Method and apparatus for securing data transmissions|
|US4467139 *||Mar 12, 1981||Aug 21, 1984||Compagnie Internationale Pour L'informatique Cii Honeywell Bull||Process and system for transmission of signed messages|
|US4504052 *||Jun 16, 1982||Mar 12, 1985||Ardac, Inc.||Note receptacle for currency validator|
|US4556140 *||Aug 8, 1983||Dec 3, 1985||Kabushiki Kaisha Universal||Method and apparatus for discriminating coins or bank notes|
|US4649266 *||Mar 12, 1984||Mar 10, 1987||Pitney Bowes Inc.||Method and apparatus for verifying postage|
|US4853962 *||Dec 7, 1987||Aug 1, 1989||Universal Computer Consulting, Inc.||Encryption system|
|US5014325 *||Sep 30, 1985||May 7, 1991||Nihon Eiwan Denshikiki Co., Ltd.||Apparatus for discriminating specified sorts of printed matters|
|US5076441 *||Jan 9, 1990||Dec 31, 1991||Landis & Gyr Betriebs Ag||Device for the acceptance and delivery of banknotes and process for its operation|
|US5096038 *||Aug 13, 1990||Mar 17, 1992||De La Rue Systems Limited||Thread detector assembly|
|US5197094 *||Jun 15, 1990||Mar 23, 1993||Arachnid, Inc.||System for remotely crediting and billing usage of electronic entertainment machines|
|US5236072 *||Nov 20, 1990||Aug 17, 1993||Technitrol, Inc.||Document size detection device|
|US5311595 *||Jun 7, 1990||May 10, 1994||Kommunedata I/S||Method of transferring data, between computer systems using electronic cards|
|US5317636 *||Dec 9, 1992||May 31, 1994||Arris, Inc.||Method and apparatus for securing credit card transactions|
|US5325434 *||Oct 23, 1992||Jun 28, 1994||Koninklijke Ptt Nederland N.V.||Method for authenticating communications participants, system for application of the method and first communications participant and second communication participant for application in the system|
|US5343529 *||Sep 28, 1993||Aug 30, 1994||Milton Goldfine||Transaction authentication using a centrally generated transaction identifier|
|US5363448 *||Jun 30, 1993||Nov 8, 1994||United Technologies Automotive, Inc.||Pseudorandom number generation and cryptographic authentication|
|US5379344 *||Apr 26, 1991||Jan 3, 1995||Scandic International Pty. Ltd.||Smart card validation device and method|
|US5416307 *||Sep 3, 1993||May 16, 1995||Danek; Robert||Currency paper verification and denomination device|
|US5417316 *||Mar 18, 1993||May 23, 1995||Authentication Technologies, Inc.||Capacitive verification device for a security thread embedded within currency paper|
|US5429361 *||Sep 23, 1991||Jul 4, 1995||Bally Gaming International, Inc.||Gaming machine information, communication and display system|
|US5451759 *||Jun 21, 1994||Sep 19, 1995||Nhk Spring Co., Ltd.||Using high-permeability magnetic elements randomly scattered in the objects|
|US5473147 *||Oct 19, 1993||Dec 5, 1995||Nhk Spring Co., Ltd.||Method and an apparatus for checking objects to be checked for authenticity|
|US5555304 *||Nov 18, 1994||Sep 10, 1996||Fujitsu Limited||Storage medium for preventing an illegal use by a third party|
|US5615760 *||Aug 9, 1995||Apr 1, 1997||Mars Incorporated||Method and apparatus for validating money|
|US5635696 *||Jun 22, 1993||Jun 3, 1997||Dabrowski; Stanley P.||Currency acceptor with magnetic card reader|
|US5640463 *||Oct 4, 1994||Jun 17, 1997||Cummins-Allison Corp.||Method and apparatus for authenticating documents including currency|
|US5662201 *||Oct 23, 1995||Sep 2, 1997||Mars Incorporated||Banknote reader|
|US5662202 *||Nov 24, 1995||Sep 2, 1997||Ardac Incorporated||Currency validator with cassette cash box|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US5947255 *||Apr 15, 1997||Sep 7, 1999||Glory Kogyo Kabushiki Kaisha||Method of discriminating paper notes|
|US6264561||Oct 1, 1998||Jul 24, 2001||International Game Technology||Electronic game licensing apparatus and method|
|US6620047||Sep 29, 2000||Sep 16, 2003||Igt||Electronic gaming apparatus having authentication data sets|
|US6729957||Apr 10, 2002||May 4, 2004||Mgm Grand, Inc.||Gaming method and host computer with ticket-in/ticket-out capability|
|US6729958||Apr 10, 2002||May 4, 2004||Mgm Grand, Inc.||Gaming system with ticket-in/ticket-out capability|
|US6736725||Apr 10, 2002||May 18, 2004||Mgm Grand, Inc.||Gaming method and host computer with ticket-in/ticket-out capability|
|US6745887||Feb 20, 2002||Jun 8, 2004||Jcm American Corporation||Gaming table validator assembly|
|US6746330||Dec 19, 2002||Jun 8, 2004||Igt||Method and device for implementing a coinless gaming environment|
|US6934844||Dec 19, 2001||Aug 23, 2005||Mars Incorporated||Secure communications for a currency handling machine|
|US6935953||Jan 28, 2003||Aug 30, 2005||Adrian R. Marcu||Method and apparatus for encoding vouchers in a casino gaming system|
|US6968787||Jun 7, 2004||Nov 29, 2005||Jcm American Corporation||Gaming table validator assembly|
|US7043641||Mar 8, 2000||May 9, 2006||Igt||Encryption in a secure computerized gaming system|
|US7063615||Jun 23, 2003||Jun 20, 2006||Igt||Electronic gaming apparatus with authentication|
|US7116782||Sep 7, 2001||Oct 3, 2006||Igt||Encryption in a secure computerized gaming system|
|US7128650||Sep 12, 2001||Oct 31, 2006||Igt||Gaming machine with promotional item dispenser|
|US7162036||Aug 6, 2001||Jan 9, 2007||Igt||Digital identification of unique game characteristics|
|US7203841||Mar 8, 2001||Apr 10, 2007||Igt||Encryption in a secure computerized gaming system|
|US7267612||Nov 12, 2002||Sep 11, 2007||Igt||Gaming apparatus with portrait-mode display|
|US7329187||Aug 6, 2001||Feb 12, 2008||Oneida Indian Nation||Cashless computerized video game system and method|
|US7406602||Jun 26, 2002||Jul 29, 2008||Paul Gauselmann||Authentication of data for a gaming machine|
|US7491122||Jul 9, 2003||Feb 17, 2009||Wms Gaming Inc.||Gaming machine having targeted run-time software authentication|
|US7491125||Mar 24, 2006||Feb 17, 2009||Jcm American Corporation||Chip tray loading device and process|
|US7520811||Mar 1, 2007||Apr 21, 2009||Igt||Method and apparatus for software authentication|
|US7581256||Oct 6, 2003||Aug 25, 2009||Igt||Process verification|
|US7684607 *||Mar 23, 2010||Council Of Scientific & Industrial Research||Fake currency detector using visual and reflective spectral response|
|US7758420||Jul 20, 2010||Igt||Gaming machine with promotional item dispenser|
|US7783040||Sep 20, 2006||Aug 24, 2010||Igt||Encryption in a secure computerized gaming system|
|US7794323||Jul 25, 2003||Sep 14, 2010||Igt||Gaming apparatus with encryption and method|
|US7831047||Jul 14, 2006||Nov 9, 2010||Igt||Digital identification of unique game characteristics|
|US7837556||May 2, 2005||Nov 23, 2010||Igt||Decoupling of the graphical presentation of a game from the presentation logic|
|US7867084||Dec 22, 2006||Jan 11, 2011||Igt||Pass-through live validation device and method|
|US7921978 *||Sep 7, 2005||Apr 12, 2011||Kabushiki Kaisha Toshiba||Processing data transfer method in sheet processing apparatus|
|US7931533||Apr 26, 2011||Igt||Game development architecture that decouples the game logic from the graphics logics|
|US7963843||Jun 21, 2011||Oneida Indian Nation||Cashless gaming system and method with monitoring|
|US7967682||Jun 28, 2011||Bally Gaming, Inc.||Wireless gaming environment|
|US7988554||Aug 2, 2011||Igt||Game development architecture that decouples the game logic from the graphics logic|
|US7988559||Mar 8, 2001||Aug 2, 2011||Igt||Computerized gaming system, method and apparatus|
|US7996916||Aug 9, 2011||Igt||Process verification|
|US8033902||Oct 11, 2011||Wells William R||Wide screen gaming apparatus|
|US8038530||Oct 18, 2011||Wms Gaming Inc.||Method and apparatus for filtering wagering game content|
|US8052519||Jun 30, 2006||Nov 8, 2011||Bally Gaming, Inc.||Systems, methods and articles to facilitate lockout of selectable odds/advantage in playing card games|
|US8100245 *||Oct 24, 2006||Jan 24, 2012||Glory Ltd.||Bill recognizing and counting apparatus|
|US8131829||Nov 12, 2008||Mar 6, 2012||Bally Gaming, Inc.||Gaming machine collection and management|
|US8191121||May 29, 2012||Bally Gaming, Inc.||Methods and systems for controlling access to resources in a gaming network|
|US8192283||Jun 5, 2012||Bally Gaming, Inc.||Networked gaming system including a live floor view module|
|US8195825||Jan 21, 2010||Jun 5, 2012||Bally Gaming, Inc.||UDP broadcast for user interface in a download and configuration gaming method|
|US8195826||Jan 21, 2010||Jun 5, 2012||Bally Gaming, Inc.||UDP broadcast for user interface in a download and configuration gaming method|
|US8201229||Jun 12, 2012||Bally Gaming, Inc.||User authorization system and methods|
|US8251807||Aug 28, 2012||Igt||Game development architecture that decouples the game logic from the graphics logic|
|US8266213||Sep 11, 2012||Bally Gaming, Inc.||Apparatus, method, and system to provide a multiple processor architecture for server-based gaming|
|US8275848||Sep 25, 2012||Bally Gaming, Inc.||System and method for one-way delivery of notifications from server-to-clients using modified multicasts|
|US8347280||Jan 1, 2013||Bally Gaming, Inc.||System and method for validating download or configuration assignment for an EGM or EGM collection|
|US8347303||Nov 14, 2008||Jan 1, 2013||Bally Gaming, Inc.||Apparatus, method, and system to provide a multi-core processor for an electronic gaming machine (EGM)|
|US8366109||Feb 5, 2013||Bally Gaming, Inc.||System and method to handle playing cards, employing elevator mechanism|
|US8366542||Feb 5, 2013||Bally Gaming, Inc.||Networked gaming system with enterprise accounting methods and apparatus|
|US8382584||Feb 26, 2013||Bally Gaming, Inc.||Networked gaming system with enterprise accounting methods and apparatus|
|US8408551||Aug 2, 2012||Apr 2, 2013||Bally Gaming, Inc.||System and method to handle playing cards, employing elevator mechanism|
|US8412768||Apr 2, 2013||Ball Gaming, Inc.||Integration gateway|
|US8423790||Nov 17, 2009||Apr 16, 2013||Bally Gaming, Inc.||Module validation|
|US8469172||Feb 24, 2011||Jun 25, 2013||Kabushiki Kaisha Tosiba||Processing data transfer method in sheet processing|
|US8478833||Apr 30, 2008||Jul 2, 2013||Bally Gaming, Inc.||UDP broadcast for user interface in a download and configuration gaming system|
|US8597107||Dec 28, 2007||Dec 3, 2013||Bally Gaming, Inc.||Systems, methods, and devices for providing purchases of instances of game play at a hybrid ticket/currency game machine|
|US8627097||Mar 27, 2012||Jan 7, 2014||Igt||System and method enabling parallel processing of hash functions using authentication checkpoint hashes|
|US8631501||Nov 9, 2007||Jan 14, 2014||Bally Gaming, Inc.||Reporting function in gaming system environment|
|US8667457||Nov 30, 2012||Mar 4, 2014||Bally Gaming, Inc.||System and method for validating download or configuration assignment for an EGM or EGM collection|
|US8705739||Aug 15, 2006||Apr 22, 2014||Wms Gaming Inc.||On-the-fly encryption on a gaming machine|
|US8708828||Dec 28, 2007||Apr 29, 2014||Igt||Pluggable modular gaming modifiers and configuration templates for gaming environments|
|US8721431||Apr 30, 2008||May 13, 2014||Bally Gaming, Inc.||Systems, methods, and devices for providing instances of a secondary game|
|US8784212||Nov 9, 2007||Jul 22, 2014||Bally Gaming, Inc.||Networked gaming environment employing different classes of gaming machines|
|US8812709||Aug 29, 2012||Aug 19, 2014||Bally Gaming, Inc.||UDP broadcast for a user interface in a download and configuration gaming method|
|US8819124||Sep 4, 2012||Aug 26, 2014||Bally Gaming, Inc.||System and method for one-way delivery of notifications from server-to-clients using modified multicasts|
|US8834254||Sep 6, 2012||Sep 16, 2014||Wms Gaming, Inc.||Account-based-wagering mobile controller|
|US8851988||Aug 15, 2012||Oct 7, 2014||Bally Gaming, Inc.||Apparatus, method, and system to provide a multiple processor architecture for server-based gaming|
|US8870647||Apr 12, 2007||Oct 28, 2014||Bally Gaming, Inc.||Wireless gaming environment|
|US8876594||Aug 3, 2007||Nov 4, 2014||Oneida Indian Nation||Cashless computerized video game system and method|
|US8920233||Nov 12, 2008||Dec 30, 2014||Bally Gaming, Inc.||Assignment template and assignment bundle in a gaming configuration and download system|
|US8930461||Nov 12, 2008||Jan 6, 2015||Bally Gaming, Inc.||Download and configuration management engine for gaming system|
|US8966278||Dec 24, 2013||Feb 24, 2015||Igt||System and method enabling parallel processing of hash functions using authentication checkpoint hashes|
|US9017157||Aug 10, 2011||Apr 28, 2015||Igt||Wide screen gaming apparatus|
|US9076281||Aug 31, 2007||Jul 7, 2015||Oneida Indian Nation||Cashless gaming system and method with monitoring|
|US9082258||Nov 12, 2008||Jul 14, 2015||Bally Gaming, Inc.||Method and system for providing download and configuration job progress tracking and display via host user interface|
|US9111078||Nov 9, 2007||Aug 18, 2015||Bally Gaming, Inc.||Package manager service in gaming system|
|US9120007||Jan 18, 2012||Sep 1, 2015||Bally Gaming, Inc.||Network gaming architecture, gaming systems, and related methods|
|US9275512||Nov 9, 2007||Mar 1, 2016||Bally Gaming, Inc.||Secure communications in gaming system|
|US20020049909 *||Sep 7, 2001||Apr 25, 2002||Shuffle Master||Encryption in a secure computerized gaming system|
|US20020091648 *||Dec 19, 2001||Jul 11, 2002||Phillips Carl Alexander||Secure communications for a currency handling machine|
|US20030008704 *||Jun 26, 2002||Jan 9, 2003||Paul Gauselmann||Encryption of data for a gaming machine|
|US20030033538 *||Aug 13, 2002||Feb 13, 2003||Masahiro Shishikura||Bank note evaluation apparatus and bank note evaluation result data processing method|
|US20030064784 *||Sep 28, 2001||Apr 3, 2003||William Wells||Wide screen gaming apparatus|
|US20030069070 *||Nov 12, 2002||Apr 10, 2003||Alcorn Allan E.||Gaming apparatus with portrait-mode display|
|US20030069074 *||Sep 10, 2002||Apr 10, 2003||Shuffle Master, Inc.||Method for developing gaming programs compatible with a computerized gaming operating system and apparatus|
|US20030078103 *||Jan 3, 2002||Apr 24, 2003||Igt||Game development architecture that decouples the game logic from the graphics logic|
|US20030203755 *||Apr 25, 2002||Oct 30, 2003||Shuffle Master, Inc.||Encryption in a secure computerized gaming system|
|US20030224858 *||Mar 8, 2001||Dec 4, 2003||Yoseloff Mark L.||Computerized gaming system, method and apparatus|
|US20040002381 *||Jun 23, 2003||Jan 1, 2004||Igt||Electronic gaming apparatus with authentication|
|US20040068654 *||Oct 6, 2003||Apr 8, 2004||Igt||Process verification|
|US20040198479 *||Apr 19, 2004||Oct 7, 2004||Igt||Computerized gaming system, method and apparatus|
|US20040204231 *||Mar 28, 2003||Oct 14, 2004||Martin Richard L.||Cashless gaming system and method with monitoring|
|US20040206601 *||May 5, 2004||Oct 21, 2004||Raymond Heidel||Note acceptor-dispenser validator|
|US20040219974 *||Jun 7, 2004||Nov 4, 2004||Cannon Lee E.||Method and device for implementing a coinless gaming environment|
|US20040222061 *||Jun 7, 2004||Nov 11, 2004||Raymond Heidel||Gaming table validator assembly|
|US20040249501 *||Mar 30, 2004||Dec 9, 2004||Hand Peter E.||Enhanced bill acceptor/dispenser for vending machines|
|US20050009599 *||Jul 9, 2003||Jan 13, 2005||Ryan Chad A.||Gaming machine having targeted run-time software authentication|
|US20050020356 *||Jul 25, 2003||Jan 27, 2005||Cannon Lee E.||Gaming apparatus with encryption and method|
|US20050040006 *||Sep 14, 2004||Feb 24, 2005||Prashanth Kodela||Table game validation and event audit system|
|US20050126880 *||Oct 4, 2004||Jun 16, 2005||Iannello Richard J.||Counter/tabletop alignment note feeder|
|US20050126881 *||Oct 4, 2004||Jun 16, 2005||Iannello Richard J.||Counter/tabletop alignment note feeder with plunger|
|US20050148386 *||Feb 10, 2005||Jul 7, 2005||Burns James G.||Gaming system with reader and code printer|
|US20050192092 *||May 2, 2005||Sep 1, 2005||Igt||Decoupling of the graphical presentation of a game from the presentation logic|
|US20050212203 *||Mar 25, 2005||Sep 29, 2005||Deraedt Peter W||Note validating and storage assembly and method|
|US20050284728 *||Apr 25, 2005||Dec 29, 2005||Joshua Corrick||Vending machine having direct data link to cash dispenser|
|US20060115139 *||Nov 4, 2005||Jun 1, 2006||Council Of Scientific & Industrial Research||Fake currency detector using visual and reflective spectral response|
|US20060157317 *||Sep 7, 2005||Jul 20, 2006||Kabushiki Kaisha Toshiba||Processing data transfer method in sheet processing apparatus|
|US20060160598 *||Mar 16, 2006||Jul 20, 2006||Igt||Wide screen gaming apparatus|
|US20060283934 *||Jun 28, 2006||Dec 21, 2006||Deraedt Peter W||Note validating and storage assembly and method|
|US20070015590 *||Sep 20, 2006||Jan 18, 2007||Igt||Encryption in a secure computerized gaming system|
|US20070023500 *||Jul 11, 2006||Feb 1, 2007||Deraedt Peter W||Note validating and storage assembly and method|
|US20070049373 *||Oct 25, 2006||Mar 1, 2007||Igt||Gaming machine with promotional item dispenser|
|US20070060313 *||Mar 24, 2006||Mar 15, 2007||Jcm American Corporation||Chip tray loading device and process|
|US20070135216 *||Dec 22, 2006||Jun 14, 2007||Igt||Pass-through live validation device and method|
|US20070149280 *||Mar 1, 2007||Jun 28, 2007||Igt||Method and Apparatus for Software Authentication|
|US20070265099 *||Jul 17, 2007||Nov 15, 2007||Cole Joseph W||Gaming apparatus having wide screen display|
|US20070296793 *||Nov 29, 2006||Dec 27, 2007||Yugen-Kaisya Noa||Checker for print paper sheets|
|US20080026823 *||Jul 10, 2006||Jan 31, 2008||Igt||Reusable cashless instruments for gaming machines and systems|
|US20080058097 *||Oct 31, 2007||Mar 6, 2008||Igt||Computerized gaming system, method and apparatus|
|US20080287197 *||Apr 30, 2008||Nov 20, 2008||Bally Gaming, Inc.||Udp brodcast for user interface in a download and configuration gaming system|
|US20090124392 *||Nov 12, 2008||May 14, 2009||Bally Gaming, Inc.||Download and configuration management engine for gaming system|
|US20090124394 *||Nov 12, 2008||May 14, 2009||Bally Gaming, Inc.||System and method for validating download or configuration assignment for an egm or egm collection|
|US20090125603 *||Nov 12, 2008||May 14, 2009||Bally Gaming, Inc.||System and method for one-way delivery of notifications from server-to-clients using modified multicasts|
|US20090132720 *||Nov 12, 2008||May 21, 2009||Bally Gaming, Inc.||Method and system for providing download and configuration job progress tracking and display via host user interface|
|US20090220078 *||Aug 15, 2006||Sep 3, 2009||Campbell Steven M||On-the-fly encryption on a gaming machine|
|US20090275393 *||Apr 30, 2008||Nov 5, 2009||Bally Gaming, Inc.||Systems, methods, and devices for providing instances of a secondary game|
|US20090275400 *||Apr 30, 2008||Nov 5, 2009||Bally Gaming, Inc.||Multiple denomination progressive jackpots|
|US20090282489 *||Nov 12, 2009||Igt||Process verification|
|US20100124990 *||Nov 14, 2008||May 20, 2010||Bally Gaming, Inc.||Apparatus, method, and system to provide a multiple processor architecture for server-based gaming|
|US20100151926 *||Jan 21, 2010||Jun 17, 2010||Bally Gaming, Inc.||Udp broadcast for user interface in a download and configuration gaming method|
|US20100161798 *||Jan 21, 2010||Jun 24, 2010||Bally Gaming, Inc.||Udp broadcast for user interface in a download and configuration gaming method|
|US20110004336 *||Oct 24, 2006||Jan 6, 2011||Glory Ltd.||Bill recognizing and counting apparatus|
|US20110154463 *||Jun 23, 2011||Kabushiki Kaisha Toshiba||Processing data transfer method in sheet processing apparatus|
|US20110177867 *||Jul 21, 2011||Igt||Computerized gaming system, method and apparatus|
|US20110179409 *||Jul 21, 2011||Igt||Computerized gaming system, method and apparatus|
|USRE39368||Jun 17, 1996||Oct 31, 2006||Igt||Electronic casino gaming system with improved play capacity, authentication and security|
|USRE39369||Jun 17, 1996||Oct 31, 2006||Igt||Electronic casino gaming system with improved play capacity, authentication and security|
|USRE39370||Jun 17, 1996||Oct 31, 2006||Igt||Electronic casino gaming system with improved play capacity, authentication and security|
|USRE39400||Jun 17, 1996||Nov 14, 2006||Igt||Electronic casino gaming system with improved play capacity, authentication and security|
|USRE39401||Jun 17, 1996||Nov 14, 2006||Igt||Electronic casino gaming system with improved play capacity, authentication and security|
|EP1274050A2 *||Jun 19, 2002||Jan 8, 2003||adp Gauselmann GmbH||Method for enciphering data, which is sent from a peripheral module to a control unit of a coin-feed apparatus|
|EP1286314A2 *||Aug 9, 2002||Feb 26, 2003||Kabushiki Kaisha Toshiba||Bank note evaluation apparatus and bank note evaluation result data processing method|
|WO2002052513A1 *||Dec 18, 2001||Jul 4, 2002||Mars Incorporated||Secure communications for a currency handling machine|
|WO2007062189A2 *||Nov 22, 2006||May 31, 2007||Wms Gaming Inc.||Wagering game device with secure storage device|
|U.S. Classification||713/176, 194/205, 463/25, 194/207, 340/5.4, 380/251, 340/5.9, 194/210, 194/212, 194/213, 382/135, 194/206, 194/211|
|Sep 28, 2001||FPAY||Fee payment|
Year of fee payment: 4
|Feb 10, 2003||AS||Assignment|
Owner name: IGT, NEVADA
Free format text: CHANGE OF NAME;ASSIGNOR:INTERNATIONAL GAME TECHNOLOGY;REEL/FRAME:013728/0785
Effective date: 20021014
|Sep 27, 2005||FPAY||Fee payment|
Year of fee payment: 8
|Oct 7, 2009||FPAY||Fee payment|
Year of fee payment: 12