Patent Application
20130296034
The invention relates to identification devices and more particularly to radio frequency identification devices and methods for detecting and monitoring access of an identification device.
RFID (Radio Frequency Identification) type tags have become a popular way to monitor and track items. RFID tags have found use in stores, to track merchandise, and warehouses, to track product. Casinos often utilize RFID technology within tokens to monitor game play. RFID technology provides for rapid access, without a wired connection, to data on the RFID tag.
Although RFID technology has numerous uses, one such example environment is in connection with gambling. Gambling has become a popular form of entertainment in the United States and in numerous foreign countries. Numerous wagering events are offered within the casino or other gaming environment, one of the most traditional and popular forms of wagering occurs at table games. As is widely understood, traditional table games utilize a playing surface, often called a felt, upon which a dealer or other game operator offers a wagering event to one or more players or upon which a player may make a bet or wager.
As compared to slot or video type games, traditional table games offer greater excitement for some players, group play, and often attract big money players, which can result in larger profit margins for the casino. Prior art systems make use of gaming tokens embedded with Radio Frequency Identification (“RFID”) to track a player's betting for this purpose. An example of such a system is the Mikohn® Gaming Corporation's d/b/a Progressive Gaming International Corporation's Tablelink® product.
However, even with prior art bet tracking techniques, numerous opportunities for player manipulation of token RFID information may be missed or unmonitored. To prevent such cheating, a myriad of human game protection elements may be employed in a casino to monitor table games. The monitors comprise of pit bosses, dealers, video surveillance personal, security guards, and the like. However, these individuals cannot monitor every bet, and are an expensive option for a casino.
Current tokens including RFID information have limited capability and hence may be at risk of being compromised. These security limitations have inhibited progress in the expansion of RFID capability and the amount or type of information embedded therein.
The method and apparatus described below overcomes these drawbacks and provides additional benefits.
In one embodiment of the invention, a DID gaming token comprises, in combination a communication device configured to receive power and data from at least one reader and a power converter device configured to provide power to a processor including read-write logic and counter logic of the DID gaming token. The processor is configured to receive data from the communication device and communicate with a memory of the DID gaming device. The counter logic of the DID token is configured to selectively increment a portion of the memory to indicate when the DID gaming token has been accessed by at least one reader. The memory is to configured to be written to by the read-write logic within the DID, and the memory is configured to be read-only when accessed by an external system.
In another embodiment of the invention, a method for detecting and monitoring access of a DID is disclosed. The method comprises the step of providing a DID including a communication device configured to receive transmission from at least one reader, a power converter device, memory, and a processor including read-write logic and counter logic. The method further comprises the steps of powering the power converting device with at least one reader and accessing the DID with at least one reader. The method further comprises the step of selectively incrementing a portion of memory with the counter logic to indicate when the DID has been accessed by at least one reader.
In one variation, the invention comprises a system for tracking access of a game token. The game token has a token identification element comprising one or more token memories configured to store at least one type of token data and at least one counter value. The game token also has a counter configured to modify the counter value each time the token data is read. The system further comprises one or more authorized readers that are configured to read the token data from the token during play of a wagering game and communicate the token data to a computer to enable the computer to track use of the game token during play of a game.
In another embodiment, the system may further comprise a processor in communication with one or more authorized readers, and memory associated with the processor, such that the memory stores processor executable machine readable code configured to maintain and modify a reader access value. The reader access value represents the number of times the game token has been read by an authorized reader. The system may have one or more authorized readers or a counter value reader that is configured to read the counter value from the game token. Additionally, the system may have processor executable machine readable code that is configured to compare the counter value stored on the game token to the reader access value.
In another variation, the processor executable machine readable code is configured to generate an alert in response to the comparison of the counter value stored on the game token to the reader access value. Additionally, the system may have a token identification element that further comprises a token identification element processor configured to execute machine executable code. The machine executable code performs the modification to the counter value and the modification may comprise an incremental value.
It is further contemplated that the invention may comprise a game token having a counter system. The game token comprises a housing and a token identification element at least partially contained within the housing. The token identification element may include one or more antenna configured to receive and transmit a signal, a processor or control logic configured to perform memory read operations and to generate a control signal in response to a memory read operation. Also part of the identification element is a memory configured to store token data and a read attempt value, and a counter, which is configured to be responsive to the control signal. The counter may be configured to modify a read attempt value to maintain the read attempt value within the token such that the read attempt value represents the number of read attempts of the memory. The game token may further comprise token data representing one or more of the following: token value, token serial number, read attempt value.
In another variation, the memory is further configured to store a successful read value representing a number of successful reads of the memory. In addition, modifying a read attempt value may further comprise retrieving the read attempt value from memory, incrementing the read attempt value with the counter to create an incremented read attempt value, and writing the incremented read attempt value to the memory. The read attempt value may represent the actual number of times token data was read from memory. The game token may also contain token data that comprises any type data stored in the token.
It is further contemplated that the game token may additionally include a reader system comprising one or more authorized readers configured to energize the token identification element. Also part of the reader system is memory configured to store machine readable code and one or more processors configured to execute the machine readable code. The machine readable code may be configured to maintain a token read value external to the game token representing the number of times the token identification element was read.
Also disclosed herein is a method for tracking read attempts of a readable memory in a game token. The method comprises generating a read signal to energize a token identification element in an attempt to read data from the readable memory. The method further comprises energizing the token identification element to attempt reading data from the readable memory. In response to attempting to read data from the readable memory, the method may modify a token counter value. The token counter value may represent the number of times an attempt has been made to read data from the readable memory.
It is further contemplated that the token counter value may be stored in a memory within the token or conversely the token counter value may be stored in a memory external to the token. The method may further comprise maintaining a read attempt value for a particular game token by which the read attempt value represents the number of times an authorized reader has attempted to read data from a token. Additionally, the method may also include comparing the read attempt value to the token counter value and in response to the comparison, optionally generating an alert. The read attempt value may also be stored within a server in communication with an authorized reader. In another variation, the method further comprises modifying a second counter value when a read attempt is unsuccessful.
Other systems, methods, features and advantages of the invention 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 invention, and be protected by the accompanying claims.
The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. In the figures, like reference numerals designate corresponding parts throughout the different views.
Various radio frequency identification devices (hereinafter denoted RFID) and systems that are well known for use in the gaming industry. Without limiting the disclosure herein, it is understood that the various aspects of RFID technology and RFID systems as illustrated below may be applied to other types of RFID elements and RFID systems and environments other than gaming.
In this example embodiment of a table 100, configured for use with the game of black jack, there is an outer edge 104 of the table. One or more player stations 112 (also denoted herein as player locations) are provided and configured for use by a player to participate in a waging game or a game of chance offered at the table such as blackjack. In this embodiment the player stations 112 comprise a bet spot 116 wherein a player may place one or more wagers during the course of play. For example, the player may place the gaming chips or tokens within the area of bet spot 116 when placing a bet during the course of play. Overlapping the bet spot 116 is a detection zone 120. The detection zone 120 comprises a zone within which a bet detection system (see description below) may detect the token, such as an amount bet by a player at the player station 112 at the table 100. Likewise, other data stored on the token may also be detected by the bet detection system.
In other various embodiments, one or more supplemental bet spots may be located in one or more other locations on the table surface 108. By way of example, a supplemental bet spot 130 may be located as shown in
In this example embodiment a dealer position 138 is located generally opposite one or more of the player positions. As is generally understood, the dealer presents the game from the dealer station 138. Associated with the dealer station 138 are one or more dealer spots 142 which in turn may be associated with one or more dealer detection zones. The dealer spot 142 is a location on or in some way associated with the table 100 and/or the dealer on which tokens may be placed for detection by the detection system. As used herein, the term token may refer to a DID (detectable identification device) type token. The dealer detection zone 146 is the area in which the detection system can detect tokens placed in the dealer spot 142. This dealer detection zone 146 could be used in player banked traditional table games such as those played in the State of California or other jurisdictions. The dealer detection zone 146 may also be used to hold ante bets contributed by players in Class II gaming jurisdictions such as Native American gaming establishments in the State of Florida.
A dealer interface 150 (referred to as D.I in
As part of the table 100, there is an underside 200 of the table, which is shown in
The player DID antenna 204 connects to a multiplexer, diplexer, or switch 220, which in this embodiment controls communication between a reader 226 and the player DID antenna. It is contemplated that communication between the reader 226 and the one or more player DID antenna 204 is bi-directional such that the reader may provide an electrical excitation signal to the player DID antenna. The player DID antenna 204 converts the electrical signal to an electro-magnetic field (EMF), which excites or powers the DID aspects of the token located within the detection zone. As a result and in response to the excitation EMF signal, the player DID antenna 204 may also detect data emitted from the DID. The data is sent back, via the multiplexer 220, to the reader 226.
A token tray 280 may also be provided that reads and/or writes to any token within the tray and may report newly incoming tokens and outgoing tokens. This provides the monitoring system with data regarding the tokens purchased by or paid out to players and tokens collected from players. This allows the system to further track incoming and outgoing tokens. Tokens purchased by a player and not passing through the token tray 280, i.e. won or cashed in, may be assumed to have left with or been kept by the player. Tokens presented for play on the table 100 that do not pass through the token tray 280 may be assumed to have been brought to the table by the player.
In one embodiment, the electronic readable token tray 280 can provide token inventory information within any four wall casino or multi site casinos and managed by any software that is separate or part of the full player tracking system that in turn will provide, at a moments notice, the entire banked token inventory, each token tray inventory, floating token inventory (tokens not in play and not in the bank), and notification when a de-issued token has been received or played.
Operation of each player DID 204 antenna associated with each of the player stations 112 occurs as described above. A dealer DID antenna 224 is also provided with an associated detection zone. One or more secondary bet or token spot antenna 228 with associated detection zone is also provided as shown. These elements 224, 228 also connect to the multiplexer/switch 220. A reader 226 may selectively read the DID information contained within the tokens placed at the bet spots 116 as shown in
The reader 226 connects to any type processor which may be embodied in a computer 230 having memory 234. The computer is configured to execute machine readable code which may be stored on the memory 234. The machine readable code may comprise software code or code logic capable of interaction with other systems, such as the reader 226. The computer 230 may include an input interface for receiving input from a user such as pit supervisory personnel or dealer, such as a keyboard, analog dial, potentiometer, mouse, touch screen, or any other device capable of providing information to the computer. The computer 230 may also be configured with one or more displays. The computer 230 will allow the input of information by pit supervisory personnel and/or a dealer.
In the embodiment shown in
The biometric interface 248 comprises any type system configured to monitor and identify players based on one or more player characteristics. In one such configuration a camera is capable of capturing a player's picture, such as of their face, and the biometric system compares the player's picture to a data base of known dishonest players or banned individuals. The biometric system 248 in connection with the bet detection system may be utilized to monitor for and identify certain players who may be attempting to gain an unfair advantage. One exemplary biometric system is available from Biometrica Systems, Inc in Las Vegas, Nev.
It is also contemplated that the computer 230 and the network 240 may be equipped to send and receive e-mail or other forms of electronic output. In one embodiment, the detection system, such as the computer 230, the network 240, or a mail server associated with the network, may be controlled to send e-mail, voice messages, or other notification to a party to alert or notify them of information generated by the detection system.
It is further contemplated that the system shown in
In operation, the system shown in
When the tokens are monitored or detected, in the various manners described below, the token information may be provided to the computer, processed in the manner described below, and output to a dealer, pit supervisory personnel, surveillance, casino hosts, or other third party. In one embodiment the processing may occur at the table itself such as with a controller or control logic, and not at the computer.
The detection system may be configured in any desired manner, such as described below. In general, the detection system detects tokens on the table. The detection system may be configured to detect player cheating such as when a player alters a token's denominational face value. In other embodiments, as discussed herein, the detection system may be utilized for other monitoring and reporting functions.
As shown in
In one example embodiment the token 300 having DID element 312 comprises a microchip having read and write memory, such as for example 256 bits and the like, with one or more configurable sections of the microchip to meet a particular application. Data may be entered into the DID element 312 and sealed or encrypted to prevent fraud or tampering. In one embodiment, at least some of the data stored within the DID element 312 may be changed or updated by a casino or when provided to a player.
While the above description refers to a DID element of a token, it is understood that a DID element may also be embedded directly in any DID including, but not limited to a card, key chain, jewelry item, watch, such as on the back of a watch, into a wallet, as part of a bracelet, into or part of a purse, into a player tracking card (with or without a magnetic strip), money clip, room key, under the skin, on or part of glasses, back of a credit card, drivers license, smartcards, or other item or card type element. The term DID element is defined to mean any portion of a DID that is capable of being detected by a detection system, such as the detection system described herein. Any type technology may be used to detect the DID element. In operation, the DID element, regardless of how it is housed or contained may be interrogated by the detection system described herein.
Although described in
The DID element 312 further comprises one or more power converter 404, R/W (read/write) logic 406, counter logic 408, non-volatile memory 416. The antenna 402 may communicate with the logic 406 and converter 404. In this example embodiment the power converter 404 receives all or a portion of the signal from the antenna 402 and generates power, which powers the other aspects of the element 312. Operation of the logic 406, 408 is described below in more detail.
The DID element 312 may further or alternatively comprise an optional processor 410. Each of the power converter 404, R/W logic 406, counter logic 408, processor 410 and non-volatile memory 416 may comprise one or more circuit elements. The term “non-volatile memory” as used herein refers to memory that may retain data within DID element 312 even when the token is not powered from an external antenna.
Also part of the element 312 is non-volatile memory 416, which may be divided or segmented into data memory 412 and counter memory 414. Locations in data memory 412 and counter memory 414 may be identified by one or more addresses.
Any type data may be stored in memory 412 including but not limited to client or casino name, secret data, encryption information or codes, public information, physical chip size, data regarding memory, creation or in use date, DID type or family, denominational value of the token, locality code to provide for currency differences in different localities, or any other information or data. Some locations of memory 412 may contain writable or re-writable data. One example of rewritable data may include player tracking information. However, other addresses of memory 412 may only be read by a reader.
The counter memory 414 contains counter values stored at one or more locations of counter memory and the locations may be identified by memory addresses. It is contemplated that a counter value may be associated with one or more operations or tasks that may occur within the DID element 312. For example, one counter value may indicate the number of times a particular address (memory locations) has been accessed. For example, if an address is associated with the token's serial number, each time that the token's serial number is accessed, the counter value associated with that address or memory location is incremented. Thus, counter memory is accessed.
In addition, other counter memory locations may store counter values that represent the number of times other actions or operations have occurred within the DID element 312. It is contemplated that any action or operation of the element 312 may be tracked or monitored and upon execution, a counter value incremented and optionally stored in memory. In this manner, a running total of the number of times a particular action or operation has occurred within the element 312. Examples of potential operations which may be tracked and monitored are shown in
In one aspect, this disclosure is directed to detecting unauthorized access to information coded within a DID element or unauthorized execution of actions (or attempted execution of actions) within the DID element 312. As is generally understood, a reader (collectively a reader and antenna element) powers the DID element 312 and hence initiates one or more actions of the DID element. There may exist both authorized and non-authorized readers. For example, authorized readers may comprise a reader owned by a casino and which is intended by the casino to read the DID elements. In contrast, unauthorized devices may comprise any device used by one or more persons who have not been authorized by a gaming establishment to communicate with any DID element. Such person may be attempting to commit fraud by reading and/or writing to the DID element 312 in an effort to change or copy important data on the DID element.
According to
In this embodiment DID element 312 may optionally include a processor 410. The processor 410 may replace the logic elements discussed above, or provide for addition functions within the DID element as typified by central processing units and the like. Furthermore, it is contemplated that R/W logic 406, counter logic 408 and processor 410 may be contained within a single integrated circuit. The processor 410 and logic may comprise or utilize hardware, software, or a combination of both.
In operation, when a reader generates a signal to activate a DID element, communication may occur between the DID element and the reader. Communication may comprise a transfer of power from the reader to the DID element, which in turn provides for communication by driving one or more circuit elements of the DID element 312.
When the DID token antenna 402 receives communication, a portion of the communication may comprise a power signal and a portion may comprise a data signal. The power signal may be communicated to a power converter 404. As a result, the power converter 404 may generate and provide an appropriate power signal to the other circuit elements of the DID element 312, such as one or all of R/W logic 406, counter logic 408, and optional processor 410.
Furthermore, when the DID token antenna 402 receives communication, a portion of the communication may be communicated as data to R/W logic 406. R/W logic 406 may communicate data to memory 412 or the reader may send a signal to the DID element to read data from memory 416. It is contemplated that once powered, the reader and DID element 312 may communicate to read data from and/or write data to the DID element. Other operations may occur including, but not limited to: encrypting or decrypting data, authentication operations, reading data, writing data, and use of external device control ports.
As part of any operation described above, the counter logic 408 may be triggered by R/W logic 406 because the DID element 312 has taken an action, such a read operation. In this embodiment, the counter logic 408 retrieves a counter value from counter memory 414, increments this value and updates counter memory 414 with the incremented value. The retrieved counter value is a counter value associated with the particular action taken by the DID element. There may be a different counter value associated with the various actions that may occur within the DID element 312.
The counter value may be indicative of unauthorized activity between the DID element 312 and other devices of the RFID system, such as a reader. Unauthorized activity may comprise numerous attempted or achieved read or write operations performed by unauthorized readers. In one example of unauthorized access of a DID, an unauthorized reader may attempt to access information so that the DID element may be cloned, copied, or modified. Since the DID comprises a counter logic 408 of the type described above (see also
Determining unauthorized access therefore may lead to a suspicion that unauthorized access of a DID may be occurring. Such knowledge of expected counter values versus unexpected counter values may be obtained from a back end system such as a server (computer system) communicating with authorized readers which keeps a concurrent database of counter values matching the counter values of each DID.
It is contemplated that in one embodiment of the DID, the memory may store authorized reader signatures. During operation, the DID element would compare the reader's signature against the list of authorized readers. Only authorized readers would be able to read the DID. Such readers may be termed “compliant” readers. Additionally, a counter value associated with reader access attempts would be incremented each time the DID was accessed or attempted to be accessed, even if unsuccessful. If there was a discrepancy between the number of times a DID was accessed versus the number of times authorized readers accessed the DID, this discrepancy may further lead to a suspicion that unauthorized access of a DID may be occurring.
In principal, any state in
When a DID passes through a detection zone (see description above), the reader may initiate a variety of command operations. Referring both to
In addition to the serial number queries operation executed by the DID element, at state 504, counter logic may retrieve a counter value from counter memory associated with the serial number read operation from the DID. If communication between the reader and the DID is unsuccessful, the reader and/or the DID may return to an idle state as shown by return path from state 504 to state 502.
In state 506, when communication is successful, this serial number counter value may be incremented by counter logic to indicate the DID was queried for the serial number by a reader. Moreover, at state 508, the incremented serial number counter value may then be updated and stored back in the serial number access counter memory address. Thereafter, the DID token may then return to an idle state at state 502. In this manner, when a reader, either authorized or unauthorized, queries the tag to obtain the tag serial number, a counter value that represents how many times that operation has occurred is likewise incremented.
In state 510, when a reader activates the DID token and queries the status register then the “status access” counter will increment to indicate that a reader initiated a command to read the current counter information of the DID. This serves as a means of determining if only authorized reader systems have accessed the status data of the DID by correlating this counter value with system stored counter values. When the DID is queried or powered by a reader, so that the inactive state of the DID becomes an active state, this status counter value may be incremented and stored in counter memory, followed by a return to an idle state of the reader and/or the DID token. This occurs at state 508. It will be appreciated, that any other operation may also be redirected to states 508 and 510 and the status active state counter value may be updated as appropriate.
In state 512 a reader may query other data such as a page of memory. A page may comprise any collection of data such as user information including name of establishment or provider of the DID, password data, denomination value and country code of the DID, and the like. In one example of a page, the page may comprise 4 bytes of information with each byte comprising 8 bits of information. Each DID may have any number of pages depending on the size of the DID memory.
In state 514, when communication is successful, a page counter value may be incremented by counter logic to indicate the DID was queried for the page by a reader. In state 508, the incremented page counter value may then be updated and stored back in a counter value location that represents the number of times the page memory has been read. Either the reader and/or the DID token may then return to an idle state 502.
In state 516 a reader may request DID page authentication. Page authentication refers to a determination of the accuracy of page data. In other embodiments the authentication may comprise of negotiating a public or private key encryption method in order to access the desired page information. In state 518, when communication is successful, a page authentication counter value may be incremented by counter logic to indicate the DID was queried for page authentication by a reader. In state 508, the incremented page authentication counter value may then be updated and stored back in a page authentication counter value memory address. Either the reader and/or the DID may then return to an idle state 502.
In an optional operation, when a reader requests DID page authentication in state 516 (see above), the reader may provide a reader signature as part of the request. The reader signature may comprise data that identifies the particular reader. In state 520, the reader signature may be written to DID memory and a counter value representing that the reader signature written may be updated in DID memory. Either the reader and/or the DID token may then return to an idle state 502.
A benefit of writing a reader signature to DID memory is that unauthorized reader access to private information in a DID may be detected and the ID or signature of the reader may be recorded on the DID. A comparison of a reader's signature against authorized reader signatures stored in DID memory may be a flag that unauthorized access to the DID has occurred. Moreover, the unauthorized reader may be identified and traced thereby allowing an authority to prevent further unauthorized read/write operations. While not all current readers are compliant in providing signature data, the current disclosure suggests great benefit by requiring that all readers be signature compliant.
In an alternative embodiment, a reader may also include counter logic and counter memory and the counter memory may store values related to or identifying the DID when the reader accesses the DID. Such access may indicate that a DID is unauthorized when the DID signature is compared to a data base of authorized DID stored in the reader system. Furthermore, in yet another exemplary embodiment of a counter logic and counter memory located in a reader, the DID may trigger a compliant reader to write a DID's serial number into a reader's data memory anytime the reader queries the DID, or anytime the reader triggers a write cycle within the DID. Advantageously, in this embodiment, the DID may be in control of a process wherein a substantially secure unalterable write cycle is triggered in a compliant reader. As a result, the DID serial number may be written to the reader if an establishment suspected that unauthorized access of a DID was occurring and the establishment could impound the unauthorized compliant reader and determine counter values or DID data stored in the compliant reader to confirm that unauthorized access may have occurred.
As described above, a reader may initiate writing to a DID. This may occur for any purpose, such as during player tracking. In state 522 a reader may initiate a write operation. In state 524, when communication is successful, a write operation counter value may be incremented by counter logic to indicate a reader requested a write operation. Once again, incrementing the counter logic may be used to determine whether an unauthorized reader has accessed the DID because the counter value incremented by the write operation can be compared directly to the corresponding values stored in the reader system for that DID. If these values, i.e. write operation counter values stored in the DID and the write operation value stored in the reader for that DID, do not match, then unauthorized write operations may be occurring. This may be particularly troubling if the value of the DID tag is modified. (see discussion above). In state 508, the incremented write operation counter value may then be updated and stored back in a write operation counter value memory address. Either the reader and/or the DID may then return to an idle state 502. With reference to
It is contemplated that other operations such as accessing or decrypting DID encrypted information may also trigger a counter value being incremented. Example of encrypted data may include but are not limited to an encrypted code number indicating manufacture date of the DID or an encrypted establishment code number. In yet another embodiment, each time a DID is powered by a reader, another reader may access the DID. A DID may be configured with a counter value to indicate that the DID has been powered-on by a first reader and accessed for data by a second reader. When the counter value for DID power-on by a reader does not correspond to the values for power-on and accessing data from any other reader, an establishment may suspect that an unauthorized reader has attempted to piggy-back onto an authorized reader
Furthermore, it may be appreciated that a DID counter logic may be read by a reader, but may be configured to not allow the reader to directly write by a reader. This provides a greater degree of security.
As described above, any back end system such as a server (computer system) communicating with a reader may keep concurrent counter values for each particular DID element within the server's database. The concurrent counter values database, maintained by the reader system, may be used to determine discrepancies indicating unauthorized access to DID counter logic. One method that may be utilized to determine discrepancies is to read the counter values from the DID and then compare these values to the values stored on the reader system. The values stored on the reader system indicate the actual number of times each DID operation occurred or was initiated by an authorized reader. If the counter values stored on the DID do not match the values stored in the reader system, it can be assumed that unauthorized access has occurred.
Another counter feature that may appear on a DID element comprises lifetime usage data indicating the number of times that a DID has been used during its life. Each time the DID is accessed the counter logic may be incremented thereby incrementing a counter value representing usage. This usage counter value may be used to determine usage of a DID. When a DID has reached its useful life limit, the counter logic of the DID element may be programmed to alert a reader to withdraw the DID from further use.
From the earlier discussion regarding counter logic embedded in readers, all elements and steps described herein for DID may also be incorporated in readers.
While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible that are within the scope of this invention.
This application claims priority to Provisional Patent Application No. 60/735,329 entitled Secure Identification Devices and Methods for Detecting and Monitoring Access Thereof which was filed on Nov. 9, 2005.
| Number | Date | Country | |
|---|---|---|---|
| 60735329 | Nov 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11594658 | Nov 2006 | US |
| Child | 13937049 | US |
