US20070046467A1

US20070046467A1 - System and method for RFID reader to reader communication

Info

Publication number: US20070046467A1
Application number: US11/408,652
Authority: US
Inventors: Sayan Chakraborty; Brian McKinney
Original assignee: SkyeTek Inc
Current assignee: Novanta Inc
Priority date: 2005-08-31
Filing date: 2006-04-21
Publication date: 2007-03-01
Also published as: EP1929450A4; US20070046434A1; WO2007027885A2; US7456746B2; US20070182558A1; EP1929450A2; WO2007027885A3

Abstract

A system and method for coordinating a plurality of radio frequency identification (RFID) readers to minimize reader noise and increase reader sensitivity. A first set of one or more of the plurality of readers is coordinated to operate in a transmit only mode. A second set of one or more of the plurality of readers is coordinated to operate in receive only mode. The first and second set are synchronized such that a receive period of the second set coincides with a transmit period of the first set.

Description

RELATED APPLICATIONS

This application claims priority to provisional patent application Ser. No. 60/673,692, filed Apr. 21, 2005 and 60/712,957, filed Aug. 31, 2005. The disclosures of which are incorporated herein by reference.
This application is also related to U. S. patent application Ser. No. 11/387,442, filed Mar. 23, 2006, entitled “RFID Reader Operating System and Associated Architecture”; which is a continuation-in-part of U.S. patent application Ser. No. 11/323,214, filed Dec. 30, 2005, entitled “System and Method for Implementing Virtual RFID Tags.” This application is also related and co-filed with U.S. patent application entitled “Combined RFID Reader and RF Transceiver.” All of the aforementioned applications are incorporated herein by reference.

BACKGROUND

Radio-frequency Identification (RFID) systems employing RFID tags and RFID tag readers (RFID readers) are commonplace. With the increasingly varied applications for the RFID tags, greater numbers of readers are required across an ever-widening range of regulatory, technological, and operating environments. Costs associated with developing specialized, monolithic readers that require custom manufacturing may, however, be prohibitive.
Since current RFID readers depend upon ‘upstream’ systems (typically involving RFID middleware running on servers) to coordinate and manage multiple readers in a hierarchical fashion, particularly where network topology is unknown or is dynamic, RFID reader management is very difficult. For example, where portable RFID readers enter and leave a network, management of such devices is difficult. This is especially true when RFID readers within the network have differing capabilities.
RFID middleware operates to filter and aggregate captured RFID tag data, thereby decoupling RFID readers from applications that utilize the captured RFID tag data. This filtering and aggregation is typically performed in an RFIDStack within the RFID middleware. The RFIDStack may perform entry & exit aggregation, which estimates when each RFID tag first appeared within read range and when that *RFID tag subsequently disappeared from read range. The RFIDStack may also produce an aggregate count of the number of RFID tags of a specific category that have been read. It may further indicate a direction of movement of an RFID tag based upon interaction among different RFID readers.
The RFIDStack may operate to aggregate data from multiple RFID readers where applications do not require distinction between these readers. Conversely, where an application is interested in receiving RFID tag data from a particular RFID reader, the RFIDStack may filter (e.g., remove) RFID tag data received by other RFID readers for that application. Thus, RFIDStack may remove unchanging data and events.
Use of multiple RFID readers requires that each reader communicate with an application running on a host computer via RFID middleware. The RFID reader typically includes a serial interface, to facilitate wired connection to the host computer or RFID middleware system; or it may include a wireless interface (e.g., WiFi). Where the RFID reader connects wirelessly to the network, it typically includes a separate radio circuit and controller to facilitate communications.
Configuring multiple RFID readers requires manual download of selected RFID protocols to each RFID reader. Accordingly, where an RFID reader encounters an unknown RFID tag type, the RFID tag may simply remain unread.
FIG. 1 shows a prior art system 8 that reads data from RFID tags. System 8 has two RFID readers 10(1) and 10(2) and a server 22. Server 22 includes two reader interfaces 24(1), 24(2), RFID middleware 26 with RFIDStack 28, and two applications 30(1), 30(2). Each RFID reader 10 includes a controller 12, an RFID radio circuit 14 and a host interface 16. Each RFID radio circuit 14 connects to an antenna 18 used to communicate with one or more RFID tags 20. RFID middleware 26 communicates with each application 30 and each RFID reader 10; for example, RFID middleware 26 utilizes reader interface 24(1) to communicate with RFID reader 10(1) and utilizes reader interface 24(2) to communicate with RFID reader 10(2). Each RFID reader 10 includes a host interface 16 used in communications with server 22. RFIDStack 28 is used to aggregate and filter tag data received from RFID tags 20 before passing the aggregated and filtered information to applications 30, thereby decoupling applications 30 from RFID readers 10.
RFIDStack 28 also manages configuration of RFID readers 10, typically requiring human interaction prior to updating firmware of controller 12. RFIDStack 28 also downloads tag protocols to each RFID reader 10 when they are required to read a new RFID tag type. In certain situations, RFIDStack 28 specifies operation of each RFID reader 10 based upon RFID reader location. RFID readers 10 contain limited or no intelligence as to managing their own configuration or operating characteristics.

SUMMARY OF THE INVENTION

In one embodiment, a method coordinates a plurality of radio frequency identification (RFID) readers to minimize reader noise and increase reader sensitivity. A first set of one or more of the plurality of readers is coordinated to operate in a transmit only mode and a second set of one or more of the plurality of readers is coordinated to operate in receive only mode. The first and second set are synchronized such that a receive period of the second set coincides with a transmit period of the first set.
In another embodiment, a method distributes activity across a network of radio frequency identification (RFID) readers. A first set of one or more readers at a first location is configured to identify a plurality of RFID tags and a second set of one or more readers at a second location is configured to interact with one or more of the tags using identification information received from at least one of the readers of the first set without searching to identify the tags at the second location.
In another embodiment, a method updates firmware of a first radio frequency identification (RFID) reader connected to an RFID reader network having one or more other readers. If it is determined that a version of firmware within the first reader is older than a version of firmware within one or more other readers, a copy of the firmware within the one or more other readers is transferred to the first reader.
In another embodiment, a method provides connectivity between a server and at least one of a plurality of radio frequency identification (RFID) readers. The plurality of readers are communicatively coupled to create an RFID reader network wherein not all of the readers are directly connected to the server. At least one of the readers connects to the server to create a proxy server, wherein the proxy server exchanges information between the server and at least one of the readers not directly connected to the server.
In another embodiment, a method determines a scope of operation of one or more radio frequency identification (RFID) readers within an RFID reader network. One or more RFID tag types of a plurality of tags are determined and the scope of operation of each reader is determined based upon its ability to handle the identified tag types. Any reader unable to handle a specific tag type is configured to not interact with any tags of the specific tag type.
In another embodiment, a method coordinates a plurality of radio frequency identification (RFID) readers to minimize reader noise and increase reader sensitivity. One or more groups of readers are determined where operational fields of readers in the group overlap. A first set consisting of one reader from each group is selected and a second set consisting of readers of each group not in the first set is selected. The first set is coordinated to operate in a transmit only mode and the second set is coordinated to operate in a receive only mode. The first and second set of readers are synchronized such that a receive period of the second set coincides with a transmit period of the first set.
In another embodiment, a method searches for information stored within a radio frequency identification (RFID) reader network of RFID readers, each including a tag cache capable of storing the information. A search message containing search criteria is generated and sent to a set of readers within the reader network, each reader within the set searching its tag cache to identify information matching the search criteria. A response containing the identified information is received from any reader within the set having the identified information in its tag cache.
In another embodiment, a method creates a network of radio frequency identification (RFID) readers. A first RFID reader is initially included in the network and additional RFID readers are connected to the network, such that each of the additional readers is connected to at least another one of the additional readers by a peer to peer communication link, and such that at least one of the additional readers is also connected to the first reader by a peer to peer communication link.
In another embodiment, a system interacts with one or more radio frequency identification (RFID) tags, and includes a first set of one or more RFID readers at a first location, the first set operating to identify at least one of the tags, and a second set of one or more readers at a second location, the second set operating to interact with one or more tags identified by the first set. The second set uses identification information received from at least one of the readers of the first set and without searching to identify the tags at the second location.
In another embodiment, a system reads radio frequency identification (RFID) tags and includes a server, at least one RFID reader not directly coupled to the server, and at least one RFID reader directly coupled to the server and operating as a proxy server. The readers are couple to create an RFID reader network such that the proxy server exchanges information between the server and the at least one reader not directly connected to the server.
In another embodiment, a system interacts with one or more radio frequency identification (RFID) tags and includes a first set of one or more RFID readers at a first location, the first set operating to identify at least one of the tags, a second set of one or more readers at a second location, the second set operating to interact with one or more tags identified by the first set, and a server connected to at least one but not all of the readers. The second set uses identification information received from at least one of the readers of the first set and without searching to identify the tags at the second location and the readers couple to create an RFID reader network such that the proxy server exchanges information between the server and the at least one reader not directly connected to the server.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a prior art system for reading data from RFID tags.
FIG. 2 shows one exemplary system for RFID reader to reader communication, in accord with an embodiment.
FIG. 3 shows exemplary system architecture utilized within each RFID reader of FIG. 2.
FIG. 4 shows exemplary firmware architecture illustrating an application layer, an application software interface, a hardware abstraction layer and an operational platform.
FIG. 5 shows exemplary functionality of the network manager of FIG. 4, including discovery, authentication, protocol security, timing coordination, version/capability, offline detection and a version/capability functionality.
FIG. 6 shows the coordinator of FIG. 4 in further detail.
FIG. 7 is a flowchart illustrating one method for coordinating a plurality of RFID readers to minimize RFID reader noise and increase RFID reader sensitivity.
FIG. 8 shows the reader manager of FIG. 4 in further detail.
FIG. 9 shows the data manager of FIG. 4 in further detail.
FIG. 10 is a block diagram illustrating one exemplary swarm of three RFID readers within an RFID reader network.
FIG. 11 is a flowchart illustrating one exemplary method 1300 for coordinating a plurality RFID readers to minimize RFID reader noise and increase RFID reader sensitivity.
FIG. 12 is a flowchart illustrating a method 1400 for distributing activity across a network of RFID readers.
FIG. 13 is a flowchart illustrating a method for providing connectivity between a server and at least one of a plurality of radio frequency identification (RFID) readers.

DETAILED DESCRIPTION OF THE FIGURES

A radio frequency identification (RFID) reader is used to identify RFID tags within its operational field. The operational field of a reader is the area within which the reader may successfully communicate with tags. This identification process typically involves ‘searching’ for the tags using an anti-collision protocol (known in the art) since only one tag may transmit information to the reader at a time. The reader may, for example, read identification information from each tag within its reading range. This identification information includes a unique identification number (UID) that is unique to the tag. When several tags are within the operational field of the reader, this identification process, using the anti-collision protocol, may take a significant amount of time.
Once the tags are identified, individual tags may be addressed using their UIDs. For example, an reader may perform additional operations (e.g., read, write and lock) on a tag within its operational field by first transmitting a ‘select’ command, including the UID of the tag, setting the identified tag into a communicative state. The reader may then utilize additional commands (e.g., write block, read block, lock block, etc) to control or access data of the selected tag. For example, the reader may read data from one or more memory blocks of the selected tag using a read block command. In another example, the reader may write data to one or more memory blocks of the selected tag using a write command. In another example, the reader may prevent further changes to one or more memory blocks of the selected tag using a lock command. Thus, operations performed upon tags by the reader typically involve first selecting the tag using its UID and then reading or writing data from and to the selected tag.
In another example, if interaction with certain tag is not desired, the reader may transmit a ‘Stay Quiet’ command, including the UID of the certain tag, setting the tag into an uncommunicative (i.e., no-transmit) mode.
FIG. 2 shows one exemplary system 100 for RFID reader to reader communication. In particular, FIG. 2 shows a server 106 and three readers 102(1), 102(2) and 102(3), each with an antenna 104(1), 104(2) and 104(3), respectively. In operation, reader 102(3) communicates directly with server 106, reader 102(3) communicates with reader 102(2), which in turn communicates with reader 102(1). Readers 102(1), 102(2) and 102(3) collectively form an RFID network 105, in this example. Accordingly, server 106 communicates with reader 102(2) via reader 102(3), and communicates with reader 102(1) via readers 102(3) and 102(2). Readers 102 are shown interacting with five exemplary RFID tags 108.
Each communication path 110, 112 and/or 114 may be a wired or wireless connection. In one embodiment, communication paths 110 and 112 are implemented through combined RFID and RF antenna technology that allows antenna 104 to interact with tags 108 and other readers, as disclosed in U.S. patent application Ser. No. ______, titled “Combined RFID Reader and RF Transceiver.”
FIG. 3 shows exemplary system architecture 200 that may be utilized within each reader 102 of FIG. 2. Architecture 200 is illustratively shown with an operational platform 208, a hardware abstraction layer 210, an application software interface 212 and an application layer 214. Operational platform 208 is formed by hardware 202, a radio 204 and an optional operating system 206, upon which application software of reader 102 runs.
Operating system 206, if included, may be realized by a variety of operating systems including operating systems sold under the trade names of Linux, WinCE, Symbian, and VxWorks.
Hardware abstraction layer 210 includes platform-dependent drivers that effectuate low-level functions that interact with hardware 202, radio 204 and, optionally, operating system 206. For example, hardware abstraction layer 210 may implement alterations of the reader in accordance with specific protocols (e.g., a message authentication code (MAC), physical layer and/or command syntax) and/or other operational characteristics defined by data within configuration and data files. These drivers may be optimized for hardware 202, radio 204 and operating system 206.
Application software interface 212 includes platform-independent libraries that provide, via a common API, certain functions associated with effectuating the specific protocols and/or operational characteristics of reader 102. In addition, application software interface 212 may provide many functions associated with reading RFID tags. Advantageously, these library functions are portable across multiple reader platforms because they are independent of specific hardware (e.g., hardware 202), operating systems (e.g., operating system 206) and radio hardware (e.g., radio 204) that reside within platform 208 of the exemplary architecture.
Application layer 214 defines the functionality for implementing reader to reader communication. In one example of operation, application code within application layer 214 makes one or more calls to lower level library and driver functions within application software interface 212 and hardware abstraction layer 210.
FIG. 4 shows exemplary firmware architecture 300 illustrating an application layer 352, an application software interface 336, a hardware abstraction layer 318 and an operational platform 302. Application layer 352 may represent application layer 214 of FIG. 3; application software interface 336 may represent application software interface 212; hardware abstraction layer 318 may represent hardware abstraction layer 210; and platform 302 may represent platform 208. Application layer 352 shows exemplary application code including a coordinator 354, a reader manager 356 and a data manager 358 that cooperate with a network manager 360 to facilitate reader to reader communication.
Application software interface 336 is illustratively shown with a reader protocol 338, a reader configuration 340, cryptography 342, code loader 344, a baseband 346 and a tag protocol 348. Hardware abstraction layer 318 is illustratively shown with a stream 320, sockets 322, sensors & I/O 324, a user interface 326, a block I/O 328, system 330 and a RFID radio 332.
Platform 302 includes a host interface 304, peripherals 306, a user interface 308, memory 310, a processor 312, a power supply 314 and an RFID radio 316. It should be recognized that this is only exemplary of the type of hardware that may be part of a platform. In an alternative embodiment for example, platform 302 may include an operating system. In another embodiment, platform 302 may not include user interface 308.
Drivers 318 provide interface handling for hardware of platform 302 through a driver Application Programming Interface (API) 334, illustratively shown as bi-directional arrow 334, between application interface 336 and hardware abstraction layer 318. Specifically, API 334 is portable and platform independent whereas driver functions within hardware abstraction layer 318 may be dependent upon platform 302. As a consequence, a developer need only learn API 334 to be able to create application code applicable to a variety of platforms.
Stream 320 includes drivers that provide hardware interface handling for communication with a host (e.g., server 106, FIG. 2) or other peripheral devices. For example, stream 320 may include drivers for TTL, I²C, SPI, USB and RS-232 interfaces.
Sockets 322 includes drivers that enable task management, port sharing among multiple applications and networking management functionality. Some examples of socket drivers include Ethernet, Wi-Fi, Zigbee, Bluetooth, etc.
Sensors and I/O 324 includes drivers that provide hardware interface handling for communication with sensors and other I/O devices that connect to hardware of platform 302. For example, sensor and I/O 324 may include drivers for temperature sensors, current sensors, voltage sensors and general purpose I/O (GPIO).
User interface 326 includes drivers that provide hardware interface handling for communication with user interface 308 of platform 302. For example, the user interface 326 may include drivers for touch screen hardware, pointing devices, biometric security devices and keyboards, etc.
Block I/O 328 includes drivers that enable communications with memory 310 and other platform resources (e.g., hard drives, busses, ROM, RAM, EEPROM, etc.).
System 330 includes drivers that provide an interface to various system components of platform 302. For example, system 330 may include drivers for timers, power management and interrupt handling and control of platform 302.
RFID radio 332 includes drivers that provide an interface to a variety of radio types (e.g., analog front ends (AFEs)) enabling communication with a variety of different radio hardware (e.g., RFID radio 316). In addition, RFID radio 332 drivers may enable data-defined aspects of operation at the physical layer to be effectuated. For example, RFID radio 332 drivers may carry out transmission and reception of signals in accordance with a physical layer protocol defined by data in a data file. Thus, if a user desires to upgrade the RFID radio 316, only RFID radio 332 drivers may require changing.
Application layer 352 accesses application software interface 336 via a portable and platform-independent API (illustratively represented by a two way arrow 350 in FIG. 4).
Reader protocol 338 may include functions that implement low-level operations required by host communication protocols. For example, reader protocol 338 may include one or more of: a cyclical redundancy code (CRC) library, a parity calculation library, forward error correction algorithms, message data parsers, ASCII to hexadecimal encoders and decoders, host-protocol command interpreters, host-protocol command executors and host-protocol error handlers.
It should be recognized that a reader-side implementation of a host-to-reader communication protocol may reside in reader protocol 338, application layer 352, or both. For example, an application may reside within application layer 352 to facilitate calls to functions of reader protocol 338, as well as other libraries of application software interface 336 and hardware abstraction layer 318.
Reader configuration 340 includes functions that enable applications within application layer 352 to control the inner workings of RFID reader 102. For example, reader configuration 340 may include functionality to control one or more of: schedule, event, interrupt and priority handlers.
Cryptography 342 includes functionality for handling security and cryptographic data processing that may be required relative to many aspects of RFID reader 102. For example, cryptography 342 may include one or more of: tag-reader cryptography, reader-host cryptography, user data security, network data security and hardware security management.
A variety of cryptographic techniques may be utilized including private key algorithms and propriety security algorithms (e.g., security algorithms marketed under the trade names of Philips, Mifare, Inside Contactless, Pico Pass, Infineon, My-d, Atmel, CryptoRF, etc.). In addition, public key algorithms may be utilized including PGP and commonly known algorithms such as DES, 3-DES and RSA, for example.
Tag protocol 348 includes functions for defining one or more of: the air interface (i.e., the protocols between RFID radio 316 and RFID tags), initialization and anti-collision protocols and procedures, and a data transmission method utilized for forward and return links. The air interface describes characteristics of baseband radio functionality and RF symbol definitions, which define how data bits are sent and received through the air via the RFID radio 316.
The initialization and anti-collision procedures describe how reader 102 and tags 108, FIG. 2, interact to communicate unique or repeated tag identification numbers from one or more of tags 108 to reader 102. The data transmission method defined by tag protocol 348 describes how the forward and return link messages are constructed, encoded and recoded to perform basic RFID transactions including, for example, identifying, reading and writing tags.
In some variations, tag protocol 348 is segregated into three general classes of functions: agnostic functions, which provide the highest level of abstraction so that applications within application layer 352 may operate independently of the tag types that reader 102 interacts with; protocol functions, which allow applications to utilize a particular tag type without concern for implementations specific to RFID tag manufacturers; and manufacturer functions, which enable applications to access manufacturer-specific features of a standards-based tag and utilize independent tag manufacturers proprietary tag protocols.
In the context of high frequency (HF) air interfaces (e.g., 13.56 MHz), tag protocol 348 may support a variety of protocols including ISO15693-2, ISO18000, ISO14443-2 Type A, ISO14443-2 Type B, Phillips ICode SL1, Texas Instruments Tag-it HF and TagSys C210, C220 and future protocols. With respect to ultra high frequency (UHF) air interfaces (e.g., 860-960 MHz), tag protocol 348 may support protocols including ISO18000-6A, ISO18000-6B, ISO 18092, EPC Class 0/0+, EPC Class 1, EPC Class 1 Gen 2, and other protocols yet to be developed.
Baseband 346 includes baseband functions that are portable across disparate hardware chips, processors and operating systems (if present). These baseband functions handle low-level interaction between tag protocol 348 and drivers of RFID radio 332. In addition, baseband 346 includes functionality for digitally defining RF characteristics of individual bit symbols and presenting the defined symbol definitions to the low-level, protocol specific, drives of RFID radio 332, thereby enabling tag protocol 348 functions to receive only binary code (i.e., ones and zeros).
Code loader 344 includes functions that facilitate loading of new code and/or data into reader 102. For example, code loader 344 may facilitate loading of programs into application layer 352, loading of new drivers into hardware abstraction layer 318, loading new configuration data or default values for reader 102 into memory 310 and adding new functions to application software interface 336.
It should be recognized that the specific hardware, drivers, libraries and applications described with reference to FIG. 4 are exemplary only and that certain functions may be omitted, combined or enhanced without departing from the scope of the present invention.
Networking RFID Readers
As shown in FIG. 2, readers 102(1), 102(2) and 102(3) may be communicatively connected to form RFID reader network 105. FIG. 5 shows exemplary functionality of network manager 360, FIG. 4, including discovery 402, authentication 404, protocol security 406, timing coordination 408, version/capability 410, offline detection 412 and a version/capability structure 414. Network manager 360 is, for example, a distributed application implemented across networked readers 102(1-3) and operates to create and maintain reader network 105.
Continuing with the example of FIG. 2, assume readers 102(2) and 102(3) are connected to form reader network 105 and that RFID reader 102(1) is not yet part of reader network 105. Within reader 102(1), discovery 402 includes algorithms for discovering other readers (e.g., readers 102(2) and 102(3)) and also algorithms that allow discovery of reader 102(1) by other readers (e.g., reader 102(2) and reader 102(3)). Discovery may occur at any time (e.g., when a reader is first connected to a network, when a reader loses and regains power, etc.).
In one embodiment, network manager 360 within reader 102(1) utilizes algorithms of discovery 402 to periodically send a ‘beacon’ message to facilitate detection of reader 102(1) by other readers (e.g., readers 102(2) and 102(3)). For example, each established reader within reader network 105 may periodically send out a ‘beacon’ message containing their network location/address. An reader joining reader network 105 would thus, over time, learn the location/address of each of its peers (i.e., each reader within reader network 105).
In another embodiment, reader 102(1) generates a ‘peerRequest’ message and broadcasts it on reader network 105. Reader 102(1) then awaits replies from readers already connected to reader network 105. These replies may contain information about the replying readers and/or information about readers known to the replying readers. An exemplary discovery sequence using XML messages is shown below:
Reader broadcast:

<peerRequest/>
Each peers to Reader:

<peer name=“Front Door”/>

<myPeers>

<peer name=“Jim's Office” address=“192.168.1.93”/>

<peer name=“Boyd's Office” address=“192.168.1.12”/>

</myPeers>
In another example of discovery, a central authoritative source (e.g., a Universal Description, Discovery and Integration (UDDI) server, a Lightweight Directory Access Protocol (LDAP) server or a proprietary server) operates as a directory of readers. In this example, each reader knows the location/address (e.g., Ethernet address or web URL) of the central authoritative source and may know authentication/authorization information associated with the central authoritative source required for access. To join a reader network, a reader may query (using authentication if necessary) the central authoritative source for the location/address of its peers. An exemplary reader message exchange with a XML message based proprietary server is shown below:
Reader to server:

<peerReguest/>
Server to reader:

<peers>

<peer name=“Back Door” address=“192.168.1.34”/>

<peer name=“Conveyer One” address=“192.168.1.35”/>

<peer name=“Shipping” address=“192.168.1.36”/>

</peers>
Continuing with the example of FIG. 2, once discovery of reader 102(1) occurs (or once reader 102(1) discovers one or more of readers 102(2) and 102(3)), network management 360 may utilize algorithms of authentication 404 to identify and authenticate reader 102(1) to its peers within reader network 105 (and optionally server 106). For example, network manager 360 within reader 102(2) may interact with network management 360 within reader 102(1) to effect authentication, ignoring readers that fail to authenticate, thereby preventing unauthorized access to reader network 105. Further, upon successful authentication, network management 360 within each reader 102 may utilize algorithms of protocol security 406 to ensure reader to reader communication is secure.
Reader authentication by another reader may be implemented using an authentication scheme similar to current tag authentication schemes. For example, assume reader 102(1) and reader 102(2) are to authenticate each other; both reader 102(1) and reader 102(2) possess a known ‘key’ (e.g. an X.509 certificate). Reader 102(1) generates a random number and sends it to reader 102(2). Reader 102(2) utilizes its key to ‘hash’ (using a common algorithm) the random number and generate a ‘hash value’, which it sends back to reader 102(1). Reader 102(1) also generates a hash value of the random number using its key, and compares this hash value to the hash value returned by reader 102(2); is the two hash values are identical, reader 102(1) assumes reader 102(2) has the same key. Reader 102(2) may then generate a random number and send it to reader 102(1). Reader 102(1) generates a hash value, using the common algorithm and its key, and returns this hash value to reader 102(2). Reader 102(2) also generates a hash value of the random number using its key, and compares this hash value to the returned hash value from reader 102(1). If these hash values are identical, reader 102(2) knows that reader 102(1) has the same key, and authentication is complete. Additional iterations of generating random numbers and hash values may occur to increase confidence of authenticity.
A session key may be generated, utilizing a common algorithm to hash one or more of the random numbers exchanged between two readers during authentication and their shared key. This session key may be used for message encryption and may be used to generate a cryptographic MAC, used to authenticate a message.
Using the shared key method of the above authentication method, only readers that possess the ‘key’ may be successfully authenticated; readers that are not configured with this key cannot join the reader network. If the key is to be changed periodically for security reasons, each reader of the reader network must be updated with a new key. An alternative to the above authentication method that does not utilize a shared key, may therefore be employed.

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization information between an identity provider and a service provider. Each reader (e.g., reader 102, FIG. 2) wishing to join a reader network (e.g., reader network 105) is required to provide a SAML assertion. The readers obtain this SAML assertion from a mutually agreed upon authentication source (e.g. a LDAP server, ideally the same central authoritative source used for discovery). One exemplary SAML assertion is shown below:



<saml:Assertion

	xmlns:saml=“urn:oasis:names:tc:SAML:1.0:assertion”
	MajorVersion=“1” MinorVersion=“1”
	AssertionID=“...”
	Issuer=“https://ldapserver/saml/”
	IssueInstant=“2006-03-16T17:05:37.795Z”>
	<saml:Conditions

	NotBefore=“2006-03-16T17:00:37.795Z”
	NotOnOrAfter=“2006-03-17T17:10:37.795Z”/>

<saml:AuthenticationStatement

	AuthenticationMethod=“urn:oasis:names:tc:SAML:1.0:am:password”
	AuthenticationInstant=“2006-03-16T17:05:17.706Z”>
	<saml:Subject>

<saml:NameIdentifier

	Format=“urn:oasis:names:tc:SAML:1.1:nameid-format:string”>
	Boyd's Reader

	</saml:NameIdentifier>
	<saml:SubjectConfirmation>

<saml:ConfirmationMethod>

urn:oasis:names:tc:SAML:1.0:cm:artifact

</saml:ConfirmationMethod>

</saml:SubjectConfirmation>

</saml:Subject>

</saml:AuthenticationStatement>

</saml:Assertion>

In one exemplary use of an SAML assertion, a joining reader (e.g., reader 102(1)) supplies a token (e.g. a password) to a central authentication source (e.g., a central authoritative source 107 within server 106) to prove its identity. If the token is matched by the central authentication source, the central authentication source generates and sends a SAML assertion to the joining reader. The joining reader may then supply this SAML assertion to other readers within the reader network to prove authentication. Readers receiving this SAML assertion may verify authenticity of the joining reader by sending the received SAML assertion to the central authentication source which replied to the verifying reader indicating its validity. As shown in the example above the SAML assertion may include an expiry time (e.g., see the entry NotOnOrAfter). Thus readers may be required to re-authenticate after expiration of their SAML assertions.
The SAML assertion only provide proof of authentication it does not secure messages during actual transport. A transport security mechanism, such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS), may be used for secure communication between readers.
Each reader within the reader network knows the location/address of each of its peers. If two readers that wish to communicate are directly connected, messages may be exchanged directly by the readers. If two readers that wish to communicate are not directly connected, routing of messages may be based upon an Ad-Hoc On-demand Distance Vector routing algorithm (known in the art).
Once a reader network is established, capability and version information (hardware and software) for each networked reader is exchanged. For example, network manager 360 within reader 102(1) may utilize algorithms of version/capability 410 to interrogate hardware and software of reader 102(1) to construct host version and capability structure 414. Information from host version and capability structure 414 may then be shared with other readers within the reader network such that overall capability of the reader network is known to coordinator 354, reader manager 356 and data manager 358 within each reader.
One exemplary capability exchange mechanism is based upon the firmware version of the readers. Each reader knows a priori which capabilities are available for each firmware version, and may assume that later firmware versions support everything that earlier firmware versions support. In one exemplary capability exchange using a XML based message system, a reader may send a capability message to a second reader, as shown below:
Reader to Reader:

<capabilities>

<firmware version=“1.0”/>

</capabilities>
This capability message may be extended by adding information about specific functions/items supported by the reader. For example:
Reader to Reader:

<capabilities>

<firmware version=“1.0”/>

<Regions>

<USA/>

<EU/>

</Regions>

<Bands>

<HF/>

</Bands>

<AirInterfaces>

<ISO15693/>

</AirInterfaces>

</capabilities>
In the above exemplary capability message, the sending reader indicates to its peers that it cannot handle UHF tags and therefore should not receive information relating to UHF tags (i.e., for tag caching).
In another example, a reader in a reader network reads one or more tags located upon a palette and determines that products associated these tags are “cold chain” products and require handling by readers with time stamping and security capabilities. Readers that do not have these capabilities are therefore instructed, for example through use of a control message, to stay quiet, allowing readers with time stamping and security capabilities to operate upon these tags without interference.
If a reader is determined to have an older firmware version (e.g., through analysis of its capability message by a receiving reader), then its peers may either a) send it a newer firmware version, b) continue using it with knowledge of its limitations, or c) not use the reader at all if the firmware/hardware version is such that it is unable to perform the required functionality.
The reader to reader protocol and functionality disclosed herein operates as a peer to peer network and does not utilize a ‘master’ or ‘arbiter’. However, as described above, a central authoritative source may be utilized to store the location/address of each reader within a directory.
Within a reader, network manager 360 may utilize algorithms of offline detection 412 to determine when one or more readers within the reader network disconnect. For example, a portable or handheld reader may periodically move out of range of a wireless network link, thereby disconnecting from the reader network.
If one or more readers disconnect (go offline) from the reader network, no detriment occurs to the network unless these readers were actively performing work. For example, a portable reader may frequently join and leave a reader network without affecting operation of other readers within the reader network. However, where a first reader operates to identify tags as they enter a warehouse, a second reader reads a manifest from the tags and a third reader writes information to the tags, operation of any of the first, second and third readers within the reader network may be critical because of the cooperation of these readers; incorrect operation may require immediate attention and an alarm may be raised.
Determination that a reader is offline may be made by its peers through lack of response to direct and indirect transactions with the reader. In a beaconing system where each RFID reader broadcasts a “heart beat” message every few seconds, a more deterministic assessment of RFID reader status may be known. For example, one or more readers within the reader network may determine, though use of timers, that a particular reader has stopped transmitting the ‘heart beat’ and is therefore disconnected from the reader network.
Upon determining that the reader as disconnected from the reader network, remaining readers may initiate a discovery process to attempt to ‘repair’ the reader network. If the disconnected reader results in orphaned readers (i.e., one or more readers unable to connect to the reader network without operation of the disconnected reader), an alarm may be raised requesting corrective action.
When a disconnected reader rejoins the reader network, a synchronization process may occur to ensure integrity of data within the reader network. For example, if readers within the reader network share tag cache information then the cache of the rejoining reader may be updated with any data captured after it disconnected and, if the rejoining reader continued to operated (e.g., reading tags) while disconnected, the new information within its cache may be distributed throughout the reader network.
In one exemplary embodiment, the tag cache within each reader is implemented using a Berkeley DB database and a Berkeley DB synchronization method is utilized to synchronize the cache; other proprietary methods (e.g. XML messages) may be used for cache synchronization without departing from the scope hereof.
In a desired embodiment, if a reader's persistence in the reader network is transient, the reader should not connect as an active routing ‘node’ within the network, but simply connect as a leaf node.
Coordination
In FIG. 6, coordinator 354 is illustratively shown with time service 502, operational service 504 and coordinated sampler 506. Coordinator 354 facilitates synchronization of timing and capability between a plurality of networked readers (e.g., readers 102, FIG. 2). In one example of operation, time service 502 of reader 102(3) interacts with time services 502 of readers 102(1) and 102(2) to ensure that clocks within each reader 102 are synchronized. For example, time service 502 may utilize network manager 360, FIG. 4, to effect communication with other networked readers 102. By synchronizing clocks, readers 102 that have overlapping operational fields can coordinate read and write operations as described below.
In one example of clock synchronization, each reader queries a Network Time Protocol (NTP) server, thereby obtaining an accurate time. In another example, where an NTP server is not available (or is not accessible by all readers), as readers join the reader network they are synchronized with the reader network time. If a first reader has access to an NTP server, it may synchronize its clock to that of the NTP server and, as other readers join the reader network, they synchronize with the reader network time obtained from other readers established within the reader network. Where an NTP server is not available at all, the reader network time may be based upon a clock of the first reader forming the reader network. Time synchronization within the reader network may be based upon methods used by NTP servers to ensure low skew between clocks of various readers in the reader network. Further, each reader within the reader network may periodically resynchronize to maintain clock accuracy.
Operational service 504, within coordinator 354, operates to coordinate operation within reader network 105. For example, readers 102 may be identified as a first group of readers with overlapping operational fields. A first set may include reader 102(2) which is selected for transmit only functionality, while a second set may include readers 102(1) and 102(3) for operation with receive only functionality. Such coordination may minimize reader noise and increase system 100 sensitivity for reading tags 108.
The operation (e.g. identifying, selecting, reading, writing, killing, etc.) to be performed by a reader may be determined a priori by a user of the reader or their agent (e.g. a systems integrator) during installation of the reader. Reader location often determines the operation selected for the reader. For example, where a first reader is located at an entrance to a warehouse, its operation may be defined as identifying tags attached to products that enter the warehouse; the first reader thus searches for tag UIDs as products enter the warehouse. A second reader may be located at the start of a conveyor belt transporting products within the warehouse and its operation may be defined as reading manifests (e.g., containing information relating to the product such as manufacturer, date made, distribution chain to date, etc.) from the tags previously identified by the first reader. The second reader may also perform writes to the RFID tags. A third reader may be located at the end of the conveyor belt and its operation defined as writing additional and/or updated information (e.g., the operation performed to the product within the warehouse and/or additional distribution information) to the manifest stored within the tags read by the second reader. The third reader may also operate to read and verify-data written to the RFID tags by the second reader. See also the example of FIG. 9 and associated description.
FIG. 7 is a flowchart illustrating one method 530 for coordinating a plurality of readers to minimize reader noise and increase reader sensitivity. In step 532, groups of readers where reader to reader transmission interference occurs within readers of the group are determined. In one example of step 532, an installer of the reader system, identifies one or more groups of readers that are proximate, having overlapping operational fields, and may therefore interfere with one another during simultaneous transmissions. Using the example of FIG. 2, if readers 102(1), 102(2) and 102(3) have overlapping operational fields, a group including readers 102(1), 102(2) and 102(3) is identified in step 532.
In step 534, a first set consisting of one reader from each group determined in step 532 is selected. In one example of step 534, reader 102(2) is selected for the first set. In step 536, a second set including remaining readers of each group not in the first set is selected. In one example of step 536, readers 102(1) and 102(3) are selected for the second set. In step 538, the first set of readers is coordinated to operate in transmit only mode. In one example of step 538, reader 102(2) is coordinated to operate in transmit only mode. In step 540, the second set of readers is coordinated to operate in a receive only mode. In one example of step 540, readers 102(1) and 102(3) are coordinated to operate in the receive only mode. In step 542, the first ands second set of readers are synchronized such that a receive period of the second set coincides with the transmit period of the first set. In one example of step 542, the read period of readers 102(1) and 102(3) is synchronized with the transmit period of reader 102(2).
In one example, where a number of readers are in close proximity to one another such that simultaneous transmissions causes interference and reduces sensitivity of one or more of the readers, coordination of the readers to operate in a synchronized manner (i.e., coordinating when each turns its radio transmitter on and off) may eliminate cross reader interference. In yet another example, each reader may select a different frequency slot for operation thereby also eliminating cross reader interference.
In one embodiment, each reader may automatically determine its proximity to one or more other readers. For example, the reader may sense signal strengths from other readers within the reader network. Theses readers may then cooperate to select a desired operational mode to reduce reader interference.
Each reader may contain the following information relating to its physical location, illustratively shown as a data structure:

struct _reader {

char* name;

char* location;

...

};

The name and location strings may, for example, have meaning to a user selecting operation of each reader. Coordinated Sampler 506 utilizes synchronized clocks of readers within the reader network to distribute read and write activity across the reader network, thereby optimizing coverage within a specified sample period and minimizing power consumption. Coordinated sampler 506 may also synchronize sampling of one or more peripherals connected to one or more readers within the reader network; the one or more readers may, for example, include hardware for sensing temperature, battery voltage, humidity, etc.
In one example, a plurality of readers may operate as an assembly line. A first reader reads the ID, a second reader reads information from the tags, and a third reader writes information to the tags. In another example, a plurality of readers operate as a pipeline to select, read and write to tags. Each of the readers is coordinated to perform each of select, read and write tasks on separate tags. These operations on the tags may also be performed out of order once UIDs of the tags are known and distributed to the other readers within the reader network. In another example, invalid tags may be flagged within each reader to be ignored for select, read and write operations, thereby protecting against rogue tags introduced into the tag population. In another example, a plurality of readers may be used to determine (e.g., by triangulation) the location of one or more tags.
Management
FIG. 8 shows reader manager 356 of FIG. 4 illustrating functionality of code update 602, script update 604 and proxy server 606. Reader manager 356 may utilize functionality of code update 602 to request a more recent code or configuration file update from another reader and/or from a server (e.g., server 106, FIG. 2). In one example of operation, reader 102(1) interacts with reader 102(2) and host version and capability structure 414 of each reader is exchanged. Upon analysis of host version and capability structure 414 received from reader 102(2), reader manager 356 within reader 102(1) determines that reader 102(2) is operating with a later version of software than its host. Reader manager 356 thus utilizes functionality of code update 602 to load updated software from reader 102(2). In one example, the updated software is transferred within the CDATA section of a XML message. In another example, the updated software is transferred as a FTP-like binary transfer.
In one example of operation, reader 102(1) may load the updated software while continuing tag operations. For example, reader 102(1) may perform a read using the earlier version of software and then use the updated software on a subsequent read. Alternatively, reader 102(1) may cease all tag operations while the updated software is being transferred and re-boot prior to resuming tag operations.
An optimal time for identifying a need for, and loading, updated software is when a reader joins the reader network. Alternatively, a predetermined “quiet” time (e.g., after business hours) may be selected for identifying readers with older software and for loading updated software to these readers if necessary.
Ideally, each reader keeps a “golden” copy of its firmware within a local non-volatile storage, such that, if anything should go wrong during an update, the reader simply reverts to its golden copy. For example, a watchdog timer/supervisor may be utilized to resets the reader if the updated software does not operate correctly and the ‘boot-loader’ would revert to operation with the golden copy of the software, rather than the updated software, thereby restoring original functionality of the reader.
In particular, after loading a firmware update, the reader may reboot to begin using the new firmware. Initially it would perform a BIST/POST to ensure everything is in working order. The reader network learns if the updated software is operational when the reader rejoins the reader network and sends its capabilities message containing the firmware version of the updated software. Optionally, if the updated software failed to run, the reader, operating from its golden copy, would issue an alert to the user requesting further investigation.
Scripts are utilized within readers to perform certain business logic activities. Each reader may, for example, utilize Python Scripts. Reader manager 356 may utilize functionality of script update 604 to transfer scripts to or from itself from or to other readers within the reader network. For example, a user may create Python scripts to implement various business logic processes. The need for an-update would be initiated by the user through management messages.
Referring again to the example of FIG. 2, tag information received by reader 102(2) first passes to reader 102(3) and then to server 106. In particular, reader manager 356 utilizes functionality of proxy server 606 within reader 102(3) to relay information between reader 102(2) and server 106.
Since each reader has a unique identifier, messages may be addressed to specific readers using their name or another unique identifier generated by the protocol (e.g. a hash of the reader name and its ‘P address and/or the order in which it joined the network).
Server 106 detects available readers by issuing a management message:
Server to network:

<queryPeers/>

This causes each reader connected to the reader network to respond to the server with its list of known peers:
Each individual reader to server:

<peer name=“Boyd's reader”>

<peers>

<peer name=“Ben's Reader”/>

<peer name=“Intern Reader”/>

</peers>

</peer>
Reader manager 356 may also implement a power management policy within the reader. This power management policy may be defined by a user or installer of the reader. In one example, when a reader joins a reader network, reader manager 356 within the reader may adopt power management policies employed by the reader network.
Data Manager
FIG. 9 shows data manager 358 of FIG. 4 and illustrates functionality of tag data 702 and search and locate 704. In one example of operation, data manager 358 utilizes functionality of tag data 702 to share tag cache entries with one or more other networked readers. In another example of operation, data manager 358 utilizes functionality of tag data 702 to share tag cache data with one or more other networked readers. Tag data 702 operates to maintain synchronicity of the tag cache within the reader with tag caches of other readers within the reader network.
Further details of tag cache operation may be found in U.S. patent application Ser. No. ______, titled “System and Method for Implementing Virtual RFID Tags”. In general, a tag cache is stored locally on each reader. A typical tag cache entry is illustratively shown in the following data structure:

struct _tagData_t {

tagData_t* next;

uint16_t start;

uint8_t data[32];

uint32_t dirty;

uint32_t inuse;

};

struct _tag_t {

air_interface_t airInterface;

char* uid;

uint8_t uidLength;

time_t firstSeen;

time_t lastSeen;

uint32_t firstSeenBy;

uint32_t lastSeenBy;

tagData_t* data;

};
If a reader loses contact with the reader network, it may continue operation on any tags that enter its operational field, storing the tag information within the tag cache. Once the reader rejoins the reader network, any accumulated information may be disseminated to other readers and the server.
If tags enter and exit the reader's operational field rapidly (e.g., they are located upon a fast moving conveyer), there may be insufficient time to query an upstream source (e.g., a server) for desired operations upon the tag. The tag cache allows the reader to queue operations for later consumption by the server.
In one example of operation, data manager 358 utilizes functionality of search and locate 704 to search for a specific value (e.g., an tag UID or data value) within a tag cache and, if located, returns its reader ID and other related information of the located value to a requesting device (e.g., another reader, a server or a user). In particular, server 106, for example, issues a message, indicating that it requires information relating to a specific tag ID, to a reader network. In another example, server 106 issues a search message to reader 102(3). Data manager 358, within reader 102(3), utilizes functionality of search and locate 704 to search local tag cache information for the specific tag ID and may also relay the search messages to reader 102(2) thereby furthering the search through the reader network. Thus, functionality of search and locate 704 enables a reader, or a server, to find a specific value across all networked readers and identify which reader last interacted with a specific tag.
Search requests may be broadcast to every reader connected to the reader network. If a user has prior knowledge of the readers, the search may be targeted for a specific reader or group of readers. In general, the tag cache (see the exemplary _tag_t and _tagData_t structures above) within the targeted readers would be searched. The following examples illustrate some of the types of data that can be the subject of a search.
Searching for specific tags or tag types:
Search for all ISO15693 type RFID tags:

<search>

<byByAirInterface type=“ISO15693”/>

</search>
Search for all tags whose EPC begins with 1234:

<search>

<byEPCUID regex=“{circumflex over ( )}1234”/>

</search>
Searching for specific locations or time periods:
Search for all tags seen today:

<search>

<byTime start=“0:00T03/13/2006”

end=“23:59T03/13/2006”/>

</search>
Search for all tags that have entered the shipping area:

<search>

<byReaderGroup name=“shipping”/>

</search>
Search for specific data contained on a tag:
Search for tags that contain the phrase “Skyetek”:

<search>

<byData regex=“Skyetek”/>

</search>
Tags whose fifth byte is 0xAF

<search>

<byData start=“5” end=“5” regex=“OxAF”/>

</search>
The following message may represent an exemplary search return:

<searchResult reader=“Boyd's Reader”>

<tag type=“ISO15693”

uid=“e07000002312”

lastSeen=“12:31:41T03/13/2006”/>

<tag type=“ISO15693”

uid=“e04000002848”

lastSeen=“1:02:45T03/13/2006”/>

</searchResult>
Where a search targets multiple readers, each targeted reader may return results for the search. Where multiple results are received in response to a search, it is the responsibility of an upstream entity (e.g. a user or a server) to decide which result is more relevant (e.g., based upon ‘lastSeen’ or ‘reader’ or some other metric).
If a search locates no pertinent tags then the reader may return an empty result set within a response message, as follow:

<searchResult/>
It is the burden of the search requester to determine when to timeout a search. For example, a requester may assume that 5 seconds after the last ‘searchResult’ is received, no further result may be expected.
A user may also issue search requests, using a server, for example. In one example, reader 102(3) receives a message from a user of server 106 requesting data from the tag with a unique identifier (UID) of e0070001020304:
User to reader

<getTagData uid=“e0070001020304”/>
RFID reader 102(3) then sends the requested data back to server 106:
Reader to User

<tagData uid=“e0070001020304”>

<![CDATA[

00010203040507AB

]]>

</tagData>
FIG. 10 is a block diagram illustrating one exemplary ‘swarm’ 800 of three readers, 802, 804 and 806 within a reader network 822. In particular, reader 802 is positioned at a location ‘A’; reader 804 is positioned at a location ‘B’ and reader 806 is positioned at a location ‘C’. For example, location A may represent an entrance to a warehouse, location B may represent at a start of a conveyor belt 811 within the warehouse and location C may represent an end of conveyor belt 811, where conveyed packages are transferred to storage within the warehouse.
FIG. 10 also shows a palette 810 upon which is a package 808 containing a plurality of tags 812, 814, 816, 818 and 820, where each tag may identify a product within package 808, for example. In particular, package 808 is shown moving through locations A, B and C.
Reader 802 reads identification information (e.g., UIDs) of tags 812, 814, 816, 818 and 820, storing them as data 828 within its tag cache, for example. Reader 802 sends data 828 (i.e., UIDs of tags 812, 814, 816, 818 and 820) to readers 804 and 806 through reader network 822. Data 828 is illustratively shown in dashed outline within readers 804 and 806. Thus, readers 804 and 806 have identification information of tags 812, 814, 816, 818 and 820 before palette 810 arrives in locations B and C.
In one example, where tag 812 contains additional information regarding prior transportation of palette 810, reader 804 may read this information when palette 810 is in location B, store it as data 830 within its tag cache and send data 830 to reader 806 (data 830 is illustratively shown in dashed outline within reader 806). Reader 806 may then update data 830 with information of handling within the warehouse and conveyor 811 and write data 830 back to tag 812 when palette 810 is within location C. In particular, reader 802 may ‘select’ tag 812 prior to palette 810 leaving location A such that upon arriving in location B, reader 804 may read data from tag 812 without delay. Such coordinated operation is particularly important when palette 810 transits rapidly through each location A, B and C.
In another example, reader 802 (or another authority such as the user or a server) may determine that tag 820 is bogus (e.g., of no interest). Reader 802 may therefore notify readers 804 and 806 that tag 820 should be ignored, thereby preventing further undesired interaction with tag 820.
Since reader 802 updates readers 804 and 806 with data 828 (i.e., UIDs of tags 812, 814, 816, 818 and 820), reader 804 and 806 do not search to identify, a time consuming process, other tags within palette 810. Again, this is significant where palette 810 transitions rapidly through locations A, B and C. The use of networked readers effectively extends the area of interaction with tags of palette 810 through multiple locations.
Services Provided by the Reader to Reader Protocol
The reader to reader protocol may be an XML based protocol over HTTP/HTTPS based and may be functionally equivalent to a binary protocol over TCP/UDP. However, other protocols and communication medium may be used without departing from the scope hereof.
The reader to reader protocol functionality may be summarized as follows:
Reader management allows a reader to be interrogated as to its status (e.g., what the reader is doing, firmware/hardware version, script versions etc.). Firmware and/or scripts may be updated. Readers within the reader network may coordinate and synchronize their tag caches and also synchronize their operation to achieve an eventing/swarming mode (e.g., where a first reader selects a tag and then a second reader writes to the tag) of operation. Transmitted radio power levels and operational periods may be coordinated and/or synchronized between one or more readers to reduce or eliminate radio interference when density of readers in one area is high (i.e., when readers interfere with one another during reading and writing of tags).
Tag caches of readers within the reader network may be searched to locate tags based upon meta data (e.g. time, reader location), tags whose values have changed within a defined period of time, data stored within tags (e.g. ‘Hello World’ at 0x0f) and other tag attributes (e.g. tag types such as ISO15693).
The reader network may be queried to determine status of the network, RFID readers and their relationship to one another. Messages may be routed through the reader network directly and indirectly. Readers may join the reader network through a discovery process, during which the joining reader will become synchronization (in both time and with tag cache data). Communication within the reader network is secure, messages may be encrypted, for example, and readers may require authentication and/or authorization before being allowed to join the reader network.
FIG. 11 is a flowchart illustrating one exemplary method 1300 for coordinating a plurality readers to minimize reader noise and increase reader sensitivity. In step 1302, a first set of one or more of the plurality of readers is coordinated to operate in a transmit only mode. In one example of step 1302, reader 102(2), FIG. 2, is coordinated to operate in a transmit only more. In step 1304, a second set of one or more of the plurality of readers is coordinated to operate in receive only mode. In one example of step 1304, readers 102(1) and 102(3) are coordinated to operate in-a receive only mode. In step 1306, the first and second set of readers are synchronized such that a receive period of the second set of readers coincides with a transmit period of the first set of readers. In one example of step 1306, readers 102(1), 102(2) and 102(3) are synchronized such that a receive period of readers 102(1) and 102(3) coincides with a transmit period of reader 102(2).
FIG. 12 is a flowchart illustrating a method 1400 for distributing activity across a network of readers. In step 1402, a first set of one or more reader at a first location is configured to identify a plurality of tags to determine identification information. In one example of step 1402, reader 802, FIG. 10, at location A, identifies tags 812, 814, 816, 818 and 820. In step 1404, a second set of one or more readers at a second location is configured to perform at least one additional operation upon at least one of the plurality of tags, the additional operation comprising interaction by the second set with one or more of the plurality of-tags. In one example of step 1404, reader 804 interacts with tag 812. In step 1406, the second set utilizes the identification information, received from at least one of the readers of the first set, to interact with one or more of the tags without searching to identify the tags at the second location. In one example of step 1406, reader 804 utilizes the UID of tag 812 received from reader 802 to select and read tag 812.
FIG. 13 is a flowchart illustrating a method 1500 for providing connectivity between a server and at least one of a plurality of readers. In step 1502, the plurality of readers is communicatively coupled to create a reader network wherein not all of the readers are directly connected to the server. In one example of step 1502, reader network 105, FIG. 2, is created by communicatively coupling readers 102(1), 102(2) and 102(3), wherein readers 102(1) and 102(2) are not connected to the server. In step 1504, at least one of the readers is connected to the server to create a proxy server, such that the proxy server exchanges information between the server and at least one of the readers not connected to the server. In one example of step 1504, reader 102(3) connects to serve 106 and forms a proxy server for exchanging information between server 106 and reader 102(2).
Changes may be made in the above methods and systems without departing from the scope hereof. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall there between.

Claims

1. A method for coordinating a plurality of radio frequency identification (RFID) readers to minimize reader noise and increase reader sensitivity, comprising:

coordinating a first set of one or more of the plurality of readers to operate in a transmit only mode; and

coordinating a second set of one or more of the plurality of readers to operate in receive only mode;

wherein the first and second set are synchronized such that a receive period of the second set coincides with a transmit period of the first set.

2. The method of claim 1, wherein the readers are connected to form a reader network.

3. The method of claim 1, wherein operational fields of each reader of the first set overlap at least one operational field of readers of the second set.

4. The method of claim 1, wherein readers within the first set do not interfere with one another during transmission.

5. The method of claim 1, wherein operational fields of readers within the first set do not overlap.

6. The method of claim 1, further comprising coordinating a third set of one or more of the plurality of readers to be non-operational.

7. A method for distributing activity across a network of radio frequency identification (RFID) readers, comprising:

configuring a first set of one or more readers at a first location to identify a plurality of RFID tags; and

configuring a second set of one or more readers at a second location to interact with one or more of the tags using identification information received from at least one of the readers of the first set without searching to identify the tags at the second location.

8. The method of claim 7, wherein an undesirable tag identified by the first set is flagged such that the undesirable tag is ignored by the second set.

9. The method of claim 7, wherein the tags pass through the first location prior to passing through the second location.

10. The method of claim 7, further comprising:

writing data to one or more of the tags using one or more of the readers of the first set; and

verifying the data written to the one or more tags using one or more readers of the second set using the identification information and data received from at least one reader of the first set.

11. A method for updating firmware of a first radio frequency identification (RFID) reader connected to an RFID reader network having one or more other readers, comprising:

determining that a version of firmware within the first reader is older than a version of firmware within one or more other readers; and

transferring a copy of the firmware within the one or more other readers to the first reader.

12. The method of claim 11, wherein the step of determining occurs within the first reader.

13. The method of claim 1 1, wherein the step of determining occurs within one or more of the other readers.

14. The method of claim 11, including initiating operation of the transferred firmware within the first reader, wherein the step of initiating reboots the first reader.

15. The method of claim 11, including initiating operation of the transferred firmware within the first reader, wherein the step of initiating does not reboot the first reader.

16. A method for providing connectivity between a server and at least one of a plurality of radio frequency identification (RFID) readers, comprising:

communicatively coupling the plurality of readers to create an RFID reader network wherein not all of the readers are directly connected to the server; and

connecting at least one of the readers to the server to create a proxy server, wherein the proxy server exchanges information between the server and at least one of the readers not directly connected to the server.

17. The method of claim 16, each of the readers utilizing an ad-hoc on-demand distance vector routing algorithm to route messages to other readers not directly connected to the reader.

18. A method for determining a scope of operation of one or more radio frequency identification (RFID) readers within an RFID reader network, comprising:

determining one or more RFID tag types of a plurality of tags; and

determining the scope of operation of each reader based upon its ability to handle the identified tag types;

wherein any reader unable to handle a specific tag type is configured to not interact with any tags of the specific tag type.

19. The method of claim 18, wherein any reader unable to handle all of the tag types is disabled.

20. The method of claim 18, wherein readers unable to handle the specific tag type do not receive information related to the specific tag type from other readers.

21. The method of claim 18, wherein any reader unable to handle data of a specific tag is configured to not interact with the specific tag.

22. A method for coordinating a plurality of radio frequency identification (RFID) readers to minimize reader noise and increase reader sensitivity, comprising:

determining one or more groups of readers where operational fields of readers in the group overlap;

selecting a first set consisting of one reader from each group;

selecting a second set consisting of readers of each group not in the first set;

coordinating the first set to operate in a transmit only mode;

coordinating the second set to operate in a receive only mode;

synchronizing the first and second set of readers such that a receive period of the second set coincides with a transmit period of the first set.

23. The method of claim 22, wherein the steps of determining, selecting, coordinating and synchronizing are performed automatically by the readers.

24. The method of claim 22, wherein the readers are configured as a reader network.

25. The method of claim 22, wherein operational fields of each reader of the first set overlap at least one operational field of readers of the second set.

26. The method of claim 22, wherein readers within the first set do not interfere with one another during transmission.

27. The method of claim 22, wherein operational fields of readers within the first set do not overlap.

28. A method for searching for information stored within a radio frequency identification (RFID) reader network of RFID readers, each including a tag cache capable of storing the information, comprising:

generating a search message containing search criteria;

sending the search message to a set of readers within the reader network, each reader within the set searching its tag cache to identify information matching the search criteria;

receiving a response containing the identified information from any reader within the set having the identified information in its tag cache.

29. The method of claim 28, wherein the step of generating is performed within one reader of the reader network.

30. The method of claim 28, wherein the step of generating is performed within a server connected to the reader network.

31. A method for creating a network of radio frequency identification (RFID) readers comprising:

initially including a first RFID reader in the network;

connecting additional RFID readers to the network, wherein each of the additional readers is connected to at least another one of the additional readers by a peer to peer communication link, and wherein at least one of the additional readers is also connected to the first reader by a peer to peer communication link.

32. The method of claim 31, further comprising updating firmware of one or more of the readers within the reader network by transferring updated firmware from one or more other readers within the network.

33. The method of claim 31, wherein the firmware of the one or more additional readers is updated by transferring updated firmware from a server connected to the reader network.

34. A system for interacting with one or more radio frequency identification (RFID) tags, comprising:

a first set of one or more RFID readers at a first location, the first set operating to identify at least one of the tags; and

a second set of one or more readers at a second location, the second set operating to interact with one or more tags identified by the first set;

wherein the second set uses identification information received from at least one of the readers of the first set and without searching to identify the tags at the second location.

35. The system of claim 34, wherein the readers of the first and second sets form a reader network.

36. The system of claim 34, wherein an undesirable tag identified by the first set is flagged such that the undesirable tag is ignored by the second set.

37. The system of claim 34, wherein the tags pass through the first location prior to passing through the second location.

38. A system for reading radio frequency identification (RFID) tags, comprising:.

a server;

at least one RFID reader not directly coupled to the server; and

at least one RFID reader directly coupled to the server and operating as a proxy server;

wherein the readers are couple to create an RFID reader network such that the proxy server exchanges information between the server and the at least one reader not directly connected to the server.

39. A system for interacting with one or more radio frequency identification (RFID) tags, comprising:

a first set of one or more RFID readers at a first location, the first set operating to identify at least one of the tags;

a second set of one or more readers at a second location, the second set operating to interact with one or more tags identified by the first set; and

a server connected to at least one but not all of the readers;

wherein the second set uses identification information received from at least one of the readers of the first set and without searching to identify the tags at the second location; and

wherein the readers couple to create an RFID reader network-wherein the proxy server exchanges information between the server and the at least one reader not directly connected to the server.